Our FR5 dashboard shows a mode after the status read fails

Maintainer already found it treats the returned container as a success flag.

Is the displayed mode taken from that failed reply, or retained from an earlier successful one?

Either way, show people that the read failed. Keeping the last mode can be useful, but not when it sits there pretending to be fresh news.

Earlier successful value. Failed reply has no usable mode.

Then test the good-to-failed transition as well as each response separately, so the display cannot retain current status after the failed read.

Added to maintainer's test list. Current dashboard isn't being used to decide cell operation.

Our wrapper once guessed a mode from a missing field. Include malformed replies too, with no fallback to a plausible operational state.

Missing fields included. Unexpected shapes still need a case.

I would include startup before any valid reading, then a failed read after success and an unexpected response shape, checking that the operator can distinguish unavailable status from an actual reported mode in each case.

Who owns updating those examples when the SDK changes again? Otherwise the wrapper and the tests can grow old together while agreeing beautifully.

Software maintainer owns them with the version record. Test version marks stale and unavailable explicitly. Controller comparison remains outstanding.