UniFi Presence Detection in Home Assistant: Why It Flaps

Have you ever had Home Assistant switch the house into away mode while the whole family sat at the dinner table? Router-based presence is appealing because your UniFi network already knows which phones are connected.

UniFi presence needs no app, reacts the moment a phone rejoins Wi-Fi and runs entirely on your own network.

That said, it also fails in ways that look random until you know where to look. Most of the causes sit in the network rather than in Home Assistant: an address that changed, a roaming feature that hid a departure, or an access point that pushed a phone off.

Accordingly, this guide covers how the integration decides home and away, what makes it flap, and how to combine UniFi with GPS so neither source's weakness reaches your automations.

The Wi-Fi roaming guide covers the radio settings in depth. Here they matter only for what they do to presence.

The UniFi Network integration signs in with a local account on your console, because Ubiquiti SSO cloud accounts are not supported. It then holds a WebSocket connection to the UniFi Network application.

As a result, client changes arrive in near real time instead of on a polling schedule.

Presence comes from four options in the integration's settings:

• Track network clients. Creates a device tracker for each client, which is the presence feature itself.
• Select SSIDs to track wireless clients on. Limits tracking to the networks you choose. Tracking only the household SSID keeps phones on the guest network and devices on an IoT SSID out of your entity list.
• Include wired network clients. Adds wired clients to the wireless ones, which rarely matters for phones.
• Time in seconds from last seen until considered away. The away window, 300 seconds by default.

Home Assistant classes these as connection trackers. Its device tracker documentation says a connection tracker assumes the device is in its associated zone, the home zone by default, whenever it is connected.

In other words, a UniFi tracker can say home or not home, but it knows nothing about where a phone is once it leaves.

Keep in mind that a lost connection behaves differently from a departure. If the WebSocket to UniFi drops, the integration retries and marks its entities unavailable until it reconnects, rather than away.

Home Assistant's UniFi documentation is blunt: presence detection is not compatible with MAC address randomization, which most modern phones enable by default, and it tells you to disable the feature per network on the phone. That advice is safe.

However, the phone makers' own documentation shows the real requirement is narrower, because the tracker simply needs an address that stays the same.

Apple's private Wi-Fi address documentation describes three settings from iOS 18, iPadOS 18 and macOS Sequoia 15 onward:

• Off. The device uses its hardware MAC address.
• Fixed. The device uses a private address that does not rotate. It is the default when joining a new network secured with WPA2 or stronger.
• Rotating. The private address changes every 2 weeks. It is the default when joining a new network with weak security or none.

Android's MAC randomization documentation makes persistent randomization the default from Android 10. The address is derived from the network profile, including the SSID and security type, and it survives until a factory reset.

Non-persistent randomization, which can change the address between connections, applies only in narrower cases: a developer option, apps that request it for a network, and some open networks.

In practice, a household phone on a WPA2 or WPA3 SSID usually keeps a stable address. The events that change it are the ones worth remembering:

• On an iPhone, forgetting the network discards its private address, unless the same network was also forgotten in the previous 24 hours. Erasing the phone or resetting its network settings produces a new address too.
• On Android, the SSID and the security type both feed the persistent address, so renaming the SSID gives every Android phone on it a new one.
• On any phone, switching between the hardware address and a private one changes what UniFi sees. An iPhone using a private address also treats a renamed SSID as a new network, and Apple gives each network its own address.

Note that the renaming rules catch people who reconfigure the network itself. If you change an SSID's name or security type, for instance moving it to WPA3-only for MLO as the Wi-Fi 7 MLO guide describes, check your trackers afterwards.

The integration's Ignore Wi-Fi clients with private (randomized) MAC addresses option skips any Wi-Fi client with a locally administered address, which Home Assistant's documentation says covers private and randomized addresses and leaves wired clients alone. Clients you select under Create entities from network clients are still included, so select the household phones before switching it on.

The next set of causes lives in the Wi-Fi settings, and each one affects presence in its own way. In fact, several of them are settings that improve roaming for everyone else.

Ubiquiti's SSID and AP settings reference describes the ones that matter here:

• 802.11r Fast Roaming. Home Assistant's advice to disable it when trackers stick at home collides with Ubiquiti's "strong recommendation" to keep it on, which is why a test settles it better than either rule. If a phone stays home long after it leaves while UniFi still lists it connected, this is the likely cause.
• Minimum RSSI. It disconnects clients below a signal threshold. Ubiquiti warns that some devices may refuse to reconnect to an access point that has kicked them several times, and generally does not recommend it outside high-density deployments. A phone that gives up on Wi-Fi reads as away.
• Roaming Assistant. New in UniFi Network 9.2, it uses BSS transition frames to warn a client before dropping it. Ubiquiti says modern clients tolerate this soft kick much better, and suggests a threshold below -70 dBm.
• WiFi Blackout Scheduler. Turning an SSID off on a schedule disconnects every phone on it, so each of their trackers turns away one window later.
• WLAN switches in Home Assistant. The integration's documentation says changing a WLAN's state reconfigures the affected access points, limiting access to all WLANs they broadcast. A nightly guest-network toggle can therefore briefly touch the household SSID too.

Note that Minimum RSSI and Roaming Assistant are per-access-point settings, so they vary across your UniFi access points if you tuned them one at a time. The roaming guide covers where Minimum RSSI belongs in a roaming design.

Finally, one cause sits outside Wi-Fi entirely. Presence depends on accurate time between Home Assistant and the UniFi Network application, and Home Assistant's documentation says unsynchronized clocks lead to it failing to mark a device home.

If the two run on separate machines or virtual machines, keep their clocks in sync.

Home Assistant's person documentation spells out the priority. With several trackers attached, a person's state comes from the most recently updated connection tracker that reports connected, then from position trackers, and otherwise from the latest tracker reporting not home.

Put simply, connection trackers lead at home and position trackers lead away from it.

That ordering has three practical consequences:

• Arrival is fast. When the phone joins Wi-Fi before the GPS tracker updates, the person turns home with the UniFi tracker as the source.
• Departure waits for the away window. While the UniFi tracker still says home, the person stays home even if GPS already says otherwise, so the window adds its length to every departure.
• A tracker stuck at home pins the person home. This is why the 802.11r symptom above matters more with a Person entity than without one.

Tune the away window with that trade in mind. A shorter window makes departures faster but turns every brief Wi-Fi drop into a false departure, and a longer one does the reverse.

The GPS half has its own requirement. The Companion app's location reaches Home Assistant only over a working remote path, and on a VPN path its sensors stop updating while the tunnel is down, as the remote access guide explains.

Finally, the person entity records which tracker decided its state as its source. That makes it the first thing to check when presence misbehaves, because it tells you whether to look at the network or at the phone.

Accordingly, setting the integration up in this order avoids several of the causes above:

1. Create a local user on the console. Home Assistant's documentation walks through it: an admin user restricted to local access only, with Full Management for Network and no OS Settings access. It also says admin rights unlock the full feature set but are not required, and the entities adjust to the account's permissions.
2. Give each phone a stable address on the household SSID, using Off or Fixed on iPhones and the default on Android.
3. Add the integration and turn on Track network clients, limited to the household SSID.
4. Select the household phones under Create entities from network clients, then decide whether to ignore other private addresses.
5. Attach each phone's UniFi tracker and its Companion app tracker to the same Person entity.

Remember that if Home Assistant sits on an IoT VLAN, it still needs to reach the console, which the UniFi Network integration uses on port 443 by default. The IoT VLAN guide covers the zone policies that keep that path open.

Keep in mind that each model handles Wi-Fi differently, so test with the phones you actually care about, one at a time. These four checks cover the failure modes above:

1. Walk out with the phone and note the time. The UniFi tracker should turn not home roughly one away window after the phone drops off Wi-Fi, and the person should follow.
2. Walk back in. The person should turn home as the phone rejoins, with the UniFi tracker as its source.
3. Read each tracker's history over a normal day. Short not-home blips while the phone sat on a desk mean it dropped off Wi-Fi for longer than the window.
4. Check the entity list after any network change. A second tracker for the same phone means its address changed, and the old entry can linger until you delete it from its device page.

Finally, for automations, a state trigger with a duration, such as not home for ten minutes rather than the instant it changes, absorbs the blips that survive all of the above.