Like many I was super excited to see that HA was finally getting a way to manage automations via the web interface. This I felt was going to be an extremely welcome change and allow for much more on the fly development of my home automation system, but honestly I feel it falls short in such fundamental ways that I am concerned about its direction in the future.
First, enabling this new config means pooling all your automations into a single file, that means that all the work done with splitting config, and creating packages for your config is completely trashed if you have any desire to use this new web UI. That alone is insanely frustrating for those of us who have spent a great deal of time trying to keep our config clean and organized. Especially when the current iteration of the web UI doesn’t provide a way of organizing automations in any way. It is just a big long messy list.
This lack of organization is one of the fundamental things that I feel makes it really hard to develop robust and reliable automations for HA. To me, it seems that we have a strong platform that can connect to a huge number of devices, but HA falls short on helping users build complex home automation.
It is my personal belief and I think others here would agree that home automation isn’t easy. There are numerous variables that are required to make an educated decision on what should happen when things occur. Just think about developing an automation that would control a sprinkler system. For it to be robust, I would hope that it could understand if it had rained recently, and as such adjust the time it will run accordingly to keep the ground at the right moisture level, but just think how complex that automation would be for HA. You’d need conditions and templates galore, just to massage the data into a format that would be useful for the triggers.
These are the two major reasons why I feel the automation UI is the wrong direction. It, yet again, leaves the user in a disorganized space and doesn’t provide any method for crowd sourcing the development of automations like we already have for components. (Another issue I’ve discussed here: Packages as a distributable automation template)
So ultimately I find it bizarre that we’ve taken a system of organizing yaml code and cannibalized it into this decipherable large automations.yaml file if you have any intention of using the web ui.
So I’ll leave this here for others to comment on, and say that my opinion is that HA needs a way to share and distribute automaton code, so that new users can have complex automations with very little knowledge of the underlying infrastructure just as users now do not need to know anything about how the component is actually talking to the device/service they want to interact with.
You don’t have to use the web editor for automations, you can very much keep it split up into a bunch of different files and edit it all by hand.
Home-Assistant is still version 0.x, the release notes even mention that this web automation editor is a work in progress. It’s definitely not feature complete.
If you’re concerned with sharing automation code, you can still copy and paste it out of the .yaml file. If it becomes a major issue (which I doubt), then I’m sure someone will submit a PR for an import/export option.
The entire idea behind the web configuration UI’s is to make it so 90% of people never have to touch the underlying yaml files. Sure, it will be a little more limited, but it will work fine for most, and those that need the advanced features should be savvy enough to write them yaml themselves.
I, for one, am incredibly excited to see resources working on graphical/web editors for configuring the system, and hope this process continues.
Let me be clear, I do not necessarily think that making a web front end is bad. I argue that the method in which the front end is proceeding in conjunction with the YAML configuration is what is wrong.
My main point still stands, if we had a platform for sharing generic automation code, then the process of adding those “packages” could be streamlined and your the 90% as you say they could just click, and have a fully functioning automation with very little workflow.
It isn’t that I want to see a web config go away, it is that for HA to stand apart, and to provide an easy user experience, it isn’t moving all the things the current YAML stuff can do into the web front end that I think will ultimately make HA better.
I agree with you both. I also like having a “quick and easy” way of adding simple automations, like timers or similar.
However, I have also some packages for some more complex timers and radio controls. These packages are great to have these individual “encapsulated” packages, which help a lot to keep the configuration.yaml a bit cleaner. (While the encapsulation is to some extend violated, due to the groups, but I can live with that).
While the automations of the packages are initially loaded correctly at first start and even shown in the web interface, after I change an automation rule, all package automations are gone. So apparently, the reloading only looks at the automations.yaml.
As a solution, would it be possible to have a automations_static section, which behaves as the previous automation rules and can be merged using the packages?
It should also not be shown in the webinterface I guess.
I tried using “automation old” in the packages, which does not work.
The editor underlines a different problem: automations.yaml is badly documented right now and confusing. This is made worse when you think “Hey, I’ll use the editor to create it for me so I can see what it’s supposed to actually look like” and the editor populates it with bad data…