Failed FR5 reply displayed as a valid status

Display only, Kai. The wrapper takes the first value without checking request success.

Luca, I would want the supported-version list in the handover either way. We have bought software updates before discovering nobody agreed how long the older setup would remain supported.

Both versions for now, Luca. Different teaching laptops. Maintainer has examples from each.

Use version-specific interpretation behind one clear display result. Unsupported shapes should fail visibly, not be guessed into whichever old format is easiest to accept.

Jasper, thanks, that is the ownership question I was circling. Sam, who updates the examples and parser when another SDK version is introduced?

Course software maintainer. Added supported versions and the update check to the handover draft.

Include a failed request following a successful reading, so the screen does not leave the old value looking current when the new parser correctly reports failure.

And failure before the first successful read. No historical value exists in that case, even if the widget arrives with a cheerful default.

Both cases added. Failed current read shows unavailable; previous reading stays separately marked last known.

Does the previous reading retain its time and source laptop or connection identity? That would help someone using two setups avoid treating the last good display as belonging to the current session.

Also have a student read those states, Sam. Ask what is known now, not whether the revised screen looks nice.

Time and connection identity retained, Jasper. Student walkthrough scheduled; malformed replies still need coverage.

Include missing required data and wrong field types in those malformed cases. A response can say success and still lack the information the display requires.

Did the walkthrough distinguish unavailable now from that last-known reading? Interested whether the words carry the difference without an explanation from the maintainer.