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.