UniFi Access in Home Assistant: Doors, Doorbells, Events

UniFi Access is Ubiquiti's door system: a PoE hub wired to a lock, a reader on the wall, and the Access application on a UniFi console. That console is usually the one already running Network and Protect. Until Home Assistant 2026.4 it was a UniFi application without a core integration.

That changed in Home Assistant 2026.4, which added a UniFi Access integration to core at platinum quality. It talks to the controller over the local network, and the controller pushes door changes to it over a WebSocket, so nothing polls.

The integration is modest. It unlocks doors, reports their position, relays doorbell rings and access results, and exposes two emergency modes, yet it does not pretend a door strike is something it is not.

Accordingly, this guide walks through what you need, what each door becomes in Home Assistant, why a door is a button rather than a lock, and where Ubiquiti's own Alarm Manager fits. The Protect smart detections guide explains the camera side, including Ubiquiti's own plate-driven gate unlock.

First, though, the hardware and the token.

Ubiquiti's getting started article lists the parts: a console that supports the Access application, an Access Control Hub wired to the lock, and a reader connected to the hub. A compatible lock and, of course, PoE switching to power the hubs and readers complete it.

The hub is the piece that decides what Home Assistant can later read, so it is worth choosing with the integration in mind. Ubiquiti's hub comparison sets out the lineup:

• Door Hub (UA-Hub-Door). The standard single-door hub, with lock, door operator and siren outputs, plus motion, exit button, door position sensor and emergency inputs. Powered by PoE++.
• Door Hub Mini (UA-Hub-Door-Mini). The compact single-door hub, with a request-to-exit input and a door position sensor input. Also PoE++.
• Access Ultra (UA-Ultra). A hub and reader in one body, powered by PoE+, with a request-to-exit input and no door position input. It cannot be attached to another hub.
• Enterprise Access Hub (EAH-8). Up to eight doors on AC power, with battery backup support.
• Gate Hub (UA-Hub-Gate). Gates and garage doors, including License Plate Unlock through paired AI cameras. PoE++.
• Retrofit Hub and Elevator Hub. A two-door hub that reuses Wiegand wiring, and an elevator hub covering up to 18 floors.

Power matters here too. Ubiquiti's PoE reference lists the Door Hub at 30 W and the Access Ultra at 18 W, which the PoE budget guide and the planner tool can set against a switch's budget.

The token comes next, and the documentation is specific about where. Open the console, choose Access, go to Settings, then General, and under API Token select Create New, name it for Home Assistant, and copy it for the setup form.

Be aware that newer consoles have two pages that look alike. A key made on the console's Integrations page belongs to the console, and Home Assistant's documentation says Access rejects it with a message that the key is associated with UniFi Protect.

The network path comes next. Ubiquiti's getting started FAQ says readers and hubs communicate over Layer 2 and must share a network, although the hubs themselves reach the Access application over IP. When the console is also the gateway, they can sit on a different VLAN from it, provided routing and firewall rules allow it and the application's network setting is All Networks.

Home Assistant only needs to reach the controller. Ubiquiti's ports reference lists TCP 12445 for the Access Open API, while the getting started FAQ prints 12455 for OpenAPI access. Check your own console's Access settings, therefore, before writing a firewall policy around either number.

Per door, the integration has one button, Unlock. Home Assistant's documentation says it triggers the configured lock relay to open the door for its configured duration.

The door sensor is only as true as the hardware behind it. It turns on when the door is open, and Ubiquiti's door position sensor article treats a hub with no sensor wired as a closed door whatever the door is doing.

In other words, a door with no position sensor will never show open in Home Assistant. Ubiquiti notes that its Magnetic Lock has a sensor built in, and the Door Hub, Door Hub Mini, Retrofit Hub, Enterprise Access Hub and Gate Hub all have an input for one.

Two event entities carry the moments worth automating on:

• Doorbell fires a ring event. The integration creates one for every door because the API does not say which doors can ring, so a door with no way to ring simply never fires.
• Access fires access_granted when the controller reports a result of ACCESS, and access_denied for anything else. When available it carries the actor's name, the authentication method, such as NFC, PIN code or Face, and the raw result.

The thumbnail image shows the most recent snapshot from the door's camera, updated whenever the controller pushes a new one, for instance after an access event. Ubiquiti's recording article names the Intercom, the G3 Reader Pro and the G2 Reader Pro among the readers with built-in cameras.

Then the two switches that deserve a warning label. Evacuation unlocks every door the controller manages, and Lockdown locks every one of them, and Home Assistant's documentation asks you to restrict them on dashboards and keep them out of accidental automations. Ubiquiti adds that admins can still unlock a single door remotely during a lockdown.

Finally, the select. On controllers that support temporary lock rules, a door gets a Door Lock Rule entity with the options custom, keep_lock, keep_unlock, lock_early, lock_now, reset and schedule. A diagnostic sensor beside it reports when the active rule expires.

Everything above updates by push. The documentation describes a WebSocket that delivers lock, position and emergency mode changes in real time, with no polling at all.

This is the question to settle before anything else, and the documentation answers it in one paragraph. A lock entity promises a state and two actions, and a strike that re-locks on its own after a pulse can honestly offer only the unlock.

A related limitation sits beside it. The documentation lists the missing per-door lock command as a known one: the Access API only supports unlocking individual doors, while the controller-wide Lockdown mode can lock them all at once.

That said, HomeKit users are not stuck. The documented workaround creates a Template Lock helper whose value template is simply true, whose lock action is empty, and whose unlock action calls the button. HomeKit Bridge then exposes it as a door lock.

Telling Siri to unlock the door then presses the button, the door opens for its pulse, and HomeKit shows it locked again because the template never says otherwise.

Of course, Ubiquiti has its own vocabulary for holding a door unlocked or locked, and it lives in the Access application rather than the integration. Its unlock schedules article describes a Leave Unlocked timer of 10 minutes, 30 minutes, an hour, a custom time or Always Unlocked, plus a Lock Now override during a scheduled unlock.

In fact, the lock rule select is where those words appear in Home Assistant. Where the controller supports it, choosing keep_unlock or lock_now sets a temporary rule, and the rule end time sensor says when it lapses.

The ring reaches Home Assistant without taking anything away from Access. Ubiquiti's doorbell article describes receivers of its own, including the Intercom Viewer, chimes, users on the mobile apps, phone numbers and SIP phones. Indeed, the integration's documentation never touches those receivers, which stay configured in Access.

The readers that can ring are a shorter list than the readers that exist. Ubiquiti names the G6 Pro Entry, the G6 Entry, the G3 Intercom, the Intercom, the G3 Reader Pro, the G2 Reader Pro and the Reader Pro. It adds that the two G6 Entry models must be adopted in Protect and wired directly to a hub before they can unlock anything.

Access events are the richer trigger, since they say who. The authentication attribute's documented examples, NFC, PIN code and Face, are three of Ubiquiti's unlock methods. That list runs from NFC cards and PINs through Mobile Unlock, Touch Pass, Face Unlock, fingerprint, visitor QR codes and License Plate Unlock.

For instance, an access_granted event with a known actor can run that person's arrival scene, while an access_denied event after hours can send a notification with the door thumbnail attached.

Remember what the controller already does on its own. When a door position sensor sees a locked door open, Ubiquiti's interface reports an Unauthorized Opening and the hub can sound a wired siren. A Home Assistant alert on the same condition is therefore a second channel rather than the first.

Home Assistant ships two blueprints for exactly these cases, one for doorbell notifications and one for access events, which the integration page links. They are a quick way to see the attributes with real values before writing anything custom.

Alarm Manager is version-gated on Access. Ubiquiti's article puts it at UniFi OS 4.3.6 and Access 3.4.20 or later, with triggers grouped as Unlocks, Denied, Doorbell, User and System.

Its actions say what it is for. Access alarms lock and unlock doors and switch the emergency modes, and as a result Alarm Manager is the place for rules that should hold even when Home Assistant is down.

One rule crosses applications, and it is the interesting one. A Protect alarm can unlock a specific door through Access, so a recognized face or plate can open a door with the whole decision inside Ubiquiti's software. Home Assistant only learns of it afterwards, through whatever event the controller reports.

Keep in mind that the automations guide describes the Network side of Alarm Manager, where webhooks are available and the gateway posts to Home Assistant from inside the house. The same webhook trigger receives Protect alarms, as the smart detections guide shows.

Accordingly, the division of labor is plain. Rules that move a lock belong in Access, rules that react to a door belong in Home Assistant, and Alarm Manager carries the recognition events across.

The emergency switches come first because one tap acts on every door. Home Assistant's documentation says they have direct physical security and safety implications and asks that dashboards restrict them and automations never trigger them by accident.

Ubiquiti's emergency mode article adds a wrinkle worth knowing. When a wired fire panel triggers emergency mode for a door, it cannot be deactivated from the application, the mobile app or a reader. As a result, a switch that flips in Home Assistant is not the whole story of a door's state.

The token deserves the same care. It opens doors, and Ubiquiti's API article says the same Access API manages users, permissions, schedules and unlock methods, so treat it as an administrator credential. Home Assistant's documentation suggests revoking it in Access when the integration is removed, which is also the thing to do if the host is ever rebuilt.

Where the host lives matters for the same reason. The IoT VLAN guide argues for putting Home Assistant beside the devices it controls. A door token on that host is the same trade the automations guide weighs for an administrator credential, so decide it deliberately.

Webhooks stay away from doors. Home Assistant's own guidance gives unlocking a lock as its example of what never to trigger from a webhook. After all, the button entity is still a Home Assistant action that any webhook automation could call.

Finally, let Access keep its own rules. Ubiquiti says a remote unlock from the mobile app does not satisfy a first-person-in requirement, so treat an unlock from Home Assistant the same way until you have tested it. Leave access policies and schedules where the controller enforces them.

These five use only what the integration publishes, and, what's more, none of them unlocks a door from a webhook:

1. Doorbell with a face. Trigger on the doorbell event, then notify with the door thumbnail image entity attached. The documented doorbell blueprint is the starting point.
2. Arrival by name. An access_granted event with a matching actor attribute runs that person's arrival scene.
3. Denied after hours. Outside a time window, access_denied sends a notification naming the method that was tried, and Access keeps refusing.
4. Door left open. Ten minutes of the door sensor staying on sends a notification, provided a door position sensor is wired to the hub.
5. Unlock from inside only. Expose the Unlock button to a wall tablet or a HomeKit Template Lock on the trusted network, and nowhere a webhook can reach.

Start with the first one, naturally. It proves the token, the push connection and the thumbnail in a single step, and the worst outcome is a notification.