A device shows as unresponsive, and how to find out why

What "unresponsive" actually means#

No controller pings devices continuously. Each protocol decides differently that a device is gone, and the gray tile appears when that mechanism trips.

Matter controllers subscribe rather than poll. The controller negotiates a minimum and a maximum reporting interval, and the device must report at least once per maximum interval even when nothing changed. That report is a heartbeat. Miss it and the controller marks the device unreachable whether or not it is fine. The SDK budget is three subscriptions per fabric, which is one reason sharing a device across many ecosystems can degrade it.

Zigbee and Z-Wave hubs infer status from failed commands and missed check-ins. A battery Zigbee sensor that reports hourly looks identical to a dead one for 59 minutes. Z-Wave controllers mark a node failed after repeated delivery failures, and the marking sticks until you clear it.

Cloud devices are the least visible: either the vendor's server has not heard from the device or your platform cannot reach that server, and the app cannot tell you which.

The isolation test#

Four questions, in this order. Each one eliminates a layer.

1. Does the device work at the device?

   Press the physical button, flip the switch, or check whether it still does its local job. A smart plug whose button toggles the load is alive and merely unreachable. If nothing physical works, stop here: this is power or hardware. Check the breaker, the load, the batteries, and whether a switch upstream cut power to it.

2. Does anything else on the same radio still work?

   Pick another device on the same protocol, preferably in a different room. If everything on that radio is out, the shared component failed: coordinator, border router, dongle. If only this one is out, the fault is local to it or its link, meaning placement, interference or a dead battery.

3. Does a device on a different radio still work in the same app?

   If Zigbee devices are dead but Wi-Fi devices respond in the same app, the hub is running and one radio has failed. If everything is dead across all radios, the hub itself is the problem: look at power, storage, an update in progress, or a crashed service.

4. Does voice or a local command work when the app does not?

   This is the most informative test in the whole list. If a voice command reaches the device while the app shows it as unresponsive, the device and its radio are healthy and discovery is broken. Your app finds devices over mDNS on the LAN; voice goes through the hub, which already knows the route. Blocked multicast produces exactly this split.

   Then pull the internet for two minutes and try a local command. Still works and the fault is in a vendor cloud. Stops working and your platform routes that command through the cloud by design, which local versus cloud control explains per platform.

Wi-Fi devices#

Wi-Fi devices drop off for network reasons far more often than for device reasons.

DHCP lease and address changes. A device that took a new address while your controller cached the old one becomes unresponsive without either side noticing. Long lease times and DHCP reservations for hubs and bridges eliminate a whole class of intermittent failures.

Association table limits. Access points hold a finite number of associated clients, roughly 32 to 64 on budget hardware and higher on prosumer gear, and vendors rarely document the figure. The symptom is that everything works until you add more devices, then random ones drop. Past roughly 50 Wi-Fi IoT devices you want dedicated access points or a different radio. Wi-Fi smart devices: the hidden costs has the airtime side.

Band steering and roaming. A device that keeps being steered between bands or access points, or that handles 802.11k, v and r badly, will disconnect and reconnect all day. Pinning IoT devices to a 2.4 GHz only SSID fixes it.

Power save. Budget Wi-Fi devices sleep aggressively and reconnect slowly. A device that is reliably slow on the first command and fine afterwards is waking up, not faulty.

Client isolation. On by default on some mesh systems and all guest networks, it stops the controller reaching the device while the router still shows it connected. See the network setup a smart home wants.

Thread devices#

For Thread, the top failure surface is not the mesh. It is mDNS on your home network.

A border router runs a service registration protocol server and an advertising proxy, publishing mDNS records on behalf of sleeping Thread devices. If your router suppresses multicast, those records never reach the controller and healthy devices vanish from the app. IGMP snooping, client isolation, VLAN boundaries without a reflector and multicast optimization on mesh Wi-Fi all do this.

After that, in order:

• The border router is down or has no route. Every Thread device attached to it goes at once. If you have only one border router, it is a single point of failure for your entire Thread estate.
• You have more than one Thread network. Devices split across networks cannot relay for each other, so the smaller group has fewer repeaters and worse reliability. Thread devices dropping or split networks has the detection method.
• No router in the right direction. Battery devices are sleepy end devices and never relay. If a corner of the house is unreliable, add a mains-powered Thread device between it and the border router. Designing a Thread mesh that holds up covers placement.
• Congestion. OpenThread logs ChannelAccessFailure when the radio listened and never found the channel clear. That is spectrum, not hardware. Compare your Thread and Wi-Fi channels with the channel planner.

Thread troubleshooting, in order is the full ordered decision tree.

Zigbee devices#

Coordinator child capacity, not network size. The theoretical Zigbee network is enormous; the real limit is how many devices can be direct children of your coordinator. Old CC2531 sticks supported around 20. Modern EFR32MG21 and MG24 coordinators are far higher. The fix is not a bigger coordinator, it is mains-powered routers so end devices attach to something other than the coordinator.

A removed or moved router. Zigbee end devices attach to a single parent. Unplug a mains-powered bulb that ten sensors used as their parent and those sensors go quiet until they find a new one, on their own sleepy schedule.

Congestion. MAC_CHANNEL_ACCESS_FAILURE in Zigbee2MQTT means the spectrum is busy, typically an overlapping Wi-Fi network or a running microwave. NoAck on battery devices is normal and not by itself a fault.

USB 3.0 noise. A dongle plugged straight into a USB 3.0 port sits in broadband noise that cannot be filtered, because it is in-band across 2.4 to 2.5 GHz, as documented in an Intel and USB-IF white paper from 2012. The fix is physical: a 1 to 2 meter USB 2.0 extension cable, which is why Nabu Casa ships one with the Connect ZBT-2.

Green Power devices need a proxy such as a mains-powered bulb and never appear in network scans, so their absence from a map is not a fault. More in Zigbee in 2026.

Z-Wave devices#

Z-Wave fails differently because routes are calculated and stored, not discovered continuously.

Stale routes. Move or remove a mains-powered node and devices that routed through it keep trying the old path. Classic mesh allows up to 4 hops, so a broken link near the hub can strand a branch. Run your controller's heal or rebuild routes function after moving mains-powered nodes, and expect hours on a large network.

Nodes marked failed. After repeated delivery failures the controller flags a node dead and stops trying. The flag persists after the device recovers, so a device can be working and still show as failed until you clear the status or ping the node.

Wakeup intervals. A battery Z-Wave device is asleep almost all the time and accepts configuration only during its wakeup, so a queued setting change can sit unapplied for hours. Designed behavior, not a failure.

Long Range is a star, not a mesh. Z-Wave Long Range devices talk straight to the hub, with no repeaters and no hops, so adding devices never improves LR coverage. See Z-Wave and Z-Wave Long Range.

Cloud devices#

If a device depends on a vendor cloud, half the failure modes are not on your property at all.

Symptoms that point at a cloud: one brand fails while others are fine, the vendor's own app fails too, the device answers a local integration but not your platform, or failures follow a schedule rather than a location. Vendor outages are real and large: Google's global outage on 18 August 2026 lasted about twelve hours and left Nest hubs unresponsive.

Local causes that imitate cloud failures: an expired account token after a password change, a device registered to a different regional cloud than your account, and a router blocking outbound connections from the IoT VLAN. What still works when the internet goes down has the device class breakdown, and when a smart home company shuts down covers the permanent version.

Symptom lookup#