Background
While fixing #201 (stale health-check banner), we identified a related design
gap worth tracking separately.
The dashboard's critical-sensor-health banner is a live status indicator
(see #201) — once fixed, it will accurately reflect whether there is a
sensor/config problem right now, refreshing periodically and via a manual
recheck. That's the correct model for a live condition, but it has a
consequence: a sensor that goes unavailable briefly (e.g. during an HA
restart or integration reload) and recovers on its own leaves no trace.
If nobody happens to be looking at the dashboard during that window, the
intermittent issue goes unnoticed and unreported.
Proposal
Keep a small, separate history log of health-check state transitions
(OK -> ERROR, ERROR -> OK) per component, each with a timestamp. Surface
this as a "recent issues" list the user can check independent of the live
banner state — e.g. under Settings or a dedicated health/diagnostics view.
Unlike the live banner (which should have no dismiss/acknowledge — see
discussion on #201), entries in this log describe something that already
happened, so per-entry acknowledge/dismiss is appropriate there.
Scope notes
Background
While fixing #201 (stale health-check banner), we identified a related design
gap worth tracking separately.
The dashboard's critical-sensor-health banner is a live status indicator
(see #201) — once fixed, it will accurately reflect whether there is a
sensor/config problem right now, refreshing periodically and via a manual
recheck. That's the correct model for a live condition, but it has a
consequence: a sensor that goes
unavailablebriefly (e.g. during an HArestart or integration reload) and recovers on its own leaves no trace.
If nobody happens to be looking at the dashboard during that window, the
intermittent issue goes unnoticed and unreported.
Proposal
Keep a small, separate history log of health-check state transitions
(
OK -> ERROR,ERROR -> OK) per component, each with a timestamp. Surfacethis as a "recent issues" list the user can check independent of the live
banner state — e.g. under Settings or a dedicated health/diagnostics view.
Unlike the live banner (which should have no dismiss/acknowledge — see
discussion on #201), entries in this log describe something that already
happened, so per-entry acknowledge/dismiss is appropriate there.
Scope notes
Critical system issues detected #201 should ship first as a focused bug fix.
no need for a full DB), a new read endpoint, and a UI list/panel.
Critical system issues detected #201).