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.