Thinking way back to when I started with home assistant I thought YAML and the way it was used to configure Home Assistant was utterly fantastic.
Instead of having to learn Python and write a program to notify me when my (snail) mailbox was full all I had to do was look up some options in the documentation and fill them in. It was dead easy in comparison to what I was initially planning. Instead of spending weeks learning a programming language all I had to do was follow a recipe of sorts and choose “ingredients”.
Configuration of integrations and using the simple trigger/condition/action (service) layout was a breeze.
YAML was used for configuration markup. And it excelled at it.
It did take a bit longer to get the hang of jinja.
The use of automation/script YAML has evolved since then and the syntax now includes loops and branching instructions and I can see how some find that unusual for a markup language. But having been along for the ride learning as it was introduced I have no problem with it.
Has HA outgrown YAML’s usefulness?
I don’t think so (my opinion).
Sure the graphical editors have an even easier entry point for new users and I think that’s great (no rocket science degree required) but YAML can still be used effectively to supply options for some integrations (including automations) and is a lot easier than learning JavaScript or Python.
Andreas spiess made a good comparison between ESP-Home and the alternative in a recent video.
It summarizes both ESP-Home and any yaml configuration in HA in my opinion.
I’m going to suggest an alternative to the “YAML vs whatever” approach to the new user problem and instead offer another idea. I think the answer is not to change anything about the way Home Assistant is constructed but instead to just prioritize some new user friendly features.
Home Assistant is often compared to a box of lego blocks that let you can easily put together to create useful automations but new users feel the Visual Editor is missing some of the really basic blocks that they are used to using on other platforms.
So what if the Home Assistant team simply set aside some resources to review and update basic GUI functionality. This might involve looking at other popular platforms such as Homekit, Hubitat, Homeseer, Universal Devices Eisy, etc. just to see what features they offer in their GUI interface. These companies would not waste resources providing features that nobody wants so there is a good argument that if it exists in these systems that it would be welcome in Home Assistant.
Once there is parity between the Home Assistant graphical editor and all of the core tools offered on most other systems then it is more than fair to ask users to invest time in learning YAML for more advanced stuff.
Another approach would be to review the features offered within dashboards that are not exposed in the graphical editor for use in automations and notifications. The dashboards are great but helpers and features that can only be leveraged to display things in dashboards are bit frustrating if you need that functionality for something else.
Just to add to the mix, there is the ability to use python to create automations. People who want a “proper” programming language can use it. AppDaemon and pyscript come to mind.
That is good to hear. I hope they expand on the ways they engage with users beyond the annual survey. It sounds like this entire WTH should be brought to their attention.
Interesting. I never thought about it, but the complaints about how Home Assistant works from new users could mean that what long-time users consider optional (that may not be the right way to put it) are actually things that are considered essential parts of the user experience because that how other systems do it.
If the automations/logic are created in the UI, it doesn’t matter what the storage format is. I’d almost suggest JSON or YAML because from a machine perspective it is perfectly reasonable to store configuration.
From a user perspective, YAML is an insane way to create programs leading to much confusion.
YAML is a perfectly good way to define a configuration (ie. configuration.yaml). That’s what is designed to do.
It is a terrible way to create a program (automations.yaml) because it was never designed to be used that way. It is completely counterintuitive for the purpose.
I would probably say “low priority” rather than optional. But yes, there is frustration because things new users consider “basic” and “essential” are not available in the graphical interface and do not seem to be on any roadmap to add.
On the other hand there are a lot of advanced things in Home Assistant that other systems cannot do easily if at all, but are of no interest to new users. For example: Home Assistant Geeks seem to be obsessed with charting things and there are tons of tools for doing some very advanced charting. I can almost picture an advanced Home Assistant user proudly showing visiting friends the detailed chart they made of temperature fluctuations within their refrigerator… only to wonder later why those friends don’t drop around much anymore.
I’m curious what you’re talking about that’s not on the roadmap?
Most of your comments have been about automations, which is currently on the roadmap, and there will likely be sweeping changes this year. (Additional ways to automate on top of the current method)
Most of the things I have in mind are ones that I have already mentioned either here or in other WTHs but it would not be a bad idea if there was a place (and maybe there is?) where a list is kept of “things people want to see moved into or added to the graphical interface” (as opposed to features they just want added to Home Assistant generally).
I already mentioned the ability to insert entity states or values in TTS message fields without dropping out of the Visual Editor into YAML.
Another one used often on other platforms is a simple time accumulation helper with output formatted for easy use in TTS or other notifications. This is just a timer that counts up from zero and makes its current value available in 00:00:00 (rather than total seconds or whatever is used for charting things) and is started, paused, or reset from within automations.This one has been requested going back to the last WTH but it immediately gets shut down because it gets confused with things like History Stats, (which is linked to a specific entity instead of controlled in automations, requires a defined time period instead of just accumulating time, and dumps its output as a single integer of total seconds OR minutes OR hours but not in a good 00:00:00 format for use in notifications).
I guess you are right that all my comments are about automations because that is kind of what an automation platform is, so what else would they be about? I’m suggesting where I see challenges that new users who come to the platform are facing to get their devices to do basic things using the graphical interface before moving on to more advanced areas where they should expect some knowledge of YAML will be required.
Sure, YAML/JSON is the storage method, and it is ideally created through a UI which a user can use much more easily. I think that is the end goal for most purposes, but it is nice to have YAML to be able to do things not yet supported in the UI or which are easier in YAML, like mass renaming.
It is unintuitive if you view automations as a purely open system that can contain any possible programming logic, but if you are just composing different available predefined actions and conditions it is probably the best solution. It can be created via a UI (or even LLM agents) and you can much more easily test that everything works as expected.
Again, it’s not perfect, but from my experience it’s the best solution for these kind of use cases. I’d love to hear about alternatives as I have to create and maintain similar systems professionally and there are definitely pain points with YAML.
everything that is at the same indentation level belongs to the same key:value dictionary, list or list of dictionaries.
there is no way that can be harder than learning a full blown programing language.
I find it way easier than using the UI because of all the point-click-drop-down-click-type-repeat tedium involved in the UI.
It’s OK for configuring one-off integrations/devices but further than that it’s mind numbing.
and I dare anyone to try to share how to set up even a mildly complex automation via the UI.
There’s a reason why literally every single time anyone asks for help troubleshooting an automation (even if they’ve created it via the UI because that’s not fool-proof either) that they always get told to post it in properly formatted yaml.
NO ONE wants to try to look at a screen shot of an automation created in the UI. Let alone trying to correct an automation that was created via the UI. yaml is hands down easier to read and skim thru to find errors in logic than even a fairly basic screenshot of a UI created automation.
Even if it’s an easy fix then it takes more words to describe what is needed in the UI than to fix it easily in yaml or you need to open your own UI editor in HA, create the automation (clickety-clickety) then edit to fix the error (clickety-clickety) then paste another screenshot of the fixed automation back and hope the original user can figure out how to re-create it in their system (clickety-clickety).
or you can easily and quickly copy/paste/edit/post the yaml.
But again the point that everyone seems to be missing in all of this is that…
…we have options…
if you like the UI then there it is
if you like python then use pyscript
if you like JSON you’re in luck so just use it.
if you like that which shall not be named then use that
if you find the clickety clickety click of the UI tedious like me or you’ve outgrown the UI and reached it’s limitations then use yaml/jinja (EFP)
Yaml is not admittedly not a programming language as such. It is for storing configuration settings.
I tend to think of it this way:
Don’t be afraid of indentation. You downloaded a python program (home assistant). Python is indentation based. Don’t be surprised if yaml is there too.
Yaml and json are interchangeable, except json hates comments, so the comments are destroyed when you shift between the ui and pain text. Don’t be surprised to find json all over the place, like in .storage
HA has a programming interface.
The settings for that programming interface are stored in yaml. (Could equally be json, use an online converter if the reality of json cf yaml offend you, or vice versa.)
Jinja is also closely aligned with python. Again, you are working with python, don’t be surprised if Jinja rears its head.
If you think the programming interface of HA is inadequate, or you can’t be bothered learning the paradigm, use python, or node red, or whatever.
Get over it (whatever “it” is pissing you off) or do better.
I don’t think the disagreement is so much if people should learn YAML but rather at what point it should be required to do so.
Folks keep saying you can use the UI if you want to but the whole point is that there are too many things that force you out of the UI and into YAML. The request is just to fill in the UI gaps a little more.
I don’t really follow the argument that it is easier to read or find logic errors in YAML vs an automation listing presented in the UI. I have been using point and click UI logic systems going all the way back to my JDS Stargate from the 1980s and it is much easier for me to follow a listing of nested IF-Then-Else logic than to parse through a page of syntax laden special characters in a markup language. If this is truly a challenge in the Home Assistant UI then maybe the UI formatting just needs a refresh?
I don’t think it is helpful to characterize people who are struggling and looking for more functionality to be moved into the UI as somehow lazy or “pissed off”. WTH month is an opportunity to talk about what folks would like to see. Even if you don’t agree with their point of view there is no point in criticizing them for asking.
It’s much easier for me to read yaml, which is why I’ll always want it.
The UI itself needs work. There needs to be a universal method that allows users to change any field that accepts templates to swap to a template.
All the options available in yaml should also be available in the UI. I constantly see decisions being made to exclude functionality from the UI under the guise of “it will make the UI complicated”, when we really just need to make it easy to use instead of another dropdown. Many of these one-off oddball parameters could easily be hidden in expandable menues or inside 3 dot menus.