If that is the case Athom will never admit, but come up with a new hardware release.
By the way, for a reliable system, better configuration management is required, like rolling back & forward, and devices which can remotely be reset. Mean while I consider home automation a nice hobby but not something I want to depend on.
Just wait for your doomsday. There are enough users experiencing unexpected behavior.
So far I have been lucky. Just IQ insights stopping for the 3 time this year. I don’t even bother to signal the problem anymore. Just to much trouble.
That’s because you moved most of your devices to separate hubs 
@staeff …short question, you wrote you run approx. the same setup, do you have other Border Router from different brands in your system for example like in my system i have 3x HomePods 1XApple TV and the Aqara G5 Hub as well…all End Devices (13) and Routers (13 Smart Plugs) are teached directly to Homey, the other Border Routers are only part of the Thread Network because i cant deactivate them…
Yes, I did move many devices to the manufacturer’s bridge, but even before I moved most of my devices, they also worked correctly direct on Homey. The reason I moved to the bridges is because of OTA and because I wanted to move devices to the cloud to create more internet traffic. Not because they weren’t working on Homey or anything.
If I remember correctly that is because you think internet is more reliable as your local network(s).
Yes correct. More secure than LAN connections since a LAN connection is often unencrypted. That’s the reason for using cloud instead of LAN. But the reason for moving devices from Homey Zigbee to the vendor’s hub is OTAs, those can’t be run from Homey directly.
That is exactly what I said.
I would never rely on Homey, or any other smart-home controller, as the only safety mechanism. Power can fail, the network can fail, hardware can fail, and any automation system can fail.
But if I add an automation as an additional safety measure, I still expect it to work reliably under normal operating conditions.
Opening all roller shutters when a smoke alarm is triggered would not replace proper escape routes, smoke detectors or any other safety measures. It would simply be an additional action that may help.
And in that context, a three-minute delay caused by a contact or another device not reporting its state is still unacceptable. There is a big difference between accepting that a system can fail under exceptional circumstances and accepting that it sometimes takes several minutes to process a simple state change while everything else is up and running.
I do not think that conclusion follows.
First, how much confidentiality does a TRV or a light bulb actually require? What matters much more in this context is authentication, integrity and availability: only authorised controllers should be able to operate the device, commands must not be modified, and the device should remain reachable when it is needed.
And “LAN” does not automatically mean “unencrypted”. Matter, for example, encrypts and authenticates its communication regardless of whether the IP transport underneath is Ethernet, Wi-Fi or Thread.
More importantly, moving communication through a cloud service introduces an additional attack surface and an additional dependency.
With a purely local system, an attacker normally first has to gain access to the local network or one of its devices. With a cloud-dependent system there are additional possibilities: compromised accounts, stolen credentials, vulnerabilities at the cloud provider, compromised backend infrastructure, DNS or Internet routing problems, provider outages, or simply loss of the Internet connection.
And availability is part of security too.
If an automation depends on a cloud service, disrupting the Internet connection may be enough to prevent commands, notifications or alarms from reaching their destination, even though every device inside the house is still working perfectly.
That is particularly important for anything remotely safety-related. I would much rather have a local automation continue to work while the Internet is down than have a beautifully encrypted connection to a server I can no longer reach.
So for me the comparison is not:
encrypted cloud = secure
unencrypted LAN = insecure
It is about the complete architecture: encryption, authentication, attack surface, dependencies and availability.
For a bulb or TRV, a properly secured local connection is usually both sufficiently secure and considerably less dependent on infrastructure outside my control.
I’m not saying every LAN connection is unencrypted, I said that LAN connections are often unencrypted.
That’s why I have LAN connections blocked for most IoT devices. If a device ever gets compromised (and I know some of my devices are old and use a poorly secured update server, so it’s possible), then it stays at that device. The threat can’t spread to other devices through the network since all it can reach is the internet.
That’s probably a smart home architecture decision then. In my case, Homey is the controller that brings together all the devices from different ecosystems/backends. The cloud is its infrastructure layer where it can reach individual devices and the bridges, which bridge a communication protocol to the server after which Homey can control the devices through it as well.
This means that whenever Homey is unavailable, or the manufacturer made a change and the Homey app for the reverse engineered API is not working anymore, I can still control all devices from the manufacturer’s mobile app. Homey runs all Flows and connects devices with eachother, but I can still use the manufacturer’s mobile app to control everything manually if anything goes wrong.
I completely agree that this is ultimately an architectural design decision.
What I do not agree with is presenting cloud communication as being generally more secure than local LAN or Wi-Fi communication, especially on a forum that is also read by many non-technical users.
There are several reasons why I personally prefer a local-first architecture:
- Platforms such as Home Assistant, Hubitat, Homey and others put considerable emphasis on local processing. Reducing cloud dependencies is not an exotic idea; it is a general trend in serious smart-home systems.
- Matter is encrypted and authenticated while remaining completely IP-based and capable of operating locally. If a device and controller are in the same home, I see little advantage in sending a state change across the Internet to a remote server only to have the resulting command travel all the way back again.
- In professional network environments, the usual strategy is to minimise unnecessary external dependencies, segment systems properly and keep operational services local whenever possible. Cloud access may certainly be used where it provides a benefit, but it is normally something that is deliberately designed into the architecture rather than assumed to be inherently safer.
- Apple’s smart-home architecture also relies heavily on local communication and local automation through the home hub, even though cloud services are obviously still used for things such as synchronisation and remote access.
- Matter itself is another strong indication of where the industry is heading: Google, Apple, Amazon and many others jointly support a standard that deliberately allows devices from different manufacturers to communicate locally.
Cloud services can absolutely have advantages. They may provide convenient remote access, manufacturer-specific features, redundancy at another level, and sometimes easier recovery.
But they also introduce additional dependencies and attack surfaces: the Internet connection, DNS, the manufacturer’s servers, account security, authentication infrastructure and the continued existence of the service itself.
So this is your architectural choice, and that is perfectly legitimate. I simply cannot subscribe to the statement that it is generally the more secure approach. For my own system, I consider a well-designed and properly segmented local network the lower-risk architecture.
Regarding this part:
I can still control all devices from the manufacturer’s mobile app.
That advantage is not necessarily exclusive to cloud-based devices either.
With standards such as Matter and Multi-Admin, a device can be commissioned to more than one controller ecosystem. A Matter device can therefore remain accessible through another controller even if Homey disappears completely, provided it has been added to that fabric as well.
And that is actually one of the main reasons why I gradually changed my own strategy.
I used to integrate whatever device I liked and then depend on manufacturer APIs, Homey apps and sometimes reverse-engineered interfaces. Today I try to buy Matter devices wherever possible.
The reason is independence.
I can already achieve perhaps 98% of what I want with Matter, and the available device range is growing every month. If one controller turns out not to meet my requirements anymore, the devices themselves are not tied to it. They can be moved or shared with Apple Home, Home Assistant, Gladys or another Matter controller.
That is, for me, one of Matter’s greatest advantages: the smart home should not depend on the continued availability of one manufacturer, one cloud service or even one controller.
At the moment, the weakest point in that strategy may unfortunately be Homey itself. But if that eventually proves to be the case, I can replace the controller without replacing the complete house full of devices.
Just don’t interact with him.. he tries to push his cloud fallacy on every community topic that barely touches something about local control, and it just makes things go off-topic…
Ah actually I missed the part about your additional border routers, I currently don’t have them (but an Apple TV is in my future once they finally release a new version). In theory additional border routers should improve your mesh, but I can see that maybe on trying to take over as the primary if there is some hickup with your Homey could cause problems.
In that case you should not buy WiFi or LAN devices.
Yep
He’s actually the worst culprit for taking things off topic here, but he’s aggressively pro Athom, so never gets pulled up on it
Thx for the feedback…currently i search with the support team in this direction…we had out of my reports some hints the crash will be caused from topology/partition change (e.g., a leader/partition switch or router count drop)…, at the moment only presumptions!
Regarding the “Additional Border Router”, well basically more Border Router in a System should make it more stable, thats the basic reason why i keep my HomePods a live…but in my situation it seems to be exactly the opposite at the moment..for example if one of the Boarder Router lost the power connection because someone plug off the device…
Question?
You guys that having problems with thread/matter devices. Are you having them paired as matter directly to homey, or are you using the makers app for ex: ikea?
At the beginning shared with multi-admin, but it get mutch more stable when you teach the devices directly on Homey!
I don’t agree. I think this is the conclusion Athom is trying to draw, but I don’t think the facts support it.
As soon as @Doekse saw that the Thread Leader in my network was an Apple TV, his reaction was essentially, “Now the duck is coming off the shelves” — in other words: now we have found the reason. I think that is a rather defensive and, technically, questionable position.
My pure Apple Thread network had been completely stable for more than a year, and there are plenty of Home Assistant users running Thread networks with Apple TVs and HomePods as Border Routers without such problems.
Apple TVs and HomePods are simply doing what Thread is designed to do: the eligible Thread routers elect a Leader among themselves. That decision is based on several factors. If Homey is not elected Leader, that does not mean something is wrong with the network — it simply means another router was considered the better candidate at that moment.
And this needs to be clearly separated from Matter. Homey remains the Matter Controller for the Matter devices commissioned through Homey. That is the Matter layer. Being or not being the Thread Leader is a completely different matter.
If Homey has difficulties recovering or getting back in sync when the Thread Leader changes, then I consider that a Homey problem. It would point to how Homey handles changes in the Thread topology internally, not to the mere presence of an Apple TV or HomePod.
I also still wonder whether Homey’s approach of reducing traffic on the Thread network is related to another problem I am seeing: some of my window contacts occasionally take several minutes to report a state change. Reducing network traffic may help with “device unavailable” issues, but it could potentially introduce timing or latency problems elsewhere.
That is exactly what I asked before: what happens to the other Thread communication when this traffic is being reduced or suppressed? I never received an answer to that question.
All in all, I genuinely respect the amount of effort Athom and @Doekse are putting into solving these problems. But over time I am increasingly getting the impression that many of these software changes and workarounds are compensating for hardware that may simply no longer be fully up to the requirements of a modern, increasingly complex smart home.
P.S: SHS may actually be an indication that Athom intends to separate hardware and software more clearly in the future. The current version still feels more like a beta, but if Athom adds direct support for Thread and Zigbee radios/adapters that are already available on the market, SHS could eventually become something like Home Assistant on steroids — combining Homey’s usability and ecosystem with much more flexible hardware.
The big question is whether Athom can make the software stack stable and hardware-independent enough to run reliably across different platforms and with a selection of officially supported Thread and Zigbee radios.
If they manage that, it could also solve one of Homey Pro’s fundamental limitations: you would no longer be tied to whatever radio hardware happens to be built into a particular Homey generation.
As already mentioned a couple of times, the only thing we’ve changed is the subscription interval, meaning how often a device needs to check in with Homey.
When pairing, the device and Homey essentially agree on an interval at which they’ll check in with each other to make sure the connection is still active and the device is still reachable. We’ve now made that interval adjustable.
We haven’t changed any of the actual messaging or communication beyond that.
And there’s really no need to speculate here. We’ve been pretty open about why we released Self-Hosted Server: a lot of users like our software, so why limit it to our own hardware if the architecture allows it to run perfectly well on other hardware too? Next to that it opens up the door to a lot of B2B oppertunities as well.
