Troubliq

Smart-home fixes, step by step.

Category: Lighting & Plugs

Troubleshooting for connected lighting, switches, plugs, dimmers, relays, and groups. Check electrical safety, power, native-app control, protocol connectivity, coordinator or hub state, entity availability, then automations. Stop immediately for heat, arcing, damaged wiring, or burning smells and contact a qualified professional.

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

    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.

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

    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.

  • Philips Hue room or zone missing in Home Assistant: safe grouped-entity fixes

    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.