That’s exactly what my script does. What I was trying to explain is that instead of having to remember the specific setup for a critical notification, I use a script that takes care of those details. All I have to do in my automations is call the script, which has some very easy-to-remember parameters.
There are various blueprints available that will take care of the details for you, so you can send critical notifications without having to write a single line of YAML manually.
Yes, putting this into a script is definitely the better approach.
It took me some time to really understand the difference between scripts and automations. At first, I mainly saw scripts as automations without triggers and conditions.
Now I think of them more as reusable automation blocks with parameters. Once you look at them that way, they make a lot more sense — and they are extremely useful for avoiding duplicated logic.
But Homey’s Dashboards are restricted to the mobile app only… so mobile phones and Android tablets only.
For this reason I bought a Shelly Wall Display XL to run a Homey Dashboard on. A HUGE waste of money… it is sooooooooo slow it is unusable. I tried the browser TV interface in Silk browser on an Echo Show 15, equally useless.
The only one I have had any success with is installing the Android app on a tablet, and running a Dashboard in Kiosk mode. I’ve yet to find a decent wall mounted solution for Homey with snappy responses that doesn’t cost the earth… like I have seen numerous YouTube/Facebook posts show off in their Home Assistant setups.
I think this is drifting off-topic a little — please see the rules in the opening post.
Of course Homey has dashboards, and they can be extended. I even wrote Widget Forge myself. But when comparing the two systems directly, the difference is still quite clear.
A fair summary would be:
Both systems can create simple dashboards very easily.
Without coding, Home Assistant already offers more flexibility, interaction and configuration options.
With YAML, Jinja and tools such as card-mod, HA goes much further: dynamic content, conditional visibility, state-dependent layouts, CSS styling and much more.
The number and variety of available dashboard cards in HA is also on a completely different level.
So for users who want predefined building blocks and minimum effort, Homey probably has a small usability advantage.
For everything beyond that, Home Assistant is clearly more capable.
But the point of this thread is not to prove that one system can somehow reproduce a feature using third-party solutions. It is to identify what each platform genuinely does better and what the other could learn from it.
And in this particular case, I already find everything I need from Homey’s dashboards in HA. The reverse is not true.
That said, I would not want Homey to simply copy HA’s dashboard system either, because that would conflict with Homey’s promise of simplicity.
One general point for everyone: please keep in mind that both systems have a very different focus.
Homey’s focus is simplicity.
The promise is that almost everyone should be able to use the system without needing deep technical knowledge.
Home Assistant’s focus is flexibility and power.
It tries to give you the tools to build almost anything you can imagine.
Home Assistant has made enormous progress in recent years. The visual editors have become much better, and YAML is being pushed further into the background for many everyday tasks.
But HA is still far away from Homey’s level of simplicity.
At the same time, almost every update shows that Home Assistant is still evolving quickly and that improving usability is clearly an ongoing process.
So when we suggest bringing a feature from one platform to the other, we should always keep these different goals in mind.
A feature that is perfect for Home Assistant may be completely wrong for Homey if it destroys the simplicity of the system.
And a limitation that feels frustrating in Homey may sometimes be a deliberate consequence of keeping the system approachable.
So the question should not only be:
“Can platform A copy this feature from platform B?”
but also:
“Can it adopt the idea in a way that still fits its own philosophy?”
For super big or more complex Homey Flow you can add Notes and write in there information for later to remember the reason you used X instead of Y etc.
Not sure if HA has that as well.
I only tried Home Assistant briefly maybe a week at the same time I was testing Homey and Hubitat and decided to put the effort into Homey.
I still from time to time get confused with the Variables,Logics but slowly have got better at them.
One thing I wish that I could categorize the devices, for example the Thirdreality Smart night light does not show under Lights.
I wish I could change that so I can easily see if the light is On.
If I understand the rematk on the ‘required expression’ correctly then this should map to the Homey concept ‘AND’ in a flow. The ‘WHEN’ condition triggers the flow, the ‘AND’ condition(s) check if the flow may continue.
From how I understand it, the “WHEN” does not trigger with a required expression. In Home Assistant and Homey you can mimic this by creating an automation/flow that triggers on enabling/disabling the heating and using it to enable/disable the “main” automation/flow.
A Required Expression is better understood as a precondition that sits before the triggers.
If an event occurs while the Required Expression is false, the automation is not eligible to run, so the trigger does not fire at all.
Internally, you can think of the rule as being inactive while that expression is false. Only when it becomes true are its triggers effectively enabled again.
If this is implemented efficiently through internal state tables, it can avoid a lot of unnecessary processing.
That is different from both Home Assistant and Homey:
In Home Assistant, the trigger fires first. Conditions can then stop the automation immediately, either through the general automation conditions or later inside the actions.
In Homey, you can let the Flow continue into an unused True/False branch, but the trigger has still fired.
So in both cases, the trigger event is processed.
With a Required Expression, the automation is effectively filtered before the trigger stage. That is the important difference.
With that approach, the automation that enables or disables the main automation still has to be triggered itself. So some trigger processing still happens, although the total number of trigger executions may indeed be reduced.
That makes it a reasonable theoretical workaround, but it is not exactly the same concept.
In Hubitat, the Required Expression state is maintained at a much lower level and directly determines whether the rule is eligible to react to trigger events at all.
The other practical problem is scale: if you use this pattern extensively in Homey or Home Assistant, you may end up creating many additional automations whose only purpose is to enable or disable other automations.
So yes, it can approximate the behaviour, but it is more of a workaround than an equivalent implementation.
Just because Hubitat doesn’t show you that things are being triggered with these Required Expressions, there must still be some trigger processing being done under the hood to respond to the heating being enabled or disabled. It’s nice syntactic sugar, but I have never found trigger processing to even cause a blip in CPU usage, also on lower-end hardware with close to 150 automations.
I don’t have any internal insight into Hubitat, so I can only make an educated guess from a programmer’s perspective.
All three systems are essentially event-driven. If, for example, a window contact changes state, that produces an event. Automations that are interested in that event are normally registered somewhere so the system knows which automations need to be evaluated.
My assumption is that Hubitat’s Required Expression is handled very close to that subscription or dispatch level.
Of course, some processing still has to happen. The system must notice that the Required Expression changed and maintain its internal state accordingly.
But that work is part of the core event handling that has to happen anyway.
The important difference is what happens afterwards.
If the Required Expression is false, the actual rule does not need to be started, its trigger logic does not need to be evaluated further, and no execution trace or rule-level logging needs to be created.
So I am not saying that Required Expressions require zero processing.
My point is that they can stop processing at a much earlier stage than a normal automation condition.
And that is why the practical difference may not be obvious at first glance.
That’s a good point for Homey, and it definitely helps readability.
In Advanced Flow, you can place notes directly at specific points in the flow. That makes it much easier to document why a certain branch or piece of logic exists.
Home Assistant does have descriptions and notes in some places, but they are much less visible. Often you have to hover over or open something to actually read them.
You can also add comments directly to YAML:
# This is a comment
But strangely, once you open and save the automation again in the visual editor, those comments may disappear.
So I would add another item to my Home Assistant wish list:
Add a dedicated “Comment” block to the automation editor.
It should simply appear inline between conditions and actions, so you can document the logic exactly where it matters.
Something like:
Choose
└─ Option 1
├─ Comment:
│ "Keep the shutter partly closed here because of TV glare."
├─ Conditions
│ ...
└─ Actions
...
Since YAML already supports comments at a lower level, this should at least conceptually fit very naturally into the system.
For complex automations, this would make a surprisingly big difference.
And HA doesn’t crash for no reason, what did the logs show? Often with people running HA on Raspberry Pi’s, they use SD cards that aren’t meant for high endurance so they fail after a few months. That’s not HA’s fault.
I use regular SD cards in my Raspberry Pi’s (one running eWeLink CUBE, the other 2 are running a DNS logger and some staging/test versions of my webservices) for years now and I have never had to replace them. So I think it might still be that HA writes too much to the SD or similar. Or I might just be lucky that it has never happened.
Just like Homey, HA writes to various databases for things like history, “insights”, etc. You really want to use either a high endurance SD card, or eMMC storage like Homey has.
