It often feels as if Homey requires users to adapt their home environment to make Homey work reliably, even if those changes may affect other systems that are already running without issues.
Other solutions seem to coexist more easily with existing networks and radio environments. With Homey, the impression is often that everything around it has to be adjusted first: Wi-Fi settings, Thread placement, possible interference sources, device placement, routing behaviour, and so on.
To me, that is another indication that the radio side of the system is too sensitive. If a system only becomes stable when almost every possible source of interference is removed or adjusted, then the problem is not only the environment. The system itself may simply have too little margin for real-world conditions.
And that is an important distinction. People like us are not randomly bashing Homey. We have experience with Homey, we have written apps for it, and we have used other systems as well. We are comparing behaviour based on real usage, not on brand loyalty.
This is not about being a fan of another platform or about discrediting Homey. It is also not about pretending that Homey is perfect. The truth is somewhere in the actual behaviour users experience: if Matter and Thread only work reliably under very specific conditions, then that should be discussed honestly.
@Pascal_Nohl, also in regard to your previous message: unfortunately, at this stage we can’t really identify a specific issue. If we could, we’d of course be more than happy to look into it and work towards a solution.
As for the issue @deejayreissue is facing, we received a diagnostic report and identified two things:
Based on those findings, we’re implementing the following changes:
So we are very much willing to help out here! Don’t get me/us wrong.
Since I can’t see your history with Support, I would suggest creating a diagnostic report and sharing it with my colleagues there. They’ll be able to take a detailed look at what exactly is going wrong, what the most likely culprit is, and whether it’s something we can address with changes on our side.
The same applies here. We didn’t allow this when we first launched our Matter implementation, but we listened to user feedback, and it has been possible to connect non-certified Matter devices for quite some time now.
We do listen
It’s certainly true that a large part of Homey’s user base probably couldn’t tell Zigbee from Z-Wave or Matter over Thread. Those are also users who buy Homey specifically because it’s an all-in-one solution that doesn’t require external dongles, antennas, or additional hardware.
For more advanced users, we have Homey Self-Hosted Server, which people can install on their own hardware and combine with external Zigbee coordinators through Zigbee2MQTT, for example.
(Although Homey Pro (2026) has been working fine for the power user that I am)
And yes, if you’re a real die-hard power user, it could very well be that Home Assistant is the better platform for you. And that’s completely fine. In the end, what matters is that you’re using a platform you’re happy with in your own home.
We’re able to offer that to almost a million users, but we also understand that there will always be users who are looking for something different or who have requirements that another platform is better suited to.
Since I can’t really add much more to this conversation without more information about the specific situation, I’ll check out for now. But if more data becomes available, such as a diagnostic report, please don’t hesitate to reach out. I’m always happy to help.
My ticket was closed without any resolution to the memory leak issue
Also, why did support close my ticket if the above fixes haven’t even been implemented yet
Do Athom even want to find out if it fixes the issues? Do they care?
I actually didn’t notice your comment about the memory leak issue until today and I’m also incredibly disappointed that support failed to raise this with me or work through a solution.
In fact, I think they said it was the Homey core doing the memory dump, so there is a clear misalignment with what you are saying and what support was saying at the time.
Can you please clarify?
I will now need to start a new support ticket to get to the bottom of this issue.
In this case I’m referring to the issue you were facing with Matter, the one talked about in the other thread I referred to. This thread is about Matter devices being unavailable.
I’m not sure which memory leak issues you are now referring to? There’s no mention of a memory leak in the other thread.
As mentioned, I am currently on holiday so it could be that I missed some bits.
15 Thread messages per second sounds like a lot at first glance. A good mini-PC running Home Assistant with a dedicated Thread radio would probably not care much from a CPU point of view, but the Thread radio network itself is still a low-power mesh network. At some point, the available airtime and reliability become the limiting factors.
But I do not think it is normal for a regular Matter device to generate that amount of traffic by itself. Even an Eve Energy plug with power measurement should not constantly flood the network. In normal use, measurement reports should be sent when there is a meaningful change, or after a defined reporting interval.
So the more important question is: what kind of communication was actually measured?
Were those real application-level reports from the device?
Were they Thread routing messages?
Were they retries because acknowledgements were not received?
Was the device repeatedly trying to establish or repair routes?
Could the multiprotocol design be missing too many packets, causing retries and additional traffic?
In other words: the high message rate may not necessarily be the original cause of the problem. It could also be a symptom of an underlying reception, acknowledgement or routing issue.
Without blaming anyone, it is also possible that Homey itself, or Homey’s Thread implementation, contributes to this traffic. For example, if acknowledgements are missed, devices may retry. If routing tables are unstable, routers may repeatedly try to discover or rebuild routes. So before concluding that the device is simply “too chatty”, it would be useful to know exactly what kind of messages are being counted.
That also leads to another question: how would a user setting for update frequency actually solve the problem?
If the setting is not applied directly to the Matter device or to the subscription/reporting configuration, what happens to the messages? Are they dropped? Are they filtered inside Homey? Are they queued and delivered later? Could this introduce delays of several minutes, or hide the real issue instead of fixing it?
From the outside, this looks less like a real fix and more like damage control. It may reduce the visible impact, but it does not necessarily explain why the traffic is so high in the first place.
I think it isn’t related to CPU at all. At least with Zigbee, the amount of messages it can handle are limited by the radio, not by the CPU. Even a cheap SoC might be able to handle many messages with a powerful Zigbee radio. Since Thread is quite similar, I think the same applies there. But it also depends a lot on interference, because missed packets need to be resent when there’s more interference, which causes even more messages to be sent.
I have up with Matter over Thread devices and SHS a while ago. I created a ticket and support told me they couldn’t help and to ask the forum. That was less than helpful tbh and I still see people on here having issues
I have SmartThings as my TBR. Its extended and has onvis plugs to make a good strong mesh.
Ive previously tried apple HomePod too and had no luck with that either.
Ive now resorted to bridging them over Home Assistant but id rather it was all in one place.
That can actually cause issues as well, especially when they’re set to the same channel. I had an issue with my Hue bridge a few months ago: lights would sometimes not respond, Dimmer Switches needed to be pressed multiple times to turn the lights on, and my entire Hue system was unstable. It turned out that my ThirdReality Hub was set to the same Zigbee channel, which caused a lot of interference with the Hue bridge. After changing the Zigbee channel on the Hue bridge, all the issues disappeared. I didn’t notice any issues with ThirdReality though, so you can’t rule out interference if another system is working correctly. It was also quite strange, since ThirdReality has only 1 device added while the Hue bridge has 23 devices.
Interference can also be caused by other systems. WiFi, Bluetooth, Zigbee and Thread all share the same frequency. Many other (non-smart) devices also use 2.4Ghz for RF communications (like some wireless keyboards/mice for PC). So it also depends a lot on environmental factors. For example, in my street there are around 70 WiFi networks total across all frequencies, 10 Zigbee networks and ~150 Bluetooth devices. This means that 2.4Ghz is so crowded that messages often have to get re-transmitted, which causes even more messages to be sent, which also causes even more interference. I improved my WiFi interference by setting my main network to only 5 Ghz and disabled 2.4Ghz (since my phone, tablet and laptop all support 5Ghz), and then setting that to a DFS channel to prevent interference. This means that there is less traffic on 2.4 as well (only IoT traffic).
The devices would either not add at all. Eg Tado Raad valves. I could only ever get 2 of the 6 i have to join. Full resets tried everything. Always the same 2.
After a day or so they would drop offline
Nuki smartlock. Impossible to have stable. Can take anywhere between first try and several tries over days to add. Then just drops off.
Not one thread device stays stable on the SHS. They worked rock solid on the HP23 when i had that.
I have one Thread network, they have added to that and work on that perfectly but Homey just wont connect to them or work with them for long periods.
Ive had lots of advice regarding ipv6 / smart connect / 5ghz etc and nothing made the devices work.
I was not talking about Apple Home or Home Assistant running in parallel with Homey on the same Matter/Thread devices.
I was talking about those systems as alternatives to Homey. In the same physical environment, with the same house, the same walls, the same Wi-Fi environment and the same potential sources of interference, systems like Apple Home or Home Assistant can run reliably without requiring the user to change half of the setup around them.
In my case, Apple Home does not have a single Matter device connected to it anymore. Before joining the devices to Homey, all devices were factory reset to make sure they did not keep keys or commissioning data from both systems. I also removed all Matter-related objects from the keychain on my iPhone.
So this is not about devices being shared between Apple Home and Homey, or about multiple controllers fighting over the same Matter devices.
My point is different: when another system works reliably in the same physical environment, but Homey requires many environmental changes to become stable, then it is fair to question whether the issue is really only the environment — or whether Homey’s Matter/Thread implementation is simply more sensitive.
I do not have any insight into Homey’s core systems, so this is obviously only a guess.
But from the outside, this looks less like a Nuki-specific problem and more like an issue somewhere in Homey’s Matter/Thread stack, especially if devices are hard to commission, unstable after pairing, or disappear again after initially working.
It may be the same underlying area that causes issues with other Matter-over-Thread devices on Homey Pro as well: commissioning, Thread routing, border router behaviour, subscriptions, or how Homey handles the Thread network state over time.
The important point is that this should not simply be dismissed as “the device is bad” or “the user’s environment is wrong”. If the same type of devices can run more reliably on other Matter/Thread controllers in the same home, then it is fair to question whether Homey’s implementation is more sensitive or less tolerant to real-world Thread conditions.
Its only ever given me issues on SHS it was solid on HP23 and has never disconnected from my TBR or when it was in Apple Home with a homepod.
Thats the same with all my thread devices. Only SHS has failed.
To best of my knowledge, Homey will pick the best thread network to use. I only have one Thread network so Homey has no choice to use it. However there seems to be nowhere to look if its connected or working. Pairing thread matter devices for me into Homey has been like sticking my finger in the air to guess the wind speed. I was frustrated having to use HA to bridge them over but now ive got even more, ive got node red and all sorts of buttons so ive got a really decent set up.
Would be nice to have Homey work as intended though
Bought the ZBT-2 for HA for Thread and I’ll be using the Sonoff Dongle M for Zigbee, eventually.
I moved over 20 Matter over Thread devices from Homey to HA and bridged them back into Homey with the HA app.
I was astounded how quickly the devices paired with HA. Not a single failure and all devices added within 30 seconds.
Contrast that with Homey. Sometimes it can take up to five attempts to get a battery powered device to pair and it can take sometimes up to a minute to get past the “Checking Thread connectivity stage”
I will be moving over the remaining devices tonight and will share some medium term results once the Mesh has stabilised and a few days of testing.
To keep this thread on topic and make the previously shared information easier to find, it might be best to create a separate thread where you can share more about your new setup and findings.
Well I’m still continuing to use Homey for automations, so this is very much still on topic, as it’s Matter related and I still use Homey
What could be more on topic that that, but I understand that the more I comment, the more prominent this thread becomes for SEO, which Athom would love to avoid, I’m sure.
A full 24 hours since I moved all Thread devices over from Homey to HA.
Not a single flow failure so far and devices are much more responsive.
Perhaps the ZBT-2 is more efficient at handling ‘very chatty’ thread networks. Who knows?
I don’t see experiences with using Home Assistant in combination with the ZBT-2 to be on topic with Homey. So for that I’ll ask you to create a thread in the offtopic section of this Homey Community Forum.
For any Matter related issues in regards to Homey feel free to keep using this thread.
When a user operates Home Assistant and Homey in the same house, on the same network and under essentially identical conditions, and one system works reliably while the other does not, that comparison is directly relevant to identifying the cause of the problem.
It may be an uncomfortable result for Homey, but that does not make it off-topic. On the contrary, it provides an important reference point: it shows that the devices, network and local radio environment are not necessarily the underlying problem.
Moving such comparisons to the off-topic section would only remove relevant evidence from the discussion because the conclusion is inconvenient.
