Blog

Samsung TV not authorized in Home Assistant: permissions, token, network, and Wake-on-LAN fixes

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

Observation	Likely layer	Safest next step
TV is unavailable while powered on	IP, subnet, permission or WebSocket connection	Compare the router’s current IP with the integration host
TV turns off but not on	Wake on LAN or network standby	Verify the MAC address and wake settings
TV asks for permission repeatedly	Samsung Device Connection Manager	Set access notification to First time only
Failure began after moving the TV to an IoT VLAN	Known subnet limitation	Test TV and Home Assistant on the same subnet
Remote commands fail on an older H/J model	Legacy encrypted pairing	Complete the TV’s pairing prompt and preserve the entry
State works but a specific key does not	Model-specific command support	Test a documented basic command before changing the integration

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.

Evidence, applicability, and safe verification

Applies to: the Home Assistant Samsung Smart TV integration and Samsung TVs that expose the required local-network control interface. Menu names differ by model and firmware.
Exact symptom covered: “Home Assistant is not authorized to connect to this Samsung TV. Check your TV’s External Device Manager settings to authorize Home Assistant,” plus unavailable entities and failed power-on attempts.
Least-destructive check: keep the TV on, confirm Home Assistant and the TV can reach each other locally, then approve the on-screen connection request in the TV’s External Device Manager before deleting tokens or re-adding the integration.
Expected result: the TV accepts the authorization request, Home Assistant stores a usable token where the model supports it, and a basic command works while the TV is awake. Wake-on-LAN is a separate path and may still require the correct MAC address and network broadcast handling.
Verification: reload the integration once, confirm the entity remains available, and test one reversible command such as mute or volume. Do not use a source-launch failure alone as proof that authorization failed.
Rollback: if a change worsens control, restore the previous IP reservation, VLAN/firewall rule, or MAC setting. Removing the integration should be a last resort because it can discard a working token and entity references.
Privacy and safety: do not publish TV tokens, MAC addresses, internal IPs, network captures, or diagnostic downloads without redaction. Avoid broad firewall rules; allow only the minimum local traffic required.
Testing disclosure: this guide is based on current official Home Assistant documentation and conservative network diagnostics. Troubliq did not physically test every Samsung model, firmware, router, or VLAN design.
Last reviewed: September 30, 2026.

Sources and review record

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.

September 21, 2026

TP-Link Kasa or Tapo unavailable in Home Assistant: authentication, IP, VLAN, and camera fixes

Direct answer: When a TP-Link Kasa or Tapo device is unavailable in Home Assistant, do not factory-reset it first. Confirm that the device still works in the vendor app, verify its current IP address, check whether the model now requires TP-Link account authentication, and enable Third-Party Compatibility when the firmware provides that control. If the device is on another VLAN, add it manually by IP because automatic discovery normally will not cross subnets.

This guide applies to the official TP-Link Smart Home integration in current Home Assistant releases and covers Kasa plugs, switches, bulbs and power strips as well as supported Tapo plugs, lights, hubs, sensors, cameras and doorbells. It focuses on connection and authentication failures, not cloud outages in the Kasa or Tapo mobile apps.

Symptoms this guide covers

A Kasa or Tapo device is present but all or most entities show Unavailable.
Home Assistant discovers the device but setup fails with an authentication or communication error.
A device worked until a firmware update, router replacement, password change or IP-address change.
The vendor app works, but Home Assistant cannot connect locally.
A device on an IoT VLAN is not discovered.
A Tapo camera is controllable but live view is missing or unavailable.
An old total-consumption or update sensor remains unavailable even though the physical device works.

Before changing anything

Record the device model, hardware revision, firmware version, current IP address and the exact error shown under Settings → Devices & services → TP-Link Smart Home. Download diagnostics if Home Assistant offers them. Do not paste credentials, tokens, public IP addresses, Wi-Fi passwords or unredacted diagnostics into a forum post.

Electrical safety: Do not open a mains-powered plug, switch, power strip or wall device. If a hardwired switch must be inspected, isolate the circuit and use a qualified electrician. A factory reset can erase schedules, camera settings and network configuration, so it belongs near the end of the process.

Quick decision table

Observation	Most likely layer	Safest next check
Device also fails in the Tapo or Kasa app	Power, Wi-Fi, router or device firmware	Confirm power and check the router client list
Vendor app works; Home Assistant reports authentication failure	Credentials or Third-Party Compatibility	Verify the case-sensitive account email and compatibility setting
Device moved to another VLAN	Discovery or firewall routing	Add the current IP manually and test same-VLAN access
Only one historical sensor is unavailable	Entity removed or no longer reported	Identify the entity type before changing the integration
Tapo camera controls work but live view does not	Camera account or live-view option	Check the separate camera account in the Tapo app
Failure began after the DHCP lease changed	Stored host address	Reconfigure the entry with the current IP

1. Separate a device problem from a Home Assistant problem

Start with observations that do not change configuration. Confirm that the device has power and appears online in the correct Kasa or Tapo account. Then open the router’s client list and locate the device by hostname, vendor or MAC address. Compare the listed IP with the host saved in Home Assistant.

If the vendor app cannot reach the device while your phone is on the same local network, Home Assistant is unlikely to be the first problem. Check Wi-Fi coverage, access-point association and whether client isolation is enabled. Power-cycle a removable plug only if the connected appliance can safely lose power. Do not power-cycle a refrigerator, medical device, server, pump or security system without considering the consequence.

If the app works and the device answers at its current IP, continue with the integration-specific checks below. The official integration communicates locally even though newer devices may require TP-Link cloud-account credentials to authorize that local connection. That distinction explains why internet access during initial setup may matter even when normal control is local.

2. Confirm model and firmware support

The official Home Assistant documentation maintains a supported-device list and links to the python-kasa project for current hardware and firmware coverage. Match the exact model and, when available, the hardware revision. A similar product name is not proof of support. Hub-attached products can also have different capabilities from directly connected Wi-Fi devices.

If the model is absent, do not repeatedly delete and recreate the integration. First compare the device against the current python-kasa support table and known issues. An unsupported model may partially identify itself but still fail during feature negotiation. Preserve diagnostics for a maintainer report rather than guessing at credentials or ports.

Firmware can change authentication requirements. Newer Kasa and Tapo devices commonly require the TP-Link cloud username and password for local authorization. Older devices that never required authentication may behave differently. Avoid downgrading firmware unless TP-Link or the integration maintainers provide model-specific instructions; an interrupted or incompatible firmware change can permanently disable a device.

3. Fix authentication without exposing credentials

Open the integration entry and choose Reconfigure when that option is available. Use the TP-Link cloud username associated with the device. Home Assistant’s documentation notes that this is normally the account’s case-sensitive email address. Do not use the separate camera account username in the general TP-Link account field.

If setup fails after a password change, update the integration with the new account password instead of deleting the device. Deletion can break entity-based automations and dashboards if replacement entities receive different identifiers.

Some firmware versions require an explicit compatibility switch in the vendor app. Depending on the product line and app version, look under Tapo Lab → Third-Party Compatibility or Settings → Third-Party Compatibility. Enable it only for devices you intend to expose to the official integration, then retry reconfiguration. This setting is preferable to an immediate factory reset because it preserves device placement, schedules and account association.

Do not test credentials with random third-party websites or paste them into terminal commands copied from strangers. If advanced testing with the official python-kasa command-line tool is necessary, run it only on a trusted computer and avoid saving the command—with its password—in shell history.

4. Correct IP-address and DHCP problems

A router restart, lease expiration or replacement can assign a different address. If Home Assistant still targets the old address, reconfigure the integration with the current IP. After it works, create a DHCP reservation in the router so the same MAC address receives the same IP. A reservation is usually safer than manually assigning an address on the device because the router remains the source of truth and can prevent conflicts.

Verify the repair by watching the integration for at least several polling cycles and operating one low-risk entity. The official integration normally polls device state every five seconds and updates immediately after a Home Assistant command. A single successful toggle is useful, but ten to fifteen minutes without another availability drop is better evidence.

If the address changes again despite a reservation, check for duplicate MAC entries, mesh nodes using isolated guest networks, or a second DHCP server. Do not solve an address conflict by choosing an arbitrary static address that might already be in the DHCP pool.

5. Handle VLANs and discovery correctly

Automatic discovery generally does not cross subnets. A Kasa or Tapo device on an IoT VLAN may work perfectly yet never appear in the Discovered section. Add the integration manually using the device’s IP address.

If manual setup also fails, temporarily place Home Assistant and the device on the same trusted test network. If the connection works there, the integration is probably healthy and the remaining issue is routing or firewall policy. Restore the intended network afterward and permit only the traffic required between Home Assistant and the device. Avoid broad “allow any” rules between an untrusted IoT VLAN and your main network.

Multicast reflection is not a universal cure. Discovery and steady-state control are separate phases: discovery may rely on local broadcast behavior, while normal control uses the device’s unicast IP. Document which phase fails before changing mDNS, IGMP or multicast settings.

6. Fix Tapo camera live view separately

Tapo camera and doorbell live view has an additional prerequisite. In the Tapo app, create or verify the camera account under Device Settings → Advanced Settings → Camera Account. This camera-specific username and password are different from the main TP-Link cloud-account credentials.

When adding or reconfiguring the integration, enable Live view and enter the camera-account credentials only in the camera fields. If you do not want live video in Home Assistant, leave Live view disabled; other supported controls can still be used.

If live view alone fails, do not reset the whole camera. First disable and re-enable the camera-account option or reset only those camera-account credentials in the Tapo app, then reconfigure Home Assistant. Review privacy mode before troubleshooting a missing stream, and never expose RTSP or camera web ports directly to the public internet.

7. Recognize removed or historical entities

Not every unavailable entity means the device is offline. The official documentation identifies historical sensors that may remain in the entity registry after integration behavior changes.

The total consumption sensor is reported by some older Kasa devices. Tapo and newer Kasa devices may not provide it. A newer device can therefore work normally while that one entity remains unavailable. Likewise, a legacy update-available binary sensor was removed because the cloud check was unstable. If an unavailable entity ends with an update-related identifier, confirm its history and documentation before deleting only that stale entity.

Deleting a stale entity is different from deleting the device or integration. Take a screenshot or note its entity ID first, confirm that no automation or dashboard depends on it, and remove only the obsolete registry entry.

8. Eliminate conflicts with custom integrations

Disable custom integrations that also communicate with the same TP-Link devices. Two integrations can compete for sessions, create duplicate devices or make error messages misleading. Restart Home Assistant after disabling the custom component, then test the official integration by itself.

Do not delete custom-component files while troubleshooting. Disable the component through its documented method, keep a record of its version and preserve a backup. If the official integration works alone, choose one integration and migrate deliberately rather than running both indefinitely.

9. Use logs without creating a privacy problem

Enable debug logging from the TP-Link integration’s menu, reproduce the failure once, then disable logging and download the file. The official documentation also describes logger entries for homeassistant.components.tplink and kasa. Debug logging can grow quickly, so do not leave it enabled.

Before sharing a log, remove account email addresses, IP addresses if your threat model requires it, camera names, Wi-Fi identifiers, tokens and any credentials. A useful escalation report includes the exact model, hardware revision, firmware version, Home Assistant version, integration error, whether the vendor app works, whether both systems share a subnet, and the least-destructive checks already completed.

Verification checklist

The device appears online in the vendor app and router client list.
Home Assistant uses the device’s current reserved IP.
The exact model and firmware are supported.
The case-sensitive TP-Link account email is correct.
Third-Party Compatibility is enabled when the firmware requires it.
Manual-IP setup is used across VLANs instead of relying on discovery.
Camera live view uses the separate camera-account credentials.
Only obsolete entities—not the whole working device—are removed.
Debug logging is turned off after the test.

Rollback and recovery

If a change makes the situation worse, restore the previous VLAN rule, move the device back to its original network, or re-enter the former integration host. Restore Home Assistant from a current backup only when configuration damage is confirmed; a network or authentication failure normally does not justify a full restore.

If you must factory-reset the device, first export or document automations, schedules, camera privacy settings, entity IDs and room assignments. Reset one device at a time. Re-add it to the official app with the exact model selection, confirm local operation, then reconfigure Home Assistant. This prevents a broad reset from hiding the original cause.

Prevent the problem from returning

Create DHCP reservations for locally controlled smart-home devices.
Record models, firmware versions, VLANs and integration ownership.
Review firmware release notes before enabling automatic updates on critical devices.
Keep a current Home Assistant backup and an offline copy of essential configuration.
Use one supported integration per device whenever possible.
Test IoT firewall changes with one noncritical device before applying them broadly.
Periodically review disabled and unavailable entities for documented removals.

Related Troubliq guides

For a protocol-neutral path, start with the Smart-Home Diagnostic Decision Tree or the Device Unavailable Diagnostic. If the symptoms began after a local address change, compare the process in WLED unavailable after an IP change. For another integration where discovery and local transport must be separated, see SwitchBot device not discovered.

Sources and review record

Last reviewed: September 20, 2026. Testing disclosure: This guide synthesizes current official documentation and documented integration behavior. Troubliq did not claim hands-on testing with every listed model or firmware version.

September 20, 2026

SwitchBot device not discovered in Home Assistant: Bluetooth and passive-mode diagnosis

Direct answer: A SwitchBot Hub is not required for Home Assistant’s SwitchBot Bluetooth integration. If a device is missing, verify working Bluetooth coverage and check whether the Home Assistant Bluetooth adapter is in Active or Passive mode. Active mode supports local discovery; Passive mode requires synchronizing nearby devices through the SwitchBot account. Trigger pairing advertisements safely, confirm the device is not connected to another app, and use account import for encrypted-device keys when required.

Last reviewed: September 15, 2026. Applies to current Home Assistant installations using the official integration named below; menus can vary slightly by release and installation type.

Symptoms and scope

The device may never appear in discovered integrations, appear only intermittently, expose sensors but not controls, or remain unavailable after moving Home Assistant. Multiple identical models can also be confused if their Bluetooth addresses were not recorded. Discovery failure is not proof that a cloud hub is required.

Prerequisites and evidence to preserve

Identify the exact model, firmware, Bluetooth address when available, distance and obstructions to the nearest Home Assistant Bluetooth adapter or proxy, and whether the device is already linked to a SwitchBot account. Confirm Home Assistant’s Bluetooth integration itself is healthy before diagnosing one product.

Likely causes

1. No working Bluetooth adapter or proxy can hear the device reliably.

2. The device is not advertising until a button press or power cycle.

3. Home Assistant’s Bluetooth adapter is configured in Passive mode, which requires SwitchBot account synchronization instead of local discovery.

4. Encrypted device data requires a key imported from the account or entered securely.

5. The device is connected to another app, or two same-model devices were confused because their Bluetooth addresses were not verified.

Least-destructive diagnostic sequence

Step 1: Open the Bluetooth integration and verify at least one active adapter or proxy. Confirm other nearby Bluetooth devices are being received. If all Bluetooth devices disappeared together, repair the shared adapter path first.

Step 2: Move temporarily within reasonable range without permanently relocating equipment. Bluetooth uses low power and walls, metal enclosures, appliances, and USB interference can matter. A brief close-range discovery test distinguishes coverage from configuration.

Step 3: For devices with a physical button, follow the documented hold action to enter pairing mode. For devices without a button, power-cycle once to trigger advertising. Avoid repeated resets; advertising and factory reset are different operations.

Step 4: Wait through a realistic discovery interval and check discovered integrations. Record the Bluetooth address so identical devices can be distinguished. Do not add whichever same-model entry appears first without verification.

Step 5: Check the Bluetooth adapter’s Add mode. In Active mode, devices are normally discovered locally; if one remains missing, verify it is powered, in range, and not connected to another app. In Passive mode, local scanning cannot add devices directly, so synchronize nearby devices through the SwitchBot account.

Step 6: For encrypted models, use the supported account-import method where possible, or enter the key ID and encryption key only in Home Assistant’s secure setup interface. Never paste encryption keys into forums, screenshots, or chat.

Step 7: If using account synchronization, understand that SSO accounts such as Login with Google are not supported by the integration’s username-and-password flow according to the documentation. Do not weaken account security or reuse passwords to work around that limitation.

Step 8: After addition, verify several state updates and one safe command if the device supports control. Then move back to the intended location and confirm the signal path remains reliable.

Diagnostic asset: choose the next branch

Discovery decision tree: no Bluetooth devices visible means repair the adapter or proxy; an Active-mode adapter with only this device missing means trigger advertising, confirm support, and disconnect other apps; a Passive-mode adapter means synchronize the SwitchBot account; encrypted data without usable entities means import the correct key securely; discovery only at close range means improve Bluetooth proxy placement rather than resetting.

Deeper checks when the first sequence does not solve it

Begin with observation rather than removal. In Settings, Devices & services, open the integration entry and compare the integration status with individual entity states. Write down exactly what is unavailable, what remains responsive, and when the change began. This boundary prevents a narrow entity problem from being treated as a complete integration failure.

Check Settings, System, Repairs before changing configuration. A repair notice can describe a migration, deprecated behavior, reauthentication requirement, or duplicate-device correction more accurately than a generic entity state. Read the notice fully and record its wording before dismissing or applying it.

Use the device’s own local controls or official app as a comparison, but interpret that test carefully. A working vendor app may use a cloud path while Home Assistant uses the local network; conversely, a local device may work while its cloud account is unavailable. The comparison narrows the path but does not by itself identify the fault.

Build a short timeline from router events, Home Assistant updates, integration reloads, firmware changes, power interruptions, account changes, and the first failed automation. Correlation is not proof, but a reliable timeline tells you which evidence to inspect and which unrelated changes to leave alone.

Inspect diagnostics without publishing secrets. Useful evidence includes exact timestamps, sanitized error classes, addresses within your private network when appropriate, firmware versions, integration versions, and whether failures are continuous or intermittent. Remove tokens, cookies, serial numbers, email addresses, coordinates, and encryption material.

Change one variable at a time. After each change, repeat the same test and record the result. Simultaneously restarting the router, Home Assistant, bridges, and devices destroys the evidence needed to learn which action mattered and makes recurrence harder to prevent.

Prefer reload over restart when the integration supports it. Prefer reconfigure over delete-and-add when the host or account changed. Prefer a DHCP reservation over hard-coding addresses independently in several places. These choices preserve registry relationships and provide a simpler rollback.

Treat factory reset as recovery, not diagnosis. Before any reset, document pairings, automations, scenes, dashboards, entity IDs, network assignments, encryption keys, and manufacturer-specific recovery requirements. If those cannot be preserved, escalate before resetting.

When service returns, verify both directions: Home Assistant should read fresh state from the device, and a safe command from Home Assistant should be reflected by the device. Also confirm that a physical or vendor-app change is reported back to Home Assistant.

Test the real workflow, not only the device page. Trigger a representative automation in a controlled way, inspect its trace, confirm conditions and targets, and restore the previous state. A device can be healthy while an automation still points to an old entity.

Check recurrence across a normal operating period. Include at least one integration refresh, a DHCP lease check, or the next expected sensor update. For battery equipment, allow for its documented reporting interval instead of assuming silence means failure.

Create a rollback note containing the former value, new value, change time, and verification result. If the change worsens availability or creates duplicate entities, restore the known-good value before trying the next hypothesis.

Escalate with a compact evidence bundle when the problem survives safe local checks: model, firmware, Home Assistant version, integration name, sanitized first error, network topology relevant to the path, steps already attempted, and the smallest reliable reproduction. This gives maintainers actionable information without exposing the household.

Prevent recurrence by documenting address reservations, account ownership, update practices, backup location, integration-specific dependencies, and recovery contacts. Review these notes after router, firmware, or Home Assistant changes rather than waiting for the next outage.

Avoid unsupported certainty. An unavailable state describes a communication result, not necessarily a failed device. Power, privacy controls, address changes, authentication, sleeping behavior, rate limits, firmware, and network policy can create similar symptoms, so evidence must select the branch.

If the problem began immediately after an update, read the official integration documentation and current release notes before downgrading. A migration or renamed entity may be expected. Downgrades can introduce database incompatibility and should never be the first response to a single unavailable entity.

If several unrelated integrations fail together, stop device-specific troubleshooting. Check Home Assistant host health, DNS, time synchronization, network interfaces, Bluetooth or radio adapters, and upstream internet only where the affected integrations require it. Shared failures usually have a shared dependency.

If only one entity fails while sibling entities from the same device remain current, inspect whether it is disabled, unsupported, conditionally exposed, asleep, or dependent on a specific feature. Re-pairing the entire device is disproportionate until those possibilities are excluded.

Verification checklist

Confirm the integration reports loaded, the affected entities have current timestamps, state changes travel in both directions, and the original automation or dashboard works with the expected entity. Repeat the test after a normal reload. Do not declare success from a single momentary update.

Check that no duplicate device or replacement entity appeared. If a new entity ID was created, compare it with automations, scripts, scenes, dashboards, voice-assistant exposure, and history before removing or renaming anything.

Rollback and recovery

If the latest change made the system worse, restore the recorded prior address, option, entity reference, or integration configuration. Reload once and retest. If rollback cannot restore the known-good state, stop making changes, preserve logs, and use the evidence bundle described above.

Safety and privacy warning

Do not disassemble mains-powered SwitchBot products, defeat locks, or repeatedly operate motors against an obstruction. Account synchronization may share device identifiers and encryption material with Home Assistant; protect backups and diagnostic exports accordingly.

Prevention

Keep Home Assistant, the official integration, and device firmware within supported versions, but avoid changing all layers on the same day. Maintain a current backup, reserve stable network addresses where appropriate, label devices by MAC address, and review logs after planned maintenance.

Related Troubliq guides

Start with the Smart-Home Diagnostic Decision Tree, visit the category hub, and compare these related guides: esphome offline still on wifi, matter device unavailable home assistant, homekit device already paired home assistant.

Sources

Primary source: Home Assistant SwitchBot Bluetooth integration documentation. This guide synthesizes the official behavior into a conservative diagnostic order; it does not claim hands-on testing of every model or network.

Frequently asked diagnostic questions

Is a SwitchBot Hub required?

No. Home Assistant’s official SwitchBot Bluetooth documentation explicitly states that a hub is not required. What is required is working Bluetooth coverage from Home Assistant or a suitable proxy.

Why does power cycling sometimes help discovery?

Some devices advertise more actively after a button action or power cycle. This is different from factory reset and can make the device visible without erasing configuration.

What is passive mode?

Passive mode is a Home Assistant Bluetooth adapter setting, not a SwitchBot product type. With the adapter in Passive mode, devices cannot be added through local Bluetooth scanning and must be synchronized through the SwitchBot account while they are within Bluetooth range.

Why would an encryption key be needed?

Some SwitchBot device types encrypt Bluetooth data. Home Assistant needs the correct key ID and encryption key, imported through the supported account route or entered securely.

Can I use Login with Google for synchronization?

The documented integration login flow does not support SSO accounts such as Login with Google. Do not weaken security or share credentials to work around it.

How do I distinguish two identical devices?

Record and compare their Bluetooth MAC addresses, trigger one device at a time, and verify a physical state change. Names and model numbers alone are not sufficient.

Final verification record

Record the date, Home Assistant version, device firmware, integration status, entity IDs checked, commands tested, state-update interval observed, and any network or account change that solved the failure. This record turns today’s repair into a faster and safer response if the symptom returns.

What not to do

Do not respond to an unavailable state by deleting every related device, clearing registries, changing several network rules, or restoring an old backup without first proving the scope. Those actions can create duplicate entities, break historical continuity, invalidate automation targets, and erase the best evidence. Do not follow screenshots from older releases when the current official integration flow differs.

Avoid disabling firewalls, privacy controls, encryption, account protections, or electrical safety features as a test. A safer test is narrow, timed, documented, and reversible. If a proposed action cannot be rolled back or its effect is unclear, collect diagnostics and escalate instead of experimenting on a live household system.

Maintenance check after recovery

One day after recovery, review entity history for another unavailable period, confirm the router or account still shows the expected relationship, and inspect the automation trace from a normal run. Remove temporary diagnostic logging so secrets and storage use do not accumulate, but keep a sanitized summary of the cause and verified fix.

September 20, 2026

Shelly unavailable in Home Assistant: CoIoT, RPC, VLAN, and security diagnostics

Direct answer: When a Shelly device is unavailable in Home Assistant, first confirm that the device still has the expected local IP address and that its own web interface opens from the same network. Then identify the hardware generation. Generation 1 devices depend on CoIoT push traffic, normally sent by unicast to the Home Assistant host on UDP port 5683. Generation 2 and newer devices use RPC and usually require no extra push configuration, although some battery-powered devices may need a correct outbound WebSocket address. Do not factory-reset the device until you have separated an IP or Wi-Fi problem from a CoIoT, WebSocket, VLAN, HTTPS, or authentication problem.

Scope and versions: This guide applies to the official Shelly integration in current Home Assistant releases and to supported Shelly generations. It focuses on local communication between Home Assistant and the device. Shelly BLU devices are a special case: most use the BTHome integration rather than the Shelly integration, while the Shelly BLU TRV is handled differently through a supported gateway. Menu names vary by Shelly generation and firmware, so use the device-generation branch that matches the hardware rather than copying a setting from another model.

Symptoms this guide covers

The Shelly integration shows a device or entities as unavailable.
Switching a relay from Home Assistant fails, but the physical input still works.
The device responds slowly or entity states update only after a delay.
Home Assistant reports that push updates are not reaching it.
A device became unavailable after moving Home Assistant, changing its IP address, adding a VLAN, replacing a router, or enabling Enhanced Security.
A battery-powered Shelly appears only briefly or stopped reporting after a Home Assistant migration.
The Shelly web interface works, but Home Assistant does not receive current state changes.

This guide does not assume that every unavailable state has the same cause. A dead device, unstable Wi-Fi, a changed DHCP lease, blocked local traffic, stale integration configuration, and missing push updates can look similar in the dashboard but require different fixes.

Safety and privacy before troubleshooting

Electrical safety: Many Shelly products are installed behind switches, inside electrical boxes, or near mains voltage. Do not open an enclosure, remove a wall switch, touch terminals, or work on energized wiring to perform network troubleshooting. Use only the device web interface, router, and Home Assistant controls described here. If power cycling requires access to fixed wiring, use the appropriate circuit breaker only if you can identify it safely, or use a qualified electrician.

Before changing configuration, record the device model, generation, firmware version, current IP address, Home Assistant entity IDs, automation references, and any existing CoIoT or WebSocket value. Take screenshots that do not expose passwords, tokens, public IP addresses, precise location data, or wireless credentials. Never post a full Home Assistant diagnostic download publicly without reviewing and redacting it.

Ranked causes

The device is offline or has a different IP address. DHCP changes, weak Wi-Fi, access-point roaming, client isolation, or a router replacement can break the route Home Assistant previously used.
Generation 1 CoIoT push traffic is not reaching Home Assistant. CoIoT may be disabled, the unicast peer may contain an old Home Assistant address, UDP 5683 may be blocked, or the device may not have been restarted after changing the peer.
A VLAN or firewall permits web access but blocks device-to-server traffic. Opening the Shelly page from a laptop proves that one path works; it does not prove that the Shelly can send push traffic to Home Assistant.
A Generation 2+ battery device has a stale outbound WebSocket address. This can occur after moving Home Assistant or changing its internal address.
Enhanced Security or HTTPS configuration changed. On supported Gen2+ firmware, secure local communication can require the expected port and certificate-verification choice.
The integration entry contains stale host information or credentials. This is less common than basic reachability problems and should be addressed after the device and route are verified.
The device is the wrong product type for the Shelly integration. Most Shelly BLU sensors use BTHome, not the Shelly integration.

Step 1: identify the device generation and connection path

Do not begin with a reset. Open the device information in Home Assistant or the local Shelly interface and identify the exact model and generation. The official integration documentation distinguishes four generations and explains that their update paths differ. Generation 1 uses CoIoT. Generation 2 and newer use RPC. That distinction determines which network setting matters.

If the product is a Shelly BLU sensor, check whether it belongs in the BTHome integration. A device appearing in Bluetooth discovery but not in the Shelly integration may be behaving normally. Correct classification prevents unnecessary firmware changes and resets.

Step 2: verify power, IP address, and local reachability

Confirm the device has power using its normal, safe indicator or physical behavior.
Check the router or DHCP server for the device’s current lease.
Compare that address with the host shown in Home Assistant.
From a device on the same trusted LAN, open the Shelly’s local web interface.
Record the firmware version and Wi-Fi signal information if shown.

Interpretation: If the local page does not open and the router has no current lease, troubleshoot power and Wi-Fi before changing Home Assistant. If the router shows a new address and the local page opens there, reserve that address in DHCP and allow Home Assistant to rediscover or reconfigure the device. Do not assign a static address inside the device and a conflicting reservation in the router.

If the device page opens but Home Assistant still reports unavailable, the problem has narrowed to the route between the two endpoints, integration configuration, authentication, or the generation-specific push channel.

Step 3: distinguish complete unavailability from missing push updates

Try one low-risk control from Home Assistant and then change the device through its local web interface or safe physical input. Observe whether Home Assistant eventually catches up.

No control and no state: investigate IP reachability, routing, HTTPS, credentials, and integration host information.
Control works but state updates are delayed or absent: investigate CoIoT on Gen1 or outbound WebSocket behavior on the affected Gen2+ battery devices.
Only one entity is unavailable: review whether the entity is supported, disabled, diagnostic, or dependent on a sensor channel. A whole-device network repair may not be appropriate.
All local devices on one VLAN fail together: suspect routing, firewall, multicast, or client-isolation policy before editing each device.

Step 4: repair Generation 1 CoIoT safely

For a Generation 1 device, open its local interface and verify that CoIoT is enabled. The official Home Assistant Shelly documentation recommends unicast and specifies the Home Assistant server’s local IP address with port 5683 as the CoIoT peer. Use the address Home Assistant actually has on the local network, not its public domain, a Cloudflare address, or a remote-access URL.

Record the existing CoIoT peer.
Confirm Home Assistant’s stable internal IP address.
Set the peer to HOME_ASSISTANT_IP:5683.
Save the setting.
Restart the Shelly device as instructed by the official documentation.
Wait for it to reconnect before testing state changes.

Battery-operated Generation 1 devices require this unicast configuration even when connected by USB. If the Shelly and Home Assistant are on different subnets, allow the necessary UDP 5683 traffic from the device network to the Home Assistant host. Create the narrowest rule that fits the path; do not expose UDP 5683 to the internet and do not disable an entire firewall as a test.

If the CoIoT setting is missing, check whether the device firmware is extremely old. Review the manufacturer’s release information and update through the official device interface only after preserving settings and confirming stable power. Do not interrupt a firmware update.

Step 5: check Generation 2+ RPC and outbound WebSocket

Generation 2 and newer devices use RPC and normally need no additional configuration. Therefore, do not add a WebSocket merely because a mains-powered Gen2 device is unavailable. Start with IP reachability, routing, authentication, and security settings.

The documented exception is certain battery-operated devices, including devices temporarily connected by USB, when Home Assistant cannot determine the correct internal URL or when the device still points to a different Home Assistant instance. In that case, check Settings → Connectivity → Outbound WebSocket in the device interface. The documented path uses:

ws://HOME_ASSISTANT_LOCAL_IP:8123/api/shelly/ws

If the local Home Assistant endpoint itself uses HTTPS with a suitable certificate, use the corresponding wss:// form. Do not use wss:// simply because the public website or remote-access domain uses HTTPS; the device must be able to validate and reach the exact local endpoint configured.

After correcting a stale address, save the change and let the device reconnect. Avoid running two active Home Assistant instances that both try to control the same device during a migration.

Step 6: test VLAN, firewall, and Wi-Fi behavior

A useful diagnostic is to draw the actual path: Shelly IP, wireless access point, IoT VLAN, router or firewall, and Home Assistant IP. Test each boundary. Common policy mistakes include wireless client isolation, a rule that permits established connections in only one direction, a guest network that blocks local destinations, and a firewall that allows TCP web access but not the UDP traffic needed by Gen1 CoIoT.

Do not permanently move every device to the main LAN as a shortcut. If a temporary same-network test makes the problem disappear, that result identifies a routing or policy issue. Recreate the required narrow local flow, then return the device to the intended network.

For unstable Wi-Fi, compare behavior close to the access point and review signal strength. The official documentation notes that access-point roaming can help on networks with several access points. Avoid changing channel width, roaming, band steering, multicast, and firewall rules simultaneously; one change at a time preserves the ability to identify the cause.

Step 7: review Enhanced Security and HTTPS

Supported Gen2+ devices can use Enhanced Security. The Home Assistant integration detects this and communicates over HTTPS on port 443. Devices shipped with supported newer firmware may have factory-provisioned certificates, while devices upgraded later may require a separately installed certificate before Enhanced Security can be used as intended.

If Enhanced Security was enabled immediately before the failure, confirm that Home Assistant can reach port 443 on the device and review the integration’s certificate-verification setting. Enable certificate verification only when the presented certificate chains to a certificate authority trusted by Home Assistant. Leaving verification disabled for a self-signed or internally provisioned device certificate is different from turning off encryption entirely. Do not upload unknown certificates or bypass warnings on a public interface.

Step 8: reload only after the network path is correct

Once reachability and the generation-specific channel are correct, reload the Shelly integration entry. If the device has a new IP address, allow discovery or use the supported reconfiguration flow. Avoid deleting the integration first: deletion can disrupt entity IDs, device associations, dashboards, histories, and automations without fixing the network cause.

If reauthentication is requested, use the device’s current local credentials. Do not paste passwords into logs or community posts. If a credential change is necessary, record which automations or external systems also rely on that account.

Verification checklist

The device’s local page opens at the expected reserved IP address.
Home Assistant shows the device and main entities as available.
A safe command from Home Assistant reaches the device.
A physical or local-interface change appears promptly in Home Assistant.
No new Shelly repair issue appears after a restart.
The device remains available after restarting Home Assistant.
The device remains available after restarting the router or access point.
Automations referencing the established entity IDs still run.

Verification after both endpoint and network restarts matters. A fix that works only until the next DHCP renewal or reboot is not complete.

Rollback and recovery

If a configuration change makes the device less reachable, restore the recorded CoIoT peer, WebSocket URL, security option, or DHCP reservation one change at a time. Keep Home Assistant’s integration entry intact while rolling back. If a firmware update introduced the behavior, do not install unofficial firmware or attempt an unsupported downgrade; consult the manufacturer’s documented recovery path.

A factory reset is the last resort. Before resetting, export or record device schedules, calibration, input mode, power-on behavior, Wi-Fi configuration, authentication, and automation references. For a mains-wired relay, follow the model’s official manual and use a qualified electrician when physical access is required.

When to escalate

Escalate when the device repeatedly reboots, disappears from DHCP despite good power and Wi-Fi, rejects its own local interface, shows certificate errors you cannot explain, or remains unavailable after the documented local path is verified. Provide the exact model, generation, firmware, Home Assistant version, installation type, network topology, redacted error text, and whether local control works. State whether the failure affects command traffic, push updates, or both.

Do not publish device credentials, backup archives, serial numbers that function as secrets, precise public addressing, or unredacted diagnostics. Community reports can help identify patterns, but the official integration and manufacturer documentation should control safety-sensitive changes.

Prevention

Reserve stable DHCP addresses for Home Assistant and fixed smart-home infrastructure.
Document Gen1 CoIoT peers and Gen2+ WebSocket settings before migrations.
Use narrow, documented firewall rules between IoT networks and Home Assistant.
Change one network or security setting at a time and verify afterward.
Maintain a current Home Assistant backup before integration or network migrations.
Review repair notifications instead of disabling them without understanding the tradeoff.
Keep firmware current through official channels, with stable power during updates.
Preserve entity IDs when reconfiguring to avoid breaking automations.

Diagnostic matrix

Observed result	Most likely layer	Next safe check
No DHCP lease or local page	Power or Wi-Fi	Confirm safe power state, access point association, and signal
Local page works; no Home Assistant control	Routing, host, HTTPS, or credentials	Compare IP, ports, VLAN route, and integration entry
Control works; state is stale on Gen1	CoIoT push path	Enable CoIoT, verify unicast peer and UDP 5683
Battery Gen2+ stopped after migration	Outbound WebSocket	Remove the old Home Assistant address and set the current local endpoint
Failure began after Enhanced Security	HTTPS or certificate handling	Verify port 443, certificate source, and Verify SSL choice
Every device on one IoT VLAN fails	Network policy	Inspect routing, isolation, and narrowly scoped firewall rules

Sources and testing disclosure

Testing disclosure: This guide is based on current official documentation and protocol-specific diagnostic reasoning. Troubliq did not claim hands-on testing with every Shelly generation, firmware revision, network topology, or security configuration.

Last reviewed: September 18, 2026.

Continue troubleshooting

September 20, 2026

WLED unavailable in Home Assistant after an IP change: reconfigure without resetting

Direct answer: When WLED becomes unavailable after a router restart—or Home Assistant reports “MAC address does not match the configured device”—identify the controller by MAC address and verify its current IP. Discovery may update a changed address automatically; if it does not, use Reconfigure on the affected WLED integration and enter the verified address. Reserve that address afterward to prevent DHCP reuse. Do not reset the controller.

Last reviewed: September 14, 2026. Applies to current Home Assistant installations using the official integration named below; menus can vary slightly by release and installation type.

Symptoms and scope

The WLED web interface may still work at a new address while Home Assistant shows every related light, sensor, button, and update entity as unavailable. If the web interface is also unreachable, the problem is broader than Home Assistant and may involve power, Wi-Fi credentials, VLAN policy, or the device itself.

Prerequisites and evidence to preserve

Confirm the controller runs WLED 0.14.0 or newer, which the current Home Assistant integration requires. Record the WLED device name, MAC address, old address, current router lease, firmware version, segments, presets, and Home Assistant entity IDs. Export WLED configuration before risky firmware or reset work. Confirm the outlet or controller is electrically safe and powered.

Likely causes

1. DHCP assigned a new IP address after a lease, router, or network change.

2. Home Assistant and WLED are separated by a VLAN, guest network, or client-isolation rule.

3. The controller lost Wi-Fi credentials or is in access-point recovery mode.

4. The integration points to the right host but a firewall or duplicate address blocks communication.

5. The device is reachable but an automation references obsolete segment or entity identifiers.

Least-destructive diagnostic sequence

Step 1: Check whether the WLED controller is powered and whether its LEDs show the expected startup behavior. Do not cycle power rapidly, especially on an installation with a large power supply or inaccessible wiring.

Step 2: Open the router’s client or DHCP lease list and identify WLED by MAC address, not just hostname. Note the current address and confirm no other client is claiming the old one.

Step 3: Open the current WLED address from a device on the same relevant network path. If it loads only from ordinary Wi-Fi but not from Home Assistant’s segment, investigate routing, firewall, multicast, or client isolation rather than rebuilding WLED.

Step 4: In Home Assistant, open Settings, Devices & services, WLED, choose the affected entry, and select Reconfigure. Enter the verified current address and submit. This is the documented recovery path and preserves the integration better than delete-and-add.

Step 5: If Reconfigure fails, review Home Assistant logs for host, timeout, route, or connection errors. Compare timestamps with router events. Do not conclude that firmware is corrupt based solely on a timeout.

Step 6: After the integration reconnects, reserve the address in DHCP using the controller’s MAC address. Prefer a reservation inside the router’s managed range unless your network plan intentionally uses static addresses.

Step 7: Verify the main light entity, segments, effects, presets, diagnostic sensors, and any automations that depend on them. A green integration status does not prove every segment mapping survived a configuration change.

Step 8: Test one low-brightness command, one effect change, and restoration to the previous state. Watch for renewed unavailable transitions over at least ten minutes and after one normal Home Assistant integration reload.

Diagnostic asset: choose the next branch

Error-to-cause guide: “MAC address does not match the configured device” means the stored IP now reaches a different controller, commonly after DHCP reuse—identify the intended MAC and reconfigure its address. An old address that fails while the new WLED page works indicates an address change; neither address working with no router lease indicates power or Wi-Fi; phone access working while Home Assistant fails indicates network segmentation; a connected integration with different segments indicates WLED configuration or entity mapping changed.

Deeper checks when the first sequence does not solve it

Begin with observation rather than removal. In Settings, Devices & services, open the integration entry and compare the integration status with individual entity states. Write down exactly what is unavailable, what remains responsive, and when the change began. This boundary prevents a narrow entity problem from being treated as a complete integration failure.

Check Settings, System, Repairs before changing configuration. A repair notice can describe a migration, deprecated behavior, reauthentication requirement, or duplicate-device correction more accurately than a generic entity state. Read the notice fully and record its wording before dismissing or applying it.

Use the device’s own local controls or official app as a comparison, but interpret that test carefully. A working vendor app may use a cloud path while Home Assistant uses the local network; conversely, a local device may work while its cloud account is unavailable. The comparison narrows the path but does not by itself identify the fault.

Build a short timeline from router events, Home Assistant updates, integration reloads, firmware changes, power interruptions, account changes, and the first failed automation. Correlation is not proof, but a reliable timeline tells you which evidence to inspect and which unrelated changes to leave alone.

Inspect diagnostics without publishing secrets. Useful evidence includes exact timestamps, sanitized error classes, addresses within your private network when appropriate, firmware versions, integration versions, and whether failures are continuous or intermittent. Remove tokens, cookies, serial numbers, email addresses, coordinates, and encryption material.

Change one variable at a time. After each change, repeat the same test and record the result. Simultaneously restarting the router, Home Assistant, bridges, and devices destroys the evidence needed to learn which action mattered and makes recurrence harder to prevent.

Prefer reload over restart when the integration supports it. Prefer reconfigure over delete-and-add when the host or account changed. Prefer a DHCP reservation over hard-coding addresses independently in several places. These choices preserve registry relationships and provide a simpler rollback.

Treat factory reset as recovery, not diagnosis. Before any reset, document pairings, automations, scenes, dashboards, entity IDs, network assignments, encryption keys, and manufacturer-specific recovery requirements. If those cannot be preserved, escalate before resetting.

When service returns, verify both directions: Home Assistant should read fresh state from the device, and a safe command from Home Assistant should be reflected by the device. Also confirm that a physical or vendor-app change is reported back to Home Assistant.

Test the real workflow, not only the device page. Trigger a representative automation in a controlled way, inspect its trace, confirm conditions and targets, and restore the previous state. A device can be healthy while an automation still points to an old entity.

Check recurrence across a normal operating period. Include at least one integration refresh, a DHCP lease check, or the next expected sensor update. For battery equipment, allow for its documented reporting interval instead of assuming silence means failure.

Create a rollback note containing the former value, new value, change time, and verification result. If the change worsens availability or creates duplicate entities, restore the known-good value before trying the next hypothesis.

Escalate with a compact evidence bundle when the problem survives safe local checks: model, firmware, Home Assistant version, integration name, sanitized first error, network topology relevant to the path, steps already attempted, and the smallest reliable reproduction. This gives maintainers actionable information without exposing the household.

Prevent recurrence by documenting address reservations, account ownership, update practices, backup location, integration-specific dependencies, and recovery contacts. Review these notes after router, firmware, or Home Assistant changes rather than waiting for the next outage.

Avoid unsupported certainty. An unavailable state describes a communication result, not necessarily a failed device. Power, privacy controls, address changes, authentication, sleeping behavior, rate limits, firmware, and network policy can create similar symptoms, so evidence must select the branch.

If the problem began immediately after an update, read the official integration documentation and current release notes before downgrading. A migration or renamed entity may be expected. Downgrades can introduce database incompatibility and should never be the first response to a single unavailable entity.

If several unrelated integrations fail together, stop device-specific troubleshooting. Check Home Assistant host health, DNS, time synchronization, network interfaces, Bluetooth or radio adapters, and upstream internet only where the affected integrations require it. Shared failures usually have a shared dependency.

If only one entity fails while sibling entities from the same device remain current, inspect whether it is disabled, unsupported, conditionally exposed, asleep, or dependent on a specific feature. Re-pairing the entire device is disproportionate until those possibilities are excluded.

Verification checklist

Confirm the integration reports loaded, the affected entities have current timestamps, state changes travel in both directions, and the original automation or dashboard works with the expected entity. Repeat the test after a normal reload. Do not declare success from a single momentary update.

Check that no duplicate device or replacement entity appeared. If a new entity ID was created, compare it with automations, scripts, scenes, dashboards, voice-assistant exposure, and history before removing or renaming anything.

Rollback and recovery

If the latest change made the system worse, restore the recorded prior address, option, entity reference, or integration configuration. Reload once and retest. If rollback cannot restore the known-good state, stop making changes, preserve logs, and use the evidence bundle described above.

Safety and privacy warning

Address changes do not require opening electrical enclosures. Disconnect power before touching LED wiring or power supplies, and use appropriately rated components. Do not factory-reset WLED until configuration is exported and simple addressing and network checks are exhausted.

Prevention

Keep Home Assistant, the official integration, and device firmware within supported versions, but avoid changing all layers on the same day. Maintain a current backup, reserve stable network addresses where appropriate, label devices by MAC address, and review logs after planned maintenance.

Related Troubliq guides

Start with the Smart-Home Diagnostic Decision Tree, visit the category hub, and compare these related guides: esphome offline still on wifi, home assistant automation not triggering, mqtt entities unavailable after home assistant restart.

Sources

Primary source: Home Assistant WLED integration documentation. This guide synthesizes the official behavior into a conservative diagnostic order; it does not claim hands-on testing of every model or network.

Frequently asked diagnostic questions

Why did WLED fail after a router restart?

A new DHCP lease may have changed the controller’s address while Home Assistant retained the old host. Verify by MAC address and use the WLED integration’s Reconfigure action.

Should I delete and add WLED again?

Not for a simple address change. Reconfigure is the documented route and is more likely to preserve entity relationships, dashboards, and automations.

What if the web interface works only from my phone?

Your phone and Home Assistant may be on different VLANs or subject to different firewall and client-isolation rules. Test the route from the Home Assistant network before changing WLED.

Is a DHCP reservation better than a device static IP?

A reservation centralizes address management and avoids accidental collisions when configured correctly. Use the WLED MAC address and document the reservation.

What if the integration loads but segments changed?

Compare WLED segment and preset configuration with entity mappings. Address recovery restores communication but cannot recreate segments that were removed or renumbered on the controller.

When is a factory reset justified?

Only after configuration export and after power, Wi-Fi, address, routing, and firmware evidence rules out safer recovery. An IP mismatch never requires a reset.

Final verification record

Record the date, Home Assistant version, device firmware, integration status, entity IDs checked, commands tested, state-update interval observed, and any network or account change that solved the failure. This record turns today’s repair into a faster and safer response if the symptom returns.

What not to do

Do not respond to an unavailable state by deleting every related device, clearing registries, changing several network rules, or restoring an old backup without first proving the scope. Those actions can create duplicate entities, break historical continuity, invalidate automation targets, and erase the best evidence. Do not follow screenshots from older releases when the current official integration flow differs.

Avoid disabling firewalls, privacy controls, encryption, account protections, or electrical safety features as a test. A safer test is narrow, timed, documented, and reversible. If a proposed action cannot be rolled back or its effect is unclear, collect diagnostics and escalate instead of experimenting on a live household system.

Maintenance check after recovery

One day after recovery, review entity history for another unavailable period, confirm the router or account still shows the expected relationship, and inspect the automation trace from a normal run. Remove temporary diagnostic logging so secrets and storage use do not accumulate, but keep a sanitized summary of the cause and verified fix.

September 20, 2026
Philips Hue room or zone missing in Home Assistant: safe grouped-entity fixes
Direct answer: If individual Hue bulbs appear but a room or zone light is missing, identify the bridge generation first. With a square V2 Hue Bridge, Home Assistant creates room and zone lights automatically but disables them by default; enable only the grouped entity you need. With a legacy round V1 bridge, room entities are not created automatically—turn on Allow Hue groups in the integration options. Do not delete and pair the bridge again for either condition.

Last reviewed: September 13, 2026. Applies to current Home Assistant installations using the official integration named below; menus can vary slightly by release and installation type.

Symptoms and scope

The most recognizable pattern is that individual bulbs work while an expected room or zone entity cannot be selected in a dashboard or automation. A different pattern—individual bulbs marked unavailable—indicates connectivity or device status rather than a disabled group. Establish which pattern you have before touching the bridge.

Prerequisites and evidence to preserve

Confirm the room or zone exists in the Hue app, identify the square v2 bridge if relevant, and note whether the missing item was recently renamed. Back up or screenshot automations that reference an old entity ID. Home Assistant names and entity IDs do not always follow later Hue app renames automatically.

Likely causes

1. The automatically created grouped room or zone entity is disabled by default.

2. The Hue room or zone changed and the old Home Assistant entity is stale or renamed.

3. A sleeping battery remote is reported unavailable even though lights work.

4. The bridge address or local network path changed.

5. An automation references an individual bulb or an obsolete group entity.

Least-destructive diagnostic sequence

Step 1: Go to Settings, Devices & services, Philips Hue, then open the entities list. Include disabled entities in the filter and search for the exact room or zone. Confirm the entity belongs to the expected bridge before enabling it.

Step 2: Enable the grouped entity and wait for a normal integration refresh. Do not enable every disabled entity; a selective setup keeps dashboards and automations understandable.

Step 3: Open the entity details and verify it controls the intended set of lamps. Test on, off, and a modest brightness change. If membership is wrong, correct the room or zone in Hue first and allow Home Assistant to refresh.

Step 4: If the entity exists but is unavailable, test individual lights and the bridge. A group cannot be healthier than its underlying bridge connection, but one unreachable bulb should not automatically justify rebuilding the entire bridge integration.

Step 5: For v2 bridges, review the integration option that can ignore connectivity status for selected devices. This is intended for cases such as sleeping battery remotes; do not use it to conceal a genuinely unreachable mains-powered lamp.

Step 6: Check automations, scripts, and dashboards for the former entity ID. If a rename created a new ID, update references carefully and keep a rollback note. Test manual control before testing automation behavior.

Step 7: Review logs only after reproducing one controlled failure. Record whether the command reached the bridge and whether the bridge rejected it, timed out, or reported a device unavailable.

Step 8: After changes, verify the grouped state follows manual changes made in both Home Assistant and Hue. A usable group should not merely accept one command; it should report subsequent state consistently.

Diagnostic asset: choose the next branch

State matrix: on a square V2 bridge, missing from selectors plus visible under disabled entities means enable the group; on a round V1 bridge, no room entity means check whether Allow Hue groups is enabled. Present but unavailable plus bridge unavailable means repair bridge connectivity; a working group with one failed bulb means diagnose that bulb; a sleeping remote alone may reflect connectivity reporting rather than a broken lighting network.

Deeper checks when the first sequence does not solve it

Begin with observation rather than removal. In Settings, Devices & services, open the integration entry and compare the integration status with individual entity states. Write down exactly what is unavailable, what remains responsive, and when the change began. This boundary prevents a narrow entity problem from being treated as a complete integration failure.

Check Settings, System, Repairs before changing configuration. A repair notice can describe a migration, deprecated behavior, reauthentication requirement, or duplicate-device correction more accurately than a generic entity state. Read the notice fully and record its wording before dismissing or applying it.

Use the device’s own local controls or official app as a comparison, but interpret that test carefully. A working vendor app may use a cloud path while Home Assistant uses the local network; conversely, a local device may work while its cloud account is unavailable. The comparison narrows the path but does not by itself identify the fault.

Build a short timeline from router events, Home Assistant updates, integration reloads, firmware changes, power interruptions, account changes, and the first failed automation. Correlation is not proof, but a reliable timeline tells you which evidence to inspect and which unrelated changes to leave alone.

Inspect diagnostics without publishing secrets. Useful evidence includes exact timestamps, sanitized error classes, addresses within your private network when appropriate, firmware versions, integration versions, and whether failures are continuous or intermittent. Remove tokens, cookies, serial numbers, email addresses, coordinates, and encryption material.

Change one variable at a time. After each change, repeat the same test and record the result. Simultaneously restarting the router, Home Assistant, bridges, and devices destroys the evidence needed to learn which action mattered and makes recurrence harder to prevent.

Prefer reload over restart when the integration supports it. Prefer reconfigure over delete-and-add when the host or account changed. Prefer a DHCP reservation over hard-coding addresses independently in several places. These choices preserve registry relationships and provide a simpler rollback.

Treat factory reset as recovery, not diagnosis. Before any reset, document pairings, automations, scenes, dashboards, entity IDs, network assignments, encryption keys, and manufacturer-specific recovery requirements. If those cannot be preserved, escalate before resetting.

When service returns, verify both directions: Home Assistant should read fresh state from the device, and a safe command from Home Assistant should be reflected by the device. Also confirm that a physical or vendor-app change is reported back to Home Assistant.

Test the real workflow, not only the device page. Trigger a representative automation in a controlled way, inspect its trace, confirm conditions and targets, and restore the previous state. A device can be healthy while an automation still points to an old entity.

Check recurrence across a normal operating period. Include at least one integration refresh, a DHCP lease check, or the next expected sensor update. For battery equipment, allow for its documented reporting interval instead of assuming silence means failure.

Create a rollback note containing the former value, new value, change time, and verification result. If the change worsens availability or creates duplicate entities, restore the known-good value before trying the next hypothesis.

Escalate with a compact evidence bundle when the problem survives safe local checks: model, firmware, Home Assistant version, integration name, sanitized first error, network topology relevant to the path, steps already attempted, and the smallest reliable reproduction. This gives maintainers actionable information without exposing the household.

Prevent recurrence by documenting address reservations, account ownership, update practices, backup location, integration-specific dependencies, and recovery contacts. Review these notes after router, firmware, or Home Assistant changes rather than waiting for the next outage.

Avoid unsupported certainty. An unavailable state describes a communication result, not necessarily a failed device. Power, privacy controls, address changes, authentication, sleeping behavior, rate limits, firmware, and network policy can create similar symptoms, so evidence must select the branch.

If the problem began immediately after an update, read the official integration documentation and current release notes before downgrading. A migration or renamed entity may be expected. Downgrades can introduce database incompatibility and should never be the first response to a single unavailable entity.

If several unrelated integrations fail together, stop device-specific troubleshooting. Check Home Assistant host health, DNS, time synchronization, network interfaces, Bluetooth or radio adapters, and upstream internet only where the affected integrations require it. Shared failures usually have a shared dependency.

If only one entity fails while sibling entities from the same device remain current, inspect whether it is disabled, unsupported, conditionally exposed, asleep, or dependent on a specific feature. Re-pairing the entire device is disproportionate until those possibilities are excluded.

Verification checklist

Confirm the integration reports loaded, the affected entities have current timestamps, state changes travel in both directions, and the original automation or dashboard works with the expected entity. Repeat the test after a normal reload. Do not declare success from a single momentary update.

Check that no duplicate device or replacement entity appeared. If a new entity ID was created, compare it with automations, scripts, scenes, dashboards, voice-assistant exposure, and history before removing or renaming anything.

Rollback and recovery

If the latest change made the system worse, restore the recorded prior address, option, entity reference, or integration configuration. Reload once and retest. If rollback cannot restore the known-good state, stop making changes, preserve logs, and use the evidence bundle described above.

Safety and privacy warning

Keep wall power supplied to smart bulbs unless the manufacturer’s procedure says otherwise. Rapidly toggling mains power can trigger reset sequences on some products. Do not reset the Hue Bridge or remove it from the account merely to reveal a disabled Home Assistant entity.

Prevention

Keep Home Assistant, the official integration, and device firmware within supported versions, but avoid changing all layers on the same day. Maintain a current backup, reserve stable network addresses where appropriate, label devices by MAC address, and review logs after planned maintenance.

Related Troubliq guides

Start with the Smart-Home Diagnostic Decision Tree, visit the category hub, and compare these related guides: home assistant automation not triggering, zigbee device wont pair zha, duplicate devices home assistant 2026 8 repair.
Evidence, applicability, and safe verification
- Applies to: the Home Assistant Philips Hue integration using a Hue Bridge, including the different grouped-light behavior described for bridge API generations. It does not assume that a Matter-paired Hue device exposes the same room and zone model.
- Primary symptom: an individual bulb is present but its Hue room or zone entity appears missing, disabled, renamed, or unavailable in Home Assistant.
- Least-destructive check: open the integration’s device and entity lists and look for a disabled grouped-light entity before reloading, deleting, or re-pairing anything. A disabled entity is not the same as a failed bridge.
- Expected result: enabling the correct grouped entity restores a stable room or zone control without changing bulb membership on the Hue Bridge. If individual lights are also unavailable, diagnose bridge reachability first.
- Verification: toggle the group once from Home Assistant, confirm the expected bulbs respond, then run one existing automation that references the entity. Check entity history for repeated unavailable transitions.
- Rollback: disable the newly enabled entity again or restore the previous automation entity ID. Do not remove the Hue integration merely to expose a disabled group; removal can break entity references.
- Privacy and safety: redact bridge IP addresses, diagnostics, device identifiers, area names, and automation details before sharing logs. Do not reset a bridge unless its configuration is backed up and simpler checks have failed.
- Testing disclosure: this guide synthesizes current Home Assistant documentation into a conservative diagnostic order. Troubliq did not physically test every Hue Bridge generation, firmware version, light, or network.
- Last reviewed: September 30, 2026.
Sources

Primary sources: Home Assistant Philips Hue integration documentation and the Home Assistant Matter documentation. This guide synthesizes official behavior into a conservative diagnostic order; it does not claim hands-on testing of every bridge, light, or network.

Frequently asked diagnostic questions

Why can I see bulbs but not the Hue room?

Home Assistant creates Hue room and zone groups but disables them by default. Show disabled entities under the Hue integration, identify the exact group, and enable only what you intend to use.

Does an unavailable Hue remote mean the Zigbee network is broken?

Not necessarily. Battery remotes sleep, and Hue v2 bridge options can ignore connectivity status for selected devices. Verify lighting operation and device history before changing that option.

Should I add my Hue Bridge through Matter instead?

The official Matter documentation notes that the native Hue integration provides broader features and local operation; Matter bridging can expose fewer features. A missing disabled group is not a reason to migrate.

Will renaming a room update every automation?

Do not assume it will. Compare the Home Assistant entity ID before and after the rename and inspect automation targets. Friendly-name changes and entity-ID changes are different.

What if the group turns on but its state is wrong?

Allow a refresh, then compare individual bulb reachability and changes made in the Hue app. A group with an unreachable member or stale bridge report can appear inconsistent.

When should I rebuild the bridge integration?

Only after bridge authentication or connectivity is confirmed irrecoverable and configuration has been documented. Enabling a grouped entity, correcting membership, or fixing an address is less destructive.

Final verification record

Record the date, Home Assistant version, device firmware, integration status, entity IDs checked, commands tested, state-update interval observed, and any network or account change that solved the failure. This record turns today’s repair into a faster and safer response if the symptom returns.

What not to do

Do not respond to an unavailable state by deleting every related device, clearing registries, changing several network rules, or restoring an old backup without first proving the scope. Those actions can create duplicate entities, break historical continuity, invalidate automation targets, and erase the best evidence. Do not follow screenshots from older releases when the current official integration flow differs.

Avoid disabling firewalls, privacy controls, encryption, account protections, or electrical safety features as a test. A safer test is narrow, timed, documented, and reversible. If a proposed action cannot be rolled back or its effect is unclear, collect diagnostics and escalate instead of experimenting on a live household system.

Maintenance check after recovery

One day after recovery, review entity history for another unavailable period, confirm the router or account still shows the expected relationship, and inspect the automation trace from a normal run. Remove temporary diagnostic logging so secrets and storage use do not accumulate, but keep a sanitized summary of the cause and verified fix.
September 20, 2026
Ecobee integration unavailable in Home Assistant after 2026.3: authentication recovery

Direct answer: For Home Assistant 2026.3 and later, new Ecobee setup no longer requires obtaining a developer API key. Existing keys can continue working, but official documentation warns that revoking an existing key breaks that integration and requires removing the service from Home Assistant and setting it up again. Diagnose authentication before changing thermostat wiring, schedules, or HVAC settings.

Last reviewed: September 12, 2026. Applies to current Home Assistant installations using the official integration named below; menus can vary slightly by release and installation type.

Symptoms and scope

The Ecobee device may appear unavailable, stop updating temperature and occupancy, reject setpoint changes, or request reauthentication after an upgrade or account change. If the physical thermostat still controls heating and cooling normally, treat this first as an integration or cloud-authentication problem, not an HVAC hardware failure.

Prerequisites and evidence to preserve

Confirm the Home Assistant version is 2026.3 or later, the thermostat works locally, and the Ecobee account can see the device. Record entity IDs, dashboards, automations, helpers, and any legacy API-key history before removal. Do not expose tokens, cookies, passwords, or developer keys in logs or support posts.

Likely causes

1. A legacy Ecobee developer key was revoked or its authorization changed.

2. The Ecobee account session requires reauthentication.

3. The integration is temporarily unable to reach the cloud service.

4. An entity ID or device mapping changed after re-setup.

5. The thermostat itself is offline, which is distinct from a Home Assistant-only integration failure.

Least-destructive diagnostic sequence

Step 1: Check the physical thermostat first. Confirm it has power, shows the expected equipment state, and can safely control the system. If the thermostat itself is blank or reports an HVAC fault, stop software troubleshooting and follow Ecobee or qualified HVAC guidance.

Step 2: Open the Ecobee integration entry and record its exact status and repair message. A reauthentication prompt is more specific than a generic unavailable entity and should be handled through the provided flow. With username-and-password setup, Home Assistant supports authenticator-app TOTP codes; push, SMS, and email MFA are not currently supported. A password change can invalidate the refresh token and trigger reauthentication.

Step 3: Review Home Assistant logs around the first failure for authentication, authorization, rate-limit, timeout, or connection messages. Redact account identifiers and secrets before sharing anything.

Step 4: If you knowingly revoked the old developer key, plan a controlled remove-and-add operation because the official documentation says the existing integration will fail. First inventory every automation and dashboard reference so they can be checked after setup.

Step 5: Before removal, export or capture important Home Assistant configuration references. Removing an integration should not erase thermostat schedules stored by Ecobee, but Home Assistant entity identifiers may be recreated differently.

Step 6: Use the current Ecobee add-integration flow rather than following old tutorials that require creating a developer key. Complete account authorization only in the legitimate account window.

Step 7: After setup, compare the new entity IDs with the saved inventory. Repair references deliberately instead of renaming multiple entities blindly. Test read-only sensor updates before sending setpoint or mode changes.

Step 8: Observe at least two normal polling cycles, then make a small safe temperature adjustment and reverse it. Confirm both Home Assistant and the thermostat show the same state.

Diagnostic asset: choose the next branch

Version decision: before 2026.3, older setup instructions may discuss developer keys; on 2026.3 and later, use the current account-linking flow. Existing legacy keys may continue, but a revoked key cannot be repaired by repeatedly reloading; inventory references, remove the failed service, and add it again.

Deeper checks when the first sequence does not solve it

Begin with observation rather than removal. In Settings, Devices & services, open the integration entry and compare the integration status with individual entity states. Write down exactly what is unavailable, what remains responsive, and when the change began. This boundary prevents a narrow entity problem from being treated as a complete integration failure.

Check Settings, System, Repairs before changing configuration. A repair notice can describe a migration, deprecated behavior, reauthentication requirement, or duplicate-device correction more accurately than a generic entity state. Read the notice fully and record its wording before dismissing or applying it.

Use the device’s own local controls or official app as a comparison, but interpret that test carefully. A working vendor app may use a cloud path while Home Assistant uses the local network; conversely, a local device may work while its cloud account is unavailable. The comparison narrows the path but does not by itself identify the fault.

Build a short timeline from router events, Home Assistant updates, integration reloads, firmware changes, power interruptions, account changes, and the first failed automation. Correlation is not proof, but a reliable timeline tells you which evidence to inspect and which unrelated changes to leave alone.

Inspect diagnostics without publishing secrets. Useful evidence includes exact timestamps, sanitized error classes, addresses within your private network when appropriate, firmware versions, integration versions, and whether failures are continuous or intermittent. Remove tokens, cookies, serial numbers, email addresses, coordinates, and encryption material.

Change one variable at a time. After each change, repeat the same test and record the result. Simultaneously restarting the router, Home Assistant, bridges, and devices destroys the evidence needed to learn which action mattered and makes recurrence harder to prevent.

Prefer reload over restart when the integration supports it. Prefer reconfigure over delete-and-add when the host or account changed. Prefer a DHCP reservation over hard-coding addresses independently in several places. These choices preserve registry relationships and provide a simpler rollback.

Treat factory reset as recovery, not diagnosis. Before any reset, document pairings, automations, scenes, dashboards, entity IDs, network assignments, encryption keys, and manufacturer-specific recovery requirements. If those cannot be preserved, escalate before resetting.

When service returns, verify both directions: Home Assistant should read fresh state from the device, and a safe command from Home Assistant should be reflected by the device. Also confirm that a physical or vendor-app change is reported back to Home Assistant.

Test the real workflow, not only the device page. Trigger a representative automation in a controlled way, inspect its trace, confirm conditions and targets, and restore the previous state. A device can be healthy while an automation still points to an old entity.

Check recurrence across a normal operating period. Include at least one integration refresh, a DHCP lease check, or the next expected sensor update. For battery equipment, allow for its documented reporting interval instead of assuming silence means failure.

Create a rollback note containing the former value, new value, change time, and verification result. If the change worsens availability or creates duplicate entities, restore the known-good value before trying the next hypothesis.

Escalate with a compact evidence bundle when the problem survives safe local checks: model, firmware, Home Assistant version, integration name, sanitized first error, network topology relevant to the path, steps already attempted, and the smallest reliable reproduction. This gives maintainers actionable information without exposing the household.

Prevent recurrence by documenting address reservations, account ownership, update practices, backup location, integration-specific dependencies, and recovery contacts. Review these notes after router, firmware, or Home Assistant changes rather than waiting for the next outage.

Avoid unsupported certainty. An unavailable state describes a communication result, not necessarily a failed device. Power, privacy controls, address changes, authentication, sleeping behavior, rate limits, firmware, and network policy can create similar symptoms, so evidence must select the branch.

If the problem began immediately after an update, read the official integration documentation and current release notes before downgrading. A migration or renamed entity may be expected. Downgrades can introduce database incompatibility and should never be the first response to a single unavailable entity.

If several unrelated integrations fail together, stop device-specific troubleshooting. Check Home Assistant host health, DNS, time synchronization, network interfaces, Bluetooth or radio adapters, and upstream internet only where the affected integrations require it. Shared failures usually have a shared dependency.

If only one entity fails while sibling entities from the same device remain current, inspect whether it is disabled, unsupported, conditionally exposed, asleep, or dependent on a specific feature. Re-pairing the entire device is disproportionate until those possibilities are excluded.

Verification checklist

Confirm the integration reports loaded, the affected entities have current timestamps, state changes travel in both directions, and the original automation or dashboard works with the expected entity. Repeat the test after a normal reload. Do not declare success from a single momentary update.

Check that no duplicate device or replacement entity appeared. If a new entity ID was created, compare it with automations, scripts, scenes, dashboards, voice-assistant exposure, and history before removing or renaming anything.

Rollback and recovery

If the latest change made the system worse, restore the recorded prior address, option, entity reference, or integration configuration. Reload once and retest. If rollback cannot restore the known-good state, stop making changes, preserve logs, and use the evidence bundle described above.

Safety and privacy warning

Heating and cooling equipment can be damaged by inappropriate rapid cycling or extreme setpoints. Do not alter wiring, compressor protection, installer settings, or equipment thresholds to solve an authentication error. Keep a manual way to control the thermostat while integration work is underway.

Prevention

Keep Home Assistant, the official integration, and device firmware within supported versions, but avoid changing all layers on the same day. Maintain a current backup, reserve stable network addresses where appropriate, label devices by MAC address, and review logs after planned maintenance.

Related Troubliq guides

Start with the Smart-Home Diagnostic Decision Tree, visit the category hub, and compare these related guides: home assistant automation not triggering, alexa devices integration unavailable home assistant, duplicate devices home assistant 2026 8 repair.

Sources

Primary source: Home Assistant Ecobee integration documentation. This guide synthesizes the official behavior into a conservative diagnostic order; it does not claim hands-on testing of every model or network.

Frequently asked diagnostic questions

Do I still need an Ecobee developer key?

For Home Assistant 2026.3 and later, the official integration documentation says a new developer API key is no longer required. Avoid obsolete setup guides that instruct you to create one.

What happens if I revoked the old key?

The existing integration fails and must be removed and set up again, according to the official documentation. Inventory entity references first so dashboards and automations can be repaired predictably.

Can reloading restore a revoked credential?

No. Reloading can retry a temporary connection, but it cannot make a revoked authorization valid. Use the current reauthentication or setup flow.

Why does the thermostat work while Home Assistant is unavailable?

The thermostat can continue local HVAC control and communicate through paths separate from Home Assistant’s session. That pattern points toward integration or account connectivity rather than wiring.

Should I change HVAC settings during setup?

No. Authentication recovery does not require installer settings, compressor delays, wiring, or extreme setpoints. Keep safe manual control available and test only modest reversible commands.

What should I verify after adding it again?

Compare entity IDs, temperature and occupancy updates, HVAC mode, setpoints, dashboards, automations, voice exposure, and history. Reverse any small test change and observe multiple refresh cycles.

Final verification record

Record the date, Home Assistant version, device firmware, integration status, entity IDs checked, commands tested, state-update interval observed, and any network or account change that solved the failure. This record turns today’s repair into a faster and safer response if the symptom returns.

What not to do

Do not respond to an unavailable state by deleting every related device, clearing registries, changing several network rules, or restoring an old backup without first proving the scope. Those actions can create duplicate entities, break historical continuity, invalidate automation targets, and erase the best evidence. Do not follow screenshots from older releases when the current official integration flow differs.

Avoid disabling firewalls, privacy controls, encryption, account protections, or electrical safety features as a test. A safer test is narrow, timed, documented, and reversible. If a proposed action cannot be rolled back or its effect is unclear, collect diagnostics and escalate instead of experimenting on a live household system.

Maintenance check after recovery

One day after recovery, review entity history for another unavailable period, confirm the router or account still shows the expected relationship, and inspect the automation trace from a normal run. Remove temporary diagnostic logging so secrets and storage use do not accumulate, but keep a sanitized summary of the cause and verified fix.

September 20, 2026
Reolink camera unavailable in Home Assistant: privacy mode, IP, and stream diagnostics

Direct answer: When a Reolink camera becomes unavailable in Home Assistant, check the camera’s Privacy mode entity first, then confirm its current IP address and local reachability before changing credentials or rebuilding the integration. Official documentation notes that privacy mode makes almost all Reolink entities—including streams and motion or AI detection—unavailable, and recommends a static address or DHCP reservation to prevent temporary failures after an IP change.

Last reviewed: September 9, 2026. Applies to current Home Assistant installations using the official integration named below; menus can vary slightly by release and installation type.

Symptoms and scope

Typical symptoms include a gray camera card, unavailable motion or person entities, a stream that spins indefinitely, snapshots that fail, or an integration entry that repeatedly retries. If every entity vanished at the same time, suspect privacy mode, power, address, or authentication. If sensors still update while only video fails, concentrate on stream availability, channel selection, browser playback, and the path between Home Assistant and the camera.

Prerequisites and evidence to preserve

Record the camera or NVR model, firmware, whether Home Assistant connects to a camera directly or through an NVR, the integration entry name, and the approximate failure time. Confirm that the official Reolink integration—not an old custom component—is being diagnosed. Keep the Reolink app available only as a comparison point; success in the cloud app does not prove that local access from Home Assistant works.

Likely causes

1. Privacy mode was enabled manually or by a schedule.

2. The router assigned a different camera or NVR address.

3. The camera is powered but unreachable from Home Assistant’s network or VLAN.

4. Credentials, permissions, firmware, or the selected NVR channel changed.

5. Only the video path is failing because of stream limits, codec handling, or simultaneous clients.

Least-destructive diagnostic sequence

Step 1: Open the device in Home Assistant and inspect the Privacy mode entity and its history around the outage. If it turned on, turn it off only if that matches the household’s privacy expectations; never automate around a deliberately enabled privacy control.

Step 2: From the router, identify the camera by MAC address and compare its lease with the address stored by the integration. Do not guess from a similarly named device. If the address changed, use the integration’s reconfigure flow when available, then create a DHCP reservation after service is restored.

Step 3: Verify the camera responds from the same network segment as Home Assistant. Test its local web interface or a basic network reachability check without exposing the camera to the internet. A phone on ordinary Wi-Fi may take a different path than Home Assistant on a server VLAN.

Step 4: Review Settings, System, Logs and filter around the failure time for Reolink, connection, authentication, timeout, host, stream, or channel messages. Preserve exact timestamps and the first error in a sequence; later timeout noise is often a consequence rather than the cause.

Step 5: If an NVR is involved, confirm the affected camera remains assigned to the same NVR channel and that the account used by Home Assistant can access that channel. Avoid deleting the integration simply because one channel changed.

Step 6: Separate entity availability from video playback. Check whether motion, person, battery, or diagnostic sensors still update. If they do, the integration session works and a full reset is unlikely to help; investigate the video-specific path and concurrent viewer load.

Step 7: Reload the Reolink integration once after correcting a confirmed cause. Repeated reloads can hide the timing evidence and add connection pressure. Restart Home Assistant only if logs or the integration explicitly indicate that a reload did not clear stale state.

Step 8: Test one live view and one snapshot after recovery, then close extra viewers and confirm motion entities update. Verification should include at least ten minutes without renewed unavailable states, not merely a single successful frame.

Diagnostic asset: choose the next branch

Decision guide: all entities unavailable points first to privacy mode, power, IP, or authentication; sensors available but video unavailable points to the stream path; one NVR channel missing points to channel mapping or permissions; intermittent failures point to addressing, Wi-Fi quality, connection limits, or network policy.

Deeper checks when the first sequence does not solve it

Begin with observation rather than removal. In Settings, Devices & services, open the integration entry and compare the integration status with individual entity states. Write down exactly what is unavailable, what remains responsive, and when the change began. This boundary prevents a narrow entity problem from being treated as a complete integration failure.

Check Settings, System, Repairs before changing configuration. A repair notice can describe a migration, deprecated behavior, reauthentication requirement, or duplicate-device correction more accurately than a generic entity state. Read the notice fully and record its wording before dismissing or applying it.

Use the device’s own local controls or official app as a comparison, but interpret that test carefully. A working vendor app may use a cloud path while Home Assistant uses the local network; conversely, a local device may work while its cloud account is unavailable. The comparison narrows the path but does not by itself identify the fault.

Build a short timeline from router events, Home Assistant updates, integration reloads, firmware changes, power interruptions, account changes, and the first failed automation. Correlation is not proof, but a reliable timeline tells you which evidence to inspect and which unrelated changes to leave alone.

Inspect diagnostics without publishing secrets. Useful evidence includes exact timestamps, sanitized error classes, addresses within your private network when appropriate, firmware versions, integration versions, and whether failures are continuous or intermittent. Remove tokens, cookies, serial numbers, email addresses, coordinates, and encryption material.

Change one variable at a time. After each change, repeat the same test and record the result. Simultaneously restarting the router, Home Assistant, bridges, and devices destroys the evidence needed to learn which action mattered and makes recurrence harder to prevent.

Prefer reload over restart when the integration supports it. Prefer reconfigure over delete-and-add when the host or account changed. Prefer a DHCP reservation over hard-coding addresses independently in several places. These choices preserve registry relationships and provide a simpler rollback.

Treat factory reset as recovery, not diagnosis. Before any reset, document pairings, automations, scenes, dashboards, entity IDs, network assignments, encryption keys, and manufacturer-specific recovery requirements. If those cannot be preserved, escalate before resetting.

When service returns, verify both directions: Home Assistant should read fresh state from the device, and a safe command from Home Assistant should be reflected by the device. Also confirm that a physical or vendor-app change is reported back to Home Assistant.

Test the real workflow, not only the device page. Trigger a representative automation in a controlled way, inspect its trace, confirm conditions and targets, and restore the previous state. A device can be healthy while an automation still points to an old entity.

Check recurrence across a normal operating period. Include at least one integration refresh, a DHCP lease check, or the next expected sensor update. For battery equipment, allow for its documented reporting interval instead of assuming silence means failure.

Create a rollback note containing the former value, new value, change time, and verification result. If the change worsens availability or creates duplicate entities, restore the known-good value before trying the next hypothesis.

Escalate with a compact evidence bundle when the problem survives safe local checks: model, firmware, Home Assistant version, integration name, sanitized first error, network topology relevant to the path, steps already attempted, and the smallest reliable reproduction. This gives maintainers actionable information without exposing the household.

Prevent recurrence by documenting address reservations, account ownership, update practices, backup location, integration-specific dependencies, and recovery contacts. Review these notes after router, firmware, or Home Assistant changes rather than waiting for the next outage.

Avoid unsupported certainty. An unavailable state describes a communication result, not necessarily a failed device. Power, privacy controls, address changes, authentication, sleeping behavior, rate limits, firmware, and network policy can create similar symptoms, so evidence must select the branch.

If the problem began immediately after an update, read the official integration documentation and current release notes before downgrading. A migration or renamed entity may be expected. Downgrades can introduce database incompatibility and should never be the first response to a single unavailable entity.

If several unrelated integrations fail together, stop device-specific troubleshooting. Check Home Assistant host health, DNS, time synchronization, network interfaces, Bluetooth or radio adapters, and upstream internet only where the affected integrations require it. Shared failures usually have a shared dependency.

If only one entity fails while sibling entities from the same device remain current, inspect whether it is disabled, unsupported, conditionally exposed, asleep, or dependent on a specific feature. Re-pairing the entire device is disproportionate until those possibilities are excluded.

Verification checklist

Confirm the integration reports loaded, the affected entities have current timestamps, state changes travel in both directions, and the original automation or dashboard works with the expected entity. Repeat the test after a normal reload. Do not declare success from a single momentary update.

Check that no duplicate device or replacement entity appeared. If a new entity ID was created, compare it with automations, scripts, scenes, dashboards, voice-assistant exposure, and history before removing or renaming anything.

Rollback and recovery

If the latest change made the system worse, restore the recorded prior address, option, entity reference, or integration configuration. Reload once and retest. If rollback cannot restore the known-good state, stop making changes, preserve logs, and use the evidence bundle described above.

Safety and privacy warning

Do not port-forward the camera, disable its privacy setting without authorization, or factory-reset it as an early diagnostic. Cameras can expose private household video. Preserve recordings and configuration before firmware changes or resets, and ensure the owner understands any cloud or subscription effects.

Prevention

Keep Home Assistant, the official integration, and device firmware within supported versions, but avoid changing all layers on the same day. Maintain a current backup, reserve stable network addresses where appropriate, label devices by MAC address, and review logs after planned maintenance.

Related Troubliq guides

Start with the Smart-Home Diagnostic Decision Tree, visit the category hub, and compare these related guides: matter device unavailable home assistant, esphome offline still on wifi, duplicate devices home assistant 2026 8 repair.

Sources

Primary source: Home Assistant Reolink integration documentation. This guide synthesizes the official behavior into a conservative diagnostic order; it does not claim hands-on testing of every model or network.

Frequently asked diagnostic questions

Can privacy mode affect more than video?

Yes. The official Reolink documentation says privacy mode can make almost all entities unavailable, including motion and AI detection. Check its history before treating simultaneous failures as separate faults.

Why does the mobile app work while Home Assistant fails?

The app may reach the camera through a different local or cloud path. Compare the camera address and network route used by Home Assistant; app success proves power and account access, not local reachability from the Home Assistant host.

Should I expose RTSP or the camera web port to the internet?

No. Internet port forwarding is not a reasonable availability fix. Keep camera services on trusted local networks and use a properly secured remote-access method if remote viewing is required.

What if only one NVR camera is missing?

Check channel assignment, camera-to-NVR connectivity, and account permission for that channel. One channel failure is narrower than an NVR or integration failure and should not trigger a full reset.

When is a static address appropriate?

A DHCP reservation is usually easier to manage than configuring a static address independently on the camera. Reserve the verified MAC address and ensure the chosen lease cannot collide with another client.

What evidence belongs in escalation?

Include the exact model, firmware, whether it is direct or NVR-connected, sanitized first error, affected entities, privacy-mode history, address test, and whether sensors work while video fails.

Final verification record

Record the date, Home Assistant version, device firmware, integration status, entity IDs checked, commands tested, state-update interval observed, and any network or account change that solved the failure. This record turns today’s repair into a faster and safer response if the symptom returns.

September 9, 2026

Duplicate devices after Home Assistant 2026.8: safe repair

Direct answer: If devices appear duplicated after upgrading to Home Assistant 2026.8, do not immediately delete one, merge registries manually, or re-pair the hardware. The release changed how Home Assistant represents some physical products that are supplied by more than one integration. Review Settings, System, Repairs, follow the official repair when one is offered, and then check automations or scripts that target a device ID directly. Entity-based actions usually continue to address the same entities, but unusual configurations need verification.

What changed in Home Assistant 2026.8

Home Assistant’s August 2026 release introduced groundwork for more flexible device handling. The official release notes explain that a product previously represented as one device can be split when different integrations provide different parts of it. In rarer cases where the same device was configured through more than one integration, Home Assistant may raise a repair.

The release notes state that automations and scripts generally keep working because actions are still sent to the appropriate devices. They specifically identify device-ID-based automations and unusual setups as areas that may deserve review. This is not the same as a random duplicate created by pairing a radio device twice, restoring an old registry, or adding both a local and cloud integration.

Symptoms covered by this guide

One physical product appears as two device cards after the 2026.8 upgrade.
Entities that were grouped together now appear under separate devices.
A new repair mentions a device represented by multiple integrations.
An automation using a device trigger or device action behaves differently.
A dashboard still works but the device page looks reorganized.
You cannot tell whether the second device is intentional or stale.

Before making changes

Create and download a current Home Assistant backup.
Record the Core version and installation type.
Capture the repair text and both device pages.
List the integrations shown on each device page.
Record entity IDs, device IDs where visible, area assignments, and disabled entities.
Export or copy important automations and scripts that reference the device.

Do not edit the device registry or entity registry files manually on a running system. Do not delete database rows. Registry corruption can affect more than the visible duplicate and may leave automations pointing to identifiers that no longer exist.

Step 1: Determine whether the split is expected

Open each device card under Settings, Devices & services, Devices. Compare manufacturer, model, serial or hardware identifiers, entities, and the integrations listed. An expected split may place different functional groups under separate representations because distinct integrations provide them.

For example, one integration may provide local device controls while another provides a service-level function. The visible names may be similar even though the representations have different ownership. Do not rename them solely to make the distinction disappear; first understand which integration supplies each entity.

Step 2: Read the Repairs entry completely

The Repairs integration is enabled by default and lists issues under Settings, System, Repairs. Each repair either offers a guided fix or provides information about the required action. Open the item and read every step before confirming it.

If the repair is related to the 2026.8 device-handling change, follow the official flow. Avoid using a generic “ignore” choice until you know what remains unresolved. Take screenshots or notes so you can compare device and entity mappings after completion.

Step 3: Identify other causes of apparent duplicates

Not every duplicate after an upgrade is caused by the new device model. Check whether the same product was added through multiple paths:

A manufacturer cloud integration and a local protocol integration.
HomeKit Device and Matter for the same accessory.
ZHA and Zigbee2MQTT records from a migration.
Two configuration entries for the same network service.
A restored backup plus newly discovered hardware.
An old unavailable device with no entities and a new active device.

Multiple integrations can be intentional. A cloud entry may expose functions that the local path does not, while the local path offers better responsiveness. Decide based on ownership, reliability, privacy, and entity requirements rather than the number of cards alone.

Step 4: Compare entity registries before deleting anything

Open each entity and record its entity ID, integration, device association, state, and where it is used. Home Assistant’s interface can show related automations, scripts, scenes, and dashboards. An unavailable entity can still be referenced by an automation, so absence of a current state does not prove it is safe to delete.

Look for equivalent entities with different IDs, such as a cloud switch and local switch controlling the same relay. Test only a non-critical control and confirm which physical function changes. Do not experiment with locks, garage doors, alarms, mains-powered heating, irrigation, or other safety-sensitive systems without appropriate safeguards.

Step 5: Audit device-based automations

Automations can target entities or devices. Entity actions reference an entity ID, while device triggers, conditions, and actions can store a device identifier and integration-specific details. The 2026.8 release notes call out device-ID-based automations for review after a split.

Open each related automation in the visual editor and inspect triggers, conditions, and actions. If YAML mode is used, save a copy before editing. Confirm which new device contains the required trigger or action. Do not replace every reference mechanically; the correct representation can differ by function.

After a repair, trigger each non-critical automation under controlled conditions. Check traces to verify that the expected trigger fired, conditions evaluated correctly, and the intended entity received the action.

Step 6: Check scripts, scenes, dashboards, and areas

Scripts and scenes usually reference entities, but device actions are also possible. Dashboards can contain entity cards, device pages, conditional cards, and area-based views. Search for unavailable or renamed entities and update only confirmed stale references.

Check area assignments on both device representations. A split can leave functions in different areas, which affects area-based voice commands, dashboards, and automations. Assign each representation according to the physical location and how Home Assistant uses the area.

Step 7: Decide whether one integration should be removed

Remove a configuration entry only after proving it is redundant and documenting what it owns. Use the integration’s official removal flow. Some integrations remove devices and entities immediately; others leave registry entries until cleanup conditions are met.

Before removal, list unique capabilities, authentication requirements, cloud dependencies, update frequency, and automations using its entities. Prefer the path that meets your reliability and privacy needs, but do not assume “local” and “cloud” are interchangeable. The local path may not expose every function.

Step 8: Handle a stale unavailable device

If one device has no active entities and belongs to a removed configuration entry, Home Assistant may allow it to be deleted. Confirm that it is not a bridge, service device, or parent of hidden entities. Check disabled entities as well as visible ones.

Delete through the user interface only when Home Assistant offers the action and all references have been reviewed. If deletion is unavailable, investigate the owning integration instead of manipulating registry storage manually.

Step 9: Review custom integrations

The 2026.8 release notes say most custom integrations require no immediate changes, but developers working directly with device information should review the developer guidance. If the duplicate involves a custom integration, check its repository for a release compatible with your exact Core version.

Do not copy unreviewed patches into production. Custom integrations are outside the official project’s normal support boundary and can affect registry behavior. Back up, read release notes, and test updates one at a time.

How to verify the repair

Clear or complete the relevant Repairs item.
Restart Home Assistant once under controlled conditions.
Confirm the expected device representations return.
Check that all required entities have current states.
Run important non-critical automations and inspect traces.
Verify scripts, scenes, dashboards, area controls, and voice exposure.
Review logs for registry, config-entry, or platform errors.
Wait through at least one normal integration update cycle.

Common mistakes to avoid

Deleting the first device that shows unavailable.
Assuming similar names prove two records are duplicates.
Removing a cloud integration before checking unique entities.
Editing registry JSON files directly.
Re-pairing Zigbee, Z-Wave, Matter, or HomeKit hardware without evidence.
Ignoring device-based automations after the split.
Restoring an old backup without considering later changes.
Renaming entities before recording their original IDs.

Rollback and recovery

If a guided repair or integration removal breaks automations, stop additional changes. Restore saved automation YAML or update references to the verified new device and entities. If many registry relationships are damaged, a full backup restore may be safer than manual reconstruction, but it also reverses changes made after the backup. Review the backup date and preserve the current system before restoring.

When radio devices are involved, avoid factory resets during registry cleanup. Radio pairing state can reside in both the controller and endpoint. A reset can turn a user-interface organization problem into a network re-pairing problem.

When to escalate

Collect the Core version, previous version, installation type, repair text, integration names, device identifiers with sensitive values redacted, entity mappings, relevant logs, and steps that reproduce the problem. State whether the setup uses official or custom integrations and whether the duplicate existed before 2026.8.

Search the Home Assistant Core issue tracker and the relevant integration repository. If filing a new report, focus on one reproducible behavior. Do not upload a complete backup, secrets file, tokens, precise location, or unreviewed diagnostic archive.

Prevention and maintenance

Read release notes before major monthly upgrades.
Keep verified backups and matching recovery material.
Document integrations that represent the same physical product.
Prefer stable entity naming and avoid unnecessary renames.
Review device-based automations after device-registry changes.
Remove obsolete configuration entries through supported interfaces.
Track custom-integration compatibility separately.

Use automation traces to find hidden device references

A device-based automation can look correct in the visual editor while its stored reference still points to the representation that changed. Open the automation’s recent traces and inspect the trigger, conditions, and action path. A trace can show whether the trigger never fired, a condition evaluated against an unavailable entity, or an action targeted a device that no longer offers the expected capability.

When correcting a reference, change only the affected trigger or action and save a copy of the previous YAML. Then reproduce the event safely and compare the new trace. This is more reliable than replacing every similar device name across the system.

How names can make an intentional split look like an error

Home Assistant may derive names from the product, integration, room, and entity descriptions. After a split, two legitimate records can inherit nearly identical names. Give them clear display names only after you identify their roles—for example, distinguishing a local control representation from a cloud service representation. Renaming improves clarity but does not merge ownership or change which integration updates an entity.

Avoid changing entity IDs during the first investigation. Entity-ID changes can ripple through YAML, templates, dashboards, notifications, and external consumers. Stabilize the device relationships first, then make naming changes deliberately with a reference audit.

Check voice assistants and external consumers

Google Home, Alexa, HomeKit bridges, Node-RED, MQTT consumers, and dashboards outside Home Assistant may refer to entity IDs or exposed-device selections. After completing the repair, review exposed entities and look for a duplicate display name in the external platform. Do not delete the external copy until Home Assistant’s source entity is understood.

If an external platform retains a stale device, sync or rediscover through its supported procedure after Home Assistant is stable. Re-linking an entire account can affect rooms, routines, and names, so use the smallest supported refresh first.

Special care for bridges and multi-channel products

A bridge, power strip, multi-relay module, or climate system can legitimately contain many entities and child devices. Two cards do not necessarily represent two copies of the hardware. One may represent the bridge or service while others represent endpoints. Check the “via device” relationship and integration ownership before removing the parent.

For Zigbee, Z-Wave, Matter, and HomeKit, registry cleanup is not the same as radio removal. Exclusion, unpairing, or factory reset changes network credentials and should be reserved for a proven communication or ownership problem. A device-page reorganization after 2026.8 does not by itself justify radio changes.

2026.8 duplicate-device decision table

What you see	Likely meaning	Safest next step
Two device pages, each owned by a different integration	The former cross-integration merged device was split as designed	Keep both until you confirm which entities and automations belong to each integration
A Repairs notification after upgrading	Home Assistant detected a device-registry case that needs guided review	Follow the repair text; do not delete registry records first
Duplicate-looking cards but different entity sets	One physical product is represented by separate integration responsibilities	Rename the device pages for clarity and leave entity ownership intact
An entity is unavailable or orphaned	The issue may be an integration/config-entry failure rather than the 2026.8 split	Check the entity’s integration, config-entry status, and logs before cleanup
An automation reports an unknown device	A device-based trigger or action may reference the pre-split registry entry	Re-select the intended device/entity in a copy of the automation, test it, then replace the original

Verify before deleting or merging anything

Open each device page and record its integration, identifiers, entities, and automation links. The official 2026.8 change assigns a device to one config entry instead of merging information from several integrations. A physical product may therefore appear once for its primary integration and again for a router or tracker integration. That is not automatically corrupt data.

Use a reversible test: rename each device page temporarily with its integration name, run one device-based automation, and operate one entity from each page. If both pages control or report distinct functions, keep them. If a repair explicitly instructs you to choose an entry, follow that guided flow and recheck automations afterward. Do not unpair Zigbee, exclude Z-Wave, reset Matter credentials, or factory-reset HomeKit accessories merely because the registry presentation changed.

Expected result: entities remain attached to the correct integration-owned device, existing entity-based automations continue working, and any affected device-based automation is deliberately remapped. Rollback: restore the original automation from its backup or traceable copy and reverse temporary display-name changes. Registry deletion is not a rollback strategy because it can remove references without fixing the owning integration.

Evidence and testing disclosure: This diagnostic order is based on the Home Assistant 2026.8 release notes and the official developer explanation of single-config-entry device ownership. Community reports are treated only as examples of impact, not proof of a universal defect. Troubliq did not reproduce every integration combination. Last reviewed October 1, 2026.

Sources

Last reviewed: September 8, 2026.

Related Troubliq guides: Use the least-destructive diagnostic method, browse all troubleshooting guides, and read Matter device unavailable troubleshooting when the apparent duplicate involves a Matter accessory.

Decision summary

Follow the official repair when Home Assistant identifies a 2026.8 representation issue. Audit device-based references when functions moved between device records. Keep multiple integrations when each supplies needed capabilities. Remove an entry only after documenting its entities and dependencies. Delete a stale device only through the supported interface after confirming that it owns nothing required. This evidence-first process prevents a cosmetic duplicate from becoming lost automations, missing entities, or an unnecessary radio rebuild.

Find your next troubleshooting path

Use the related guide that matches the next confirmed layer of the failure. Avoid changing unrelated systems at the same time.

September 8, 2026

Alexa Devices integration becomes unavailable in Home Assistant: diagnose Service Unavailable errors
Direct answer: If the Alexa Devices integration becomes unavailable in Home Assistant after working normally, first identify whether the failure is an Amazon service response, an authentication problem, or a local Home Assistant issue. A log entry containing Service Unavailable after earlier successful updates does not by itself mean that your password or multi-factor authentication is wrong. Preserve the logs, verify Amazon services and local connectivity, reload the integration once, and reauthenticate only when Home Assistant explicitly reports an authentication failure.

Symptoms covered by this guide
- Alexa speakers and related entities become unavailable together.
- The integration works after setup or reload but later stops updating.
- Logs show Service Unavailable, CannotRetrieveData, timeouts, or failed coordinator updates.
- Reloading the integration temporarily restores entities.
- Home Assistant requests reauthentication or rejects a one-time password.
- The Alexa app works while Home Assistant cannot update Alexa entities.
This guide concerns the official Alexa Devices integration documented by Home Assistant. It does not cover every custom Alexa component, the separate Alexa Smart Home skill, or general voice-assistant exposure. Confirm the integration name before applying any step.

Why Alexa Devices can become unavailable

The integration depends on several layers: Home Assistant, its network and DNS path, Amazon account authentication, multi-factor authentication, and Amazon endpoints that return device and communication data. A failure in any layer can make many entities unavailable at once. The correct recovery depends on the error class.

A public Home Assistant Core issue filed for Core 2026.6.4 documents a recurring case in which initial authentication and updates succeeded, followed later by a Service Unavailable response. In that report, reloading restored operation without reauthentication. That is evidence of one observed failure pattern, not proof that every unavailable Alexa integration has the same cause or that the behavior affects every version.

Before changing anything
1. Record the Home Assistant Core version and installation type.
2. Note when Alexa entities last updated successfully.
3. Open Settings, System, Logs and save the exact redacted error.
4. Confirm whether every Alexa entity failed or only one device.
5. Check whether the Alexa mobile app can currently see and control the same devices.
6. Create a current Home Assistant backup before deleting or reconfiguring the integration.
Do not post Amazon passwords, authenticator secrets, one-time codes, cookies, tokens, full diagnostic archives, email addresses, or household information. Redact identifiers from screenshots and logs.

Step 1: Distinguish service failure from authentication failure

Read the first meaningful exception near the failed update. A server-side Service Unavailable or HTTP 503 response means the requested service did not complete the request at that time. It is different from an unauthorized or forbidden response. Authentication failures commonly mention invalid credentials, reauthentication, an expired session, unauthorized access, or a failed one-time password.

If recent log entries show successful updates followed by a 503-style response, preserve that sequence. Do not repeatedly change the password. If the integration explicitly creates a repair or reauthentication flow, follow that flow using the official interface.

Step 2: Confirm the scope outside Home Assistant

Open the Alexa app and check device state. If the app also fails, the problem is likely upstream of Home Assistant: an Amazon service incident, account problem, household configuration, or device connectivity issue. If the app works, continue testing the Home Assistant path without assuming Amazon is fully healthy; different API functions can fail independently.

Check Home Assistant’s System status and any relevant integration alert. Review the official Alexa Devices integration documentation for current prerequisites. Avoid relying on old forum instructions because authentication requirements and supported features can change.

Step 3: Verify Home Assistant network, time, and DNS

Cloud authentication can fail when the Home Assistant host has no reliable internet path, resolves DNS incorrectly, has an inaccurate clock, or is being filtered by a firewall. Confirm that other cloud integrations update normally. Review host, supervisor, and core logs for broader network failures.

Accurate time matters for TLS certificates and time-based one-time passwords. Home Assistant OS normally manages time automatically, but a host that cannot reach its time source may drift. Check the host time and timezone rather than compensating by repeatedly generating codes.

If you use a custom DNS server, ad blocker, outbound proxy, VLAN policy, or firewall, temporarily test a known-safe rule change only if you understand the impact. Do not disable perimeter security broadly. Record the result and restore the previous rule after the test.

Step 4: Reload the integration once

Go to Settings, Devices & services, locate Alexa Devices, open its menu, and choose Reload. Watch the logs while it reloads. A successful reload that restores all entities without an authentication prompt indicates that the saved credentials were still accepted at that moment.

Reloading is a diagnostic action, not a permanent fix for a repeating upstream failure. Do not create an hourly reload automation as a first response. Repeated reloads can hide the timing and error needed for a useful bug report, increase traffic to an external service, and make the problem harder to diagnose.

Step 5: Reauthenticate only when requested

The official integration documentation requires an Amazon account and multi-factor authentication through an authenticator application, with the authenticator method configured appropriately in the Amazon account. Follow the current Home Assistant reauthentication flow and the official Amazon security interface.

Enter the account email, password, and current one-time password only in the authorized setup form. Confirm that the authenticator device clock is accurate. If several attempts fail, stop briefly rather than triggering additional account protection. Verify that you selected the correct Amazon account and regional marketplace.

If reauthentication succeeds but the integration later reports Service Unavailable, treat that as a separate runtime problem. Repeating the same login process is unlikely to fix a remote availability failure permanently.

Step 6: Check account and household details

Amazon Household membership, multiple profiles, regional accounts, and changes to security settings can affect available data. The official Home Assistant documentation notes a limitation involving reminders and accounts linked to an Alexa Household. Do not remove household members merely to test an unrelated unavailable-device problem.

Review recent changes: password reset, multi-factor method change, marketplace move, household change, revoked sessions, or new security alerts. Resolve suspicious account activity directly through Amazon before reconnecting third-party software.

Step 7: Rule out custom-component conflicts

If both the official integration and a custom Alexa component are installed, confirm which one owns the failing entities and log messages. Custom integrations are maintained separately and can use different authentication or update methods. Review Settings, Devices & services and the custom integration store before deleting anything.

Start Home Assistant in a controlled configuration only when you understand the consequences. Removing a custom integration can change entity IDs and break automations. Back up first and document current entity mappings.

Step 8: Compare versions and known issues

Record the exact Core version, not merely “latest.” Check the official release notes and the Home Assistant Core issue tracker for the same integration, error, and version. Read issue status and maintainer responses. A single open report does not establish a universal regression, and a closed report may be fixed only in a newer release.

Do not downgrade Home Assistant casually. Restoring an older backup can also roll back database schema, integrations, and configuration. If maintainers recommend a specific patch release, review its release notes and create a verified backup before updating.

How to interpret common results
- Alexa app and Home Assistant both fail: investigate Amazon service, account, or device connectivity first.
- App works; reload restores Home Assistant: preserve logs and investigate a coordinator, session, or remote endpoint failure.
- Reauthentication requested: complete the official flow and verify the authenticator method.
- 401 or unauthorized: focus on credentials, session, account region, and security changes.
- 503 or Service Unavailable: avoid unnecessary password changes; check timing, service health, and known issues.
- Only one entity fails: inspect that device, its account state, and whether the integration still exposes it.
Verify the recovery
1. Confirm the integration card shows no setup failure.
2. Confirm several Alexa entities have fresh states.
3. Test one non-critical entity or information update.
4. Check logs for repeated coordinator errors.
5. Wait longer than the previous failure interval.
6. Confirm a normal Home Assistant restart does not immediately reproduce the problem.
A successful reload is not sufficient when the problem previously returned after hours. Keep the observation window long enough to distinguish recovery from temporary relief.

Rollback and safe recovery

If a configuration change makes the problem worse, restore the previous DNS, firewall, or account setting and reload once. If you removed the integration, restore from a known backup only after considering changes made since that backup. Re-adding an integration may create different entity IDs, so review automations, dashboards, scripts, and exposed voice-assistant entities.

When to escalate

Prepare a concise report with the Core version, installation type, integration name, approximate failure time, first relevant stack trace, whether the Alexa app worked, whether Reload restored operation, and how long recovery lasted. Include diagnostics only after reviewing them for secrets. Search for an existing matching Core issue before creating a new one.

If the error suggests account compromise, stop technical troubleshooting and secure the Amazon account. Change credentials through the official account page, review devices and sessions, and confirm multi-factor methods.

Prevention
- Keep Home Assistant on a supported release after reviewing breaking changes.
- Maintain a verified backup before updates or integration removal.
- Use a stable DNS and internet path for cloud integrations.
- Keep the authenticator method available and its device clock accurate.
- Document entity IDs before reconfiguration.
- Avoid automated reload loops that conceal recurring faults.
- Review integration alerts and release notes when behavior changes.
Build a timeline instead of treating every log line as the cause

Coordinator-based integrations can emit secondary errors after the first failure. Start with the earliest error in the same update cycle, then follow later messages in order. A timeout, DNS failure, or remote 503 can cause entities to become unavailable and produce additional warnings that are consequences rather than causes. Record the time of the last successful update, the first failed request, the moment entities changed state, and the result of one reload.

Compare that timeline with other events: a Home Assistant update, router restart, DNS change, Amazon password change, authenticator change, or an internet interruption. Correlation is not proof, but a precise timeline helps eliminate unrelated changes. If no configuration changed and the error begins with a remote service response, avoid rebuilding the integration before checking whether the service recovers.

Why aggressive retry automations are risky

An automation that reloads a failing cloud integration every few minutes may appear convenient, but it can create repeated authentication or API traffic, conceal the original error, and interfere with normal backoff behavior. It can also leave dependent automations alternating between available and unavailable states. Use a single manual reload as a diagnostic step. If maintainers later document a temporary workaround, follow its exact limits and remove it when a fixed release is installed.

Check dependent automations after recovery

When Alexa entities return, review automations that ran during the outage. An unavailable sensor may have prevented a condition from evaluating as expected, and state-based triggers normally do not replay missed transitions automatically. Do not assume that restoring the integration will reproduce reminders, timers, or notifications that were missed.

Use automation traces to confirm what happened. Test a non-critical path, verify entity state freshness, and inspect the trace for skipped conditions or unavailable inputs. Avoid testing announcements late at night or controls connected to safety-sensitive equipment.

Regional and account consistency checks

Confirm that the Amazon account, marketplace region, Alexa app session, and integration configuration refer to the same household. A region mismatch can resemble an empty or incomplete device list even when login succeeds. If the account has recently moved regions, document the previous and current marketplace before reconfiguration. Do not create duplicate Amazon accounts as a troubleshooting shortcut.

Sources
Last reviewed: September 8, 2026.

Related Troubliq guides: Start with the safe diagnostic method, browse troubleshooting guides, and review Home Assistant automation trigger diagnosis when the integration is available but an automation still does not run.

Final decision checklist

Reload once when credentials appear valid and the error is a temporary service response. Reauthenticate when Home Assistant explicitly requests it or logs show authorization failure. Investigate local network and time when several cloud services fail. Wait and document when a remote endpoint returns a temporary 503. Escalate with redacted evidence when the failure repeats on a current supported release. This sequence addresses the most likely layer while protecting the account and preserving useful evidence.

Find your next troubleshooting path
Use the related guide that matches the next confirmed layer of the failure. Avoid changing unrelated systems at the same time.
September 8, 2026

Blog

Samsung TV not authorized in Home Assistant: permissions, token, network, and Wake-on-LAN fixes

Symptoms and scope

Before making changes

Fast diagnostic matrix

1. Confirm the television itself is online

2. Check model and protocol compatibility

3. Repair an incorrect IP address safely

4. Fix repeated Samsung permission prompts

5. Diagnose VLAN and subnet failures

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

7. Interpret Wake on LAN results

8. Test remote commands and sources logically

9. Capture useful diagnostics

Verification checklist

Rollback and recovery

Prevention

Related Troubliq guides

Evidence, applicability, and safe verification

Sources and review record

TP-Link Kasa or Tapo unavailable in Home Assistant: authentication, IP, VLAN, and camera fixes

Symptoms this guide covers

Before changing anything

Quick decision table

1. Separate a device problem from a Home Assistant problem

2. Confirm model and firmware support

3. Fix authentication without exposing credentials

4. Correct IP-address and DHCP problems

5. Handle VLANs and discovery correctly

6. Fix Tapo camera live view separately

7. Recognize removed or historical entities

8. Eliminate conflicts with custom integrations

9. Use logs without creating a privacy problem

Verification checklist

Rollback and recovery

Prevent the problem from returning

Related Troubliq guides

Sources and review record

SwitchBot device not discovered in Home Assistant: Bluetooth and passive-mode diagnosis

Symptoms and scope

Prerequisites and evidence to preserve

Likely causes

Least-destructive diagnostic sequence

Diagnostic asset: choose the next branch

Deeper checks when the first sequence does not solve it

Verification checklist

Rollback and recovery

Safety and privacy warning

Prevention

Related Troubliq guides

Sources

Frequently asked diagnostic questions

Is a SwitchBot Hub required?

Why does power cycling sometimes help discovery?

What is passive mode?

Why would an encryption key be needed?

Can I use Login with Google for synchronization?

How do I distinguish two identical devices?

Final verification record

What not to do

Maintenance check after recovery

Shelly unavailable in Home Assistant: CoIoT, RPC, VLAN, and security diagnostics

Symptoms this guide covers

Safety and privacy before troubleshooting

Ranked causes

Step 1: identify the device generation and connection path

Step 2: verify power, IP address, and local reachability

Step 3: distinguish complete unavailability from missing push updates

Step 4: repair Generation 1 CoIoT safely

Step 5: check Generation 2+ RPC and outbound WebSocket

Step 6: test VLAN, firewall, and Wi-Fi behavior

Step 7: review Enhanced Security and HTTPS

Step 8: reload only after the network path is correct

Verification checklist

Rollback and recovery

When to escalate

Prevention

Diagnostic matrix

Sources and testing disclosure

Continue troubleshooting