Our read-only FR5 dashboard keeps a believable mode on screen when the replacement SDK reports failure. The wrapper takes one field from the new response container and never checks whether that field is valid. I need to change the interpretation without making old saved captures unreadable.
Separate the interpretation for each supported response contract. Preserve the raw captures with their source version. A parser for the new container should establish request success and field validity before returning a usable mode, rather than relying on a value that happens to look familiar.
The captures already include the SDK version. The live wrapper does not use it to choose a parser; it guesses from the shape. A failed reply can satisfy that guess.
Then keep unsupported combinations visibly unsupported. Guessing is exactly what gave the failed response a respectable-looking mode in the first place
We want that for diagnosis, Robin. But it must not occupy the current-mode field. The present design puts the last valid value and its time underneath an unavailable message.
I like the separate place. Does the unavailable wording say the read failed, rather than implying the controller itself has definitely stopped responding?
The display can distinguish a reported request failure, a timeout and a reply it cannot interpret, where the available evidence supports those distinctions. It should not manufacture a machine state from any of them.
Lin, yes, but don't put the whole parser diagnosis in the main status label. People need the immediate meaning first, with the reason available underneath
That wording is a reasonable candidate for a walkthrough. The diagnostic detail can remain separate; I was describing the information to retain, not prescribing a long label.
The two explicit parsers now pass our saved success and reported-failure examples. The live configuration names its supported SDK version. We still need malformed containers and timeout cases before I would call the wrapper ready.
Include an old value that looks perfectly ordinary in the walkthrough. A ridiculous value won't tell you whether someone mistakes a stale reading for the current one.
Can the tutor tell a saved capture from the live view too? You mentioned keeping both readable, and that is another place a valid old mode can look current
The saved view is labelled with its capture time and connection identity. I have added switching between that and the live view to the walkthrough. The current failure is not being hidden by a successful old capture.