UniFi Protect in Home Assistant: Entities, Events and Limits

Most camera integrations mean juggling RTSP URLs and hoping the stream survives a reboot. UniFi Protect works the other way around, because the console already knows every camera, every detection and every event.

Home Assistant reads that inventory through Ubiquiti's API, increasingly the public one, so the work is not plumbing streams. It is understanding what the API exposes, what it withholds, and which paths through your network each part depends on.

Two things decide most of it in practice. Which connection mode you pick, and which Protect version you run.

In fact, Home Assistant's UniFi Protect documentation requires Protect 7.2.105 or later and supports only Protect running on a UniFi OS Console. Early Access and Release Candidate builds are unsupported, as are unofficial container ports, because Protect hands out the address it is bound to and a container makes that unreachable.

What follows covers both modes, every device type, the events automations actually use, and the ports the whole thing needs. Finally, Ubiquiti's own Alarm Manager closes the gap the public API leaves.

Full access wants two credentials. First comes the local user, created in the console's own portal by IP address rather than through the Protect app.

There you add an admin, tick Restrict to local access only, and give the Protect role Full Management. Next comes the API key, generated in Protect under Integrations, which requires an administrator.

Ubiquiti SSO cloud accounts, keep in mind, do not work for the user half. That is the same restriction the presence detection guide hits on the Network side.

API-key-only mode arrived in Home Assistant 2026.9 and asks for the key alone. Accordingly, here is what each mode carries:

Entity domain	Full access	API key only
Camera	yes	streams and snapshots only
Light (floodlights)	yes	yes
Alarm control panel	yes	yes
Binary sensor, sensor, event	yes	no
Button, number, select, siren, switch, text	yes	no
Media player, media source, proxy views	yes	no

Of course, switching between the modes needs no re-adding. Reconfigure the integration, and the entities that mode cannot support become unavailable until you switch back.

The split is not permanent, either. Home Assistant's documentation says the public API is growing and the integration is being migrated onto it incrementally, so expect more domains to work without a local user over time.

Cameras carry the most. For instance, each active RTSPS quality becomes its own camera entity, up to four, with only the highest enabled by default.

A camera with a speaker also gets a media player, which accepts any audio file FFmpeg can play. Detection sensors then follow whatever the camera reports.

That means one sensor per supported smart detection, a combined sensor for any object, and a doorbell chime sensor where a chime exists. Diagnostics arrive alongside them for uptime, network statistics and storage.

Package detection is the exception. That is because Protect reports it as a single, already-ended detection, so Home Assistant exposes it as an event entity rather than a sustained binary sensor.

The rest of the lineup is narrower, and each device has one or two limits worth knowing before you design around it:

• Floodlights. A light entity with brightness, plus motion sensitivity, auto-shutoff duration and a status-light switch.
• Smart sensors. Entities appear only for the functions the device reports, so a USL Entry gets contact and tamper while a USL Environmental gets temperature, humidity, light and leak. The USL GlassBreak gets motion and tamper but no glass-break entity, because the public API carries no glass-break state to build one from.
• Sirens. Trigger, stop, volume and duration, defaulting to 5 seconds. Running a siren indefinitely is not supported.
• Relays. A switch per output channel. Input channels are not supported yet.
• Viewers and chimes. A liveview select and a chime button. Changing a liveview in Protect needs a Home Assistant restart before the new option appears.
• The NVR. Disk health per drive, utilization and storage distribution sensors, and the Alarm Manager controls covered below.

Tamper, keep in mind, behaves differently from the rest. Once a smart sensor reports tampering it stays tampered until you clear it, and Home Assistant provides a button for exactly that.

Binary sensors tell you a state is true now. Events, however, tell you that something happened, which is what an automation trigger usually wants.

For example, the smart detection event fires for each object type a camera reports, such as person, vehicle, animal, package, license plate or face. Each type fires once across the life of an event, so a type Protect only recognizes partway through still surfaces.

Vehicles work differently, and the difference is deliberate. The vehicle event waits three seconds for better thumbnails and license plate data before firing, resets that timer when new thumbnails arrive, then fires with the best frame it has.

As a result, the vehicle event is the only one carrying the recognized plate, the vehicle type and color, and a confidence score. Home Assistant's documentation is explicit that the public API does not expose those details on the general smart detection event, so the richer data still comes from Protect's private API.

Finally, check older automations against two changes in 2026.8. Per-event detection scores are gone, because the public API carries no score, and support for Protect AI Port devices was removed since they only ever exposed disabled diagnostic sensors.

In Local mode you get two entities. An alarm control panel that arms using whichever profile is selected and always reports armed away, and a select that shows and changes the active profile while the system is disarmed.

This is, of course, a real constraint rather than a bug. Adopt one USL sensor and the alarm entities go, which catches people who buy a contact sensor expecting more Home Assistant control and end up with less.

Ubiquiti's own Alarm Manager covers that gap from the other side. It exists in UniFi Network 9.3 and later as well as in Protect, and each alarm is a trigger, a scope and an action.

One of those actions is a webhook, a GET or POST to any URL you choose, which a Home Assistant webhook trigger receives directly. As a result, detections the integration cannot surface, including known and unknown faces, license plates and line crossing, can still start a Home Assistant automation.

Keep in mind where the line falls. Entities and events come from the integration, while Alarm Manager is the route for anything Protect recognizes but the public API does not publish.

Most of this stays invisible on a flat network, of course. It stops being invisible the moment cameras, the console and Home Assistant sit in different zones, which is exactly what the IoT VLAN guide sets up.

Three paths matter there. First, Home Assistant to the console for the API and the streams.

Next, Home Assistant to each camera on UDP 7004, which is what text-to-speech and audio use. Finally, nothing inbound at all, because Protect never initiates toward Home Assistant.

The proxy views are the reason the recorder itself can stay closed. Home Assistant serves thumbnails and clips from its own URLs, signing them automatically when an automation or notification uses them, so a snapshot in a notification never requires exposing the console.

Latency deserves an expectation rather than a surprise. Home Assistant's documentation puts the default live-feed delay at 5 to 15 seconds.

Enabling LL-HLS in the stream integration, with an HTTP/2 reverse proxy in front of Home Assistant, brings that down to roughly 1 to 3 seconds.

There is a quieter load consideration as well. A camera with no active stream falls back to repeatedly refreshing snapshots, which Home Assistant warns puts extra load on the console, so a repair that enables a stream is worth accepting.

Ubiquiti publishes the split in its AI detections article, and it runs deeper than person-versus-vehicle. Face recognition and license plate recognition sit with the G6 and AI series, excluding 360 models, while the G5 and G4 series reach them with an AI Port.

Moreover, several features need the AI Key instead, including clothing color, speech-to-text and natural language search. Those are Protect-side capabilities, so they shape what a detection means rather than what Home Assistant can read.

Ubiquiti also notes that this processing happens on-premises, on the camera or on an accessory. Nothing about these detections requires the video to leave the site, which is the same argument the camera placement guide makes for getting the framing right locally.

Two capabilities, however, are Alarm Manager territory rather than integration territory. Glass break on the USL GlassBreak has no public state to read, and line crossing never became an event entity, so both need a webhook if an automation depends on them.

Choosing hardware around this is its own decision. The camera buying guide and the camera lineup cover which bodies carry which detections before any of it reaches Home Assistant.

Run these checks in order before wiring Protect into anything that matters. After all, each one fails differently, and the first two account for most setup problems:

1. Check the Protect version. Below 7.2.105 the integration reports the version as too old instead of setting up.
2. Confirm the mode. If sensors and events are missing entirely, the entry is in API-key-only mode rather than broken.
3. Fire a doorbell or motion event and watch the event entity, not the binary sensor, then confirm the event ID resolves a thumbnail.
4. Test audio to a camera speaker, which proves the UDP 7004 path that nothing else on this list touches.
5. Watch a live feed for delay before you build a dashboard around it, and enable LL-HLS if 5 to 15 seconds is too slow.
6. Check the Alarm Manager mode if you expect alarm entities, since adopting any sensor moves Protect to Global mode.

Finally, storage is the thing Home Assistant will not warn you about. Retention comes from the recorder's own math, which the Protect storage sizing guide works through, and the UniFi NVR lineup covers the hardware that holds it.

Remember that remote viewing follows the same rules as the rest of this series. A phone outside the house reaches these entities over whichever path you chose in the remote access guide, not through Protect's own cloud.