Right.
But if you followed this thread, you will have noticed that I already consider the need to use YAML and Jinja in Home Assistant a disadvantage.
So why would I consider HomeyScript an answer to this? HomeyScript is actual coding, not a visual automation editor.
My rule in Home Assistant is simple:
Avoid YAML and Jinja wherever reasonably possible.
AI often generates YAML when you ask it to create an automation. If you paste that into HA, you may end up with a visual automation editor containing several YAML or Jinja blocks.
But quite often, if you explicitly tell the AI to avoid templates and use native HA building blocks wherever possible, it can generate the same logic in a form that is cleanly represented in the visual editor.
Home Assistant is getting better at this with almost every release.
There are still situations where a short Jinja template is simply the easiest solution. If the alternative is creating six Helpers just to avoid five lines of Jinja, I will use the template.
For example:
{% set t = states('input_datetime.aufstehen_werktag')
if is_state('binary_sensor.workday_sensor', 'on')
else states('input_datetime.aufstehen_wochenende') %}
{{ today_at(t) }}
That is a small, isolated block that an AI can generate in seconds. I don’t need to turn the entire automation into a programming project.
For me, that is quite different from using HomeyScript as the mechanism for implementing advanced automation logic.
And I expect this gap to shrink further over time, as more things that currently require templates become available as native visual building blocks.
I also use Claude through MCP, but only with read-only access, so it can inspect my automations and entities without changing anything.
Interestingly, Claude itself suggested blocking security-related domains such as lock.* and alarm.* from MCP access, so that even the read-only connection cannot expose those entities.
That is the direction I prefer: keep the actual automation as visual as possible, and use AI or small code fragments only where they genuinely add value.
I have also written several apps for Homey, but what I find interesting is that many of the things those apps do can be achieved natively in Home Assistant. Only a relatively small number of features from my apps require an additional Helper or a small Jinja block.
Once you get used to Helpers, they are extremely powerful.
A good example is my Fronius app for Homey. In Home Assistant, the Fronius solar system is already available as a native integration.
My Homey app provides some additional statistics and calculated values that the standard HA integration does not expose. One example is an “Over Threshold” value related to Luxembourg’s electricity system.
In Homey, this is functionality I had to implement in the app itself.
In Home Assistant, I can simply create a Helper that calculates and stores that value.
For me, that is a major advantage.
I don’t have to ask an integration developer to add a very specific feature that may only be relevant to users in a small country like Luxembourg. I can build it myself with a Helper, without writing or maintaining an entire integration.
That kind of self-service extensibility is one of the areas where Home Assistant is particularly strong.
And Scripts.
