Category: Devices & Integrations

Direct answer: When UniFi Protect is unavailable in Home Assistant, start by confirming that Protect is running on a supported UniFi OS Console, that the console is reachable by its local IP address, and that Protect is on the Stable release channel at version 7.2.105 or later. Then verify the connection mode: full access requires both a local-only UniFi OS user and an API key, while API-key-only mode intentionally exposes fewer entity types and no media source, actions, or proxy views. Do not delete the integration, rotate every credential, or reset cameras until you have identified whether the failure is authentication, permissions, routing, stream availability, or an unsupported Protect installation.

Symptoms and exact scope

This guide covers the official Home Assistant UniFi Protect integration connected to Protect running on a UniFi OS Console. It does not cover self-hosted or containerized Protect installations, which Ubiquiti does not officially offer and Home Assistant does not support. Common symptoms include the entire integration showing unavailable, cameras appearing without live video, only camera and light entities being present, event or sensor entities disappearing, media browser folders missing, repeated authentication failures, delayed video, and log messages containing NvrError with 404 - Reason: Not Found or 502 - Reason: Bad Gateway.

Record the Home Assistant version, UniFi OS version, Protect version, console model, camera models, connection mode, console IP address, and the time the problem began. If the failure followed an upgrade, record whether the console was on Stable, Release Candidate, or Early Access. This information separates an ordinary configuration problem from an unsupported release-channel regression.

Before changing anything

Confirm that recordings and live views work inside the local UniFi Protect application. If Protect itself cannot display cameras, Home Assistant is downstream of the real failure. Check storage warnings, console utilization, camera adoption status, and whether Protect is still starting. Avoid rebooting the console during an active firmware update or while storage repair is in progress.

Safety and privacy: Camera feeds, event thumbnails, doorbell images, fingerprints, NFC identifiers, access logs, local IP addresses, API keys, and usernames are sensitive. Never paste an API key or an unredacted diagnostics archive into a public forum. Do not expose the UniFi console directly to the internet to make Home Assistant connect. Use local routing or a properly secured remote-access design instead.

UniFi Protect failure matrix

1. Confirm supported hardware and software

The official integration supports UniFi Protect only when it runs on a UniFi OS Console capable of running Protect. A container or third-party self-hosted installation may report an internal address in camera-stream URLs that Home Assistant cannot reach. That symptom cannot be repaired reliably by changing Home Assistant host fields because the unsupported Protect instance is advertising unusable endpoints.

Home Assistant currently requires UniFi Protect 7.2.105 or later. Update an older installation through the supported UniFi OS interface, but do not move to Early Access or Release Candidate merely to obtain a newer number. Home Assistant explicitly does not support those prerelease channels, and they can change the API before the integration is ready.

If a feature is absent rather than the whole integration failing, check whether the feature requires a newer Protect public API version. A camera can remain available while a recently added entity is missing. That is different from authentication failure and should not trigger credential resets.

2. Test the console locally

From the same trusted network as Home Assistant, open the console by its local IP address. Confirm that UniFi OS loads, Protect opens, cameras are adopted, and a live view plays. This tests the route without depending on the cloud portal. If only unifi.ui.com works, investigate local DNS, VLAN routing, firewall policy, or console networking.

Compare the address stored in Home Assistant with the console’s current address. Reserve the console IP in the router rather than assigning an arbitrary static address inside the DHCP pool. If the address changed, use the integration’s Reconfigure flow instead of deleting the integration. Preserving the entry protects entity IDs used by automations and dashboards.

If Home Assistant and the console are separated by VLANs, verify narrowly scoped local access. Do not open broad inbound internet rules. Record existing firewall rules before testing and restore them if a change does not help. A temporary same-subnet test can prove whether routing is the failing layer without permanently weakening segmentation.

3. Understand full access versus API-key-only mode

Full access is the recommended mode for most users. It requires a local-only UniFi OS user plus an API key. It provides the broad entity set, actions, media source, and proxy views used for notification thumbnails and video clips. API-key-only mode is intentionally limited: cameras provide streams and snapshots, lights are supported, and some NVR Alarm Manager functionality is available, but binary sensors, events, media players, many controls, actions, media source, and proxy views are not.

If a reconfiguration from full access to API-key-only caused entities to become unavailable, that is expected behavior, not data corruption. Switch back through Settings → Devices & services → UniFi Protect → Reconfigure if those entities are needed. They should return when the required mode and permissions are restored.

Do not create overlapping integration entries for each connection mode. Duplicate entries can create confusing device and entity sets without solving the underlying permission difference.

4. Verify the local user correctly

For full access, the account must be created in the console’s local portal, not as a Ubiquiti cloud SSO user. Open the console by IP, go to Admins & Users, add an administrator restricted to local access, and assign the Protect role appropriate to the functions Home Assistant needs. The official documentation recommends Full Management for the widest support, but a narrower role can be used if you accept fewer or read-only entities.

A cloud account that works at unifi.ui.com does not satisfy this local-user requirement. Repeated login failures with a valid cloud password often point to the wrong account type rather than a bad password.

After changing permissions, reconfigure or reload the existing integration. Verify that the expected entity domains return before changing anything else. If only one camera remains absent, inspect device-specific access and adoption rather than increasing the global role again.

5. Validate the API key without exposing it

Create the API key from Protect’s Integrations page while logged into the local portal as an administrator. Copy it once into the Home Assistant setup flow. Do not save it in screenshots, notes synchronized to public services, YAML examples, or support posts.

If the key was revoked or rotated, reconfigure the existing integration with the replacement. Avoid deleting the entry because deletion can break dashboards, notification automations, and entity references. If compromise is suspected, revoke the old key after the replacement is confirmed, then review console access logs and Home Assistant diagnostics.

An API key alone does not grant full-access features. If the entry was configured in full-access mode, both the local username/password and API key must be valid.

6. Diagnose missing or delayed camera streams

Home Assistant uses active RTSPS streams exposed by the Protect public API and selects the highest-quality active stream as the default feed. If no stream is active, Home Assistant may create a repair that can enable one. Until a stream exists, the camera feed can fall back to repeatedly refreshed snapshots, increasing console load and looking like a slow video connection.

Open the camera in Protect and verify that it is online and streaming. Check Home Assistant Repairs for a stream-related item. Enable the required stream through the supported repair rather than copying obsolete RTSP URLs from old tutorials. Then reload the integration and test a single camera before changing all cameras.

Video delay can also reflect transcoding, browser playback, network loss, or an overloaded console. Compare a local Protect live view with Home Assistant. If both are delayed, focus on the camera, console, storage, or network. If only Home Assistant is delayed, collect integration diagnostics and note the stream quality and client used.

7. Interpret NvrError 404 and 502 safely

A 404 - Reason: Not Found means a requested Protect resource or endpoint was not found. It can occur temporarily while Protect restarts, after an API path changes, or when a saved reference points to an event that no longer exists. A 502 - Reason: Bad Gateway indicates that the gateway could not obtain a valid response from the Protect backend. Neither message proves that the camera itself is defective.

First verify that Protect is fully loaded locally. Wait for an intentional console or Protect restart to finish, then reload the integration once. Confirm Stable-channel versions and capture the exact log time, endpoint category, and affected camera. Do not loop reloads or console reboots; repeated reconnects can obscure the original failure and add load.

If the error persists while Protect works locally, download Home Assistant diagnostics, redact secrets and local identifiers, and check the official integration issue tracker for the same Protect and Home Assistant versions. A concise report should include console model, Protect version, Home Assistant version, camera model, connection mode, exact error, reproduction steps, and whether local Protect playback works.

8. Explain entities that disappear by design

Some missing entities are expected consequences of settings. Smart-sensor functions that are disabled are marked unavailable. Alarm Manager and Alarm profile entities appear only when Protect Alarm Manager is in Local mode. Adopting sensors, relays, fobs, or an Alarm Hub can switch Alarm Manager to Global mode, where the public API does not expose arm profiles and Home Assistant cannot create those entities.

Likewise, G3 cameras do not provide the smart detections documented for G4 and AI series cameras. Package detection is represented as an event entity rather than a sustained binary sensor. These capability differences should be checked before treating a missing entity as a regression.

9. Verify recovery

• The UniFi OS console opens through its local IP from the Home Assistant network.
• Protect is on Stable version 7.2.105 or later and finishes loading normally.
• The integration uses the intended full-access or API-key-only mode.
• Full access uses a local-only user, not a cloud SSO account, plus a valid API key.
• Expected cameras and supported sensors appear without duplicate integration entries.
• An active RTSPS stream plays for one camera without snapshot-only fallback.
• Media source, proxy views, actions, and events appear only when the selected mode supports them.
• Logs remain free of recurring 404 or 502 NvrErrors after one normal reload.

Rollback and recovery

If a new API key fails, restore the previous working key if it has not been revoked. If changing to API-key-only removes needed entities, reconfigure to full access. If a VLAN test fails, restore the original firewall rules and network placement. If a Protect update caused the failure, do not attempt unsupported firmware downgrades without Ubiquiti guidance; preserve recordings and configuration, collect diagnostics, and wait for a supported stable fix.

If the integration entry was deleted, recreate it with the same console and credentials, then repair automation references carefully. Restoring an entire Home Assistant backup is usually excessive for a credential or routing issue and may roll back unrelated changes.

Prevention

• Reserve the console’s local IP address.
• Use a dedicated local-only account and a dedicated API key for Home Assistant.
• Keep Protect and UniFi OS on Stable channels.
• Record the console, Protect, Home Assistant, and camera versions before upgrades.
• Export or verify backups before major console changes.
• Review entity availability after changing connection mode, user role, Alarm Manager mode, or adopted security devices.
• Keep API keys, event images, access logs, and diagnostics private.

Related Troubliq guides

Use the Device Unavailable Diagnostic when the failing network layer is unclear. The Smart-Home Diagnostic Decision Tree can separate authentication, routing, and device problems. For another camera integration workflow, compare the Reolink camera unavailable guide. If a reverse proxy produces an HTTP error before Home Assistant loads, use the Home Assistant 400 Bad Request reverse-proxy guide.

Sources and review record

• Home Assistant UniFi Protect integration documentation
• Home Assistant UniFi Network integration documentation
• UniFi Protect developer documentation

Last reviewed: September 27, 2026. Testing disclosure: Troubliq synthesized current official documentation and documented integration behavior. We did not claim hands-on testing with every UniFi OS Console, camera model, firmware version, network design, or Protect release.

Direct answer: If a Samsung TV is unavailable in Home Assistant or will not turn on, first confirm that the television is supported, connected to the same subnet as Home Assistant, and reachable at its current IP address. For power-on failures, verify that Home Assistant knows the TV’s MAC address and that network standby or Wake on LAN is enabled on the television. Do not delete the integration or factory-reset the TV until you have separated an IP, permission, VLAN, and wake-up problem.

This guide applies primarily to Samsung Smart TVs with Tizen from 2016 onward and models that expose the REST and WebSocket interfaces used by Home Assistant. Older H- and J-series televisions can use a different encrypted pairing flow, so their behavior may not match a newer Tizen model.

Symptoms and scope

• The Samsung TV entity shows Unavailable even though the television is powered on.
• Home Assistant can turn the TV off but cannot turn it on.
• The TV asks for permission every time Home Assistant connects.
• The entity works briefly and becomes unavailable after the router assigns a new address.
• Discovery fails when the TV and Home Assistant are on different VLANs.
• Volume, source or remote commands fail while basic power state still updates.
• An automation calls media_player.turn_on, but nothing happens.

Before making changes

Record the exact TV model, model year, firmware version, current IP address, wired or wireless connection, MAC address and Home Assistant version. In Home Assistant, open Settings → Devices & services → Samsung Smart TV and download diagnostics if the integration provides that option. Note the entity ID before removing or renaming anything because dashboards and automations may depend on it.

Safety and privacy: Do not open the television or power supply. Disconnecting a wall-mounted TV can create a fall or electrical hazard. Do not publish a full diagnostic file without reviewing it for local IP addresses, MAC addresses, device names or tokens. Avoid exposing the TV’s control ports to the public internet.

Fast diagnostic matrix

1. Confirm the television itself is online

Start with checks that do not alter configuration. Turn the TV on with its physical remote. Confirm that a built-in streaming app can reach the network and that the router lists the TV as a connected client. If the TV is absent from the router, Home Assistant cannot repair the underlying network connection.

For Wi-Fi, check that the TV joined the intended network rather than a guest SSID. Guest networks commonly isolate clients from one another. For Ethernet, confirm link lights on the switch or router and inspect the cable without moving a wall mount unsafely. Restarting the TV is reasonable only after you have recorded its current address and the affected appliance can safely lose power.

If the router shows the TV online, note its IP and MAC address. Do not rely on an address written down months ago. DHCP leases change after router replacements, long power outages or network redesigns.

2. Check model and protocol compatibility

The official Samsung Smart TV integration documents support for Tizen televisions from 2016 onward and models with WebSocket and REST capabilities. A “smart TV” label alone is not enough because Samsung used different control protocols across generations.

If the model is from the H or J series, Home Assistant may detect an encrypted protocol and start a manual pairing flow. Complete the permission prompt shown by the TV rather than repeatedly deleting and adding the integration. If the model predates the documented interfaces, partial discovery does not guarantee reliable control.

Before blaming a Home Assistant update, compare the model and firmware with the current official integration documentation and known issues. Do not install an unrelated custom component simply because it supports a similarly named model; running two integrations against the same TV can create duplicate entities and confusing connection attempts.

3. Repair an incorrect IP address safely

Compare the host stored in the Samsung integration with the router’s current client entry. If the addresses differ, use the integration’s Reconfigure option when available or update the entry through the supported setup flow. Preserve the existing entity whenever possible so automations and dashboards continue to reference the same object.

After a successful connection, create a DHCP reservation in the router for the TV’s MAC address. A reservation keeps address management centralized and avoids selecting an address already assigned to another device. Do not choose an arbitrary static IP inside the router’s dynamic pool.

Verify this layer while the TV is on. The media-player state should update, and a low-risk volume or mute command should work. If the entity still fails while the IP is correct, continue to permissions and subnet checks instead of cycling through random addresses.

4. Fix repeated Samsung permission prompts

Newer Samsung TVs can be configured to ask for permission on every connection attempt. That can make Home Assistant appear unreliable because reconnects wait for someone to approve the television prompt.

On the TV, open Device Connection Manager → Access Notification and change the setting to First time only. Then open the device list in the same manager and remove stale or duplicated Home Assistant attempts. Reconnect once and approve the fresh request.

Menus differ slightly by model and firmware. Do not change unrelated privacy or advertising settings just to locate this option. If the TV provides only Allow and Deny entries, remove the old Home Assistant record and allow the next connection once.

Verify by turning the television off and on normally, waiting for the integration to reconnect, and checking that no new permission prompt appears. A single successful command without a reconnect is not enough to prove this issue is resolved.

5. Diagnose VLAN and subnet failures

The official integration documents a significant limitation: Samsung televisions may refuse WebSocket connections across different subnets or VLANs. A firewall rule that allows the port does not necessarily overcome a restriction enforced by the television itself.

Test this cleanly by placing Home Assistant and the TV on the same subnet temporarily. If the integration connects there, the TV, credentials and basic integration are working. The failure is in the network boundary or the television’s same-subnet restriction.

Do not respond by opening the entire IoT VLAN to the trusted network. Some networks can use a carefully designed proxy or IP masquerading rule, but that is router-specific and should be implemented only if you understand the security effect. The safest general solution is often to keep the TV and Home Assistant interface that controls it on a compatible local segment while restricting unrelated IoT traffic.

Document the original VLANs and firewall rules before testing. Restore them if the experiment does not improve the connection.

6. Fix “turn off works, turn on does not”

Turning a television off uses an active connection. Turning it on is different because the TV’s normal control interface is asleep. Home Assistant therefore needs a wake mechanism.

If the integration learned the TV’s MAC address during discovery, it can attempt Wake on LAN when the Turn on action is called. Check that network standby, power-on with mobile, IP remote, or Wake on LAN is enabled in the TV’s network or power settings. Samsung changes the wording between firmware versions.

Wireless wake support varies by model. A television may disconnect Wi-Fi completely during deep standby even though Ethernet wake works. Test with the existing connection first; do not purchase adapters or run new cabling before confirming the model’s documented capability.

If Home Assistant did not learn the MAC address, add the official Wake on LAN integration and create a controlled automation using the Samsung TV’s samsungtv.turn_on trigger and wake_on_lan.send_magic_packet action. Use the MAC address from the router or TV network page rather than guessing it.

wake_on_lan:

automation:
  - alias: "Wake Samsung TV"
    triggers:
      - trigger: samsungtv.turn_on
        entity_id: media_player.samsung_smart_tv
    actions:
      - action: wake_on_lan.send_magic_packet
        data:
          mac: "AA:BB:CC:DD:EE:FF"

Replace the sample values with your own entity and MAC address. Do not publish the real MAC in a public support post. If broadcasts do not cross VLANs, configure the broadcast address only after confirming the router’s behavior and the Home Assistant documentation.

7. Interpret Wake on LAN results

A magic packet action only proves that Home Assistant sent a packet; it does not prove the TV received it or powered on. Watch the router client list and the television’s status LED. If the TV appears on the network several seconds later, the wake path worked even if the media-player entity needs more time to reconnect.

If Ethernet wake works but Wi-Fi wake fails, the difference points to standby behavior rather than the integration. If neither works, confirm the MAC, wake setting and broadcast path. If the TV wakes from Samsung’s mobile app while away from home but not from a local magic packet, the app may be using a vendor cloud path that is different from Wake on LAN.

Do not compensate with a smart plug unless the television manufacturer explicitly permits hard power interruption. Repeatedly removing mains power can corrupt settings and is not equivalent to a normal standby wake.

8. Test remote commands and sources logically

Once availability and power are stable, test one basic command such as volume up, mute or Home. Supported key codes vary by model. A failure of one application or source shortcut does not mean the entire integration is offline.

Test commands individually before creating a sequence. Long sequences can run too quickly or behave differently depending on which screen is active. Add delays only after confirming every individual command is supported. Avoid factory or service-menu key codes; they can change calibration or other sensitive settings.

For source selection, inspect the source list exposed by the media-player entity. Some models expose only TV and HDMI, while others expose applications. Do not hard-code a source name that the entity does not currently report.

9. Capture useful diagnostics

Enable debug logging from the integration menu, reproduce the failure once, then disable logging and download the file. Record whether the TV was awake, its connection type, subnet relationship, and whether the permission prompt appeared.

Before sharing diagnostics, remove local addresses, MAC addresses, names and tokens. A useful issue report includes the exact model, model year, firmware, Home Assistant version, connection type, error time, steps already tested and whether same-subnet testing changed the result.

Verification checklist

• The TV is visible in the router at the reserved IP.
• The model is within the integration’s supported protocol range.
• The TV and Home Assistant can establish a connection on the same subnet.
• The Device Connection Manager trusts Home Assistant without prompting repeatedly.
• A basic command works while the TV is on.
• The TV wakes from a known-good magic packet or documented native wake method.
• The media-player entity reconnects after wake and stays available through multiple cycles.
• Debug logging is disabled after testing.

Rollback and recovery

If a VLAN experiment fails, restore the original network assignment and firewall rules. If a new Wake on LAN automation causes repeated wake attempts, disable the automation and keep the Samsung integration itself. If you removed stale permission records, approve the next legitimate Home Assistant request once.

If the integration was deleted, restore from a recent Home Assistant backup only when rebuilding the entity relationships would be more disruptive than the restore. A simple IP or permission error normally does not justify rolling back the whole system.

Prevention

• Reserve the television’s IP address in the router.
• Keep the model, firmware, IP and MAC recorded privately.
• Test network segmentation changes with the TV before making them permanent.
• Use First time only for connection notifications when available.
• Keep power-on logic separate from normal media-control automations.
• Review Home Assistant and Samsung firmware release notes before major upgrades.
• Avoid duplicate custom integrations controlling the same TV.

Related Troubliq guides

Start with the Smart-Home Diagnostic Decision Tree when the failing layer is unclear. Use the Device Unavailable Diagnostic for a broader network-first workflow. For another IP-change example, see WLED unavailable after an IP change. If VLAN routing is suspected across several products, compare the network isolation checks in Shelly unavailable in Home Assistant.

Sources and review record

• Home Assistant Samsung Smart TV integration
• Home Assistant Wake on LAN integration
• Home Assistant troubleshooting and diagnostics

Last reviewed: September 21, 2026. Testing disclosure: Troubliq synthesized current official documentation and documented integration behavior. We did not claim hands-on testing with every Samsung model, firmware version or network design.