There is just the minor thing (…) of that Homey OS is Athom’s IP. I don’t think a reversed engineered Homey OS version, that you also share with others, would sit wel with their legal department. Similar like earlier attempts to copy the look-and-feel of the Advanced Flow editor by third parties.
I am not talking about real reverse engineering by code analysis. I am talking about looking at features and rebuilding these features from scratch as a fresh clean sheet implementation. That is what happend with the Adobe stuff.
In the way every home automation works there is nothing Athom could protect. And the times you could protect UIs are long gone either.
For example, who could stop you building your own word processor with exactly the things you love in Word (UI included) and with makeing things better that you don´t like?
Have you considered the server costs of a smart home platform? Third party integrations like Google Home, Alexa, IFTTT? Brand partnerships, promotions/ads, CE certification, FCC certification, running a whole company, building the physical devices, offering support, dealing with returns and warranty? There’s a lot more to it than just the software if you’re building a physical hub.
A cloud platform like IFTTT would probably be way easier to replace with an AI-generated alternative, since there you only have the software and servers.
Who cares? It is my platform and I run it.
Who needs that. I build these my own to my liking.
You miss the point. It is either my own or it is free and open source. - So what is there to promote? Or what to certify, when i can just buy and use any of the antennas out there.
The disruptive thing is, that nobody needs companies like Adobe, Microsoft and also Athom any more! - That is the real point of it.
When I say “my”, I mean whoever builds that. I will not. And I am not talking about hardware.
But if you only use it yourself, why would you spend €3000 in AI tokens instead of just €449 for a Homey Pro?
You really miss the point by a country mile.
Ask Athom / @Doekse - They will know, what I am talking about.
And don´t get me wrong: I would like Athom to survive and I like Homey. I am currently only very pi*sed about the way they act and handle e.g. their undeniable Matter / Tread problems.
I have built an IFTTT alternative before for some of my family members that just wanted to link multiple brands devices to 1 smart remote (also partially with AI). Since the “real” IFTTT charges an insane price for having more than just 2 applets and also doesn’t support many devices, I built one for them. But it doesn’t take just a week, it has taken me several months to build a full auth system with sign up, password reset, login, IP lockouts on too many failed logins and building the full automation engine, and it’s not even close to ready for a production deployment. In my case, it runs on my own VPS with just a few users so it can handle that just fine. But it’s a lot harder than you think.
What should I know about? 
For the peeps who want my two cents on the whole Homey vs. Home Assistant discussion, it honestly makes me a little sad.
I’ve never really seen Home Assistant as a competitor in this space. What I find disappointing is how often people feel the need to put the two platforms head to head, rather than side by side, and recognize that each has its own strengths and might simply be a better fit for different people.
And to be frank, the people behind Home Assistant and the Open Home Foundation are genuinely great people. Some of the most fun people to hang around with in the industry, actually. I thoroughly enjoyed sharing a kebab and having some great conversations with them at IFA in Berlin this year.
I think what a lot of people forget is that choice is a good thing. Competition drives innovation, pushes us to do better, and challenges us to come up with cool new stuff. If there were only one platform to rule them all, I genuinely don’t think anyone would benefit from that. Not the companies building these platforms, and certainly not the people using them.
And let’s not forget that, despite how big the smart home world might seem to those of us deeply involved in it, we’re still talking about a relatively small part of the population. There’s an enormous amount of room for all of us to grow.
I’d much rather see us working together to make smart home technology better, more accessible, and more useful for everyone than spend our time arguing about which platform does what better.
Don’t get me wrong, I think these discussions are great. Hearing what people like, dislike, or wish we did differently is incredibly valuable. It’s how we learn and improve. But what I don’t like is when those discussions turn into some kind of religious debate, where people preach about their platform of choice as if it’s the only right answer.
There isn’t one right answer. There doesn’t need to be.
At the end of the day, we’re all working towards pretty much the same goal: making smart homes better.
And I strongly believe we’ll get there faster by building bridges rather than walls.
Smart home is always better together.
I’m completely with you on that.
Some people seem to jump into this discussion without reading my first post, where I tried to make the rules and intention very clear.
This thread was never meant to decide which system is “better”.
The idea is:
What does one system do better, and what could the other learn from it?
In my own posts, I have pointed out several things that Home Assistant does better and that I would love to see Homey adopt. But I have also highlighted things that Homey does better and that I wish Home Assistant would learn from.
For me, one thing is very clear: both systems target somewhat different users.
Homey focuses strongly on a clean and simple user experience while still trying to remain as powerful as that philosophy allows.
Home Assistant puts more emphasis on flexibility and powerful automation, but in return expects users to accept a steeper learning curve and, in some areas, a less polished or less intuitive interface.
Both approaches have value.
In a broad sense, they naturally are competitors — simply because both solve smart-home automation problems.
But that doesn’t mean they compete for exactly the same users.
It is a little like car manufacturers: a Ferrari and a Maybach are technically competitors because both sell expensive cars, but in reality they appeal to very different customers and priorities.
I don’t think it should.
If you read this thread as intended, there is actually a lot of useful feedback in it about features people would like to see in Homey.
Just one example: full backups over the network.
With Homey, creating a true full backup still means connecting it to a computer, entering the appropriate mode and creating the backup manually.
Home Assistant can create full backups automatically and store them locally, on a NAS or in other destinations.
Maybe that concept fits Homey’s roadmap, maybe it doesn’t. But this kind of comparison can still provide useful ideas.
That is how I see this thread: not as “Homey vs. Home Assistant”, but as a source of ideas showing where each platform has solved something particularly well.
Of course there will always be people who use such discussions to discredit one system, defend another at all costs, or suggest extreme things like taking the source code and building a “better” version.
That cannot be completely avoided without very strict moderation.
But that shouldn’t make the constructive part of the discussion any less valuable. That’s simply part of having an open community.
I tried C.A.F.E. and FLODE in Home Assistant before, but neither came close to the ease of use and overall feeling of Homey’s Advanced Flow.
I have now tried Circuitry — a fork of FLODE, which itself is a fork of C.A.F.E. — and this is the first one that, for me, feels like a serious candidate.
It still doesn’t have the same native and polished feeling as Advanced Flow, but in terms of simplicity, clarity and ease of use, it comes much closer.
Colors and themes are a matter of personal taste, so that’s not really what I’m comparing here.
What matters to me is how quickly you understand what is going on, how naturally you can build logic, and how little friction there is while doing it.
And in that respect, Circuitry is the first visual-flow project for HA that makes me think: this could actually become a real alternative to Advanced Flow.
It seems that in the world of vibe-coding, it’s not common to work together on one Open Source project. Instead, everyone creates their own fork and throws their own tokens at it, post an “I built…” post somewhere, then runs out of tokens or interest until someone else comes along, forks it, ad infinitum 
I see this happening quite a lot as well, real shame 
I don’t necessarily see the forks as a bad thing.
I developed five apps for Homey, and with two of them the approval process was quite frustrating.
With one app, Athom argued that Homey’s built-in cards already did the same thing, which simply wasn’t true and missed the actual advantage of the app.
With another, I was told that a similar app already existed and that I should collaborate with its author. But that app followed a very different concept, and integrating my ideas would have required major changes. Its public codebase also wasn’t structured in a way I personally would have wanted to build on.
So I can understand why developers sometimes prefer to fork a project and pursue their own idea. With C.A.F.E., FLODE and Circuitry, they clearly share a common base, but they represent quite different ideas of what a visual automation editor should look like. For example, FLODE doesn’t really represent Choose blocks as cards and instead uses a side panel somewhat similar to HA’s built-in editor. Circuitry does represent Choose visually, including multiple branches, triggers and IDs. For a Homey user that can initially look strange, simply because Advanced Flow doesn’t have an equivalent structure and often solves the same logic with multiple conditional cards instead.
So I don’t really see these forks as pointless duplication. They are different experiments around the same question:
What should a visual automation editor for Home Assistant actually look like?
And I don’t think AI cost is the limiting factor either.
Claude is around $20/month, ChatGPT is in a similar range, and both are already very capable programming assistants. Of course AI-generated code still needs review, but today it can significantly reduce the amount of work required to develop and maintain such projects.
Projects usually die for much more ordinary reasons: people change systems, jobs, priorities or interests, get married, have children, run out of time, or simply don’t get enough feedback or traction to continue.
My hope is that eventually one of these projects becomes stable and polished enough to be adopted more officially into Home Assistant.
After using both Homey and Home Assistant extensively, I actually think HA’s standard automation editor is the better tool for complex automations. But card-based flow editors are excellent for simpler logic and for beginners. That would make them a very nice additional option in Home Assistant rather than a replacement for the existing editor.
Today, I still consider Homey’s Advanced Flow the more mature, polished and stable implementation of that concept. And that fits the purpose of this thread perfectly: learning from what another system already does well. The fact that several HA projects are trying to build something closer to Homey Advanced Flow or Node-RED clearly shows that there is demand for this kind of visual editor.
One particularly strong aspect of the C.A.F.E. base is compatibility. An automation created in Home Assistant’s standard visual editor can also be opened in Circuitry. And an automation created or modified in Circuitry can still be opened and edited in the standard HA editor. So this is not a separate automation system and doesn’t require an external server like Node-RED. It is simply another way of viewing and editing the same Home Assistant automation.
For me, that is exactly why the concept is so promising.
As I explained to @robertklep, I actually see this the opposite way.
For me, the real shame is limiting developer creativity, which is something Homey’s approval process can do.
From Athom’s perspective, I understand the reasoning: keeping the app ecosystem manageable, avoiding too much duplication, and making it easier for users to decide what to install.
But the downside is that it also limits user choice.
The worst part is what can happen to developers.
Someone may spend days or weeks building an app, preparing the first release and getting it ready for submission — only to be told afterwards that it will not be approved because a similar app already exists.
That actually happened to me.
I had to argue through several exchanges that my app was not equivalent and that the existing solution followed a different approach.
If that had happened with my very first app, there is a good chance I would have stopped there — and the other four apps I later published might never have existed.
That kind of experience can be extremely discouraging and may cause developers to think twice before investing time into another Homey project.
Home Assistant takes almost the opposite approach.
It is much more of a free-market model: developers can create different solutions to the same problem, and users decide which one they prefer. Projects succeed or disappear largely based on adoption, quality and community interest.
Homey acts much more as a gatekeeper.
I understand that Homey is not an open platform and that some approval process is necessary. In fact, that can even be an advantage.
But in my opinion, approval should mainly verify things such as:
-
compliance with platform rules
-
use of supported APIs
-
security
-
stability
-
excessive memory or resource usage
-
general technical quality
It should not decide whether users are allowed to choose between two different implementations of a similar idea.
In this area, I think Home Assistant clearly has the advantage.
And Homey could actually become even better than HA here, because Athom already has a technical approval process. If that process focused on quality and compliance rather than limiting competing concepts, users would get both freedom of choice and a certain level of quality assurance.
I also think the current policy may contribute to projects being abandoned or developers deciding that continuing development for Homey simply isn’t worth the effort.
So yes, this is definitely an area where I think Homey could learn something from Home Assistant.
I understand that this was frustrating, and I agree that we should make this policy as clear as possible before someone spends weeks building an app.
But I don’t agree that this limits creativity.
We would rather see developers work together and add missing functionality to an existing app than have ten apps for the same brand which all do one thing slightly differently. That may sound like more choice, but for most users it mainly creates confusion. They have to figure out which app they need, why one supports a certain device while another supports a different one, and what happens when the app they chose is no longer maintained.
And that last part happens quite a lot. Apps are submitted, get one or two releases and are then abandoned. The remaining developer or Athom is left with the support questions, while users are stuck with devices and flows that may stop working.
Every app also has to be reviewed, and every update creates more review work. All this duplication, together with an increasing amount of low-effort AI-generated code, is creating a huge backlog that we have to deal with. That also means developers who properly maintain their apps have to wait longer.
The comparison with Home Assistant is also not completely fair. Home Assistant does not simply allow ten competing integrations for the same brand into Core either. Core is curated and has its own approval and quality requirements. Multiple integrations can exist for one brand when they cover different products, services or protocols, but that is not the same as accepting many slightly different implementations of the same thing.
Custom integrations and HACS are more open, but Home Assistant also clearly states that those integrations are not reviewed, security-audited, maintained or supported by the Home Assistant project. Homey’s App Store is much closer to Home Assistant Core than it is to HACS.
This does not mean a second app can never be justified. If it really uses a different approach, serves a different use case or cannot reasonably be added to the existing app, we can look at that. But our starting point is collaboration, because in practice one complete and actively maintained app is usually much better for users than several incomplete ones.
And that is exactly where I think the problem starts: collaboration does not always work.
If someone has a good idea for my app, that does not automatically mean I want that person changing my codebase.
They may have limited coding experience, use a completely different architecture, structure code in a way I would never use, or introduce changes that risk breaking existing functionality.
I also would not want to create a completely separate internal architecture just to add functionality that the app was never designed around.
Take my Flow Gadgets app as an example.
It contains many cards that are unique, but also some functions that overlap with other apps.
There are math functions, for example. Many apps have math cards. But in Flow Gadgets, math is more of a general capability that can be reused by several cards.
I also have a Continue elsewhere card. Homey has something that may look similar, but the purpose and implementation are different.
And then there are very simple cards such as Invert a number.
Technically, you could achieve the same thing with:
tag * -1
But for a beginner, a card called Invert a number is much easier to understand.
So yes, some functionality may exist elsewhere. That does not mean the overall concept, architecture or target audience is the same.
And there is another important point: code quality.
I have looked at the source code of several open Homey apps implementing functionality similar to mine. In some cases, what I saw simply did not match the standards I would want for my own codebase: little reuse, duplicated logic, inconsistent structure, or large amounts of very specific custom code.
I would not want someone working that way to modify my application.
That is not arrogance; it is about maintaining a codebase that I remain responsible for.
Collaboration is great when developers share the same goals, architecture and quality standards.
But when they don’t, forcing collaboration is not necessarily better than allowing two different apps to exist.
Sometimes a separate implementation — or even a fork — is the cleaner solution.
I think this is exactly where being open to collaboration matters.
Nobody is saying that you have to give another developer direct access to your codebase or accept every contribution. As the app owner, you remain responsible for the app and you can review proposed changes, explain your standards and reject code that does not meet them.
But assuming in advance that another developer may lack experience, use the wrong architecture or write code below your standards is not a convincing argument against collaboration. It is judging the developer before the conversation has even taken place.
You previously described Homey as a gatekeeper, but what you describe here might be a better example. The gate has simply moved from the platform to the maintainer. You are effectively saying that you should be free to publish an alternative to somebody else’s work, while being unwilling to let another developer even explore contributing an alternative idea to yours.
Protecting the quality of your app is perfectly reasonable. Deciding beforehand that another developer is probably not capable of meeting that quality is something else.
All my own repositories are open source as well. I regularly receive feedback and suggestions that I would not necessarily implement in the proposed way. I still remain open to the feedback and start the conversation. Sometimes it results in a contribution, sometimes we find a better solution together, and sometimes the idea does not fit. That is how collaboration works. Listening to someone does not mean that you have to merge their code.
It is also worth remembering that everybody starts somewhere. Someone with less experience may need guidance, but may still have a good idea or notice something an experienced developer has missed. More experienced developers can help those people improve instead of closing the door because their first attempt may not be perfect.
Of course, there are situations where two concepts or technical approaches are genuinely too different to fit in one app. A separate app may then be justified. But that should be the conclusion after a proper discussion, not the starting point.
If we want a healthy developer community, experienced developers cannot ask the platform to give everyone complete freedom while reserving the right to dismiss potential contributors before hearing them out. Being responsible for a codebase does not require lowering your standards, but it should include being open to feedback, other insights and people who are still learning.
I think you misunderstood my point.
I did not decide beforehand that another developer would be incapable of meeting my standards. In the particular case I mentioned, I actually looked at the codebase of the app I was told was similar to mine. So I had existing code to evaluate, and from that code I could see both the developer’s approach and that the architecture would not fit what I wanted to build. That is quite different from judging someone in advance.
I have also had users request features and, occasionally, even send me pieces of code. I don’t claim that this code was always bad. But it rarely matched the architecture or standards I use in my own projects. For example, I received code that repeatedly loaded capabilities dynamically in places where I deliberately avoid doing that. Sometimes I was very happy to receive such code and used parts of it as a starting point. But most of the time I rewrote it to fit my own architecture.
For me, that is closer to an advanced feature request than real collaboration.
And to be completely fair: when I started developing Homey apps, I had never used Node.js before either. But being new to a language does not mean abandoning the software-engineering principles and standards you already apply elsewhere.
I also asked the Homey developer community for help several times. Sometimes I received one useful answer. Quite often I received no answer at all. So my personal experience with the developer community has unfortunately been much less collaborative and supportive than the picture you are describing.
And that has consequences.
At the moment, I am busy with other projects, but I still intend to maintain my existing Homey apps when I have time. However, my motivation has changed. At the beginning, I was very enthusiastic about contributing to Homey and helping the platform move forward. Today, I mainly continue because I want to support the users of my apps.
After the experiences I had with the approval process of two of my apps, I am unlikely to start another new Homey development project. I simply feel that my development effort can be better appreciated elsewhere.
The same applies to this forum.
I still participate because most users here are polite, friendly and genuinely trying to solve problems. I am happy to help people stay with Homey if that is the platform they like, and I am equally happy to help someone migrate to Home Assistant if that is what they want. I have no intention of pushing anyone in either direction. But I no longer do this because I want to support Athom as a company.
That enthusiasm has largely disappeared, which is a pity because I still think Homey itself is a very promising platform.
