[quote=“robertklep, post:119, topic:159392”]
Many people are perfectly willing to accept this price because it helps to fund the development of Home Assistant, which is a free product.
[/quote]
“Please don’t generalize”? That’s exactly what you did with “Many people” and “We”.
Either way, there is a massive difference between needing to pay and wanting to pay.
Please don’t generalize.
I already explained the “we”, and I know for a fact that many people want to sponsor Nabu Casa.
Indeed. For Homey you need to pay, for Home Assistant you only pay if you want 
Did you not read my post?
Please stay on topic.
You do not need to pay for Home Assistant.
Remote access can be configured without Nabu Casa, and even a beginner can find plenty of step-by-step guides for that. The same applies to backups: storing them on Google Drive, OneDrive or a NAS is perfectly possible without a Home Assistant Cloud subscription.
So yes, there is a difference between needing to pay and wanting to pay — and that is exactly my point.
I choose to pay Nabu Casa because I want to support development and because the cloud services are convenient. It is not a requirement to use Home Assistant.
Now please let’s return to the actual topic: comparing the features, strengths and weaknesses of Homey and Home Assistant.
I don’t pay. Speak for yourself next time
If you want cloud backup on Homey, you have to pay for it.
With Home Assistant, you can also pay nothing if you don’t want the optional cloud service.
What is so difficult to understand about that?
And this is exactly why I asked in the opening post that people only comment if they actually know both systems.
Please stop derailing this thread.
The purpose here is to compare concrete features and design choices of Homey and Home Assistant, including ideas that Athom itself could potentially benefit from.
The rules were clear from the beginning:
no fanboy posts
no vague opinions presented as facts
no repeated off-topic arguments
and no strong claims from people who do not really know both systems
If you continue trolling and ignoring those rules, I will ask a moderator to step in.
Free Homey’s!?
Well, I expect all WiFi or Ethernet-connected smart home devices to have at least some basic functionality for free. One of those is secure, cloud-based remote access. But it appears that the “Green” device doesn’t include remote access for free, so isn’t that strange? Every other smart home device has it for free, even my €2 Tuya bulbs! And even some open source projects offer free remote access services, like openHAB which offers a free cloud service with remote access and voice assistant integrations
Read those walls of text yourself
Back to the actual topic.
This whole cloud discussion reminded me of another area where Homey and Home Assistant differ considerably: backups and recovery.
A Homey Cloud Backup is not the same as the full local backup you can create over USB.
The paid Homey Cloud Backup saves devices, Flows, Insights, variables, settings, Zigbee/Z-Wave networks and other configuration data. But it is not a complete system-image backup including the system software.
A true full Homey backup is possible locally, but creating one requires connecting Homey to a computer by USB, entering Recovery Mode and manually creating the backup.
Home Assistant takes a different approach.
Its backups can restore the complete HA configuration, apps/add-ons and their data, making them suitable for restoring the system after something goes wrong or even migrating to different hardware.
There are also major differences in backup management.
Homey Cloud Backup:
paid service
automatic nightly backup
last 7 backups retained
no choice of the automatic backup time
local full backups are possible, but require USB and Recovery Mode
Home Assistant:
automatic backups can be configured directly in the GUI
you can choose the days and exact backup time
you decide how many backups to retain
multiple destinations can be used
a NAS can be used as a backup target without a subscription
Google Drive and OneDrive can also be used as backup destinations
Home Assistant Cloud provides 5 GB for the latest encrypted off-site backup
And if the standard scheduling options aren’t enough, HA can even trigger backups through automations — for example immediately before an update.
For me, the biggest advantage is not simply “more backup space”. It is the control over the backup strategy.
Let us define exactly when automatic backups are created.
Allow automatic backups to a local NAS or external cloud storage.
Make cloud backups true full-system backups.
Give users control over backup retention instead of a fixed seven generations.
Ideally allow automatic local full backups without having to connect Homey by USB and enter Recovery Mode.
For something as central as a smart-home controller, I think backup and disaster recovery should be treated as a core system feature rather than just a convenience service.
Let’s give one point to Homey for remote access.
Not because it is free, but because it is simple and built in.
With Homey, remote access is simply there. There is nothing to configure and no additional service to install.
To be fair, Home Assistant can also be accessed remotely without paying for Home Assistant Cloud. But if you want to do it yourself, you normally need some additional setup.
The traditional approach is to configure a VPN or another secure remote-access solution. That requires some networking knowledge, although there are plenty of step-by-step guides available.
Today, however, this has become much easier.
There are several free solutions available, and one I find particularly simple is Tailscale.
It creates an end-to-end encrypted connection without requiring complicated firewall rules, port forwarding or VPN configuration.
There is a good example here:
So I wouldn’t call free remote access with Home Assistant difficult anymore. But it still requires installing and configuring an additional component.
Homey doesn’t.
Therefore, for simplicity and out-of-the-box remote access, Homey clearly gets the point.
Home Assistant Cloud already provides exactly that convenience, but as a paid service. A basic built-in free option would make HA more approachable for users who don’t want to deal with networking at all.
We previously discussed two things here:
whether Home Assistant updates can affect existing automations (@robertklep never experienced that)
and how powerful Trigger IDs are
Interestingly, the new 2026.10 update touches both topics.
One of my previous complaints was that Trigger IDs were unnecessarily hidden. You had to create a trigger, open the three-dot menu, assign an ID, remember that ID, and then use it later in a Triggered by condition.
With 2026.10, this has become much easier.
You simply add a Triggered by condition and select the relevant trigger directly from a list using a checkbox. Home Assistant manages the necessary IDs internally.
That’s definitely an improvement.
But there are a few interesting side effects.
Existing automations with manually assigned Trigger IDs continue to work.
However, manually assigning or changing those IDs is no longer part of the normal visual editor. If you want to manage custom IDs yourself, you now have to do it in YAML.
This matters because Trigger IDs don’t have to be unique.
Previously, I could deliberately give several triggers the same ID and then have one Triggered by condition react to that complete group.
That functionality still exists and is officially supported, but the new visual workflow is clearly designed around selecting individual triggers instead.
So nothing necessarily breaks, but some of the more advanced flexibility has moved further into YAML.
Imagine I have three different triggers of the same type:
attribute changed on Entity A
attribute changed on Entity B
attribute changed on Entity C
When I add a Triggered by condition, the list may basically look like:
(1) an attribute changed
(2) an attribute changed
(3) an attribute changed
Very helpful. 
Of course there is a solution: rename the triggers so they have meaningful names.
And where do you rename them?
In the three-dot menu.
The same menu from which Trigger IDs have just been removed because they were considered too hidden.
So I have mixed feelings about this change.
For new users, the new approach is clearly easier. You no longer need to understand Trigger IDs at all just to create logic based on which trigger fired.
For advanced users, however, some control has moved from the visual editor into YAML, and meaningful trigger names become even more important.
Does Homey get a point for this?
I’m not sure.
Home Assistant documents the change, existing custom Trigger IDs continue to work, and even using the same ID for multiple triggers remains supported in YAML.
So this is not really an example of an update simply breaking automations.
But it does show one characteristic of Home Assistant quite well:
The system is evolving very quickly, and sometimes making one feature easier also changes workflows that experienced users had already built around the old behaviour.
I’m not sure anyone gets the point here — but I find the evolution interesting.
The latest experimental updates for Homey (13.5.2) look like they’ve conceded there are issues:
Thread
Fixes an issue where all Thread devices could become unreachable due to an occasional address conflict between Zigbee and Thread.
Fixes an issue where all Thread devices could become unreachable if Homey Pro is connected to both Ethernet and Wi-Fi.
Improves reliability when multiple Thread Border Routers are on the same Thread network as Homey Pro.
I find this is quite a common theme with Athom.
They repeatedly and quite consistently avoid admitting that there are issues with the current firmware in support tickets and on the forum, pushing blame onto the users “network”, whilst in the background are quietly working on ‘fixes’ to these issues.
The automation engine in HA is getting a bit easier to use and navigate in 2026.10
However, it still takes about ten clicks and about 30 seconds just to create a Trigger card on a simple automation, which I could do in a few seconds and in three or four clicks using Homey.
I absolutely love tinkering with AV and home automation, but I just cannot believe people who use HA exclusively spend literally hours and hours doing this stuff. It’s incredibly boring !
I just verified this.
If you use Home Assistant the Homey-like way — meaning device triggers/capabilities instead of entities — creating a trigger takes exactly three clicks:
select the room
select the device
select the capability, such as turned on or turned off
That is essentially the same workflow as in Homey.
So I don’t think the number of clicks is really a disadvantage here.
Or use the search bar on the top.
If I type “garage” I get a list of domain triggers (“garage door opened/closed”), a list of entities in that area, and a list of devices in that area.
From there, it’s two clicks to create a trigger on the garage door opening or closing.
Great thread — really enjoying the balanced takes from people who actually use both. For me, Homey’s Advanced Flows are still easier to read at a glance, but that trigger workflow improvement sounds tempting.
Yes and no.
Advanced Flows are very easy to read as long as they stay simple to moderately complex. But once they become huge, with many cards and connections, you eventually reach a point where you can no longer arrange everything without lines crossing everywhere. Then they can become surprisingly difficult to follow.
What I used to do in those cases was split the logic into several Flows and connect them using Started with yes/no. Later, with my own Flow Gadget app, I used the Continue elsewhere card.
That helps, but it also means that one logical process is now spread across several separate Flows.
Home Assistant has a similar problem. Simple automations are easy to read, while large automations with multiple Choose branches and nested If/Then blocks can also become difficult to follow.
But HA has one major advantage here: Scripts.
Despite the name, a Script does not require programming. You can build it entirely in the visual editor. I think of Scripts more as reusable automation functions.
You can define multiple parameters yourself, including numbers, booleans, text, entities and many other types.
Unfortunately, my HA interface is in German, but this example shows one of my shutter Scripts:
It accepts three parameters, including a numeric value and two entities.
The available parameter types are extensive:
The important part is that this one Script can control any roller shutter in my house, because the shutter itself is passed as a parameter.
Calling it from an automation is also done completely in the visual editor. In my case, I simply pass:
So potentially quite complex logic is reduced to one action line inside every automation that uses it.
That is where HA can actually make complex systems easier to read: instead of repeating the same logic everywhere, you encapsulate it once and reuse it.
Homey’s Started with yes/no can be used to split logic between Flows, but Advanced Flow has no direct equivalent to a reusable visual function with freely defined, typed parameters such as entities and numeric values.
So for readability I would say:
Homey is excellent at visually displaying one Flow. Home Assistant is stronger at hiding reusable complexity behind well-defined building blocks.
..statement from Athom Support which points to the problem..also during my troubleshooting they confirmed the problem with the multible TBRs…but however the past was more important is that Athom work to solve the problem with the best solution what they can provide in the moment…sry for this “Off Topic”…
Nice statement from Athom. but another score for Home Assistanr: If HA had systemic problems, these togehther with a roadmap for fixing them would be openly communicated.
In Homey land this has never been the case. For now it is just kind of a rumour and Athom´s support will stick to the usual narrative of everybody else ist doing something wrong - just not Athom.
Homey : HA
0 : 1
Here come some more general (maybe somewhat dystopian) thoughts about Homey and HA:
Has anybody recently followed how the complete Adobe software suite got reverse engineered (https://getartcraft.com/) and reimplemented as a clean sheet implementation in Rust? They even have working versions of Word, Excel and Powerpoint!.
And how the Claude skill “Reverse Engineer Anything” ( GitHub - morluto/rea: Reverse engineer anything with agents, from app behavior down to native binaries. · GitHub ) is currently going viral?
If not check that out. There are big disruptive things going on right now!
Having said this, how much effort do you think it would take to build vour own better Homey just the way you want it? Without all the long standing flaws, which Athom is so reluctant to solve.
I recckon you spend a week or two plus some 1000 - 3000 $ in tokens and you´ll have it.
The amount seems high at first glance but it is actually nothing, when you consider that you can make company like Athom completely irrelevant with such little effort.
My prediction: Homey amd Athom will be history within the next 2 - 3 years.
Why will this not happen to Home Assistant?
Home Assistant is completely open. So there is no need to replace it because you can just make it better.
Homey : HA
0 : 1+
Can it be that Athom has long heared the call and has therefore stopped actively working on Homey improvements and is instead trying to make as much money as they can in what little time they have left?
…just some thoughts and I hope they prove to be wrong.
