WiFi

Device Sentinel watches whether your WiFi network is up, and reports one outage instead of every device on that network failing separately.

What You See

When the network goes down, the daily brief carries one sentence, the to-do list gains one row, and you get one phone notification naming the network rather than one per device. The Bridge: WiFi sensor reads down while the outage lasts and running the rest of the time.

The row indicates when it comes back and counts your devices home: it reads how many down devices are still missing, and the count falls as they reconnect. Devices slow to rejoin get a few minutes before any of them are reported on their own. A device that is still missing after that is reported by name, because it is a device fault rather than a network fault.

How It Knows

Your Home Assistant server listens for the networks around it, the same way a phone shows a list of WiFi names. Once a minute it asks its own wireless adapter what it can hear. While any access point is broadcasting a network you named, that network is up. When none is, and stays missing for the confirmation delay, the outage is reported.

The outage is dated from the moment the network went, not from the moment it was confirmed, so the length you read is the real one.

This needs no support for your particular router. It works the same whether you run TP-Link, UniFi, a Mikrotik or nothing at all.

What You Need

A wireless adapter on the machine running Home Assistant, joined to a network. Most mini PCs and every Raspberry Pi have one built in. Home Assistant Green and most virtual machines do not, and need a USB WiFi adapter.

The adapter has to be joined to a network to be switched on, but it does not have to be the network you are watching. It takes no IP address and carries no traffic; it listens.

Set it up in Settings > System > Network before configuring anything here.

Settings

Your IoT WiFi Networks

These are the networks your devices and sensors use to talk to Home Assistant. The list offers what your adapter can hear right now.

Device Sentinel cannot tell which network any individual device is using. If you choose more than one, any of them going down is reported as WiFi being unavailable, because there is no way to know whose devices were affected. Keeping every device on one network gives the clearest answer.

A network you have chosen stays chosen even when it cannot be heard, so a network that happens to be down while you are on this screen is not quietly unselected. The Device Sentinel status sensor names any chosen network that is not currently audible, which is worth checking if a network was renamed at the router.

Confirmation Delay

This is how long a network must stay missing before an outage is reported. It defaults to sixty seconds. A router rebooting overnight typically goes missing for about thirty seconds.

Router Settings

Where your router integration offers a choice about what it tracks, these are the settings that give Device Sentinel what it needs.

UniFi

• Track network clients: on. This is what creates the device trackers everything else rests on.
• Include wired network clients: off. UniFi publishes nothing that says whether a client is on WiFi or a cable, so a wired camera and a wireless sensor look the same from Home Assistant. Turning wired clients off at the source is the clean answer: what is not tracked cannot be mistaken for a WiFi device and cannot be counted in an outage it was never part of.
• Disable UniFi Network wired bug logic: leave unchecked. The wording is doubly negative. Unchecked means the workaround is enabled, which is what you want: without it, UniFi sometimes reports wired clients as wireless, and the setting above would not save you.
• Select SSIDs to track wireless clients on: tick the networks your devices use. If your IoT devices live on their own SSID, ticking only that one keeps the tracked set to the devices Device Sentinel watches.
• Track network devices (Ubiquiti devices): off unless you want them for something else. Your access points being home or away is not something Device Sentinel uses.
• Ignore Wi-Fi clients with private MAC addresses: Device Sentinel matches a device to its tracker by hardware address, so a client with a rotating private address can never be matched. Phones and tablets are the usual case, and they are not devices Device Sentinel watches, so either setting works.

TP-Link

The TP-Link router integration offers no equivalent choices. It tracks every client, wired and wireless, and publishes a connection field saying which each one is. Device Sentinel reads that field and leaves wired clients out on its own, so nothing needs configuring.

Other Routers

Most router integrations publish neither a wired marker nor an option to exclude wired clients. On those, Device Sentinel leaves every tracked device matched, because excluding on a guess would be worse than including honestly. If yours is in that position and you would like it handled properly, see Extended Diagnostics.

When You Have A Supported Router

If you run a router integration Device Sentinel supports, it also matches your devices to that router's view of them. Where the adapter scan is configured, that does not change how an outage is detected. What it adds is the count: how many of your devices went down with the network, so the notification says fourteen devices rather than listing fourteen problems.

A router integration may take a few minutes to fail, while some of its dependent devices often becoming unavailable beforehand. Device Sentinel includes those devices into the outage rather than reporting them separately. When a group of them fails together, their rows wait for the router to confirm an outage before anything is shown, so a network drop does not arrive as twenty separate alerts and then a network row.

Where no wireless adapter is configured, the tracked devices themselves carry detection, so a supported router alone still catches the outage. And without a supported router, the adapter scan still detects the outage on its own. Only the count is missing.

What It Cannot Do

Your server hears the network from one place, so an access point at the far end of the house may be faint or inaudible while serving the devices beside it perfectly. This is why the rule is that any access point broadcasting the name means the network is up, rather than anything based on signal strength.

An access point that keeps broadcasting while its connection to the rest of the network has failed reads as up, because from the air it looks exactly the same.