The replacement SDK environment returns a nonempty container on a failed status query, and our UR5e dashboard treats that container as true; the controller has not become available merely because the error arrived neatly wrapped.
Have the adapter validate the documented success indication and response structure before interpreting the status field, with explicit handling for failure, missing data and unsupported formats; generic truthiness is not a status interpretation method.
The raw failed example now produces unavailable rather than a current status, while the previous observation retains its own timestamp; supported successful responses still need checking against the documented variants.
Does the rest of the application receive the same explicit failure state as the display? I would check the stored and published result too, since fixing the colour alone could leave another consumer using the old interpretation.