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?
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
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.
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.