Why Matter Devices Keep Going Offline

Searching for why Matter devices keep going offline usually starts after the third time a lock shows “Unavailable” in Home Assistant or “No Response” in Apple Home, then comes back on its own an hour later. The device is almost never the problem. Matter is IPv6 and multicast DNS over your existing LAN, with a Thread border router bolted on for anything battery powered, and every one of those hops can drop out while the device sits there with a full battery and a green LED. Here are the five places the path breaks, in the order to check them.

First, sort your outages by transport

Which devices dropped, and when, does most of the diagnosis.

• Every Thread device went at once, Wi-Fi devices fine: the border router.
• One battery-powered Thread device drops on a schedule (about every 30 minutes, or overnight): sleep or subscription.
• Wi-Fi Matter devices drop, and pairing “works” but control fails later: multicast or IPv6 filtering.
• The manufacturer app says offline while Home Assistant or Apple Home controls it fine: the app, not the device.

The transport comparison covers why the two radios fail differently.

Cause 1: the border router went away

A Thread device has no route to your LAN except through a border router, which OpenThread describes as the thing that “connects a Thread network to other IP-based networks, such as Wi-Fi or Ethernet” (OpenThread). When it reboots for an update, gets unplugged, or is an Apple TV in deep sleep, every Thread device behind it is unreachable until it returns.

The fix is not a better border router; it is a second one. Home Assistant’s Thread docs: “Unlike other protocols, Thread can use multiple border routers in a single network. This increases wireless coverage and reduces the risk of a single point of failure” (Home Assistant). Two border routers on the same credentials, and a single reboot stops taking the mesh down. The border router guide covers placement.

Cause 2: two Thread networks pretending to be one

This is the sneaky one. Each ecosystem historically formed its own Thread network with its own credentials, and devices cannot roam between them.

The Thread Group admits this hurts: “This fragmentation of Thread devices over multiple networks could weaken the overall mesh network resilience and connectivity” (Thread Group). Thread 1.4’s answer is credential sharing, “a secure procedure that allows sharing administrative access to an existing Thread network and extracting its network credentials,” so a new border router joins the existing mesh instead of forming its own (Espressif).

On Home Assistant this surfaces as the “preferred network” setting: a March 2026 core issue documents an IKEA Thread motion sensor that became “Unavailable” about 30 minutes after pairing on Home Assistant 2026.3.3; the fix was to mark the Sonoff dongle’s Thread network as preferred, factory-reset the sensor and pair it again (home-assistant/core #166317). The layering explainer shows where the credentials live.

Cause 3: battery devices sleeping through their subscription

Battery Thread devices are Sleepy End Devices, “normally disabled, wakes on occasion to poll for messages from its parent,” and each one “attaches to exactly one Mesh Extender” (OpenThread). Silicon Labs’ Matter SDK defaults the idle poll to 30000 ms, and while asleep the device “relies on its associated Thread router to buffer any incoming message” (Silicon Labs).

The controller holds a subscription and expects periodic reports. When the parent goes away, or the subscription lapses, the controller marks the device unavailable. Matter’s Intermittently Connected Device design exists for this: the check-in protocol “is a fail-safe mechanism which allows an ICD to notify a registered client that it is available for communication when all subscriptions between the client and ICD are lost” (Silicon Labs). Older devices lack it, which is why the reset ritual works. Apple’s No Response steps: “Disconnect third-party Thread accessories from power for 5 minutes by unplugging them or removing their batteries. Then reconnect third-party Thread accessories and wait 10 minutes for the Thread network to stabilize” (Apple Support). That forces a fresh parent and a fresh subscription. If the same sensor drops every few days, give it a mains-powered Thread plug or bulb nearby as a second parent.

Cause 4: your network is filtering multicast or IPv6

This bites Thread too, because the border router uses mDNS on the LAN side. Home Assistant: “The Matter protocol relies on (local) IPv6 and mDNS (multicast traffic) traveling freely in your network,” and “a setting on your router or Wi-Fi access point to ‘optimize’ multicast traffic can harm the (discovery) traffic from Matter devices” (Home Assistant). Google describes the failure shape exactly: “Without IPv6 enabled on your home wireless network, the setup process may initially appear to succeed at times. However, control and other functionalities eventually fail due to the lack of IPv6 support” (Google Nest Help). Pairing works, then things go offline.

1Home’s networking guide lists the usual culprits: IGMP snooping, which “usually negatively affect mDNS DNS-SD related traffic, especially when using multiple WiFi access points”; a multicast enhancement option that “converts multicast to unicast traffic”; and a DHCP domain set to .local, which “is reserved for mDNS discovery” (1Home). VLANs are the other classic, since “devices in one VLAN will not be able to discover devices in other VLANs” without a reflector. If you moved IoT onto its own VLAN and Matter has been flaky ever since, the UniFi IoT VLAN guide on unifiguide.com walks through what has to cross the boundary.

Cause 5: it is the app, not the device

If your controller runs the device fine but the manufacturer’s app says offline, the app is what is offline: Matter control is local, and the vendor app usually talks to a cloud over a separate channel. The offline behaviour post covers which pieces need the internet.

A diagnostic order that does not waste your evening

1. Border router: powered, awake, same LAN and VLAN as the controller. If you have one, buy a second.
2. Thread networks: Home Assistant’s Thread page lists every border router and its network. Aim for one, marked preferred.
3. A sleepy device on a schedule: pull the battery for five minutes, wait ten, give it a mains-powered neighbour.
4. Wi-Fi devices: turn off IGMP snooping and multicast-to-unicast, confirm IPv6 is on, confirm the DHCP domain is not .local.
5. Only then the device itself: firmware, signal, and whether it is actually faulty.

Zigbee people will recognise the list; the Zigbee “unavailable” guide on homeassistanthq.com follows the same discipline with a coordinator in place of a border router. Matter moved the failure points from the radio to the IP network, and most home networks were never set up with multicast in mind. Fixing that is an evening; a second border router is an afternoon; neither means replacing a device.

Related across the network

• Zigbee vs Z-Wave vs Thread: Which Mesh to Build — homeassistanthq.com
• Home Assistant Hardware: What to Run It On — homeassistanthq.com
• Home Assistant OS vs Container: Which Install Method to Pick — homeassistanthq.com
• Zigbee Devices Going Unavailable: How to Fix It — homeassistanthq.com
• A $200 N100 Homelab: 11 Services, ~8W Idle, Low Maintenance — minilabhq.com

Related on this site

• How Many Thread Border Routers Do I Need? A Count by House Size and Ecosystem