I’ve recently made the switch from Home Assistant to Homey Pro (2026). As someone who has managed a complex self-hosted infrastructure for years, I wanted to share my perspective on why I moved—and where I think Athom has a massive opportunity to lead the market.
While I love the polished UI and the “Visual Logic” of Homey, there is one area where I feel we are still doing too much “manual labor”: Flow Creation.
In my latest blog post, I dive into:
The UX Pivot: Why I chose Homey’s clarity over HA’s power.
The “Mixed Protocol” Headache: How setting up a single remote for Zigbee/Wi-Fi/Matter bulbs still feels repetitive.
The AI Gap: Why the current ALT + Right-Click JSON import workaround is a sign that we are ready for a native AI Flow Co-Pilot.
With the extra RAM in the new 2026 hardware, I’d love to see Athom move beyond “Voice Control” and into “Automation Generation.”
That’s exactly the point I’m making. MCP currently turns Homey into a Jarvis—a conversational interface where you ask for things to happen in the moment.
What I’m looking for is an Architect.
I don’t want to talk to my house every day to get things done; I want my house to be automated so I don’t have to think about it. The bottleneck right now is that building those ‘invisible’ automations (Flows) is a manual, repetitive process.
Instead of spending 30 minutes dragging cards to map a 12-button remote to various lights, I want to describe that logic once and have the system generate the Flows for me.
MCP is about Execution (Jarvis). I’m talking about Creation (Code-Pilot). I want the AI to handle the ‘boilerplate’ of flow-building so I can spend more time enjoying the smart home and less time configuring it.
I’ve did some testing, but creating workflows via the api is a pain in the ass, broke the advanced workflow page several times. Then i found that via the homey dev page, you can create via the webapi advanced flows. Was more like creating json files with AI and the mcp i created to get each flowcard.
So there could/should be a workarround, but is ongoing like all the other projects….
I really appreciate you sharing that—and honestly, huge thanks for all the work you’re putting into the mcp-homeyrepo in your personal time. It’s exactly these kinds of community projects that make Homey so much fun for people like us.
The reason I’m so excited about what you’re doing is that I see it as the foundation for a more ‘private’ way of using AI. For me, Homey is all about local execution. I love that my traffic stays ‘In-Doors’ and doesn’t rely on the cloud for every single light switch.
That’s why I’m such a fan of the ‘Architect’ idea: If we can use an AI (via your MCP) as a one-time ‘consultant’ to help us build a complex flow, the AI does its job and then steps away. The result is a Flow that lives 100% locally on the Homey Pro.
We get the genius of AI to handle the ‘manual labor’ of dragging cards, but we keep the actual heartbeat of the home private and fast. You’ve built the bridge—I’m just dreaming of the day Athom makes it a native part of the editor so your hard work can shine without ‘breaking the page’!
Thanks for the tip, Sven! Claude is indeed great at writing HomeyScripts, and for complex calculations or deep API filtering, that’s definitely the way to go.
However, what I’m aiming for is a bit different. I’m looking at the Architect level rather than the Script level.
My goal is to use the AI to generate the Advanced Flow itself—the visual logic, the cards, and the connections. Why? Because:
Maintenance: A Flow is much easier for most people (or myself six months from now) to ‘read’ and tweak visually than a wall of Javascript.
Local Performance: Native Flow cards are highly optimized for the Homey Pro hardware.
The ‘In-Doors’ Philosophy: While a script is powerful, an Advanced Flow is the ‘native language’ of Homey.
I don’t want to write code to turn on a light; I want an AI agent that understands my house (via MCP) and drags the cards for me. I’m trying to automate the creation of the automation, not just the execution of a script!
You would at least need an AI model with a very high context for that. On my Homey, getting Trigger, Condition and Action cards from the API is already 25723 lines of JSON. Then we also need the devices, that’s another 7712 lines and then also the Flow tokens which is another 2108 lines. And I don’t even have as many devices as most people, so for most Homey users this number would be far higher. I don’t think many models support that much data/context. Homey doesn’t have an easy method of filtering AFAIK, even the web app loads it all at once.
Dumping the entire Homey state would definitely overwhelm the context.
That’s where the MCP comes in. Instead of a ‘data dump,’ it acts as a filter so the Agent only requests what’s relevant / like devices in a specific zone or specific capabilities.
This way AI stays accurate and the logic remains clean.
I really don’t understand why you moved from HA to Homey if that’s what you want, given that HA automations are always serialized to YAML, which is much more easy to generate than Homey flows (which aren’t serialized in any human-readable or easily accessible way).
You’re right that YAML is easier for serialization, but for me, the transition from HA to Homey was about the integration of the total experience.
While HA is powerful, Homey offers several structural advantages that fit my personal wishes better:
Unified Radio Stack: Having Zigbee, Z-Wave, 433MHz, Infrared, and Matter handled by a single, high-quality local antenna array on the Homey Pro is significantly more stable and ‘clean’ than managing a forest of USB sticks and drivers.
Curated Ecosystem: The strict SDK means Homey Apps are generally more ‘plug-and-play.’ I’d rather work within a curated framework than spend my weekend debugging breaking changes in a community YAML integration after an update.
I actualy value the Advanced Flow UI for its spatial logic. Just because the backend serialization is complex JSON doesn’t mean it’s wrong.
Local-First, Less Maintenance: Homey provides a ‘Premium’ feel and local execution without the maintenance overhead of a self-managed OS.
I’m looking for the best hardware platform to live in. Building a bridge to automate the flow creation is just my way of getting the Homey UX with the deployment speed of HA.
I’ve done the HA dance: the powered USB hub, the extension cables to avoid interference, and the separate sticks for Zigbee and Z-Wave. It works, but it’s a lot of hardware that never really stays working. After having an angry girlfriend several times a week because the lights didn’t turn on or something broke for no reason.
I didn’t ‘remove’ the USB hub; I fixed my relationship
Yes, that’s true. For my apps, I always reverse engineer all protocols myself. I see many developers copying HA integrations but the thing is that HA is meant for power users: if something doesn’t work, they will debug it themselves since most HA users have technical knowledge. However, this is not the same audience as the Homey users which would expect everything to work immediately. So I’m against copying HA integrations since they’re not as high-quality as what people would expect from a Homey app.
I’m sincerely hoping that your girlfriend will like your new Homey, because you can find plenty of posts on this forum about people having the exact same issues with it
I moved most hardware to H.A., it handles zigbee, Thread & Ble (& LAN of course). Yea, that’s 3 dongles in an USB hub on a 20cm extension cord.
Runs stable for several years now, I once had to change a driver.
I use Homey mainly because of (adv) flow, but I have to say H.A. automations are improved quite a lot lately.
So I joined both systems to a HAmey
Well, it depends. But I think it’s more user-friendliness than quality. For example, in HACS you see many integrations with vague names (not the name of the actual brand). This might confuse users.
But Home Assistant integrations also often reference to checking the logs, for example. That’s not very user-friendly, especially for users who don’t even know what “logs“ are in the first place. That is obviously the reason why Homey hides diagnostic reports to users.
In my Homey apps, I try to hide the actual error message to the users, because most likely won’t even understand what is meant by such an error message. Whenever an error occurs that is not supposed to happen, the app will simply use “An unexpected error occured“ or similar instead of the actual error message or stack trace. Any (error) message that looks too confusing to an ordinary user should stay hidden to the user in a Homey app in my opinion. However, this isn’t the case for Home Assistant. In Home Assistant, the people want full control over everything: everything should be visible. While some power users like this full control, it’s definitely not for everyone.
In my opinion:
Home Assistant = for users who want full control over the code that runs on their devices and want every part of it to be visible, and are willing to debug any issues when they arise.
Homey = for people who want something that simply works, out of the box, without thinking much about the technical aspect of it.
While I am a power user, I still like the simplicity of Homey with its easy-to-use (advanced) Flows. I also like that Homey uses JS instead of Python, because JS is way easier to understand for me.
For the integrations, I think Home Assistant and Homey have similar integrations. Some integrations are available in HA but not in Homey, and some integrations are only available on Homey and not on HA.
@Robert & @Peter_Kawa: I hear you on the stability—the ‘Partner Approval Factor’ is the ultimate metric. The reason I’m so focused on this AI-Architect is exactly because I don’t want to be ‘that guy’ fixing broken automations at 11 PM. I’m moving away from the DIY ‘Dongle Jungle’ because I want a stable, integrated hardware stack, but I still want the deployment speed that HA power-users have.
@Sven: You hit the nail on the head regarding quality. Homey users expect things to ‘just work.’ That’s exactly why I’m against ‘copy-pasting’ messy logic. By using the AI as a Compiler rather than a Script-writer, I can ensure that every flow it ‘draws’ follows a high-quality, standardized logic that stays 100% local.
Ultimately, I think this approach serves both ends of the spectrum:
For Beginners: It removes the ‘blank canvas’ paralysis. The AI acts as a guide to build their first solid Advanced Flow without them getting lost in the logic.
For Pros: It solves the ‘Remote Nightmare.’ We shouldn’t be wasting 20 minutes manually dragging 15 cards and lines just to map a single Zigbee remote. The AI can scaffold that boring ‘data entry’ in seconds, leaving us to do the fun, high-level architecture.
I’m going to try and use AI to get the HA speed of creation with the Homey quality of execution. I think that would be something awesome for everyone. And if I get it to work, maybe even the Homey team will take a second look and pick it up
So you’re looking for a local AI? I would recommend you to check out Ollama in that case, it also has a Homey app (though that’s primarily meant for analyzing camera snapshots and generating text based on a prompt)
The Great Smart Home Pivot: Why I Switched from Home Assistant to Homey
