0.20.5

0.20.5

Fixed

• Wired devices are now detected and no longer treated as Wi-Fi devices. Wi-Fi outage detection matches your devices to their router trackers by hardware address, and a hardware address says nothing about whether a device is on Wi-Fi or plugged into a network cable. On the reference system that pulled in four PoE cameras and a network printer, none of which can be affected by a Wi-Fi outage. Two consequences, both now closed: several wired devices dropping together (a switch rebooting, for instance) could have declared a Wi-Fi outage that never happened, and a wired device that genuinely failed during a real outage would have been blamed on the network instead of reported on its own.
• Where your router says a device is wired, it is left out of Wi-Fi detection. TP-Link and Fritz both publish this; routers that publish nothing are unaffected and keep the devices they had.

Added

• The diagnostics download now shows how your router trackers divide between wired, wireless, and unstated, and lists any that were left out for being wired. This makes the matching auditable from a download rather than a support conversation.

0.20.4

0.20.4

Bugfix. This is a patch to 0.20.3 to fix the WiFi bridge sensor.

Fixed

• The Bridge: WiFi sensor now appears on a normal boot. In 0.20.3 the Wi-Fi feature checked for router trackers once during startup, before most router integrations would have time to load and report. On a normal system that check finds nothing, the sensor is not created, and Wi-Fi outage detection stayed off even though the trackers were there. Now, detection retries until the router is fully loaded, and the sensor appears when the device trackers are detected. Systems without router trackers are unaffected and the WiFi bridge is not created.

Added

• The diagnostics download now includes a Wi-Fi section: how many devices are matched to a tracker, which tracker each is matched to, and whether an outage is in progress. This is the information that would have made the 0.20.3 fault visible from a download instead of a support conversation.

0.20.3

0.20.3

Added

• Device Sentinel can now detect when you your Wi-Fi goes down. Before this release, a Wi-Fi outage resulted in many separate device failures: every Wi-Fi device in the house was reported one by one, each with no cause. Now a WiFi outage is reported correctly. You get one notification saying the network went down that includes the number of devices that were taken down with it, one line on the to-do list, and one sentence in the daily brief. When the network comes back, the devices that recovered are cleared quietly, and only a device that stays broken afterward is reported by name.
• How it works, in one paragraph. If you run a router integration (TP-Link, UniFi, Fritz, and similar), it creates a small "device tracker" entity for each device on your network, showing home while connected. Device Sentinel matches those trackers to the devices it watches, using their network hardware addresses. When three or more of them drop off the network within a 60-second period, it debounces one more minute to be sure it is not a blip, then declares the outage.
• A new sensor, Bridge: WiFi, showing whether the WiFi network is up or down. It only appears if you have a router integration and at least one match was made. Without one, this feature is absent and changes nothing.
• For automations: the existing device_sentinel_upstream_down and device_sentinel_upstream_restored events now also fire for Wi-Fi outages, with wifi in the kind field.

Known Limits

• Matching is automatic only where the hardware addresses line up. A few device types do not expose one; a screen to match those by hand comes in a later release.
• If Home Assistant restarts in the middle of an outage, the outage is not re-detected until the network moves again.

0.20.2

0.20.2: The Integration Outage Release (Bugfix)

Bugfix for 0.20.1.

Fixed

• An integration outage now behaves like a broker or bridge outage everywhere, not only on the event bus. The to-do row for a downed integration carries the time it went down, and the phone push announcing how many devices it took with it is sent once the outage settles. Before this fix the outage event fired and the affected devices were correctly held back from individual reporting, but the row read "is not reporting" with no time, and the push never left.

0.20.1

0.20.1: The Integration Outage Release

When an integration stops running, every device it owns freezes or becomes unavailable. Device Sentinel is able to detect when a Zigbee bridge or the MQTT broker stops, but not when an any other integration fails to load or stops, so it reported every device one by one and left you to work out what they had in common. Now Device Sentinel is able to call out the integration.

Added

• An integration that stops running is reported. Its devices are gathered under it instead of appearing as separate problems, so the to-do list gains one row rather than one per device, and the daily brief says which integration went down instead of listing casualties.
• Affected devices stay out the repeat offenders table. A failure with a known cause is not a mystery, so an outage no longer puts an innocent device on the list.
• Two new lines in the brief. "The zwave_js integration went down at 3:42 AM" and "The zwave_js integration came back at 4:01 AM after 19m."
• The upstream events now carry the integration kind. device_sentinel_upstream_down and device_sentinel_upstream_restored fire with kind: integration, so any automation you wrote for the broker and bridge handles this too, with no change.
• 60-second grace. Reloading an integration, or upgrading Home Assistant, drops entries for a few seconds. The 60-second debounce gives the integration time to fully load before trouble is reported.
• Integrations without devices are ignored. Integrations with on physical devices are excluded. No noise added.

Notes

Zigbee and MQTT are unaffected: those report their own health and continue to do so, so a bridge outage behaves exactly as it did before.

This is built for integrations that manage a controller, such as Z-Wave and Matter, which restart themselves when their hardware disconnects. Integrations that run one connection per device, such as ESPHome, keep running while a device is unreachable and are not reported this way.

0.20.0

0.20.0: The Upstream Event Release

Your automations can now react to the failure of your ZHA or Zigbee2MQTT bridge, your MQTT broker, or an integation going down. When the broker stops or a bridge goes down, Device Sentinel tells you on the to-do list and in the daily brief. Now it says so on the event bus as well, so you can act on it.

Added

• Two new events: device_sentinel_upstream_down and device_sentinel_upstream_restored. One fires when a broker or bridge goes down, the other when it comes back. Use either as an automation trigger.
• The events tell you how much is behind the failure. Each carries kind (broker or bridge), name, since, and devices, the number of watched devices that upstream is carrying. So an automation can wake you for a bridge with seventy devices behind it and stay quiet for one with two.
• The recovery says how long it was gone. for_seconds on the restored event.
• Both halves are paired. Every down is answered by a restored, and a restored never arrives without a down before it, so an automation holding a fault always gets to close it.
• Nothing is announced during startup. Device Sentinel stays silent while the rest of your system is still coming up. An upstream that fails during that window and is still down when it ends is announced then, carrying the time it actually failed.

Nothing else changed. Detection, storage, the reports and the to-do list all behave exactly as they did in 0.19.14.

0.19.14

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.

0.19.13

0.19.13: The Battery Report Release

This release improves the presentation of the battery report.

Changed

• The steady cells are a presented in a table. They were a paragraph of names and levels in a huge block of unreadable text. They now sit in a two-column table, lowest level first.
• The unreadable cells are also presented in a table. Same shape as every other table on the page.
• The devices with no battery are named. The page gave you a count and nothing else. It now lists them in three columns. A device with a battery presented here has its battery entity disabled.

0.19.12

0.19.12: The Daily Brief Improvement Update

This release makes the daily brief easier to understand, so the information in it is clearer and more valuable. The same events are reported; the report presentation was improved.

Changed

• The wall of text that was "Keeps Failing on its Own", is renamed the "Repeat Offenders Table". The devices that fail repeated for no clear reason are now organized in a table format, showing each device name, how many times it has failed, when, typically for how long, and which other device failed at the same moment.
• The repeat offender table hides itself when empty. No repeat offenders, no heading and no table.
• The brief indicated whether a shutdown was clean or not. The unwatched line now gives the time the gap ended rather than the time it began, and names a clean stop as clean.
• An unclean shutdown says what it cost. How long went unwatched, and how many devices had their silence timers restarted.
• "Nothing has happened since" is now "No device problems started or ended in this window." It no longer appears to contradict the paragraph above it.

Fixed

• A renamed device is called by its current name. Everywhere the brief mentions it, including reports of failures from before the rename. It used to print the old name which was confusing.
• Restart noise is gone. An integration going quiet in the seconds around a restart is no longer reported as its own event in the summary or in Last 24 Hours. The restart line already tells you.

0.19.11

Device Sentinel 0.19.11

Fixed

0.19.10 Threw Away Data It Could Have Recovered: When the device list itself was damaged, instead of restoring damaged records from the backup, it erased them. It now restores from the backup, the same rule the main check currently uses. It repairs in place only when there is no backup, or when the backup is also damaged.

Two Repaired Devices Could Share One History: Fixed in the first check in 0.19.10. The main check had the same fault, now fixed too.

Notes

Two suspected problems were investigated and eliminated from concern: repairing the event log adds a row containing the event recording the repair; and during simulation cused a crash. Testing on a real fleet proved this theoretical crash was unfounded.