Hi, I am starting to see many of my matter devices is offline/unavailable. Its both on the Nanoleaf and Ikea apps that it seems to go “offline” Do anyone have some idea where I should look to maybe see if its a HP23 issue with Matter devices since IKEA is the new addon to this.

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. :slight_smile: 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 :slight_smile:

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.

[image] Pascal_Nohl: They asked for precise logs If only somebody asked for a diagnostic report, haven’t seen anybody do that yet :thinking: 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.

[image] Doekse: If only somebody asked for a diagnostic report, haven’t seen anybody do that yet :thinking: 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.

[image] Doekse: It could have been occupied by another Thread device, Wi-Fi, another 2.4 GHz technology or some other source of RF interference. 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.

[image] Doekse: 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. 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“ :winking_face_with_tongue: Cheers

[image] 4x4_Pete: 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 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? :sweat_smile: 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.

Matter devices are unavailable

Questions & Help

Topic		Replies	Views
Continuing Matter ove Thread Issues Questions & Help	50	1314	May 7, 2026
Back for another try Off-Topic	24	805	February 28, 2026
Matter devices keep falling off network after months of stability Questions & Help homey-pro , matter	41	1087	September 20, 2026
[LIST] Does it Matter and Work over Thread Devices devices , homey-pro-2023 , matter , thread	86	5607	October 12, 2025
Big problems with Zigbee and Matter/Thread devices losing connection Questions & Help zigbee , matter , thread	21	1287	October 19, 2026

Matter devices are unavailable

Related topics