Adapter returns unavailable correctly for the saved failure. The display handler catches that and substitutes its configured default status. So the false reading comes after decoding, not from a mysterious numeric field

Is that default also shown at startup before the first successful read?

That would be worth separating from retained history too, Ada, because a default has never been observed while a last valid value was observed at some earlier time

Yes, startup uses it too. We've removed that fallback. Initial state is no observation; failures show current information unavailable, with any earlier reading labelled as history rather than substituted as the answer

Have you tested good data followed by malformed data through the complete display path?

And use the installed-version success and failure examples rather than making both environments obey one invented response shape; the shared display meaning can stay consistent while each supported adapter interprets its own contract

Both supported adapters and the normal display now pass startup, good-then-failed, good-then-malformed and reopening with history. The read-only controller comparison also completed. No fabricated default reading returns after any of those cases

That answers the actual defect. Keep the startup case beside the sequence tests; there was no previous reading to blame there.