If by “Thread Leader” you specifically mean my Apple TV, which currently happens to be both Leader and a Thread Border Router, then I understand what you mean.
But Homey does not have to send the command through that Apple TV. Homey itself is also a Border Router on the same Thread network, so the traffic could enter the Thread mesh through Homey’s own TBR or through another Border Router.
And the Apple TV being Leader does not make it the central forwarding point. The Leader manages parts of the Thread network, but normal packet routing is distributed across the mesh.
So what would be really interesting is whether Homey’s diagnostics actually show that the failed command was sent over eth0 through the Apple TV TBR. If they do, that gives us something concrete to investigate. If not, the fact that the Apple TV is currently Leader does not tell us which route Homey used.
That’s not completely true. Even though both Thread Border Routers are part of the same Thread network, communication between them doesn’t necessarily go over Thread. Border Routers can communicate and coordinate over the IPv6 backbone network, for example via Ethernet or Wi-Fi. This is normal for Thread networks with multiple Border Routers.
Sure, Homey has a substantial app developer community. I’m part of it with 5 apps. But that’s not really the scale I was referring to.
Home Assistant had 21,000+ unique GitHub contributors in 2024. And even the Home Assistant Core repository alone has 5,000+ contributors.
That is probably the more relevant comparison: Homey’s core platform is developed by Athom’s own development team, while thousands of people have contributed directly to Home Assistant Core itself.
On top of that, HA currently has 1,500+ official integrations, plus thousands of community projects through HACS, add-ons, dashboard cards, themes, blueprints, ESPHome and so on. If Homey has integrations that do not exist in HA that would concern a very small number, as HA has nearly an integration for everything.
So 762 Homey app developers and 1,541 apps is certainly impressive. My point wasn’t that Homey has a small developer community — it was the sheer scale of the development ecosystem behind Home Assistant.
@Pascal_Nohl do you have a diagnostic report from just after you tried to send a command but didn’t get a timeout?
I quickly checked our code and also compared the behavior with matter.js. We’re handling this in exactly the same way, which is why I find the different behavior quite strange.
TL;DR: when sending a command results in a timeout, the Matter stack checks via mDNS whether the device’s address has changed. If it has, it retries the command using the new address and, if successful, updates the stored address.
But in your case, you never seem to get a timeout in the first place, which is the really strange part.
That does not happen every time. Unfortunately I have no report. The strange thing is that it happens, as my garden fountain that does not turn on and where I log the error path. It works most times, but from time to time it does not switch on (Eve Energy) without any report in my logs. Window contacts, trigger flows some times immediately, some times after 1-2 minutes, and sometimes absolutely not without error on the error path.
I never said otherwise. What I said is that Homey does not have to send commands via the Thread Leader.
Of course, in a multi-Border-Router Thread network, traffic can enter the Thread mesh through Homey’s own TBR or through another TBR over the IPv6 backbone, using Ethernet or Wi-Fi. And naturally the current Leader can also happen to be part of the actual Thread route.
Maybe I misunderstood what you meant, but even after reading your original message again, I still interpret it the same way:
To me, “sending the command via the Thread Leader” implies that the Apple TV is being used because it is the Leader.
If what you actually meant was that Homey may have sent the command over the backbone through that Apple TV because it is also a Thread Border Router, then we are saying the same thing.
The distinction is important, because the Leader role itself does not make that device the mandatory or preferred path for Matter traffic.
Since we saw Homey communicating with the Thread Border Router via its eth0 interface, I expect that’s what’s happening here as well.
To elaborate: Homey sends the Matter command to the device’s IPv6 address, and the underlying network determines how that traffic reaches the device. For a Thread device, that could be via another Thread Border Router over Ethernet or Wi-Fi, or directly through Homey’s own Thread interface.
From Homey’s perspective, we essentially interface with the CHIP stack and the Linux networking stack, which handle the actual routing to the device.
A diagnostic report from just after the issue occurs would help a lot. Please create one when it happens and share it with me so we can take a closer look.
As far as I understand, you don’t actually use Matter or Thread yourself, you have argued that cloud access is inherently safer than local Ethernet — something I strongly disagree with — and you tend to defend Homey regardless of the specific problem being discussed.
We all like Homey. Otherwise we probably wouldn’t spend this much time trying to understand the problem and help Athom solve it. But we also have to remain realistic: this is a system we use every day, and it needs to work reliably.
More importantly, these discussions with you repeatedly move away from the actual Matter/Thread problem we are trying to investigate.
So from now on, unless your post contains information that can actually help us diagnose this Matter/Thread issue, I simply won’t respond to it anymore.
If you have useful technical input regarding the problem, you are of course always welcome to contribute.
So the log clearly proves that the successful path was run, not the error path.
So the log proves that Homey considered the command to switch the fountain on successful. The error path was not executed.
The Flow is split because there are other ways to control the fountain, for example excessive wind speed or a physical button. But none of those conditions occurred, and those paths also write their own log entries.
So we can exclude a sequence such as:
fountain switched on → high wind detected → fountain switched off again
There is no corresponding log entry.
What happened is therefore quite specific: Homey executed the ON command, treated it as successful and continued the Flow, but the physical device remained off.
That is exactly the behaviour I am trying to understand.
Just to rule out the mechanical side of things: the smart plug is actually switching when you operate it manually via the quick action/normal button in the device tile?
Did Homey also add a ‘swiched on’ entry on the log tab in the device tile of the smart plug?
And here from today:
No log entry for flow O100 today. So the plug was not triggered by the flow, but the flow was run with success as “my” log proves.
This might also be a relevant element in the puzzle: the ‘turn on’ action was successful according to the outcome of the flow, but Homey did not record it in its own device log.
I thing you can do is, if you have a flow like this, that you think is failing. Add like turn on a light or other device, just to check if the flow did trigger a send command.
I run SHS, so my thread network is managed by my Apple TV and HomePod Minis. One thing I have noticed is that when I have the Matter over Thread device paired to Apple Home first and then share it to Homey, the device remains stable. If it does drop, it comes back quickly. However, if I pair the device to Homey first and then share it to Apple Home, the device drops from Homey and does not come back online, even though it is still active in Apple Home.
This morning my bedroom window contact did not report a state change at all, even after more than five minutes. This device is currently paired only with Homey.
I assumed it might have lost its Thread connection, so I removed the battery and inserted it again.
What surprised me was what happened next: almost immediately after reinserting the battery — it felt like a fraction of a second — the contact reported correctly and the corresponding actions were executed.
I had expected that, if this were simply a Thread network or routing problem, the device would first need some time to reattach to the Thread network and establish a usable route. Instead, after a complete power cycle it became responsive almost instantly.
Of course, it already had the Thread credentials and network information stored, so a rejoin can be very fast. Still, I find the contrast interesting: more than five minutes without reporting while apparently online, followed by an almost immediate response after rebooting the device.
@Doekse: I did not create a diagnostic report because Homey still showed the contact as present/available — it simply stopped reporting its state.
Would you like me to create a diagnostic report next time this happens, even if Homey shows no error, timeout or unavailable state at all?
Hi @Pascal_Nohl I had the same issues on my HP23. Devices could not upgrade. After I switched to HA my Thread devices upgraded instant.
I have switched all my battery away from IKEA batteries that is on 1.2V to XTAR 1.5v rechargeable batteries. That also helped some of my devices to work better and longer.
Next for you should just to run Homey Self hosted, and let that talk to your HA.
