WiFi Devices

WiFi Devices

Device Sentinel fully recognizes Wi-Fi devices, and every single one of them is watched right out of the box.

The main difference between a Wi-Fi device and a Zigbee or Z-Wave device is that Wi-Fi lacks a specific "coordinator." There is no Zigbee bridge or Z-Wave controller whose health can be checked. Your Wi-Fi devices talk to your router, and Home Assistant talks to them over your network.

This page explains how Device Sentinel handles that difference.

The Full Treatment

Your Wi-Fi devices get the exact same protection as every other device in your home:

• Learned Rhythms: Each Wi-Fi device's reporting rhythm is learned automatically.
• Freeze Detection: Its unique freeze window is set based on that rhythm.
• State Monitoring: Freeze, unavailable, and unknown detection are fully applied.
• Battery & Signal: Battery thresholds and falling-battery detection apply if the device reports a battery level. Signal is actively recorded if the device exposes a signal entity (ESPHome, Tasmota, and similar often publish their own link strength).

Your Wi-Fi devices will appear normally on your problem list, in your daily brief, and across all diagnostic reports.

The Missing Hub Problem

With other protocols, there is a central piece of hardware to watch. Zigbee2MQTT has a bridge that announces when it is running. ZHA has a configuration entry that fails when the radio is unplugged. When either of those stops, the devices behind it are safely grouped together, and you get one alert naming the hub rather than sixty separate alerts for sixty dead sensors.

Wi-Fi doesn't have a hub. When your network drops, twenty smart plugs go quiet, and Home Assistant has no idea why.

Device Sentinel solves this by actively monitoring the network itself, rather than looking for a specific coordinator. You can read exactly how it does this and how to set it up on the WiFi page.

During a Network Outage

When Device Sentinel detects a Wi-Fi outage, the devices caught in it are protected:

• They are counted rather than listed individually.
• They are kept off the repeat offenders table.
• You receive a single notification for the network outage, not a flood of individual device alerts.

When the network returns, the row counts your devices home as they reconnect and gives the slow ones a few minutes. A device that still refuses to come back after that is reported by name, because that is a device fault, not a network fault.

How It Knows What to Count

Device Sentinel doesn't inherently know if a device is Wi-Fi, Zigbee, or Ethernet just by looking at the integration name. A smart plug talking over MQTT could be Wi-Fi, or it could be Zigbee communicating through a bridge.

This matters for one specific reason: counting casualties.

If you run a supported router integration (like UniFi or TP-Link), Device Sentinel matches your devices to the router's view of the network. That is how it knows exactly how many of your watched devices went down with the Wi-Fi.

If you don't run a supported router integration, the Wi-Fi outage is still detected and reported, but the integration cannot provide a specific casualty count. Any Wi-Fi device that Device Sentinel cannot definitively match to a router integration will simply be reported on its own if it goes offline during an outage. A device it can match belongs to the outage even when the device notices before the router does, which is usually the case.

The reverse also holds. If your server has no wireless adapter to listen with, a supported router integration detects the outage on its own: the tracked devices going away together is the signal. Either path works alone, and running both gives you detection from the air and the casualty count from the router.