UniFi Automations in Home Assistant: PoE, WLANs, Alerts

A smart home automation usually ends at a light or a lock. The network underneath it is treated as scenery, even though it is the one system every other device depends on.

That is a missed opportunity, after all, because UniFi exposes more of itself to Home Assistant than most people use. A camera that has stopped responding can be power-cycled at its switch port, a guest network can close itself at midnight, and an internet outage can announce itself rather than being discovered.

Two mechanisms do the work, and naturally they run in opposite directions. Home Assistant's UniFi integration turns network controls into entities, while Ubiquiti's Alarm Manager sends network events out as webhooks.

This guide covers both, along with the guardrails worth having before you let an automation touch the network it depends on. First, though, what the integration actually exposes.

The UniFi Network integration is read-write, which people often miss after setting it up for presence detection alone. The same connection that reports which phone is home can also turn a port off.

Permissions, of course, decide how much of it appears. Home Assistant's documentation is explicit that button entities exist only when the account has administrator privileges, and that PoE and port control entities are disabled by default.

Firmware updates are part of it too. The integration surfaces available updates for adopted devices and, with an admin account, can install them from Home Assistant.

Be aware that entity availability tracks the account, not the hardware. A restricted user yields fewer entities, and read-only sensors where an admin would get switches, which is a useful lever when the host sits somewhere you would rather not put an administrator credential.

This is the automation that earns its keep first. A camera that has stopped sending video, a sensor that has stopped reporting, an access point that answers pings but serves nobody — all three often clear with a power cycle.

All three are also, as a rule, somewhere inconvenient to reach.

Keep in mind that the two buttons do different jobs, and confusing them wastes an afternoon. Power cycle PoE restarts the attached device, while Restart UniFi device restarts the switch or access point itself.

Pair it with a condition, of course, rather than firing it blindly. A camera entity that has been unavailable for ten minutes is a reasonable trigger, and the Protect guide covers which entities actually go unavailable when a camera drops.

Keep one port off the list permanently. Cycling the port that feeds the Home Assistant host, or the uplink of the switch it sits behind, ends the automation and your access to it in the same instant.

Of course, the power budget still applies while a device restarts and draws its startup current. The PoE budget guide covers headroom across a stack, and the switch lineup lists what each model can supply.

A WLAN switch per network is genuinely useful, of course. Closing a guest network overnight, pausing an IoT SSID during maintenance, or turning off a kids' network at bedtime are all one entity away.

The side effect, however, is the part to plan around. Because the access points reconfigure, every client on them feels it briefly, including the phones your presence detection depends on.

Note that UniFi has a native alternative for the scheduled cases. The WiFi Blackout Scheduler turns an SSID off on a schedule from the console itself, which keeps a predictable, nightly job out of Home Assistant entirely.

Use the integration's switch, then, for the conditional cases the console cannot express. Guest Wi-Fi that closes when everybody leaves is a Home Assistant job, while guest Wi-Fi that closes at midnight is a UniFi one, and the guest network guide covers the rest of that setup.

Entities tell you a state. Alarms, however, tell you an event happened, and Ubiquiti's Alarm Manager article lists the triggers a network owner cares about.

Its categories span the whole console, and four of them matter here:

• Internet. WAN offline, latency spikes, packet loss and data limits reached.
• Power. PoE issues and power loss.
• Security. Threat detections, honeypot hits and firewall blocks.
• System. Device adoption, VPN disconnects, port errors and admin configuration changes.

The Home Assistant side is a single trigger. A webhook automation listens on an endpoint you name, and its documentation notes that webhook triggers accept requests only from devices on the same network by default.

That is where your gateway sits, so the default usually needs no change, though it is worth testing once when the gateway and the host are on different VLANs.

The default is a feature rather than an obstacle. The gateway posts from inside the house, and the payload arrives in the automation as form data or JSON.

Note what Home Assistant asks of webhooks in return. Its documentation says endpoints carry no authentication beyond knowing a valid ID, so treat that ID like a password, generate your own rather than copying one, and leave the local-only option enabled.

It also says not to trigger destructive or safety-related automations from a webhook, giving locks and garage doors as the examples. That is why the alarms here end in notifications, while the port-cycling above is triggered by an entity Home Assistant owns.

Naturally, you can narrow it further. The trigger takes an allowed-methods list, so an endpoint that only ever receives a POST can refuse everything else.

Dual-WAN failover is, in fact, the event most worth automating, because it stays invisible until something else breaks. After all, the WAN failover guide sets out what actually changes: the public address moves, stateful sessions reset, and VPN tunnels tear down and re-establish on the new path.

Alarm Manager's Internet triggers are, accordingly, the signal. A WAN offline alarm firing a webhook gives Home Assistant the moment of the switch rather than the aftermath.

What you do with it, of course, depends on the circuit underneath. Announcing it is the baseline, and pausing bandwidth-heavy automations, such as a backup upload, is the obvious second step when the backup link is metered.

Remember what else moves with the address. A self-hosted WireGuard server needs dynamic DNS to stay reachable across a failover, which the remote access guide covers alongside the paths that do not care.

The credential question comes first. Buttons and PoE control need an administrator account, so a host on the IoT VLAN from the IoT VLAN guide is holding a powerful credential on your least-trusted network.

Weigh that honestly rather than assuming either way. A restricted UniFi account still yields trackers and sensors, and you can keep the admin-only automations on a host that sits somewhere better.

Test on something that does not matter, naturally. A spare PoE port with a lamp adapter or an unused access point proves the automation without taking a camera offline to find out.

Finally, add a condition that prevents loops. A power-cycle automation triggered by unavailability should fire once and then wait, because a device that stays unavailable will otherwise be cycled every few minutes.

Finally, these five cover most of what the integration and Alarm Manager make possible, and each names what it needs:

1. Power-cycle a wedged camera. Trigger on the camera entity unavailable for ten minutes, act on the Power cycle PoE button, then wait an hour before repeating.
2. Close the guest network when the house empties. Trigger on everyone leaving, act on the guest WLAN switch, and accept the brief reconfiguration of affected access points.
3. Announce a WAN failover. Alarm Manager internet trigger to a webhook, then a notification and a pause on any upload you would rather not send over the backup circuit.
4. Warn on PoE faults. Alarm Manager power triggers cover PoE issues and power loss, which usually mean a cable or a device, not a budget.
5. Hold firmware updates for a window. The integration surfaces available updates, so an automation can notify you and leave the install for a time you choose.

Start with the first one, naturally. It is the automation most likely to save a trip up a ladder, and the easiest to prove safe on a spare port before you point it at a camera.