Sorry Pascal,
I’ve already pointed out to you more than once that I’ve been running a (Homey) Matter network with Aqara, Eve and Ikea devices for a year now and have NEVER had any problems whatsoever. So to me, it seems to be more of a PEBMAC issue.
Sorry, but dismissing the reported problems as “PEBMAC” is neither helpful nor a serious contribution to this discussion.
You are effectively suggesting that the issue lies with the users rather than with Homey. However, this is not an isolated report from one inexperienced user. A significant number of people have described similar Matter and Thread stability problems on this forum. Some have spent considerable time troubleshooting them, and some have ultimately abandoned Homey because they could not achieve a reliable system.
Using an obscure acronym to imply user error does not address any of the technical observations, logs or recurring symptoms discussed here. It merely dismisses the experiences of users whose systems do not work reliably.
It is perfectly valid to say that you do not experience these problems yourself. What is not valid is concluding from your own experience that everyone else must be causing them.
Please allow those who are actually affected to discuss the problem constructively and peacefully. If you have technical evidence, test results or practical suggestions, they are welcome. Otherwise, comments that simply blame the users do not move the discussion forward.
IKEA devices were certified months before they were released, but the firmware was total garbage for everyone for the first few months of the roll out.
What exactly is your point?
Im far far away from any pro. There are people on here who blow my mind. But this forum, compared to SmartThings, Github and others has ALWAYS been helpful. This is the first time Ive ever seen a comment like this.
Do you know every single person on this forum? Do you know their lifestyle, their capability, personal commitments, intellectual abilities, physical abilities? . Have you considered the fact not everyone is a “pro” at this and a programmer or IT guru? Some of us do this for work, some for fun, some cross the line between hobby and addiction.
The whole point of a forum is for those using the platform is to get the help and discuss the issues they have.
Yes people ask the same questions Yes people miss the obvious. Yes this can be confusing for some. Yes people make mistakes. Im Guilty of all of it myslef. I will make and continue to make mistakes, i will miss things. As will many others. I have a seriously busy life, homey is a hobby not a lifestyle for me.
Comments like yours stop people wanting to ask for help and ruin that hobby. This leads to more mistakes and issues and then leads to them ranting about the platform Is and how it doesn’t work. It leads to pointless support requests and it doesn’t help
This wasn’t helpful to anyone. I don’t care if your the head of NASA, You don’t like being asked stuff or don’t like to help, don’t come on the forum and don’t automatically blame users. I can assure you, you will need help some day too.
Stop, stop—this discussion is getting a little out of hand.
I didn’t mean to offend anyone, belittle anyone, or anything like that.
I just wanted to say that individual users should perhaps first take a critical look at their own setup, instead of just repeating like a mantra: “Matter doesn’t work.” Because it does work and runs flawlessly for many other users—with the same software and the same devices. So, conversely, there must be some kind of problem with your own environment and/or configuration.
Sure, Matter isn’t currently the “perfect package” (aka Plug & Play) that we were promised. After all, it does take some effort to get up to speed on the whole subject—and the same goes for Zigbee, Z-Wave, etc., by the way. All we can do here is provide tips, tricks, and links (and there are plenty of those); the rest is up to the user, because there simply isn’t THE ultimate solution to every problem (maybe 42, but that’s another matter)
What I find particularly frustrating is when you want to help and end up realizing, for example, that the links weren’t opened even once, or that the response is “that won’t work”—even though the tip actually does work. That’s because some users expect a ready-made solution without having to think for themselves and simply repost the question in a different thread.
By the way, there’s an excellent search function that, with a little effort, lets you find an answer to most problems.
So I’m letting it go, because even my helper genes aren’t unlimited.
P.S.: To those who took offense at the term “PEBMAC,” I’d like to apologize.
PPS: I wrote this comment at 3 a.m. tonight and revised it again after a short nap.
This thread started with very good intentions but has been hijacked by a number of individuals with what seems to be gripes with Athom and that have added NO assistance to individuals experiencing this issue. I really could NOT give a rat’s arse as to how HA performs with thread devices, or Zigbee, it is totally irrelevant to resolving my issue. I don’t care about your issues with with Athom, take your complaints elsewhere, they add NO value to the intention of this thread.
Respectfully, I don’t think you’ve really been paying attention to any of my input in this thread and the many, many, many other plausible explanations that I have ruled out along the way.
If only that were the case for the issues myself, Pascal and others have experienced.
Apparently I have quite a large thread network, which I was quite shocked to hear to be honest, as I don’t think 50 Thread devices is a lot, but perhaps it is. I skipped Zigbee in my home automation journey, mostly because Zigbee isn’t universal with Homey like it is with HA and also because I just find the entire idea of Zigbee not very scalable and futureproof.
I do see a big future for Thread, especially as it becoming heavily imbedded in the architechture of Meta, Google, Apple and Amazon ecosystems, as well as what Unifi are starting to work on with Superlink. There are rumours of sub GHz Thread in the future, which will allow for long range communication, which could mean Z-Wave becomes redundant.
Homey Pro clearly isn’t robust enough to handle high density Thread networks, over around 30 devices with it’s current hardware.
As if it were by magic, I moved my 50 devices over the the HA ZBT-2 and ALL of my reliability issues literally vanished.
I haven’t changed a single other thing in my network before I made that change or since I made that change.
Hi @Craig_Allen
I cannot help noticing that you do not see HA as relevant, so let me start there.
Doekse from Athom himself has said the opposite in this thread. It is about contributing from as many angles as possible, and some of them may not look directly relevant at first glance. The quote below speaks for itself I think. 
Everyone’s frustration should be allowed out. And to those still running into trouble, the message from earlier still stands. Remember to open a support ticket and send your logs to Athom. That is their own request, simply passed on again.
Hi @ulrikb
Having used HA for about 4 years previously with more frustration than success I moved to Homey and I have found it to be more stable and far less cumbersome to work with. Hence having NO interest in considering using it now. That said HA may have become more user friendly in recent times. If there is now simple way to resolve the issue in Homey I may have to consider it. 
With regards my position on using this thread to air one’s grievances, it remains unchanged. 1 user turned the thread into his disillusionment platform with Homey Support. It added NO value to the conversation from my position. I agree the airing one’s frustration is OK, but not when the user airs the same comments post after post after post. Create a new post and link to it. I am sure @Doekse would also look at it. That is all I am saying on the matter because the thread here is to attempt to find a solution to a problem, and I am detracting from the point of the thread
Let me add another level to this discussion.
We are talking about problems that many users currently experience, or experienced before eventually leaving Homey because they felt that their reports did not receive sufficient attention from support. It is therefore disappointing when other users immediately suggest that the problem must be on the affected user’s side.
Perhaps a Matter device sends an excessive number of messages. Perhaps a certified Matter device does not behave exactly as expected. Perhaps the user’s Wi-Fi network is not perfectly aligned with Homey’s preferred configuration. Even then, a reliable smart-home platform should handle such situations gracefully, or at least clearly identify the problematic device or network condition instead of simply allowing devices to become unavailable.
This is not about comparing Homey and Home Assistant in order to declare a winner. It is about comparing what works and what does not work in the same user environment.
If both systems fail in the same environment, the user probably has a wider network or device problem. However, if one system remains stable while the other repeatedly fails with the same devices and network, it is reasonable to investigate the software or hardware of the system that is failing.
I also exchange a great deal of information privately with @ulrikb. His knowledge goes far beyond that of an average user, and he has technical insights that even I do not have, despite my own background as a developer and senior project manager. Before dismissing his comments as unhelpful, people should perhaps take a moment to consider who they are speaking to and what level of knowledge he brings to the discussion.
In my own case, Homey was rock solid for a period of time. Then an update arrived and, almost immediately, devices began becoming unavailable every day. After the most recent update, they have now remained stable again for several days.
How could I reasonably conclude that Homey has nothing to do with this?
The same hub, devices and environment were stable before. An update apparently brought the problem back, and another update may now have improved it again. That strongly suggests that software changes at least influence the behaviour.
Finally, I am currently building a new Omada network and encountered a technical problem. @ulrikb invested a great deal of time trying to help me, but unfortunately we could not solve it, so I opened a support ticket with TP-Link.
I received a reply within approximately two hours. They asked for precise logs, explained exactly how to capture the relevant traffic with Wireshark and requested the information they genuinely needed for their investigation.
I sent them everything. The following day, they provided an unreleased router firmware build for testing. It did not solve the problem, so I reported the result. A few hours later, another support engineer informed me that my original contact was not working that day, but that the case had already been escalated to their senior engineers for further investigation.
They now also have cloud access to my system.
That is what I consider real support: fast, structured and professional. There were no immediate accusations that the problem must be on my side and no endless trial-and-error suggestions involving cables, chargers or power supplies without first examining the technical evidence.
If Homey’s support were only half as responsive and systematic, many of these discussions would probably be very different.
If only somebody asked for a diagnostic report, haven’t seen anybody do that yet 
Since this is once again turning into a discussion about what Homey should do or how things could be done differently, I’m going to ask one last time to keep this thread on topic.
If the discussion continues to drift, I’ll close the topic to further replies. At this point, I don’t think this thread is helping anyone anymore.
I did open a ticket and included a diagnostic report. I was told that the only unusual thing visible in the logs was unstable power, so I should replace the charger and cable. Apparently, nothing else in the report was considered suspicious.
So please stop suggesting that users simply do not send diagnostic reports. Rammstein has already explained how painful his experience was and how much time he spent working with Homey Support and submitting reports.
And the only meaningful response to that is essentially: stop drifting off-topic, or I will close the thread.
If that is the level of openness and resilience shown by Support, then go ahead and close it—just as Homey so often seems to close the discussion instead of addressing the underlying problem.
@Pascal_Nohl, as I’ve mentioned a few times already, I’m genuinely here to help. However, I can only investigate an issue if I have some data to work with. At the moment, I don’t have any diagnostics or other information that would allow me to determine what’s happening on your Homey or identify the underlying cause.
I also want to clarify that I’m not suggesting we close this thread to ignore the issue. The reason I mentioned closing it is simply that in its current state the discussion isn’t moving us any closer to a solution. To troubleshoot a problem, we first need to establish what the actual cause is, and at the moment we don’t have enough information to do that. Once we have some diagnostics or other relevant data, I’m more than happy to continue investigating.
To that end, please feel free to generate a diagnostic report and send it to me via DM. Once I have that, I’ll gladly take a closer look. Until then, I’ll be closing this thread, as there’s unfortunately not much more we can accomplish here without additional information.
As promised, I would open the thread as soon as I got more information. And since then @Pascal_Nohl has shared a diagnostic report via DM. I had a look at it together with one of our Matter engineers. Unfortunately, the report mainly shows symptoms rather than a definitive root cause. Nevertheless, I think it’s useful to share the observations and the possible directions for further troubleshooting.
1. Nanoleaf light
One thing that stood out was a relatively high number of incomplete Thread transactions involving a single Nanoleaf light. That doesn’t necessarily make the Nanoleaf the root cause, but it does make it an interesting point to investigate.
@Pascal_Nohl had already disconnected that light from power for several days in an earlier troubleshooting attempt, while the other Matter-over-Thread devices continued to become unavailable. That makes it less likely that this particular device is the primary cause, although it could still be contributing to the overall network behaviour.
2. Additional Thread Border Routers
The diagnostics also indicate that another Thread Border Router is participating in the network. This led to an interesting observation that is worth explaining.
There is an important distinction between Thread Border Routers and Thread networks.
As mentioned earlier in this thread, when commissioning a Matter-over-Thread device with Homey, there are two options:
- Connect via Homey: the device is commissioned onto Homey’s own Thread network.
- Connect via iOS/Android: the device is commissioned onto your phone’s preferred Thread network. If that happens to be Homey’s network, the device joins Homey’s Thread network. If another Thread network is preferred, it joins that network instead.
We have a Knowledge Base article that explains these commissioning methods in more detail.
In addition, Thread Border Routers can automatically join existing Thread networks without any user intervention. Apple TV and HomePod devices are capable of doing this as well, so the Thread topology may change over time without anything being manually reconfigured.
One thing that stood out in the diagnostics is that Homey appears to be communicating with several Matter-over-Thread devices via its eth0 interface rather than directly through its own Thread radio. In practice, this most commonly indicates that those devices are part of another Thread network and are being accessed through Matter Multi-Admin rather than over Homey’s native Thread network.
Everybody can verify this themselves in the Homey Developer Tools, where the Network section shows to which Thread network each Matter device belongs.
Having multiple Thread Border Routers is generally a good thing, provided they’re all participating in the same Thread network. They improve coverage, resilience and provide redundant communication paths. Problems typically arise when multiple independent Thread networks exist alongside each other.
If, for example, Apple Thread Border Routers are participating in a different Thread network and those Border Routers communicate over Wi-Fi rather than Ethernet, communication with that Thread network also becomes dependent on the quality of the Wi-Fi connection. The Border Router itself isn’t necessarily the issue; the overall network topology is often the more important factor.
I’d therefore recommend using the Thread Tools app (available on both iOS and Android) to visualise the Thread networks in your environment and verify that all Border Routers are participating in a single shared Thread network rather than multiple independent ones.
Based on the diagnostics, my current hypothesis is that multiple independent Thread networks may be present rather than one unified Thread mesh.
3. Increased activity around 08:01
The diagnostics show a noticeable increase in Thread communication together with increased Rx/Tx issues from approximately 08:01 local time onwards.
The logs unfortunately don’t tell us why traffic increased. It’s entirely possible that this simply coincides with normal household activity starting for the day, but the available diagnostics can’t distinguish whether increased normal traffic exposed an existing issue or whether the increased traffic was itself a consequence of an already unstable Thread network.
4. Channel access failures
The diagnostics also contain a number of channel access failures reported by the Silicon Labs Thread radio, the same as we saw with @deejayreissue.
It’s important to understand what those messages actually mean. They indicate that the radio wanted to transmit but couldn’t access the channel. However, the radio itself has no way of determining why the channel was unavailable. It could have been occupied by another Thread device, Wi-Fi, another 2.4 GHz technology or some other source of RF interference.
At this point I don’t see evidence that Homey’s CPU, memory or Matter implementation became saturated. The diagnostics point towards communication issues on the Thread network itself rather than a processing limitation within Homey. Do note that I’m not saying Homey isn’t at fault here. It could be that the chipset is hitting its limits. I’m saying that the diagnostics don’t provide hard evidence to support that conclusion.
Similarly, we intentionally don’t publish a maximum number of supported Matter-over-Thread devices. There simply isn’t a meaningful single number that applies to every installation. The practical capacity depends on many factors, including the RF environment, Thread topology, device mix, reporting behaviour and overall Thread traffic. Two installations with exactly the same number of devices can therefore behave very differently.
Thread is also a distributed mesh network. Routers forward traffic for one another, so if one router starts behaving poorly or the network experiences congestion, that can affect communication with other devices as well. That’s inherent to how Thread (but also Zigbee and Z-Wave) operates rather than something Homey can isolate or prevent entirely. Normally the mesh should heal itself by selecting better routes, although that can take some time.
Regarding the new reporting interval settings, there isn’t a universal recommendation because the optimal values depend on the device and application. In my own setup, increasing the maximum reporting interval on my MotionBlinds blinds from the default 300 seconds to 3600 seconds significantly improved battery life. The setting hints describe the benefits and trade-offs of the available options.
5. Apple Home comparison
It was also mentioned that the same collection of devices previously operated more reliably in Apple Home.
That’s certainly a useful observation, but it doesn’t necessarily mean the underlying Thread topology was identical. Since Thread Border Routers can automatically join and leave Thread networks over time, today’s Thread network may differ considerably from the one that existed previously, even if the physical devices themselves haven’t changed.
6. Long-term diagnostics
There was also a suggestion to implement a longer-running diagnostic mode.
While I understand the reasoning behind that idea, I don’t think it would fundamentally change what we’re able to diagnose in this particular case. The limiting factor isn’t so much how long we collect diagnostics, but the level of detail exposed by the underlying Silicon Labs Thread stack.
The stack already provides information such as Thread topology changes, parent and router selection, route changes, Matter session establishment, retransmissions and channel access failures. However, when the radio reports that it couldn’t access the channel, it unfortunately can’t tell us why.
Collecting the same information over a longer period would tell us when those events occurred more often, but not necessarily what caused them. For that level of analysis, over-the-air packet captures or dedicated RF analysis tools would generally be required.
Hopefully these observations help explain why I currently believe the Thread network topology is the most promising direction to investigate further. At this point, confirming whether multiple Thread networks are present would be a very useful next step.
Finally, I’d like to ask everyone to keep the discussion civil and on topic.
Constructive discussion and alternative theories are absolutely welcome, but let’s keep the focus on interpreting the available diagnostic data and finding the root cause. If you have additional diagnostic reports, observations or test results that could help move the investigation forward, please share them.
Speculation is fine as long as it’s presented as speculation, but let’s avoid jumping to conclusions that aren’t supported by the available evidence. That will help us make the most progress.
It could also be power-related, as per this post on a forum that belongs to a different home automation platform that I shan’t mention.
That may also correlate with the power adapter issue mentioned earlier by @Pascal_Nohl. Interesting finding.
Disclaimer: I’m by no means an electrical engineer, so take this with a grain of salt. I’m not sure whether an underpowered USB-C adapter, or one supplying a lower-than-expected voltage under load, could affect the supply voltage reaching the SiLabs chipset. If that’s the case, it could potentially explain the behavior we’re seeing.
Edit: We didn’t find any low-voltage events in the latest diagnostic report, so I think we can rule out the power adapter as the cause.
Hi
That seems to be very important!
I myself had tried both methods, when one failed at first try because I thought they are just different ways to achieve the same result (adding the device to Honey).
Please update your UI to clearly communicate what is going to happen especially for using the iOS/Android method! If possible even tell the user clearly which Thread network the device will join.
I am convinced that simply being a bit more elaborate in the UI will prevent lots of problems from even arising. Don‘t expect users to read anything that is not boldly before their eyes Nobody will read a knowledge base article, when he is desperately trying to get his new gadget going
I say that with the experience of more than 30 years of running a software company specialised on end user ui apps. - I‘ve „seen it all“ 
Cheers
We already show a Learn more screen before the user makes that choice which points to the knowledge base article, but yeah… “Who needs a manual”, right? 
Unfortunately, we can’t always predict which Thread network a device will join if the user selects Connect via iOS/Android. That depends on several factors, such as whether a preferred Thread network exists, whether it’s currently available, and how the underlying platform prioritizes available credentials. Those decisions are largely handled by Apple’s and Google’s Thread credential management, which is mostly a black box from our perspective.
