Our read-only UR5e training dashboard expected the old SDK's direct mode value. The replacement returns a container, and failed requests now get displayed as believable readings. Reference bracket in the cell, but this is a response-interpretation problem. How should I support the documented formats without guessing from the values?
Keep raw successful and unsuccessful examples from each environment with their version details. The wrapper needs to establish success before extracting and validating the mode payload. A plausible number in a failed response is not a second opinion on the controller state.
Our wrapper currently picks out a value without checking the response outcome. I'll isolate that interpretation and give the display a valid reading or an explicit unavailable result, rather than let it inspect either container itself.
And record which formats the adapter supports. A catch-all branch that tries to interpret unknown versions would recreate the original problem with a more reassuring name. Unsupported and malformed responses should be visible diagnostic outcomes, not silently converted to a familiar mode.
The saved-response tests now reject failed and malformed containers, and the screen clears its current mode after failure. I still need to check the supported read in the installed environment and the case where fresh responses stop arriving. The software fix is not a complete connection test.