yes aim agree with your point of view, i dont want to say that the apple devices do anything wrong or they are the reason and its better to remove it because like you wrote and i also wrote they do for what thread was built and more border router makes the system stable, i dont have planed to remove my apple devices because i see the problem not there, like in your system before homey come into my network the thread was running without this kind of problems…will see what is the next recommendation form Athom Hotline side…
Looking at the map of your Thread network, I do see quite a few dotted lines. How are the devices spread throughout the house?
I hear what you’re saying. But since the last update, I’m seeing some behaviour that makes me wonder whether this change has side effects elsewhere.
Some sensors now take a surprisingly long time to report a state change. Another thing I regularly see is that lights are shown as on in Homey while they are actually off, or vice versa.
When this happens, clicking the on/off button on the device tile repeatedly gives me a “Something went wrong…” error. At the same time, automations involving exactly the same light still work as expected. For example, pressing a physical button — which is not electrically connected to the light — still triggers the Homey automation and toggles the light correctly.
So the device itself is clearly still reachable and commands can still get through, while the state shown in Homey and direct interaction through the tile seem to be out of sync.
To me, that looks very much like some kind of timing or state-synchronisation issue. This is why I keep wondering whether increasing the subscription interval may have consequences beyond simply reducing how often a device has to check in.
My speculation was not about the reasons you mentioned for releasing Self-Hosted Server. I understand those, and they make perfect sense.
What I was speculating about is whether Athom may also be aware that the hardware in the current Homey Pro can become a limiting factor in larger or more complex smart home installations.
That is a different point. SHS removes that hardware limitation by allowing the same software stack to run on significantly more powerful hardware. Whether that was one of Athom’s motivations or simply a useful consequence of the architecture is, of course, something only Athom can answer.
My concern comes from the fact that, over time, several changes seem to focus on reducing load, traffic or resource usage. That naturally makes me wonder whether some of the problems we are seeing are not only software issues, but also related to the available hardware resources.
I had this recurring issue until recently when I changed the 2.4Ghz channel in my router from auto to channel 11. I initially tried ch6 but still got unavailable devices. Since changing to channel 11 the issue has gone away.
My topology is indeed full of dotted lines, both orange and blue. But what I find interesting is that almost all of these links are between routing devices, and those same routers also have several solid green connections to other routers.
Isn’t that, to some extent, normal behaviour in a Thread mesh?
My understanding is that Thread routers maintain information about multiple neighbouring routers and the quality of those links. Some links will naturally be better than others, and routing decisions can change as link quality, interference or the availability of other routers changes.
So I am wondering what the presence of many dotted lines actually tells us.
If a router has several weak or marginal neighbour relationships, but at the same time also has multiple strong green links providing good paths through the mesh, I would not necessarily consider the weak links themselves a problem.
In other words, shouldn’t the important question be whether there are enough good routing paths available, rather than simply how many dotted lines exist in the topology?
It would therefore be useful to understand exactly what a dotted line represents in the Thread tool. Is it merely a known neighbour relationship with lower link quality, or does it indicate that Thread is actually trying to use that link for routing and experiencing problems?
P.S.
Based on the documentation I found, there are actually three different types of dotted lines, and their meaning depends on the type of connection.
Between two routing devices, a dotted line appears to indicate an unconfirmed/asymmetric neighbour relationship: Router A may have a good view of Router B, while Router B does not confirm the relationship in the same way or sees Router A with much poorer link quality.
So a dotted line between two routers does not necessarily mean that routing is failing. What seems to matter much more, according to the documentation, is that each router has at least one — and preferably several — solid green links to other routing devices.
That is also why I am not sure that simply having many dotted lines is, by itself, an indication of a problematic Thread network. The overall connectivity and availability of good alternative paths would seem much more relevant.
Thread is just not workable for me on my homey pro 2023 anymore, espescially the past couple of days.
I invested a lot of money in homey hardware, i bought a second 2023 right before the 2026 came out but i give up on the platform. After hitting memory limitations (on such an expensive device) i started moving apps, zigbee and z-wave to HA, and after these issues i’ll move my thread devices too.
I loved working with homey because of the advanced workflows but stability of the platform is just not good enough compared to my HA.
With AI a lot of the complexity of HA has been taken away and i want stability, i’m tired of constantly rebooting an re-pairing devices on homey.
It’s been a fun ride but this thread flakyness is the final nail in the coffin for me. Such a pity as it was a very promising platform.
More than a month has passed since that fix was implemented (due to my support ticket) and Athom still has not bothered to reach out to me once to see if it actually fixed the issue.
Pretty much. I have a couple of routers in my new HA mesh which have a direct line of sight to each other and just three metres between them, but a dotted line on diagnostics. Yet, I have more stable connections with devices around eight metres away and brick walls between them
Some devices just have better radios and better firmware, so can maintain connection and route traffic more efficiently.
I find it quite ironic that Athom are happy to point the finger at these kinds of examples, when there is possible correlation, but no hard evidence of causality. However, when we point out the same with Athom hardware after many examples of correlation, things become defensive quite quickly.
Just an off topic side note: Use “C.A.F.E” on HA and you will not even miss the Homey advanced flows experience there…
My house have 164m2 square meter living space with 3 Floors, i have in every floor min. 3-4 Smart Plugs (Router) and min.1 Border Router (Ground Floor and 1 Floor have 2 Border Routers) One my Terrace / Garden i have 2 Smart Plugs (Router) and 1 Border Router as well. I guess the main devices are spread very well.
3 of my 13 Smart Plugs are only installed for the Router function they have no other task…
If you need i can make a floor plan which devices exactly where…
Yeah i was thinking of using it but in all honesty my claude bridge is running on my server and has direct access to HA and vice versa. It’s the most powerful tool i’ve ever used and the most complex automations and advanced dashboards are very doable now without any knowledge of yaml. It’s craay what is possible now 
That’s something I personally would never do. In my house, no AI gets direct access to my smart home. I’m certainly not a conspiracy theorist, but I do care a lot about security and privacy.
That said, AI can still be extremely useful even if you only use it as an assistant and ask it how to achieve something.
For my more complex automations, such as my roller shutters, AI eventually fell short and I built the flows myself from the ground up. Afterwards, however, I copied the finished flow and asked AI to analyse it. Interestingly, it found an edge case that would only occur very rarely, but in that particular situation one of the roller shutters would not have operated correctly. I changed that part of the flow accordingly.
And to be fair to HA: it still isn’t as user-friendly as Homey, but over the last year I have seen a significant development towards better usability. It has already reached a point where much less “geeky” knowledge is required than before.
It is not only moving further away from YAML with every update, but there are also changes in the underlying interaction model — for example, increasingly selecting actual devices and actions instead of having to think primarily in terms of entities, capabilities and technical implementation details.
Still, and I am aware of C.A.F.E., I think Homey remains the better system when it comes to the overall user interface and especially building automations.
That is also why I think SHS has a good chance of becoming a serious competitor to Home Assistant. But a lot will depend on how SHS develops from here: whether Athom adds proper support for external Thread/Zigbee radios, how broad the supported hardware ecosystem becomes, and — probably most importantly — whether the instability we are currently seeing turns out to be caused by limitations of the Homey Pro hardware or by deeper issues in the software stack itself.
But all these discussions will not really move us forward with the actual problems we are seeing.
In my case, AI simply tells me that limited hardware resources could be one possible explanation, but it also lists a number of other potential causes. So there is certainly no definitive conclusion there.
The one thing it consistently and repeatedly confirms, however, is that switching to another Leader in a Thread network is normal and intended Thread behaviour. Leader changes are part of the protocol, and a Thread device such as Homey should be able to handle such a change and continue operating correctly afterwards.
That does not prove what is causing Homey’s problems, but it does confirm the point I have been making: the fact that an Apple TV or another Thread Router becomes Leader is not, by itself, an explanation for the instability.
@Doekse I have had similar experiences from time to time.
My house is about 140 m² and I currently have 21 Thread routing devices. The most telling point is that I deliberately installed several smart plugs around Homey purely to provide good entry points into the Thread mesh and compensate for Homey’s relatively weak radio range: one at about 2 m, one at 3.5 m, one at 4 m and another at 6 m, all in the same 42 m² living room. In addition, I have at least one routing device in every room and on every floor.
One observation I find particularly strange happens when the Thread network is rebuilding. In my bedroom, for example, I have two routing plugs only about 2 m apart. Quite often, only one of them comes back online initially, while all the nearby end devices, including window contacts, are already available again. The second plug may remain unavailable for another 10 or even 15 minutes. It is not always the same plug either.
Under Apple Home, rebuilding the Thread network usually took around three minutes in my experience.
So what is actually different in the way Homey rebuilds or rejoins the Thread network? Why does Homey appear to be less stable in the same environment, even though my former Apple-only Thread network had far fewer routing devices and was stable?
If the Leader changes identified by @Rammstein are indeed related to the problem, then I think it would be important to investigate how Homey handles those Leader transitions and how quickly it restores its neighbour and routing relationships afterwards.
I hear what you’re saying. Just as background information, i’m a security officer so it’s my nature to ensure the necessary safeguards are build in.
I have put limitations on what AI can do without my intervention, so pretty much they can’t change anything without my approval. Even their read access is extremely limited.
But what i’ve built with it are extremely complex automations that are very hard to achieve with Homey. Another main difference is the scope of integrations and most of all the dashboarding. I have tailormade dashboarding that are really helping me a lot, things that i wouldn’t be able to achieve with Homey. I also have quite a big house and pretty much everything is smart connected so my scope outgrew homey aswell (the memory issues). Just on zigbee i’m sitting on 70 devices, z-wave 20 and thread around 40 and then a lot of wifi and bluetooth aswell.
I understand.
But this is exactly why my personal approach is: no external access at all unless it is really necessary.
We have already seen how AI systems and security researchers find ways around safeguards that were specifically designed to prevent certain behaviour. Every additional interface, account, cloud service or external connection creates another potential attack surface.
You can never guarantee that a system will not contain an unknown vulnerability tomorrow.
So for my smart home, the safest cloud connection is still the one that does not exist. 
@Doekse
I finally decided to fire up my Mini PC with a fresh installation of Home Assistant.
I first joined HA to my existing Thread network, then connected the ZBT-2 antenna and flashed it with the Thread firmware.
For a first test, I removed two devices from Homey that were not used in any important Flows, factory-reset them and commissioned them with Home Assistant. I then shared both devices with Homey using Matter Multi-Admin.
After some initial setup problems, everything is now online with only two active Thread Border Routers: Homey and Home Assistant. All Apple Thread Border Routers are currently powered off.
The Thread network itself appears to work perfectly. Both test devices are quite far away from the Homey and HA antennas, with several walls and even a ceiling in between, so communication clearly relies on the Thread mesh and its routers.
But I immediately noticed something interesting:
When the window contact changes state, Home Assistant shows the new state almost instantly, while Homey sometimes needs one or even two minutes to update.
Just to clarify this for people less familiar with Matter and Thread:
The fact that the device was originally commissioned with Home Assistant and later shared with Homey through Multi-Admin does not mean that communication follows this path:
Device → Home Assistant → Homey
Both controllers have their own direct Matter relationship with the device. They are separate Matter fabrics using the same Thread network. Homey does not depend on Home Assistant to receive the device state.
So when HA receives the state change immediately while Homey takes one or two minutes, the delay is clearly somewhere in Homey’s side of the communication or processing.
That could mean Homey’s Matter subscription/report handling is delayed, that a report is missed and Homey only updates after a later report or read, or that the information is received but processed internally with a delay. I cannot tell which of these is happening without proper diagnostics.
But this test makes one thing considerably easier to isolate: the Thread mesh itself is able to deliver the state change quickly. One Matter controller reacts immediately, while the other does not.
And that is exactly the kind of comparison I was hoping to achieve.
Edit
I was finally able to update the firmware of the Ikea window contact with HA that never worked with Homey.
I finally decided to put all my IKEA window contacts through the same procedure, and I was able to update every single one of them.
Then I moved on to the IKEA BILRESA devices, with the same result: all of them updated successfully.
Homey had shown an available update for only one of my HEIMAN smoke detectors, although all of them were running the same old firmware version 1.7. So I decided to transfer those to Home Assistant as well. Once paired with HA, the update was immediately available for every detector, and I was able to update all of them to firmware 4.4.
If we want to talk about facts, these are the facts from my installation:
With Homey, I had tried updating these devices dozens of times. I tried without touching them, placing them close to Homey, deliberately keeping battery-powered devices awake, and repeating the process over and over again. None of this helped.
With Home Assistant, I had exactly one aborted update. It succeeded on the second attempt. Every other device updated successfully on the first try.
And perhaps the most interesting part: all of the HEIMAN smoke detectors received the firmware update through HA, including those for which Homey did not even indicate that an update was available.
So whatever the underlying reason may be, in my environment the difference in OTA update reliability between Homey and Home Assistant is not subtle. It is very difficult to explain this purely by device placement, radio conditions or problematic firmware when the same physical devices update almost immediately after being moved to another controller.
Couldn’t you use http://tools.developer.homey.app to see when the messages are coming in? Some times I notice a considerable update delay on my iPad in the Homey App with devices using other transmission technologies.
PS: I don’t have Thread devices, so I cannot verify this.
This is the Thread network as seen by Home Assistant:
And this is the same network with the medium and weak links filtered out:
For me, the second picture is the important one.
Even after removing all medium and weak links, there is no node without at least one good connection to the mesh. The orange nodes are simply Thread routers that participate in the network but are not known to Home Assistant as Matter devices, so HA cannot identify them by name.
Home Assistant also provides detailed information for each known device. By clicking on a device, you can see information such as its current link quality:
At first glance this may seem slightly off topic, but I don’t think it is.
One of the recurring questions in this discussion has been whether the Thread network itself is healthy enough, whether devices have poor links, whether routing is adequate, or whether RF conditions may explain the instability.
This is exactly the kind of information you need to answer those questions.
It gives me two useful things at the same time:
- evidence that the Thread mesh itself has good redundant connectivity, even when weaker links are ignored; and
- diagnostic visibility into individual devices and their links.
And this also illustrates one of the things I believe is currently missing from Homey. If Thread stability is repeatedly suggested as a possible cause of Matter problems, users and support need tools that actually allow them to inspect the Thread topology, link quality and routing behaviour.
Without that visibility, troubleshooting very quickly becomes speculation.
Doesn’t this app do the same thing then?
They look exactly the same to me. But I have no experience with Thread though
