Homey vs. Home Assistant – What Does Each System Do Better?

Off-Topic
42

It crashed. As in unreachable unrecoverable. So no logs. And I have a NVME m.2 2230

43

So a hardware problem?

44

Maybe you should stop assuming you know better than the people experiencing the problems, just because you don’t want to hear anything negative about home assistant. No it was not a hardware issue, because it was still pingable. It was a hard software crash. I could reach the hardware, I had no way Ito get into HA. Not via GUI, not via CL.

45

First:

Now:

Don’t blame me for thinking that “unreachable” means “unreachable”. If you would have said it was pingable, I wouldn’t assume a hardware issue :man_shrugging:t3:

Anyway, Homey is probably much better for you.

46

We were talking about HA. That was indeed unreachable and unrecoverable. Don’t blame me for the fact you read things I haven’t said.

And I like homey a bit better, but I have run HA for years. So I don’t really understand why you reach the conclusion homey would be ‘better’ for me. Homey also has its issues.

47

You also wrote “no logs”. I guess you mean “no HA logs” by that and not OS-level logs (although it’s very strange that HA is unrecoverable and trying to start it yields no logs whatsoever).

Why would you run something for years if you “have to fix a lot of stuff” after very update? Given that there are monthly updates, I would have given up a long time ago.

48

For the same reason almost everybody in this thread is running them both. Hobby, tinkering. We were just comparing what we liked. And I don’t like HA as much because a lot breaks after updates. Bite me.

49

Let’s come back to the topic, please.

You had a bad experience with Home Assistant and therefore don’t like it. That’s perfectly valid, but it is still a personal experience, not a general conclusion about the platform.

I could say the same about Homey: I had to restore mine twice — once because devices would not recover despite everything I tried, and once because the phone app insisted Homey was unreachable even after rebooting both Homey and the phone.

My conclusion is simply that both systems are mature and generally stable, but individual experiences differ.

I also think @robertklep was only trying to help. Heavy write activity can be problematic for SD cards, and Home Assistant generates a lot of database activity. That is why SSD or eMMC storage is generally a better choice for a permanent HA installation. Personally, I would also prefer a small N100-class mini PC over a Raspberry Pi for HA.

The same applies to updates.

I don’t think “HA updates always break things” is a useful argument. I have had Homey updates that fixed my Matter problems and later updates that brought problems back again. That’s why I disable automatic updates.

One advantage of Home Assistant is that breaking changes are documented quite extensively before updating, so you can decide whether to update immediately or make the required changes first. Waiting for the first one or two patch releases is also a reasonable strategy.

So the point I would retain for this thread is something different:

Home Assistant’s freedom to choose hardware and install unofficial integrations is both an advantage and a disadvantage.

It gives you much more flexibility, but it also means there are more variables that can affect stability.

And that is a useful comparison between the two systems. Personal preferences like “I like/don’t like HA because I had a crash” are not really what this thread is about.

50

High Availability Setup

Homey:

Not a chance. - Homey will always be a single point of failure and although you can restore your backup on a replacement unit you have to rebuild at least your complete Zigbee net. Which means touching each and any device you have, including climbig ladders and opening walls.

Home Assistant:

Easy. - Even with a single instance you can quickly set up a new HA from a backup or replace a broken antenna without loosing anything. It effortlessly scales up to e.g. running on a Proxmox High Availability Cluster and will thus be as good as bullet proof.

Conclusion:

Homey is an expensive toy, while Home Assistant is a serious work horse. - And it will stay that way until Athom decides to allow external antennas to be used.

51

It depends on how much trust you put in the system. I have almost all of my Zigbee devices on the manufacturer’s own hubs. Then, the hubs link to Homey via the cloud and then the devices can be controlled centrally by Homey. If Homey ever fails, I can just open the manufacturer’s mobile app and control the devices from there. In this case, there’s not a single point of failure. If one of the manufacturer’s bridges fails, it’s definitely annoying but the rest of your smart home will stay working. If Homey fails, I can still use the mobile app from my device manufacturer. It might be more work to go to each app manually to control them, but it’s still possible if I really need to.

Homey connects everything together to allow me to automate devices from different brands and control all of the devices in 1 place. But if Homey fails, or if there’s a server outage or anything, I can still use the “old” way to control my devices by using the mobile apps from my device manufacturers

52

I think this is mainly a different view of architecture and security.

Putting devices on manufacturers’ own hubs means accepting additional dependencies: their hardware, their cloud services, their accounts and, in many cases, additional data leaving the local network. If a manufacturer changes its business model, discontinues a service or introduces subscription fees, you may also have very little influence over that.

And of course an additional hub can fail as well. From my perspective, every extra dependency is another potential point of failure.

But to stay on topic: I don’t see this as an advantage of Homey.

One of Homey’s major selling points is precisely that it is a local hub and does not require a collection of manufacturer clouds to operate the smart home.

Where I do see a significant advantage for Home Assistant is disaster recovery.

If my HA hardware fails, I can restore my backup on different compatible hardware — for example on my Mac Studio temporarily, or on a spare Home Assistant Green until I have replaced the failed machine.

With Homey, I am much more dependent on having compatible Homey hardware available.

So in terms of hardware independence and disaster recovery, I would clearly give this point to Home Assistant.

@4x4_Pete : I also wouldn’t describe Homey as an “expensive toy”. I think that seriously understates what it can do.

I would describe Homey as a very capable consumer-oriented system whose main priorities are simplicity and accessibility.

Home Assistant can start at essentially the same consumer level, but its architecture allows it to scale much further into highly customised and much more complex installations.

That, to me, is the more meaningful distinction.

Edit:

Again, I have to come back to Hubitat.

With Hubitat you are, of course, just as dependent on their hardware as you are with Homey. The difference is that they seem to acknowledge this dependency and offer a better way to mitigate the risk.

They offer an optional annual subscription that extends the hardware warranty year by year. If the hub fails, you receive a replacement unit, shipped by express.

I actually think that is a very sensible model for a system that depends on proprietary hardware.

Something similar could be a valuable option for Homey as well: if hardware independence is not possible, then at least make hardware failure as painless as possible.

53

Painless is not about the price. Price is probably your least problem in case of a desaster. What is needed is get another box put your backup on and take off just where you left.
…but not with Homey.

In my backup routine I already read all the keys and IDs from the radio chips. I could write them to a third party antenna having the same chip and just continue as if nothing had happened.
Only thing Athom had to do is open the SHS for third party antennas. - But that is not where the money is. And money is always first for a commercial entity. (Anothe big minus compared to Home Assistant).

54

It wasn’t really the price I was talking about.

What I meant was Hubitat’s replacement model: if the hub fails, they immediately send you a brand-new replacement by express, so your downtime is kept as short as possible. The extended warranty is just an additional benefit.

I actually considered buying a second Homey as a cold spare for exactly that reason. But at Homey’s price, that is difficult to justify — especially since I could eventually end up with two outdated units.

With Home Assistant, the situation is easier for me. I already have a Home Assistant Green as a spare, and if my main mini PC dies, Amazon can usually deliver a replacement within a day or I go to the local store and get one in an hour.

The only remaining single point of failure would be the Thread/Zigbee adapter, because that may take longer to replace.

So my sensible disaster-recovery strategy is probably:

  • Home Assistant Green as emergency hardware

  • one spare Thread/Zigbee adapter

  • regular backups

With that setup, I should be able to recover from almost any hardware failure very quickly.

So yes, when it comes to disaster recovery and hardware replacement flexibility, I agree that this point clearly goes to Home Assistant.

55

No is that so.
I would say most system are “better” then homey “backup”.
Just saying..

56

Another strong point for Home Assistant is Trigger IDs.

An automation can have many different triggers, and every trigger can be given its own ID.

For example:

  • Window closed → window_closed

  • Luminance below 500 lux for 20 minutes → luminance_low

  • Mode changed → mode_changed

  • Sunset → sunset

Later, inside the actions, you can directly check which trigger started the automation.

So inside an If/Then block or a Choose block, you can simply use logic such as:

If triggered by: window_closed

or:

If triggered by: luminance_low

This makes it possible to consolidate several closely related pieces of logic into a single automation without losing clarity.

I make extensive use of Trigger IDs in my current roller shutter automations.

One of my previous Homey Advanced Flows had around seven different starting points, combined with fairly complex connections using OR and ALL logic.

In Home Assistant, that whole structure ended up as a single automation with several clearly named triggers and Choosebranches based on their Trigger IDs.

The result is actually:

  • easier to maintain

  • easier to extend

  • more compact

  • easier to understand logically

  • and it now contains even more sophisticated logic than the original Advanced Flow

This is one of those cases where Home Assistant’s automation model is not only more powerful, but can also be cleaner once you understand how to structure it.

Trigger IDs are especially useful when several different events should ultimately control the same system but require slightly different reactions.

Instead of creating separate automations or multiple disconnected starting points, you can keep the complete logic together and simply ask:

“What triggered me?”

For complex automations, that is a very elegant concept. I would like to see that in Homey.

58

I think I already mentioned Scripts earlier in this discussion, but at that time I hadn’t yet understood their real power.

First of all, I find the name a little misleading.

“Script” sounds as if you need to write code. You don’t. A Home Assistant script can be built almost entirely with the same visual editor used for automations.

The closest analogy I can think of in Homey would be a Flow started with something like “Flow started with…”.

But there are some major differences.

A Home Assistant script can accept multiple parameters of different types. Most importantly, you can even pass an entity itself as a parameter.

A script can also return data to the automation that called it.

This turns scripts into something much closer to reusable functions than simply reusable action sequences.

A practical example

I use a script for positioning my roller shutters.

It receives three parameters:

  • Entity – the shutter that should be controlled

  • Position – the target position

  • Automatic – true or false

Every roller shutter automation can therefore call the same script and simply tell it:

Which shutter? Which position? Is this an automatic movement or not?

The reason for the third parameter is that my system detects manual shutter movements and temporarily switches that shutter out of automatic control.

So the same positioning script can be used by different types of automations without duplicating the underlying logic.

“But you can do that with variables in Homey”

You can imitate parts of this behaviour with Logic variables in Homey, but that is not the same thing.

A variable is shared state.

A script parameter belongs to one specific invocation of that script.

That difference becomes important as soon as two executions overlap.

Imagine two automations calling the same logic almost simultaneously:

  • Call 1: Shutter A, position 15

  • Call 2: Shutter B, position 50

If those values are transported through shared variables, the second call can overwrite them while the first call is still running.

Now the first Flow may suddenly read values that actually belong to the second call.

That is a classic race condition.

With script parameters, each invocation keeps its own values. Call 1 continues to work with Shutter A / 15, while Call 2 has its own Shutter B / 50.

So variables can be used as a workaround to pass information around, but they are not equivalent to parameters.

Execution modes make this even more powerful

Home Assistant scripts also have configurable execution modes.

For example, a script can run in queued mode.

If several automations call it at nearly the same time, the invocations are queued and executed in order. Each call keeps its own parameters.

Other modes include single, restart and parallel, so you can explicitly define what should happen when the same script is called again while another invocation is still running.

This gives you control over concurrency instead of having to work around it.

And scripts can even return a result to the calling automation.

Again, using a shared variable in Homey as a “return value” is not really equivalent, because another Flow can potentially change that variable before the original caller uses it.

This makes Home Assistant scripts much more than a way to avoid duplicating a few actions.

They provide reusable pieces of automation logic with:

  • defined inputs

  • entity parameters

  • parameters isolated per invocation

  • controlled execution behaviour

  • and returned results

The more I use them, the more I think the name “Script” hides what they really are.

For someone coming from Homey, I would describe them more like:

Reusable parameterised automation functions.

And that distinction is important: Homey variables can emulate some of the visible behaviour, but they do not provide the same per-call isolation and execution semantics.

Edit: One point I missed.

There is another important advantage to having all shutter movements pass through one central script.

I also have an alarm automation for smoke detectors. If a smoke alarm is triggered, all shutters are opened to keep escape routes clear. Naturally, I do not want any normal shutter automation to close them again afterwards.

So I only need one global flag, for example smoke_alarm_active.

The shutter script checks that flag before executing any movement. As soon as the flag is active, normal shutter movements are blocked.

That gives me one central point that can override all shutter automations.

Instead of adding the same emergency condition to every single automation, I only have to implement it once in the shared script.

59

@robertklep : Are you still using Homey or did you migrate completely to Home Assistant ?

60

I have three Homey’s (the white ball, a 2023 model, and a Special Edition Homey that I won in the Homey Community Awards that I have yet to unbox :woozy_face:) that literally do nothing (other than running tests for my apps whenever I update them), and haven’t done so in a long time. I migrated to Home Assistant completely years ago.

61

Thanks for the feedback.

At the moment, my Homey is actually only running two or three automations that I haven’t migrated yet.

My original plan was to pair all devices with both Homey and Home Assistant and keep both systems running in parallel, each with a master switch to enable or disable all automations. That way, I could easily switch from one system to the other.

But while trying to reproduce every Homey Flow in Home Assistant, my view changed.

Some of my most complex and sophisticated Advanced Flows were already pushing Homey close to its limits. In Home Assistant, I found that I could reproduce the same logic quite easily — and then push it much further.

At this point, the real limitation is no longer what the automation engine can do. The limitation is my own ability to design the logic in a way that I can still understand and maintain it. HA automations can become so complex that understanding the complete system becomes harder than implementing it.

So after the migration, I will probably also have a Homey sitting around without much of a job. :wink:

However, I still want to maintain and update my Homey apps. I just hope I don’t lose the motivation to keep doing that once Homey is no longer my primary automation system.

62

I tend to create a lot of helpers and (binary) sensors to both reduce duplication and complexity.

For instance, I have a few template binary sensor definitions that are used to track if there is rain incoming in 15/30/60/90/120 minutes. And then I have various automations that trigger on one of those sensors becoming true (for instance to alert me that there are clothes hanging outside on the clothes dryer and there’s rain expected in 15 minutes, or that I can quickly check on a dashboard if there’s rain expected in the next hour or so, before I go out on a bike ride).