Matter Device Shows ‘No Response’ in One App But Works in Another (2026): The Fabric-by-Fabric Log That Explains Why

Here is the exact situation this page is about, because it is oddly specific and almost nobody writes about it directly. You have a Matter device — a plug, a bulb, a sensor, a lock — that you paired into more than one ecosystem. In one app it works perfectly: you tap it, it responds, the state is correct. In the other app the very same device sits there greyed out, tagged “No Response,” “Device is unreachable,” “Couldn’t reach device,” or “Status unavailable,” and refuses to do anything. Same device. Same Wi-Fi. Same minute. Working in Apple Home, dead in Google Home. Or fine in Alexa, unreachable in SmartThings. As an Amazon Associate I earn from qualifying purchases.

We are the Smart Home Guide Editors, and this is not the generic “my smart device is offline” article. If your device is dead in every app at once, that is a different, simpler problem — it is genuinely offline, and the fix is power, Wi-Fi, or the hub. This page is about the stranger and more frustrating case where the device is provably alive, because one app is controlling it fine, yet a second app insists it cannot be reached. That contradiction confuses people into resetting perfectly healthy hardware, and the reset usually makes it worse. We spent a couple of months not clearing those “No Response” flags immediately but instead recording, for each one, which app showed it, which app still worked, and what the underlying cause turned out to be. The pattern that came out of that log is what this page is built on, and it points to fixes that are almost always faster and less destructive than the factory reset everyone reaches for first.

The One Idea That Explains Almost All of It: Each App Talks Over Its Own Fabric

If you take away one concept, take this one, because it dissolves most of the confusion. When you share a Matter device across ecosystems — Apple Home, Google Home, Amazon Alexa, Samsung SmartThings — you are not giving all of them a shared pipe to the device. Each ecosystem establishes its own secure connection to the device, called a fabric. A Matter device that lives in three ecosystems is a member of three separate fabrics simultaneously, each with its own credentials, its own route to the device, and its own controller (a hub, a speaker, a border router) responsible for reaching it.

That is why “works in one app, dead in another” is not a paradox at all. It is the expected behavior when one fabric’s route to the device is broken and another fabric’s route is intact. The device is fine. The Wi-Fi is fine. What has failed is one ecosystem’s specific path — its controller went offline, its Thread border router lost the device, its cached network address went stale, or that ecosystem simply lost its share of the connection. The app showing “No Response” is telling you the truth about its own fabric and nothing about the device’s actual health.

Once you internalize that, the whole troubleshooting approach flips. You stop asking “what’s wrong with the device” — the working app already answered that, the device is fine — and start asking “what’s wrong with this one ecosystem’s path to a device that is demonstrably reachable.” That is a much smaller, much more solvable question, and it almost never requires touching the device itself.

How We Tracked This Down

A word on method, because the failure mode here punishes guessing. We did not run a certification lab or publish controlled network captures, and we are not going to dress up a home setup as one. What we did was keep a boring, disciplined incident log across a small fleet of multi-admin Matter devices in one home — a mix of Matter-over-Wi-Fi plugs and bulbs and a couple of Thread-based sensors and a lock — each one shared into at least two of Apple Home, Google Home, and Alexa, with SmartThings on a few.

The rule we set for ourselves was simple: when a device showed “No Response” in one app, do not touch it yet. First write down which app showed the flag, whether at least one other app could still control the device (to confirm it was alive), what had changed recently (a router reboot, a firmware update, a new device added, a hub unplugged), and then work the least-destructive fix first and record what actually cleared it. Over time the incidents sorted themselves into a small number of root causes with very different frequencies, and — this is the useful part — each cause had a recognizable fingerprint in which app failed and what had happened just before. That mapping is the table below. It is observational and specific to our environment; treat the frequency column as “what tends to happen in a normal multi-admin home,” not a universal statistic. Your fringe cases will differ. The ordering, though, has been stable enough that we now troubleshoot straight down it.

Read that table as a priority order, top to bottom, because that is how the incidents actually distributed for us. The cause people reach for first — “the device is broken, reset it” — is the last row and the least common by a wide margin. When exactly one app says “No Response” and another app can still flip the device, the bottom row is almost ruled out by definition. You are somewhere in the top five, and all five are fixed without resetting the device.

The Six Causes, In the Order They Actually Happen

1. That Ecosystem’s Controller Is Simply Offline

This is the most common and the most embarrassing, because the fix is trivial once you see it. Every ecosystem needs a resident controller to reach a Matter device when you’re issuing commands through its app: Apple Home leans on a HomePod or Apple TV, Google Home on a Nest speaker or display, Alexa on a compatible Echo, SmartThings on its hub or a compatible appliance. If that specific controller is unplugged, rebooting, off Wi-Fi, or was quietly moved to a guest network, that ecosystem alone loses its ability to relay — while every other ecosystem, using its own controller, carries on fine.

The tell is clean: the failing app is always the one whose hub is compromised, and the moment you power-cycle that hub and let it rejoin, the “No Response” clears without you touching the device. Before anything drastic, physically look at that ecosystem’s hub. Is its light normal? Is it on your main network and not a range extender with a different SSID? A hub sitting on a flaky outlet or a far-edge mesh node produces exactly this “works over there, dead over here” pattern.

2. A Stale Network Address After a Router Reboot

Matter-over-Wi-Fi devices are found on your network by service discovery (mDNS) and addressed over IPv6. When your router reboots, hands out new DHCP leases, or changes addressing, a device can come back at a slightly different route — and one ecosystem’s controller may keep using the old cached address for a while before it re-resolves. That ecosystem shows “No Response” while a controller that already re-resolved shows the device fine.

The reliable, low-effort fix is to nudge re-discovery rather than reset anything. Reboot the failing ecosystem’s controller so it clears its cache and re-resolves, or power-cycle the device once (off, ten seconds, on) so it re-advertises itself on the network and every fabric picks up the fresh address. Note the crucial distinction: power-cycling the device is not the same as factory-resetting it. Pulling power for ten seconds costs you nothing and keeps all your pairings; a factory reset wipes every fabric and forces you to re-add the device to every ecosystem from scratch. Reach for the power cycle; leave the reset alone.

3. A Thread Border Router That Dropped (Thread Devices Only)

If the device that shows “No Response” is a Thread device — many battery sensors, some locks and bulbs — there is an extra layer. Thread devices don’t touch Wi-Fi directly; they reach your network through a border router, and different ecosystems may route through different border routers. Apple might reach a Thread sensor through a HomePod acting as a border router while Google reaches it through a Nest device acting as another. If the border router that one ecosystem depends on goes offline, that ecosystem loses the Thread device — and an ecosystem routing through a still-healthy border router keeps it.

This is the case that most looks like “the sensor is dead” while being nothing of the sort. Confirm the device is Thread, then check which border routers are up. Power-cycle the one the failing ecosystem depends on. And if you run only a single border router in the whole house, understand that it is a single point of failure for every Thread device on that fabric — adding a second border-router-capable device is the durable fix. We cover the underlying Thread mechanics in our guide on whether you actually need a Thread border router and on a border router that isn’t working.

4. Fabric-Slot Exhaustion: The Limit Nobody Mentions

Matter devices can belong to a limited number of fabrics — commonly around five, depending on the device — and each ecosystem you share into consumes one slot. Most homes never hit this. But if you have been enthusiastically adding the same device to Apple and Google and Alexa and SmartThings and a hub app, you can run out, and the symptom is telling: the most recently added ecosystem is the one that shows “No Response” or fails to complete sharing, while the ones you set up earlier keep working. Sometimes an old, abandoned fabric — from a hub you no longer use — is squatting on a slot the new share needed.

The fix is housekeeping, not resetting. Remove the device from an ecosystem you don’t actually use (which frees its slot cleanly), then re-share to the ecosystem that was failing. If you genuinely need the device in five places, you are at the edge of what the standard supports and should decide which two or three ecosystems you truly control it from. Trimming to the fabrics you use is healthier than pushing the device to its limit and living with a flaky fifth app.

5. IPv6 and Multicast Turned Off at the Router

This one hides in your router settings and produces the most intermittent, maddening version of the problem. Matter-over-Wi-Fi leans on IPv6 and on multicast/mDNS to find and reach devices. If your router has IPv6 disabled, is filtering multicast, has aggressive “AP isolation” or band-steering that shuffles devices between 2.4 and 5 GHz under one SSID, or runs a “smart connect” feature that hides which band a device is on, one fabric’s discovery can be starved while another limps along — giving you that flickering, one-app-dead behavior that never quite reproduces on demand.

The fixes live in the router, not the device: enable IPv6, disable any multicast or mDNS filtering, and — the big one for smart-home stability — split your 2.4 GHz and 5 GHz networks into separate SSIDs so devices stop being bounced between bands. Most smart-home devices, Matter included, are happiest pinned to a stable 2.4 GHz SSID. If your “No Response” incidents cluster right after you changed anything about the router or mesh, this is very likely your cause. Our deeper walkthroughs on devices that keep dropping Wi-Fi and devices going offline after a router reboot go further into the router side.

6. When It Really Is the Device

Rarely — and it was genuinely the smallest class in our log — the device itself is the problem. But this announces itself differently: every app loses the device within a short window, not just one. If Apple, Google, and Alexa all go red on the same device inside a few minutes, stop reading this fabric-by-fabric page and treat it as a plain offline device: check its power, check its Wi-Fi, power-cycle the device, and if it’s a Thread device confirm at least one border router is up. The single-app “No Response” that this article is about is, by definition, not this case, because a working second app is your proof the device is alive.

The Same Failure Wears a Different Name in Every App

Part of why this problem is so disorienting is that the four big ecosystems each describe the identical underlying condition — “my fabric cannot currently reach this device” — with completely different wording, and none of them says the useful thing out loud, which is “the device is probably fine; my path to it is not.” Learning to translate the label back into that plain meaning stops you from taking the message literally. When Apple Home tells you a device is not responding, it is not claiming the device is broken; it is reporting that the controller it is using right now could not complete a round-trip. The same is true of every other phrasing. The table below is the decoder we keep in our heads, mapping the on-screen label to what it actually means and to the first thing worth checking.

Notice that the “first thing to check” column never says “reset the device.” In every row the first move is about the controller for that ecosystem, because that is where single-app failures almost always live. The wording is designed to make you suspect the device; the reality points at the hub. When two of these labels appear on the same device in different apps at once, and yet a third app still works, you are looking at two independent fabric-path problems on one healthy device — treat each failing app separately, starting with its own controller.

A Fast Triage Sequence

When the “No Response” flag appears in one app, resist the reset and run this order instead. Each step is cheap and non-destructive, and most incidents end within the first three.

The reason to publish this as a numbered ladder is that the internet’s default advice — “remove and re-add the device” — is step seven here, and the true nuclear option, the factory reset, is step eight. People start at seven or eight and wonder why they spend an evening re-pairing everything. Ninety percent of the time the answer was step two or three: a hub that needed a reboot.

Prevention: The Setup Order and Habits That Avoid This

You can’t eliminate the failure mode — it is inherent to sharing one device across independent ecosystems — but you can make it rare and easy to fix. A few habits did the most for us. First, decide before you share a device how many ecosystems you actually control it from, and keep it to two or three; every extra fabric is another controller that can independently go dark and another slot toward the limit. Second, give each ecosystem a healthy, wired-or-well-placed controller on your main network, not a controller stranded on a far mesh node or a guest SSID. Third, run at least two Thread border routers if you own Thread devices, so no single box takes a fabric down when it reboots. Fourth, split your Wi-Fi bands into separate SSIDs and pin smart-home gear to 2.4 GHz, which removes a whole category of intermittent discovery problems. If you’re building a Matter home from scratch, the order you do things in genuinely matters, and we walk through it in the Matter setup order that saves hours and in sharing a Matter device across Alexa and Google Home.

A Worked Example: One Plug, Three Apps, One Reboot

To make the ladder concrete, here is a representative incident from our log, condensed. A Matter-over-Wi-Fi smart plug was shared into Apple Home, Google Home, and Alexa. One evening Google Home showed it greyed out with “Couldn’t reach device.” Apple Home controlled it instantly; Alexa controlled it instantly. So step one was already answered — two apps proved the plug was alive, which immediately took the factory reset off the table and reframed the whole thing as “Google’s path is broken,” not “the plug is broken.”

Step two was to look at Google’s controller. The Nest speaker that Google relies on had been moved earlier that day onto a mesh satellite while we rearranged a room, and that satellite had briefly dropped off Wi-Fi. The plug was fine; Apple and Alexa reached it through their own healthy controllers; only Google’s relay was compromised. We did not touch the plug at all. We power-cycled the Nest speaker and let it rejoin the main network. Within about a minute Google Home re-resolved the plug and the “Couldn’t reach device” label cleared on its own.

The tempting wrong path was right there the whole time: Google Home offers a “remove and set up again” option two taps away, and taking it would have “worked” — the plug would have re-appeared in Google — while quietly consuming effort, risking a fabric-slot collision, and doing nothing about the actual cause, a controller on a bad node. The next time that satellite hiccupped, the problem would have returned, and we’d have blamed the plug again. The reboot fixed the thing that was broken. The re-pair would have fixed a symptom and hidden the cause. That gap between “made the error go away” and “fixed what was wrong” is the entire reason to work the ladder in order instead of starting at the bottom.

What Actually Helps to Have On Hand

The honest truth is that most fixes on this page cost nothing — they’re a reboot or a settings change. The few physical things that reduce recurrence are cheap and boring, which is exactly why they work. A basic smart plug on the outlet that powers your ecosystem’s hub lets you power-cycle a wedged controller from your phone instead of crawling behind furniture. A short, flat flat Ethernet cable to hardwire a HomePod, Nest hub, or Echo onto your main network removes the “controller drifted onto a bad wireless node” cause entirely. If your Thread coverage is the weak link, adding a modest Thread-capable hub or border router device as a second border router turns a single point of failure into a resilient mesh. And a simple Wi-Fi mesh node or extender placed near a chronically unreachable controller can fix a fabric that only fails because its hub sits at the edge of coverage. None of these are exciting purchases; all of them attack a specific row in the table above.

Frequently Asked Questions

Why does my Matter device work in Apple Home but show “No Response” in Google Home (or vice versa)?
Because each ecosystem reaches the device over its own separate connection — its own fabric — using its own controller. If Apple’s controller and route are healthy but Google’s controller is offline or has a stale address for the device, Apple works and Google shows “No Response.” The device itself is fine; one ecosystem’s path is broken. Reboot the failing ecosystem’s hub first.

Should I factory reset the device to fix “No Response” in one app?
Almost never, and it should be your last resort. A factory reset wipes the device from every ecosystem and forces you to re-pair it everywhere, so you turn a one-app problem into an all-app chore. Because a second app still controls the device, you already know it’s alive — the fix is on the failing ecosystem’s side (hub reboot, re-share), not the device’s.

Is “No Response” in one app a sign the device is dying?
No. If it were a hardware or firmware failure, every app would lose the device at roughly the same time. “No Response” in exactly one app while another app works is the signature of a broken fabric path, not a broken device. Only worry about the hardware when all ecosystems fail together.

Does adding a device to too many ecosystems cause this?
It can. Matter devices support a limited number of fabrics (commonly around five). If you keep adding ecosystems, the most recently added one may fail to hold a stable connection, or an abandoned old ecosystem may be occupying a slot. Remove the device from an ecosystem you don’t use, then re-share to the one that’s failing.

My device is on Thread, not Wi-Fi — does that change the fix?
Yes, it adds one likely cause: a border router. Thread devices reach your network through border routers, and different ecosystems can route through different ones. If the border router a given ecosystem depends on goes offline, that ecosystem loses the device while others keep it. Restore or power-cycle the relevant border router, and run at least two so no single reboot takes Thread down.

Could my router settings be the cause?
Frequently, especially for the intermittent version. Matter-over-Wi-Fi needs IPv6 and multicast/mDNS to discover and reach devices. If your router has IPv6 off, filters multicast, or bounces devices between 2.4 and 5 GHz under one SSID, one fabric’s discovery can be starved. Enable IPv6, stop filtering multicast, and give 2.4 GHz its own SSID.

Will power-cycling the device lose my settings?
No — power-cycling (unplug ten seconds, plug back in) keeps every pairing and simply makes the device re-announce itself on the network. That is very different from a factory reset, which erases all fabrics. Use the power cycle freely; treat the reset as the nuclear option.

Mistakes to Avoid

The costliest mistake is skipping straight to a factory reset the moment one app says “No Response.” You destroy every working fabric to fix a single broken one, then spend an evening re-pairing across ecosystems — and if the real cause was an offline hub, the freshly re-added device will just go “No Response” again in that same app. The second mistake is blaming the device when the failing app is telling you about its own path; the working app is a free, definitive proof of device health that people ignore. The third is running a single Thread border router and a single hub per ecosystem on a marginal mesh node, which turns every routine reboot into a “No Response” incident. And the fourth is over-sharing — adding a device to five ecosystems because you can — which walks you into the fabric limit and makes the newest app perpetually flaky. Almost every durable fix here is about giving each ecosystem a healthy controller and keeping the number of fabrics sane, not about the device.

The Bottom Line

“No Response” in one app while another app works is not a contradiction and it is not a dying device — it is one ecosystem’s private connection to the device having a bad day while the others are fine. That reframing is the whole game: it tells you to fix the fabric, not the hardware, and the fabric fixes are cheap and non-destructive. Confirm the device is alive in a working app, reboot the failing ecosystem’s hub, power-cycle the device without resetting it, mind your Thread border routers and router settings, and keep the number of ecosystems modest. Save the factory reset for the rare day when every app fails at once. Do it in that order and the problem that used to eat an evening becomes a two-minute reboot.

Smart Home Guide Editors — we write about Matter, Thread, and multi-ecosystem smart homes year-round. This guide is based on our own multi-admin incident log across a home fleet of shared Matter devices; it is observational and specific to that environment, not a certified lab study, and your edge cases will differ. Figures and behavior last reviewed July 18, 2026.