Our dashboard for controller status polling on Universal Robots UR5e expected a status value from the old SDK.
The replacement environment returns a container with extra information, and our screen now shows a plausible status even when a request fails.
This is in a workshop status-monitoring station, with an inspection coupon as a reference.
I'm trying to fix how we interpret the answer.
Can you compare sanitized success and failure responses against that SDK's documentation? The useful detail is which field your wrapper treats as status.
@IsabelBrooks0822 Found it. We're checking whether the outer container is nonempty. Our error response passes without containing a valid status. Brilliant.
Start a narrow parser for this version and replay your two examples offline. Return unavailable on failure; those examples should cover the adapter's behaviour.
@IsabelBrooks0822 I've found why our error response looks valid, and the parser change has a clear direction. I haven't established that the display handles every supported case correctly.