# Matter devices are unavailable
**URL:** https://community.homey.app/t/matter-devices-are-unavailable/148583
**Category:** Questions & Help
**Tags:** homey-pro, matter
**Created:** [January 5, 2026, 8:53am UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583 "2026-01-05T08:53:42Z")
**Posts on this page:** 20
**Page:** 20
### Author:  [@Pascal\_Nohl](https://community.homey.app/u/Pascal_Nohl)
#### Post date: [August 23, 2026, 8:41pm UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/385 "2026-08-23T20:41:17Z")
> [@smarthomesven](#):
>
> They look exactly the same to me.
They are not exactly the same.
As far as I know, the official Thread Network Viewer does not allow you to selectively hide weak or medium-quality links. That filtering is quite useful because it lets you reduce the graph to the links that are actually strong enough to be relevant when judging the robustness of the mesh.
Home Assistant also provides considerably more information for devices it knows. You can click on an individual node and inspect details such as its link quality and other Thread information.
So yes, the basic topology view looks similar, because both tools are visualising the same Thread mesh. The difference is in the diagnostic functionality and the amount of information you can extract from it.
---
### Author:  [@deejayreissue](https://community.homey.app/u/deejayreissue)
#### Post date: [August 23, 2026, 8:41pm UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/386 "2026-08-23T20:41:42Z")
> [@smarthomesven](#):
>
> But I have no experience with Thread
Then why do you keep commenting on it?
---
### Author:  [@Rammstein](https://community.homey.app/u/Rammstein)
#### Post date: [August 24, 2026, 8:27am UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/387 "2026-08-24T08:27:38Z")
Short feedback…exactly one week after my Thread Matter crash, and following a reboot, everything has been running smoothly ever since without any further Thread Matter failures!
The response from Athom was swift; we had a lively email exchange, and I explained in detail what I did and why. Thanks again for the prompt reply; it shows me that they are generally helpful! The disappointing part, however, is that I was once again referred to further reports and screenshots, with the final assumption being that the cause might be a topology/partition change (e.g., a leader/partition switch or router count drop).
In relation of this statement from @Pascal_Nohl
I suspect that despite all the efforts of the users, it looks like Athom itself cannot evaluate the feedback in detail. How else can you explain that after I submitted 3 reports and screenshots, in failure situation - after 12 hours in failure situation and after rebooted, no result could be obtained? It can only be due to the necessary tools or analysis, and not a lack of effort or competence on the part of Athom, because aim sure they have! @Doekse sayed one time " we need details and reports…" aim absolute agrees with this, because aim working self in a troubleshooting hotline and i know for sure how important it is to get the datas and the quality of data and thats the reason why i give always my best when i report a problem and send all what i can…but it seems it is never enough or wrong…i don’t know because this is not may first time when i open a Ticket for this topic what means i had delivered many datas before…
Anyway, I’ll spare you the standard topics we discussed again during the troubleshooting process suggested by support… I’m supposed to provide the following again the next time it crashes, whenever that may occur:
Athom final statement for further analyses:
Please send the ping screenshots + a fresh code and timestamp, and we’ll correlate immediately.
At The End, what i really do not understand finally, it seems Athom find the root cause, topology/partition change (e.g., a leader/partition switch or router count drop) and indeed related to the problem, then I think it would be important to investigate why Homey is not able the Leader transitions and how quickly it restores its neighbour and routing relationships afterwards…sounds clear for me in which direction Athom should search for a solution, provided you have the necessary analyzes tools and provides these the users enable in order to help!
---
### Author:  [@Rammstein](https://community.homey.app/u/Rammstein)
#### Post date: [August 24, 2026, 11:29am UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/388 "2026-08-24T11:29:04Z")
..well i conatct right now Athom in the Ticket (153766) again with the request to provide a clear instruction for the next Thread-Matter crash, the response was immediately what is really great and i appreciate.
Here is a short summery of the them, this are only the last lines from the last Support Email and maybe it could help somebody else who report a problem to Athom what he should note:
What to send us (so we can correlate fast)
– Failure timestamp + timezone
– Homey diagnostics code at failure
– 3–5 Ping screenshots
– Thread Diagnostics screenshots
– Any BR/power/network changes
– Second diagnostics code after recovery
Ps: At least i want to say, i really want to help Athom to understand the problem and be helpfully to find the root cause because i like the system very mutch and aim convinced we are on the right way to build a road also maybe for users who actually dont use Thread-Matter what the can use finally out of the box without problems, thats my personal goal in this story!
---
### Author:  [@Pascal\_Nohl](https://community.homey.app/u/Pascal_Nohl)
#### Post date: [August 24, 2026, 12:01pm UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/389 "2026-08-24T12:01:50Z")
> [@Rammstein](#):
>
> i really want to help Athom to understand the problem
That is exactly the point. I also want to help Athom understand what is happening.
At the same time, I have now started migrating to Home Assistant, one device after another. I began with the router-capable Thread devices; those installed inside walls are still on Homey for the moment.
Since Homey and Home Assistant participate in the same single Thread network, together with my other Border Routers, I am hoping that Home Assistant’s diagnostic tools may actually help us understand what is going on. If they do, great. If they don’t, I am already prepared for a complete platform migration anyway.
The more devices HA knows, the more useful and readable its Thread topology becomes. For example, identifying the Leader could hardly be easier: it simply gets a crown:
Thread Border Routers and router-capable devices are also clearly identifiable. And when I click on the Leader, HA immediately gives me this level of information:
That is considerably more information than Homey or the official Thread tools make conveniently available to the user, and there is no need to cross-reference several tables manually just to work out which node has which role.
Role identification is immediately visible as well:
I find it unfortunate that neither Homey nor the Thread Group provides users with diagnostic tooling at this level, especially when Thread stability is repeatedly mentioned as a possible explanation for problems.
The irony is that I now have to migrate devices to Home Assistant simply to obtain the diagnostic visibility needed to investigate my Homey problems.
And once the devices are already there, fully updated, visible and working reliably, the remaining step towards moving the whole system becomes very small.
Edit:
This is part of the information for devices not already migrated:
---
### Author:  [@Rammstein](https://community.homey.app/u/Rammstein)
#### Post date: [August 24, 2026, 12:44pm UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/390 "2026-08-24T12:44:57Z")
OMG 🫣…i really dont know that HA is so far ahead in this topic…yess there are so many things which made a troubleshooting process and reporting much more efficiency on customer side…hopefully Athom take a look beside how HA manage it because with tools & information like HA provide the life on both sides could be much more simpler!
---
### Author:  [@deejayreissue](https://community.homey.app/u/deejayreissue)
#### Post date: [August 24, 2026, 3:45pm UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/391 "2026-08-24T15:45:31Z")
> [@Rammstein](#):
>
> i really dont know that HA is so far ahead in this topic
Because they accepted their shortcomings and fixed them
All I see from Athom is “our hardware is the best on the planet… Maybe it’s your setup”
I’m coming up to six weeks now with the ZBT-2. No issues whatsoever and I now have 65 devices.
I’ll be adding 8 outdoor MoT GU10s to my decking in the next week + a few other bits, which will take my Thread devices to around 80.
Will be happy to share an update once I can
@Pascal_Nohl good luck with the migration
---
### Author:  [@Rammstein](https://community.homey.app/u/Rammstein)
#### Post date: [August 24, 2026, 4:42pm UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/392 "2026-08-24T16:42:54Z")
That sounds great; to be honest, I’m almost a bit envious—especially when I think about the last few months and how much time I’ve invested in this.
Sure, we’ve made some headway, based of this thread, but as things stand now—and considering Athom’s stance on the matter after everything that’s been delivered—it’s all very disheartening.
Well, my system isn’t nearly as large as yours, and I’ve set up plenty of redundancies so the house keeps working even if there’s a Thread/Matter crash. Still, I do find myself asking how much longer I’m going to put up with this till my patience has run out… 😮💨
```auto
```
---
### Author:  [@deejayreissue](https://community.homey.app/u/deejayreissue)
#### Post date: [August 24, 2026, 5:07pm UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/393 "2026-08-24T17:07:52Z")
One interesting thing that I have noticed (although I can’t verify accurately) is that my MoT battery powered devices (mainly by Eve and IKEA) seem to have longer battery life using Thread with HA, than with Homey
I’m using the LADDA AAA batteries in most devices, just because they were super cheap. I found I was changing them often, every 2-3 weeks when the devices were connected directly by MoT to Homey Pro 2023.
I’ve not changed them once since moving to HA and most of those devices are sitting at around 40-60%
---
### Author:  [@robertklep](https://community.homey.app/u/robertklep)
#### Post date: [August 25, 2026, 5:01am UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/394 "2026-08-25T05:01:01Z")
It wouldn’t surprise me if Homey sets some unreasonably low maximum reporting interval on all devices (including battery-powered) to work around other issues, causing the devices to wake up much more often and drain their batteries faster.
---
### Author:  [@Pascal\_Nohl](https://community.homey.app/u/Pascal_Nohl)
#### Post date: [August 25, 2026, 5:47am UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/395 "2026-08-25T05:47:26Z")
> [@robertklep](#):
>
> causing the devices to wake up much more often and drain their batteries faster.
I thought the change went in the opposite direction: longer Matter subscription/reporting intervals to reduce unnecessary communication and therefore network traffic.
For sleepy Thread devices, of course, it is a little more complicated than simply saying that the subscription interval determines how often they wake up. But if Athom deliberately increased the reporting intervals, I would expect the intention to be reducing traffic rather than making battery-powered devices communicate more frequently.
The IKEA window contacts are also a special case. They were well known for excessive battery drain with their earlier firmware. IKEA even stopped selling them for a while, and they returned after a substantial firmware update.
The problem for some owners was that getting that firmware installed over OTA was extremely difficult. I was stuck with the old firmware myself because I simply could not get the updates through Homey despite many attempts.
I have now moved all of those devices to Home Assistant and was able to update every single one of them.
> [@deejayreissue](#):
>
> every 2-3 weeks
If you really had to replace batteries every 2–3 weeks, then there was definitely a serious problem. Even if they are now still showing 40–60% after six weeks, I would expect considerably more from a Thread sensor. In my experience, battery-powered Thread devices should normally run for many months and often well over a year, depending on the device and usage.
The IKEA sensors were the only ones with which I experienced really extreme battery drain.
However, that leads to another Homey issue I have observed: battery reporting.
Several of my devices would still show around 20–30% battery in Homey and then be completely dead the following day. @Doekse explained that many devices essentially report battery voltage rather than a reliable percentage, and converting voltage into a meaningful remaining-capacity percentage is difficult because the discharge curve can remain relatively flat for a long time and then fall very quickly near the end.
Home Assistant currently shows me both the battery percentage and, where available, the actual voltage.
Whether HA calculates the remaining battery capacity more accurately, I cannot say yet. None of the devices I have migrated currently has a sufficiently low battery level for me to make a fair comparison.
So for the moment, I can confirm the OTA-update difference very clearly. I cannot yet confirm whether HA’s battery indication is actually more accurate.
### Back to the topic
But just to be clear: this thread is **not** meant to become a Homey vs. Home Assistant discussion.
My intention is to compare what works and what does not work **at a specific moment** , and hopefully use HA’s additional diagnostic tools to get better information about the cause of the Matter problems on Homey. It is perfectly possible that both systems fail at the same time or that the available diagnostics still do not provide clear evidence.
So I would prefer to keep the focus on the original problem: **Matter devices becoming unavailable or not responding correctly.**
### Todays observation
This morning my garden fountain did not start. According to my logs, however, everything ran successfully. Homey reported no error, no timeout and no unavailable device.
I noticed something very similar during yesterday’s migration. I could toggle a Matter plug on and off in the Homey UI, and the UI reacted as if the command had succeeded, but the physical plug did nothing. Again: no error, no timeout and no indication that the device was unavailable.
When I switched to HA, I could toggle the same device there and the physical plug responded immediately.
I have now observed this several times, particularly with the garden fountain.
What makes this interesting is that after the latest Homey update I seem to see **fewer explicit errors** , but that does not necessarily mean the commands are actually reaching the devices. In some cases Homey appears to accept the command and consider it successful while nothing happens physically.
Perhaps this is related to internal changes intended to improve Matter stability, perhaps not. I had never observed this particular behaviour before, so for now it is simply another symptom worth documenting rather than a conclusion about the cause.
---
### Author:  [@Doekse](https://community.homey.app/u/Doekse)
#### Post date: [August 25, 2026, 6:24am UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/396 "2026-08-25T06:24:50Z")
> [@Pascal\_Nohl](#):
>
> I thought the change went in the opposite direction: longer Matter subscription/reporting intervals to reduce unnecessary communication and therefore network traffic.
We did indeed go in the opposite direction. Before the update, we used a more frequent subscription interval. I’m not sure when @deejayreissue last tested it with Homey, but we now basically match what Matter.js does.
And if you want, you can always set a longer subscription interval, of course. That should also help prolong battery life.
> [@Pascal\_Nohl](#):
>
> What makes this interesting is that after the latest Homey update I seem to see \*\*fewer explicit errors\*\*, but that does not necessarily mean the commands are actually reaching the devices. In some cases Homey appears to accept the command and consider it successful while nothing happens physically.
The downside of a longer subscription interval is that it can take Homey longer to detect that a device has become unresponsive or gone offline. As a result, Homey may still try to send a command because it assumes the device is online and reachable.
---
### Author:  [@Rmb](https://community.homey.app/u/Rmb)
#### Post date: [August 25, 2026, 8:11am UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/397 "2026-08-25T08:11:28Z")
> [@Pascal\_Nohl](#):
>
> In some cases Homey appears to accept the command and consider it successful while nothing happens physically.
Is that conform the spec’s of Matter/Thread? Are we back to one way communication like KlikAanKlikUit? I would expect that with Matter/Thread a command shall always be confirmed before the status of the device is updated. Why would I otherwise upgrade from KlikAanKlikUit to Matter/Thread?
---
### Author:  [@robertklep](https://community.homey.app/u/robertklep)
#### Post date: [August 25, 2026, 8:52am UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/398 "2026-08-25T08:52:39Z")
> [@Rmb](#):
>
> Is that conform the spec’s of Matter/Thread?
AFAIK, a device needs to acknowledge that it has received/execute a command. However, I don’t think there’s anything in the spec that either allows or disallows a sender (Homey) to use “optimistic mode” (as HA/ESPHome call it), where merely _sending_ the command causes it to update its internal device state, before the actual device has acknowledged it.
---
### Author:  [@Rammstein](https://community.homey.app/u/Rammstein)
#### Post date: [August 25, 2026, 9:26am UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/399 "2026-08-25T09:26:37Z")
I don’t understand what the point of that is. I send a command and then respond to it myself, hoping that everything will work out? I’m not that knowledgeable about you guys, but as a regular user, this is beyond my comprehension…can anybody explain the advantage of this behavior because i have seen the same behavior in my system, but only one time…
---
### Author:  [@Pascal\_Nohl](https://community.homey.app/u/Pascal_Nohl)
#### Post date: [August 25, 2026, 9:45am UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/400 "2026-08-25T09:45:39Z")
> [@Rmb](#):
>
> Is that conform the spec’s of Matter/Thread?
We can discuss the standards on paper, and I think we would mostly agree that the concepts behind Matter and Thread are excellent.
They are among the most modern technologies currently available for the smart home: local communication, manufacturer independence, encryption, IP-based networking and, with Thread, a mesh that can dynamically adapt routes, change roles and recover from failures.
But the biggest challenge with any new technology is not necessarily the specification. It is the **implementation** in real hardware, devices and controllers.
Sometimes existing hardware can theoretically support a new technology, but starts struggling when the number of devices or amount of communication increases. Sometimes the hardware is fine and the software implementation is the problem. And integrating something fundamentally new into an existing platform is naturally much harder than designing everything around it from scratch.
Just my personal concern regarding Homey: Athom had to integrate Matter and Thread into an existing hardware and software platform with limited CPU and RAM resources and an antenna concept that was designed years before Matter over Thread became such an important part of the smart-home market. That is a real engineering challenge.
Of course competitors have their own problems.
Home Assistant may have an advantage in some areas simply because users can run it on much more powerful hardware. Mine, for example, has an N100 CPU and 16 GB RAM. HA also benefits from an enormous developer community.
But HA is certainly not better at everything. C.A.F.E., for example, is nowhere near Advanced Flow in my opinion. Development is relatively slow, long-standing bugs remain, and there is already a fork because another developer became impatient.
Homey’s Advanced Flow, on the other hand, is outstanding. It is visually far ahead, developers can extend it, and in my experience it works extremely reliably.
My problem is not Homey as a concept. My concern is specifically somewhere in the Matter and/or Thread implementation.
I really hope Athom finds the underlying problem and fixes it.
My fear is that, if hardware limitations are part of the problem, they may be forced to keep tweaking behaviour to make the system fit within those limits. And every tweak risks introducing another side effect.
We may then move from:
**Devices become unavailable**
to:
**Devices remain available, but commands no longer actually reach them.**
And that second behaviour is exactly what I have started observing now.
---
### Author:  [@Pascal\_Nohl](https://community.homey.app/u/Pascal_Nohl)
#### Post date: [August 25, 2026, 9:56am UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/401 "2026-08-25T09:56:01Z")
> [@Rammstein](#):
>
> can anybody explain the advantage of this behavior because i have seen the same behavior in my system
There is no real functional advantage. **Optimistic mode** is mainly a concept to make the UI feel more responsive.
You press a button, the command is sent and the UI immediately changes the displayed state instead of waiting for confirmation from the device. If the command later fails, the UI can revert the state and show an error. To the user, this simply feels faster.
HA definitely uses this concept in parts of its UI. During my migration I sometimes tested devices before they had completely joined the Thread network. I pressed the button, the state changed immediately in the UI, but the physical plug did nothing. A few seconds later the UI changed back and HA reported that communication with the device had failed.
That is perfectly fine **if the underlying logic distinguishes between “command sent” and “command successfully executed.”**
With Homey Flows, however, this could potentially become a real problem. Imagine a Flow sends a command, Homey considers the card successful immediately and continues with the next card. If the failure is only detected several seconds later, it may already be too late to follow that card’s error path.
I have no evidence that this is actually what Homey is doing — it is simply a logical possibility that would fit what I am observing.
And I would also not assume that HA automations necessarily wait until the physical device has changed state. The important question for both systems is **at which point an automation action is considered successful: when the command is sent, when Matter acknowledges it, or only when the expected device state is confirmed.**
That distinction could be very relevant to the behaviour we are seeing.
---
### Author:  [@Rammstein](https://community.homey.app/u/Rammstein)
#### Post date: [August 25, 2026, 10:21am UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/402 "2026-08-25T10:21:41Z")
many thx for your professionals explanations and answers of the last month..i learned a lot every time when i read your lines…well, regarding Optimistic mode, now i understand it, it make absolute sense, i will monitor more detailed the behavior in my system…
> [@Pascal\_Nohl](#):
>
> I noticed something very similar during yesterday’s migration. I could toggle a Matter plug on and off in the Homey UI, and the UI reacted as if the command had succeeded, but the physical plug did nothing. Again: no error, no timeout and no indication that the device was unavailable.
But this behavior tell us already that Homey is working with the Optimistic Mode or not?
---
### Author:  [@smarthomesven](https://community.homey.app/u/smarthomesven)
#### Post date: [August 25, 2026, 10:29am UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/403 "2026-08-25T10:29:51Z")
> [@Pascal\_Nohl](#):
>
> HA also benefits from an enormous developer community.
Homey also has a large developer community, see
> **[Homey Apps Statistics](https://smarthomesven.github.io/homey-appstore-stats/)**
762 devs, 1541 apps. And there are also many apps on Homey that aren’t available on other systems.
---
### Author:  [@Doekse](https://community.homey.app/u/Doekse)
#### Post date: [August 25, 2026, 11:20am UTC](https://community.homey.app/t/matter-devices-are-unavailable/148583/404 "2026-08-25T11:20:43Z")
@Pascal_Nohl we don’t use any form of optimistic mode when sending commands to Matter devices. The interface does indeed change to on or off for example, but if we don’t receive an acknowledgement from the device within 10 seconds, you should get a timeout and the interface should change back to its former state.
Since your Apple TV was previously the Thread Leader, my guess is that something is going wrong between Homey sending the command via the Thread Leader and receiving an acknowledgement back when it perhaps shouldn’t.
I’ll run this by the team to see if we can figure out exactly what’s going wrong here.
[Previous page](https://community.homey.app/t/matter-devices-are-unavailable/148583.md?page=19)
[Next page](https://community.homey.app/t/matter-devices-are-unavailable/148583.md?page=21)