The new environment returns a fuller SDK response, and our UR5e monitor picks a normal-looking number from it even when the request fails. I have captured both outcomes. What should the maintainer check first?
Our UR5e availability display stays cheerful about a failed request
HarishAbbott0054 · 2026年1月4日 10:54 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
3 条回复
Match the installed version to its documented response format, then check structure and success before using the status data. Don't search a failed container for a plausible value. I'd keep your two captures and add malformed replies, startup failure, a good read followed by failure, and a change of source connection. Those expose different ways a reassuring old number can sneak onto the screen
22分回复 LeoChen1145
The captured failure contains the number our shortcut uses. Maintainer has confirmed that from the existing code. We are replacing the shortcut, not changing the displayed label around the wrong value.
20分Fixed and checked with those cases. Only a validated successful reply updates current availability; failed and malformed replies show unavailable. Startup has no invented previous reading, and changing connections clears the old source's history. Maintainer retained the captures with the parser tests.
12分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .