All Matter devices unavailable in Home Assistant

Applies to

Home Assistant installations using the Matter integration with Wi-Fi or Thread devices. Menu names and behavior can change between releases; record your Home Assistant Core, Matter Server, border-router, and device firmware versions.

1. Preserve the working evidence

• Do not factory-reset or remove the device yet.
• Save the exact Home Assistant error and the time it occurred.
• Check whether one Matter device or every Matter device is unavailable.
• Note any router, VLAN, firewall, border-router, credential, or software change.

2. Separate device failure from controller failure

Confirm that the device has power. If its manufacturer app can still control it, the device and at least one control path are alive. If all Matter devices fail together, investigate Home Assistant, Matter Server, and the network before individual devices.

3. Check Home Assistant services

Open Settings, then Devices & services. Confirm that the Matter integration is loaded and inspect its messages. Check the Matter Server add-on or service logs around the recorded failure time. Restart only the affected service once, then wait for discovery to settle before retesting.

4. Verify local network reachability

Matter depends on local IPv6 and multicast discovery. Confirm that Home Assistant and the device network can exchange local traffic. Guest isolation, client isolation, blocked multicast, strict VLAN rules, or a recent router change can break an otherwise valid pairing. Avoid broad firewall changes; test the smallest reversible rule and restore it if the result does not change.

5. For Thread devices

Confirm that the expected Thread border router is online and that Home Assistant is using the intended Thread credentials. Do not create a new Thread network simply because a device is unavailable; duplicate networks can make diagnosis harder.

6. Re-interview before re-pairing

After power, services, network, and border-router checks, reboot only the affected low-voltage device if its manufacturer instructions allow it. Removal and factory reset are last resorts because they can erase credentials and automations.

Escalate safely

Stop for overheating, swelling batteries, damaged wiring, smoke, sparks, or water near electricity. For a repeatable software failure, collect redacted logs, versions, device model, and the smallest reproduction before asking the manufacturer or Home Assistant community for help.

Official sources

• Home Assistant Matter integration and troubleshooting
• Home Assistant Thread integration

Last reviewed: September 4, 2026.

Find your next troubleshooting path

• Matter and Thread hub
• Thread credentials synced but commissioning fails
• HomeKit device already paired

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

Confirm where “unavailable” begins

Treat pairing and availability as separate stages. A successful Matter commission proves that the controller exchanged credentials and added the accessory to a fabric; it does not prove that Home Assistant can continue reaching the device afterward. Note whether the accessory becomes unavailable immediately, after several minutes, after a router restart, or only after Home Assistant restarts. That timing narrows the problem before you change anything.

Check whether the same accessory remains controllable from another authorized ecosystem. If it works there but not in Home Assistant, focus on Home Assistant’s Matter integration and the path to its Matter server. If it disappears everywhere, focus on power, Wi-Fi or Thread connectivity, the border router, and the accessory itself. Do not remove it from every controller just to perform this comparison.

Preserve evidence before re-pairing

Open the device page and record the exact availability state, diagnostic entities, firmware version, and the time of the last successful update. Save relevant Matter Server and Home Assistant logs around that timestamp. Redact fabric identifiers, Wi-Fi credentials, setup codes, certificates, tokens, and public IP addresses before sharing logs.

Create a current Home Assistant backup before changing integrations or deleting devices. Also record which ecosystem commissioned the device first and whether multi-admin sharing was used. Those ownership details matter because removing the accessory from the wrong controller can invalidate the sharing path and turn a recoverable connectivity problem into a new commissioning problem.

Check the Matter server and integration

If the problem started after updating Home Assistant 2026.9, also use our Matter Network Map missing or unsupported diagnostic to separate a Core-version issue from a Matter Server or fabric-visibility issue.

Verify that the Matter integration is loaded and that its server is running without a repeating connection or startup error. A restart may temporarily hide a race or network problem, so use it as a controlled test rather than assuming that a successful restart is a permanent repair. After restarting, observe whether the device returns on its own and how long it stays available.

Compare the device’s unavailable timestamp with Home Assistant Core, Matter Server, add-on, container, or host restarts. If many Matter devices fail together, investigate the shared server and network path first. If one device fails while the rest remain stable, prioritize that accessory’s power, firmware, radio path, and individual fabric record.

Verify local network requirements

Matter depends on reliable local IP communication. Confirm that Home Assistant, the Matter server, the accessory, and any Thread border router can participate in the required local network traffic. VLAN rules, client isolation, multicast filtering, broken IPv6, or a container network change can allow commissioning to begin yet prevent dependable operation afterward.

Do not open inbound internet ports as a troubleshooting shortcut. Matter control is designed around authenticated local communication, and exposing Home Assistant or the Matter server does not repair local discovery. Test temporary firewall or VLAN changes narrowly, document them, and restore the original policy after each comparison.

Separate Wi-Fi Matter from Thread Matter

For a Wi-Fi Matter accessory, confirm that it still has power, a valid lease, and a stable connection to the intended SSID. Check for band steering, access-point roaming, client isolation, or DHCP changes near the time of failure. A reservation can make diagnosis easier, but do not assume that changing the address alone fixes the underlying reachability problem.

For a Thread accessory, verify that at least one compatible Thread border router is online and that the Thread network used during commissioning is still available. More border routers do not automatically repair mismatched credentials or separate Thread networks. Confirm the network identity before resetting, migrating, or creating a new Thread network.

Use a controlled recovery sequence

Start with the least disruptive action: restore power or network reachability, wait for reconnection, reload only the affected integration if appropriate, and then restart the smallest relevant service. Test the device after each action. Changing several layers at once removes the evidence needed to identify what actually restored availability.

Re-interviewing, removing, or factory-resetting the device belongs near the end of the sequence. Before removal, check whether dashboards, scenes, automations, and voice assistants depend on the current entity and device identifiers. A newly commissioned record may not preserve those references even when the physical accessory is the same.

Verify the repair

After the device returns, test control and state reporting from Home Assistant several times. Then restart the accessory if practical, restart the relevant Matter service during a maintenance window, and observe the device long enough to cover the interval that previously triggered the failure. Availability for a few seconds is not enough evidence of a stable repair.

Document the confirmed cause, the single change that resolved it, and the versions involved. Keep the backup and sanitized logs until the device survives normal network and service restarts. If the failure returns, that record prevents repeated resets and gives the vendor or Home Assistant community a reproducible starting point.

When to escalate

Escalate with a concise evidence package when the accessory repeatedly becomes unavailable after the same event, the Matter server reports a reproducible error, or current firmware does not restore stable operation. Include sanitized log timestamps, Home Assistant and Matter Server versions, accessory model and firmware, connection type, border-router model when applicable, and the controlled tests already completed. This gives the vendor or community enough information to distinguish an accessory defect from a platform or network regression without asking you to reset the device again.

Detailed evidence checklist for Matter device pairs but shows unavailable in Home Assistant

Before another change, create a short incident record. Include the exact time the symptom appeared, what the system was doing, the last successful action, and every update or network change made during the previous day. Record the Home Assistant release, installation type, integration version, device model, firmware, connection method, current address, and relevant entity IDs. Screenshots are useful for visible states, but copy the exact error text because screenshots may crop the detail needed to search logs.

Compare the failing item with one known-good item that uses the same path. If both fail, move outward toward shared services such as the integration, coordinator, add-on, DNS, router, cloud account, or Home Assistant host. If only one fails, stay close to that device: power, signal, address, credentials, firmware, permissions, and configuration. This comparison prevents a single-device problem from turning into an unnecessary system-wide rebuild.

Network tests that prove the failing layer

Use tests in layers. Confirm the address is current in the router or DHCP server. Confirm the Home Assistant host or container resolves the same name and reaches the intended address. Then test the actual documented service, port, or protocol. A dashboard loading on a phone proves only the phone’s path. A successful ping proves basic reachability, not authentication, WebSocket upgrades, multicast discovery, API encryption, event subscriptions, or application permissions.

For segmented networks, document source VLAN, destination VLAN, direction, protocol, and port before editing a firewall rule. Test the smallest temporary exception and remove it if it did not help. Discovery traffic and control traffic may use different mechanisms. Seeing a device in discovery does not prove Home Assistant can maintain a working session.

Configuration comparison procedure

Export or photograph the current configuration without exposing secrets. Compare it with official documentation field by field: host, port, account, region, project, encryption setting, device identifier, and optional switches. Watch for trailing spaces, uppercase versus lowercase account names, obsolete hostnames, restored encryption keys, or an account belonging to the wrong home or region.

Use Reconfigure or Reauthenticate before deleting an integration. Preserve entity IDs and note every automation, dashboard, script, scene, or helper that refers to them. If replacement becomes necessary, take a backup and map old entities to replacements. That makes rollback controlled rather than leaving broken references.

Power, radio, and timing checks

Do not interpret every unavailable state as software failure. Low-voltage devices may stay partly online while unstable power causes resets. Battery devices sleep and report on their own schedule. Wi-Fi and Bluetooth devices can associate yet fail at the application layer. Zigbee and Z-Wave devices depend on routes, radio conditions, and powered repeaters. Match the test to the technology instead of repeatedly pressing Reload.

Allow enough time after each test. Cloud polling, sleepy devices, retained MQTT messages, mesh repair, Bluetooth advertisements, and DHCP changes do not update instantly. Define the expected interval, then wait through at least two normal cycles. If availability returns briefly, capture the next disconnect in logs instead of declaring success.

Log-reading workflow

Synchronize clocks and reproduce the problem once. Start with the first warning or error at that timestamp; later messages may be consequences. Group errors by layer: name resolution, timeout, refused connection, TLS certificate, unauthorized account, invalid token, missing permission, unsupported capability, malformed payload, device timeout, or rate limit. Each group suggests a different next action.

Turn debug logging off after reproduction. Large files consume storage and bury the event. Redact tokens, passwords, keys, email addresses, public addresses, precise locations, and unnecessary unique identifiers. Keep the unredacted copy private for comparison with later tests.

Safe change order

1. Correct time, power, cabling, or an obviously stale address.
2. Reload only the affected integration when documentation supports it.
3. Use Reconfigure or Reauthenticate without deleting the entry.
4. Restart only the affected device or add-on during a safe window.
5. Restart Home Assistant when several components share the symptom or a change requires it.
6. Update software after reading release notes and preserving rollback.
7. Delete, exclude, reset, or rebuild only after safer checks prove it necessary.

Post-repair validation

Verify both directions. Confirm Home Assistant receives a fresh state, send one harmless command, and confirm the physical response. Check the returned state, logbook, history, and automation trace. Restart the affected component and verify automatic reconnection. During a maintenance window, confirm the repair survives a normal Home Assistant restart.

Monitor long enough to cover the original pattern. If failure occurred overnight, after DHCP renewal, deep sleep, or token expiry, a five-minute test is insufficient. Record the confirmed cause and exact corrective change. Remove temporary firewall rules, extra logging, duplicate test integrations, and unused credentials.

When to stop and escalate

Stop if hardware overheats, power is unstable, storage reports errors, a controller backup fails, credentials are rejected across services, or firmware may be damaged. Escalate with versions, timestamps, topology, redacted logs, the first meaningful error, and results of each safe test. Do not repeat destructive steps while waiting for help.

A strong report answers four questions: What still works? What exactly fails? What changed immediately beforehand? Which test most clearly separates the causes? Those answers help maintainers diagnose the correct layer.