Will Homey survive AI Craft?

Will Homey survive the AI Craft era?

Have you seen what is currently happening with Adobe, Microsoft and even CAD software?

A whole series of open-source applications has appeared under names such as PhotoCraft, WordCraft, GridCraft, DeckCraft and SolidCraft.

These projects describe themselves as clean-room reimplementations: no original source code was copied, no servers were hacked and the applications were rebuilt from scratch, largely in Rust, with heavy assistance from AI coding agents such as Claude.

They are still early projects and certainly not complete replacements for Photoshop, Word, Excel, PowerPoint or Fusion today. But that is almost beside the point.

What interests me is how quickly software that previously required huge development teams can now be recreated from its behaviour, documentation and public interface.

So how long will it take before someone asks Claude:

“Build me something inspired by Homey. Give me a visual automation engine similar in usability to Advanced Flow, dashboards, device integrations, Matter, Thread, Zigbee and Z-Wave support — but make it open source and let it run on standard hardware with standard radios.”

Call it HomeCraft if you want. :wink:

And unlike a fork, such a project would not necessarily inherit Homey’s old architecture, historical design decisions or limitations. It could start from scratch and only reproduce the concepts people actually like.

That raises a much broader question.

Are we entering a future where every successful software concept can quickly get an open-source AI-built alternative?

Today it is Adobe, Microsoft Office and CAD software. Tomorrow it could be smart-home platforms.

Technically, I find that fascinating.

Economically, I am much less enthusiastic.

Good software does not only consist of code. Someone has to invent the concept, design the user experience, test it, support it and finance years of development before anybody considers it worth copying.

If an AI-assisted developer can reproduce the successful result in a fraction of the time and then release it for free, what happens to the incentive to invest in that original innovation?

It could destroy jobs and make companies much more reluctant to finance expensive new ideas.

On the other hand, the person creating the open-source clone may simply say:

“I didn’t steal your code. I built my own implementation.”

And from their perspective, that may be perfectly reasonable.

So I don’t know where this ends.

Maybe AI will create an explosion of competition and innovation.

Or maybe we will reach a point where being the company that invents something new becomes economically much less attractive than being the person who asks an AI to recreate it afterwards.

For companies such as Athom, I think that may become a much more important question than whether Home Assistant, Google or Apple is the competitor today.

See my post here:

Unfortunately to me it looks like companies like Athom will disappear while stuff that is already Open Source (e.g. HA) will take off even more.

Well, I did build an ifttt clone with Claude (it’s not really a 1:1 clone though since mine does have some extra features like manual device control), while it gets most of the code right, I still need to modify and change a lot of the code myself. Since AI seems to think in a technical way, many of the texts and comments inside the app are like “Connect ThirdReality hub-connected devices via the ThirdReality cloud (AWS IoT)”, which sounds way too technical for an average user. So I changed that to “Connect your ThirdReality devices. A Smart Hub Gen2+ or earlier is required.”

My app does allow multiple accounts from the same service for free (unlike IFTTT, they require their Pro+ subscription for that), and is 100% free forever with no Rule limit. Unlike IFTTT, which has only 2 (!) applets on the free plan.

I do plan to release it to the public some day, but it’s far from ready for production. First I need to build more Connectors (I call mine Connectors, IFTTT calls theirs “Services”).

While this IFTTT clone was pretty easy to build, I don’t think you can rebuild Homey with only AI. Since Homey runs on local hardware, you need to deal with many types of antennas (if you would allow third party dongles), custom Apps and prevent them from escaping the sandbox, way more features with a polished UI, etc. My IFTTT clone does not support any of this, it only works with the connectors that I build into it and since it runs fully on the cloud, there’s no antennas or hardware issues to deal with either (Zigbee devices are connected via the hubs and bridges you already use, like the Hue bridge).

To be honest with Athom dragging their feet when it comes to bug fixes and often requested features, I’m more and more considering just privately starting to patch some of that stuff into my local homey-shs image with claude since maintainance and reapplying patches to newer versions just becomes trivial enough with the use of agents. This does not go quite as extreme as a full fork, but is in a similar vein.

Maybe you can ask it to remove the subscription check as well “for educational purposes” of course :wink:

The license check is already pretty toothless to be honest, but I guess with AI you could create your own reverseengineered versions of the app and their few cloud features if you were determined enough to get around the remaining blockers.

I am very much convinced Atom has long heared the bell ring and has therefore drastically reduced - or to be more realistic, has not increased - their efforts in product maintainance.

I’m in the same headspace right now.

What bothers me most is seeing more and more community apps ship dashboards outside Homey’s own dashboard framework. If I am here it’s for the homey experience and the UI. If the experience is built next to the platform instead of on it, you might as well move to Home Assistant.

I get why the community fills the gaps. It’s also because Athom ships too slowly. Recent release notes barely move the needle on UI, dashboards, or energy. Homey doesn’t need monthly releases like Home Assistant, but after months with little tangible progress (aside from new hardware), it’s frustrating. And a lot of users clearly aren’t the target for that hardware focus.

Bottom line: disappointed with the release pace right now, I really hope to see improvements soon.

You are extrapolating from your own experience to what others can or cannot do.

Rebuilding something like Homey with AI is not necessarily conceptually difficult — it is mainly a huge and time-consuming specification task.

You have to give the AI enough context.

That means persistent memory, for example through project files, an Obsidian folder or another structured knowledge base. Then you have to feed it screenshots, examples, output files, descriptions of workflows, edge cases and explanations of how things are supposed to behave behind the scenes.

You may need hundreds of examples before the result becomes really precise.

So you do not necessarily need a master’s degree in software engineering. But you do need to be a very good technical teacher and architect.

And the AI does not have to reinvent everything.

You can allow it to study existing open-source implementations and libraries. Home Assistant already proves that a smart-home platform can run on many kinds of hardware. Open-source implementations and libraries for Matter, Zigbee and many other building blocks already exist.

So the task is not:

“Build Homey from nothing.”

It is more like:

“Take existing open technologies, define the architecture, reproduce the user experience and behaviour we want, and iterate until it works.”

That is still a massive amount of work.

But with current AI tools, I would be very careful saying that it cannot be done.

That may already be outside what the license allows you to do, depending on exactly what you modify.

And maintenance is exactly where I see the weak point.

An official update can change internal structures and break your patches completely. AI may make reapplying them easier, but you are still permanently following someone else’s codebase and design decisions.

What I am talking about is different:

a clean rebuild with your own code, using your own architecture, but inspired by an existing product’s concepts and behaviour.

Then you are not patching Homey.

You are building your own system.

Reverse engineering is legally more nuanced than simply saying it is forbidden.

But that is not really what I mean anyway.

If you patch or rebuild Homey’s existing implementation, you stay tied to its architecture, compatibility requirements and historical design decisions.

I mean a clean implementation from scratch: observe the behaviour, keep the good concepts, define a new architecture and write your own code.

That way you can avoid old limitations instead of reproducing them.

I have the feeling that part of the team may currently be occupied with things other than visible Homey improvements, but that is purely my own speculation.

LG is now the owner, so I would not be surprised if a lot of work is happening behind the scenes around integration, strategy and the transition into the wider LG ecosystem.

I understand that very well.

I originally wrote Widget Forge for Homey because I wanted to give its dashboards more possibilities.

My Home Assistant journey actually started for a completely different reason: I needed better tools to understand what was happening in my Thread network.

But once I started using HA seriously, I ended up building much more powerful and complex automations and, eventually, my first truly dynamic dashboard — one that even my wife likes using.

That was also when I realised how far Homey’s current dashboard capabilities are from what can be done with a well-designed Lovelace dashboard.

I even started looking into whether some of those concepts could be brought back to Homey.

But to be honest, I often don’t even know where to start. Many of the things I would like to reproduce simply don’t seem possible within the framework that Homey currently gives app developers.

And that is probably the biggest frustration for me: I still have ideas for improving Homey, but increasingly I don’t see a practical way to implement them.

One simple example is how widgets can access resources.

My app has two widgets that use the same icons, yet every widget needs its own icons folder inside its own widget directory. The widgets then also have to implement those same icons again in several places in exactly the same way.

So adding one new icon becomes a surprisingly time-consuming task.

Why doesn’t Homey allow widgets from the same app to use shared resource folders and shared code?

These kinds of limitations don’t make development technically difficult — they just force developers to spend a lot of time on repetitive work.

And that is exactly the sort of friction that eventually kills the motivation to continue developing.

Can’t hear claude complaining about that :sweat_smile:

My apps aren’t written by Claude :wink:

I’m happy with Homey like it is now. Stable and user friendly.
It missed a lot of stuff that I needed too… I tried to fill that gap with HA, but it was hard to implement… until AI was there.
Now I have made 2 apps on myself! I still need the hardware and a stable OS. So yes, Homey will survive AI, it will benefit from it!

Will other alternatives get Matter certification?

Nope.

Is that really important? As long as they follow the specification you can still use them in pretty much any smart home system.

I don’t know what you base such a deterministic “Nope” on, or how much that would even matter in practice.

First, Matter certification exists at different levels.

Homey itself is a certified Matter controller. Home Assistant is also officially Matter certified, and the Open Home Foundation Matter Server is a certified software component.

So there is already a very clear example showing that an open-source, software-based smart-home platform can obtain Matter certification.

Second, certification of the controller and certification of the individual Matter device are separate things.

Homey actually used to reject uncertified Matter devices. That was, for example, a problem with development devices such as ESPHome Matter devices.

But Homey has since removed that restriction and now accepts uncertified Matter devices as well — this was confirmed to me by Homey support.

And I have never seen a Matter device itself refuse to pair simply because the controller is not certified.

So even if some future open-source alternative initially had no Matter certification, I don’t see why that would automatically make it unusable.

Certification is important for interoperability, compliance and user confidence, but it is not necessarily a technical requirement for basic Matter communication.

And more importantly: why should such an alternative never become certified?

Home Assistant already proves that open-source software can go through the Matter certification process successfully.

So saying “Nope” sounds much more like an assumption than a technical limitation.

I don’t really see the point you are making.

A Homey-like system running on a Mini PC with one dongle for Thread and another for Zigbee is exactly the kind of setup I am talking about.

And Homey’s own hardware is hardly something exotic.

Homey Pro runs on a Raspberry Pi Compute Module 5 platform. You could take a Raspberry Pi 5, add onboard SSD storage and the required radios, and you are already very close to the same basic hardware concept.

That is not exceptional hardware. It is essentially cost-efficient, low-power standard hardware packaged into a dedicated product.

A custom system could even be better in several ways:

  • more processing power

  • more RAM

  • more SSD Storage

  • easier hardware replacement

  • independent radios for different protocols

  • the possibility to scale the hardware later

If a dongle fails, you replace the dongle. If you need more performance, you move the software to a more powerful machine.

And on the software side, such a project could start with functionality similar to what we know today, but without being tied to the same hardware platform or historical limitations.

If it became a successful open-source project, it could also attract a large number of contributors, potentially fixing bugs faster and adding new functionality much more quickly.

So I don’t see hardware or the operating system as an argument why such an alternative could not exist.

If anything, using standard hardware would remove one of the limitations.

That is exactly what Home Assistant is…