Device Sentinel 0.19.14
Integration Status
| Area | Status | What that means |
|---|---|---|
| Freeze detection | Stable | Per-device rhythms are fully modeled. Verdicts accurately distinguish between frozen, unavailable, unknown, and never reported states. The core logic is settled and unchanged in this release. |
| Battery | Stable | Dual-evaluation is live: cells are judged against a fixed threshold and a predictive time-to-empty trend. Works on any device that reports a battery level. |
| Signal | Experimental | Each day's readings are folded into a time-weighted fifth percentile and median, and a day is called bad when it falls far below that device's own recent normal, in its own units and in its own spread. Where a device exposes both, RSSI and LQI are recorded side by side. Only railed links trigger phone alerts. The gates are still being tuned, and recorded metrics will shift as that settles. |
| Storage | Stable | Guards weeks of learning against corruption. A recent backup is always kept. If a power outage ever corrupts the integration's data file, the backup is restored where it can be and the damage is repaired where it cannot, without asking you anything. Both halves have now run on real hardware against a live file. |
| Zigbee2MQTT | Working | Supports pairing window recognition, bridge and broker outage detection, and bridge/broker sensor integration. Provides a second-opinion availability check alongside freeze verdicts. |
| MQTT | Working | Watches the MQTT broker itself. Supports broker outage detection and broker sensor integration. Devices behind a stopped broker are cleared of blame rather than reported one by one. A broker outage outranks any bridge outage. |
| ZHA | Experimental | Supports coordinator outage detection and bridge sensor integration. Reloads, reconfigures, and re-pairs ride through without being reported as faults, so no pairing window is needed. ZHA bridge detection will be marked experimental until proven stable over time. If you run ZHA, see the ZHA documentation to follow along or contribute. |
| Z-Wave | Coordinator features not built | Not started. If interested, see the Z-Wave documentation to contribute. |
Phase 1: The Pages You Read
A renamed device in an historical table or chart uses the device's newest name. Rename a device and every page uses the new name, including in reports about failures from before the rename.
Repeat offenders became a table. The devices that repeatedly fail for no clear reason now have their own table naming: what the device did, how many times, when, how long a typical failure ran, and any other device that tend to fail in the same proximity of time.
The Battery and Singal Reports. Previously, the battery report told you the number fo devices that reported no battery. The signal report told you 60 devices held their signal without naming them. Both now list them. This is especially useful for the battery report allowing you to see and fix any battery device on the list.
Restart noise is gone. When an integration is unloaded in the seconds around a restart, verdics of offline devices owned by the integration are supressed. Once Home Assistant and all its integrations are loaded and the system is stable, offline devices reporting begins.
Improved help text and labeling. The brief now says whether Home Assistant shut down cleanly, when the unwatched gap ended rather than when it began, and what an unclean shutdown cost you in restarted silence timers. Help text moved beneath the table it explains and names the setting that governs it.
Phase 2: Storage, Backups, and Data Safety
This integration creates a device database that takes months to record. One bad shudown can put your data a risk. This update enhanced the integrations data storage to safegard against data loss.
When a data anomoly is detected, the integration no longer asks you to do anything. 0.18.9 gave you a card with three choices when your storage was damaged. Choosing correctly required you to make the right choice or data would be lost. Now, the integration takes a backup, repairs the data, and lets you know.
Backups are taken at every storage write interval, not once a day. Before each clean save, the current save file is renamed to last-good and a new one is written. There is no window where a half-written file and a half-written backup exist together, because a rename is atomic. The copy is always exactly one good save behind.
Nine guards became two boundaries. Previous releases contained patches for faulty data readers, which meant the next unguarded reader was always waiting. This update did away with all the patching in favore of two data file verifications on file loading.
Phase 3: ZHA Coordinators
ZHA coordinator is now detected and watched. ZHA exposes no entity for its radio, so its liveness is read from the config entry state instead. No polling, no timer, no network call.
Outages are dated from when the radio died. Not from when we noticed. The difference was measured at 35 to 60 seconds.
ZHA device reconfigures and re-pairings are automatically detected. Unlike Zigbee2MQTT, no pairing window is needed to make that work.
Why this is marked experimental. This was built and tested on one system with one ZHA fleet of devices. There has been no confirmation that it functions on any other configuration.
Upgrading
Update and restart. Your learned rhythms, battery history and signal history are safe.
One file is deleted at the first start: an old backup copy of the activity clocks that the rename rule replaces. Nothing you can see depends on it.
If you had a Device Sentinel storage repair sitting unanswered in your Repairs panel, it will be gone. The repair it was asking will be made if the data fault still exists.