Yes. Same failure response produces a new displayed status every time, complete with a current timestamp. The old scalar test never exercised this container.

Keep that failing test. It's doing useful work now.

Does the wrapper know the configured SDK version, or is it trying to recognise the format from whatever happens to come back? I wouldn't buy clever guessing when you already know what you installed.

Configured version is available. Developer had one generic decoder for both, which was apparently simpler until it wasn't.

Make unsupported versions fail visibly too, rather than sending them through whichever decoder looks closest.

And define the display for a failed read after a successful one. Removing the new false value can still leave the last good value looking current.

Test build now uses two explicit paths. Saved success and error responses decode as intended for both versions. A failed read removes the current value and labels the previous one last successful reading.

With its old observation time?

Yes, the observation time stays attached to that last successful reading. Failure time is separate diagnostic information.

What if the response says success but the required value is missing? That's still no useful reading, even though the outer bit sounds encouraging.

That case exposed another fallback to zero. Removed it. Missing required value now shows unavailable and retains the malformed response detail for maintenance.

Try a legitimate zero value as well; missing data and a real zero must not get the same treatment.

AnnaAbbott's case should check the exact displayed value and its availability state, not merely that the screen didn't throw an exception.

Both tests pass now: valid zero is displayed as current, absent value is unavailable. Unknown container and unsupported-version cases also refuse to invent a status.

And a good reply after the bad one?

Restores the current reading and new observation time. We ran that sequence without reopening the screen between replies.

Have the trainer read those states without the developer explaining them. The data can be right while the words still sound like the robot has rejected the coupon.

Trainer tried it with the saved sequences and correctly distinguished unavailable controller data from an inspection outcome. Maintainer checked the installed dashboard build against the same cases. The false-status fault is closed.

Thanks for checking the missing-value path too. That was a separate way to get a plausible wrong number, and it now has a test of its own.