The replacement SDK returns request status together with the mode data, and our wrapper is displaying the request status as a mode whenever it finds a number; I have both package identities and captured replies, but I am unsure whether to keep both formats in one adapter
One training laptop still uses it, Robin, so we need two known combinations during the changeover; the new package reply starts with a request status that happens to resemble a valid old mode value
Keep separate parsing functions if that makes the contracts obvious, then return the same application-level result to the display; a failed request needs an unavailable reading, not a guessed controller mode.
What does the screen actually do when the reply is empty, Rebecca? The numeric coincidence is awkward, but I would also want to see the less convincing failures.
It retains the previous mode without showing its age, Anika; the wrapper treats an empty reply differently from a reply carrying an error, so we have two misleading failure paths
I prefer retaining the last value with its time for a diagnostic screen, provided unavailable is unmistakable; ask the people using this screen which information they need during a failed read.
Ravi, I'd want them to try it with a stopped update, not just choose the nicer mock-up; a small old-value note can disappear beside a large confident mode label.
Maintenance chose unavailable as the main reading and a smaller last-observed value with its time; they found the original mock-up too easy to read as a current mode, which is exactly Anika's concern
The revised adapter refuses that combination instead of trying the other parser; tests cover both known formats, request errors, missing mode data, empty responses and the package mismatch
Include a successful read after failure, so the unavailable state clears only when a new valid value really arrives; otherwise a defensive fix can leave the display permanently pessimistic.
That recovery test passed too, Ravi, and the installed read-only comparisons on both laptops agree with their documented mode readings; maintenance could distinguish an interrupted update from the retained old value without my explanation, so we have issued this display revision