Yes. Maintainer reproduced it from a saved response. The wrapper reads the first numeric field before checking the documented success indication.

That gives you a small failing test. Check success first, then extract the required mode field using the selected version's contract. Reject unexpected shapes

What happens to the previous mode when the current request fails? The person at the bench needs to distinguish an old observation from a new one.

At present the false number replaces it. The proposed display will show current mode unavailable, with a separately labelled last successful mode and observation time.

Would the last successful mode actually help the person using this screen? I can see it helping maintenance, but I would not want it sitting there looking like an instruction about the present machine state.

Try the proposed screen with the covering person before deciding that.

And keep the diagnostic history even if you choose not to show the old mode on the main tile. Display clarity needn't mean throwing away the useful record

We tried it. Covering technician read the old mode as current despite the small label, so the main tile now shows unavailable only. Last successful observation is in the labelled history view.

Can they reach that history from the unavailable state without changing screens through several menus?

Yes, one history control beside the state. It opens the previous observations with their times, not a second current-mode display.

The decoder tests now cover both supported versions, errors, absent mode, malformed containers and a later valid reply. The deployed screen passed those same saved sequences with the maintainer.

Thanks for testing the old-mode display with someone else. I wasn't sure it would confuse them, but that result makes the simpler main tile a sensible choice.

Did the exported history retain the unavailable readings too?