Hello everyone,
this has been requested years ago, but now the clear directive is to make everything editable from the UI.
Unfortunately, many of us are trying to keep their configs clean and tidy. Huge automations.yaml and huge scripts.yaml are counter-productive.
However, UI forbids editing of automations and scripts that are stored outside these two files. The system can cleary read the files. The system clearly recognizes errors inside the files.
There is no rational reason not to allow editing in files outside scripts.yaml and automations.yaml, if the files are recognized by the UI and are executed as planned.
Please remove this restrictions to make it possible to keep a clean and tidy setup while also opening up the UI editor.
To me, having the UI edit a YAML file is the best of both worlds. What I would really hate is if the UI edited scripts and automations would disappear into files that are no longer editable by hand. The reason is that scripts get broken when entities are removed in favor of others. If that can only be fixed by opening each script in the UI then the system would truly become impossible to maintain.
Search and replace in multiple files is doable, but not really for every one eiter.
My point is: stop restricting what the UI can edit. Let us edit automations and scripts even if they are not in automations.yaml or scripts.yaml.
It is outdated to have only one yaml file for all automations. It is difficult to maintain if you want to make adjustments manually. It is difficult to add new automations that are a pain to create via the UI.
So why restrict users like this? Why not let them edit every automation or script that the system identifies? If the system sees it and can execute it, why not let us edit it via the UI?
I feel like you’re missing the point. The idea is that you use the UI editor instead of dealing with config. A user who edits their automations and scripts only via the UI doesn’t even necessarily know everything is put into one file. Or care.
If you are the type of user who cares what your config looks like then the UI editor is probably going to make you unhappy. Have you looked at the automations.yaml or scripts.yaml file it writes in a while? It’s not exactly user friendly. All comments are removed, line breaks for large templates seem almost random, there’s tons of extra fields that are just empty or repeat the default value, etc.
I will say that I do wish I could view all my automations and scripts read-only in the UI editor. It’s clearly able to read and process my config since you can see it in a trace. It would be nice if it showed the UI editor read-only when I clicked the pencil icon. But I don’t really want the UI editor modify it, then I’ll end up spending the next few hours un-uglifying it.
Hello @CentralCommand
I agree, I probably would not edit all my files there. But the basic ones without comments, I would edit.
Many of my scripts and automations have no comments (because they are so basic, I will always know what those few lines do).
And especially for debugging it would be great to quickly see the file in the UI and maybe also edit it without moving everything into automations.yaml or scripts.yaml.
AllI wanted to add is, that any changes made should not result in GUI built automations only be editable through the GUI. So no pure segregation between the two. In other situations, that is exactly what happened - manual changes are no longer possible outside the GUI once it is built in the GUI.
E.g. for groups that is the case now. A Group created as a helper in the GUI does not edit the manually greated groups and vice versa. For automations and scripts, that would be devastating. I build using the GUI most of the time, but I maintain mostly using Visual Code.
I definitely do no want any reduction of functionality. I want extension of the current functionality.
I find it a bit worrisome that more and more features are being force-moved to the UI. I appreciate more features being available, but at the moment there is a mandatory move that is counterproductive in my personal view.
I just cleaned my config files and deleted a whole bunch that will be deprecated soon.
For me the easiest was to have all my configurations (packages, notifications, automations, scripts etc.) in dedicated files in dedicated folders. I install a fresh HA and simply copy those files. Baaammm, everything works again.
Now, suddenly, MQTT is no longer allowed via yaml. Discord is no longer allowed via yaml. And others are following soon. This means, instead of spending 1 min on Copy & Paste of my perfectly maintained yaml files, I now have to use the UI and spend 10 min just to get the basics back.
again, you aren’t understanding how the UI editor works behind the scenes.
If you use the UI editor to change one automation (or script) it will then reformat the ENTIRE automations.yaml file to remove all of the comments, rearrange the automation syntax, change to ’ ’ on anything double quoted, etc.
It doesn’t just reformat the one you edited. it’s all or nothing.
That’s why there is a designated folder for UI automations & scripts.
There is not one folder, it is one file each. That’s what makes it so difficult to maintain.
And the removal of comments is a bug, not a feature. It should also be disabled.
No idea why it was programmed the way it is right now, but other editors are capable of editing files without destroying the layout and removing comments.
And even if this is not fixed, then I would still prefer to have this option. I don’t comment that much anyway. It is not really necessary for most automations, if each automation file contains only one automation
But comments are a must if you have one huge automations.yaml as created by HA. But there it is not possible. So, the current approach is a bad approach for those who want one big file (because no comments possible) and for those who want individual yaml files (those cannot be edited via UI).
Basic functions should be used from core. Otherwise we depend on community updates for every breaking change. As this is already a stock feature, I prefer not to use 80 addons to do the jobs of the stock add-ons.
It’s not a bug. It would require a separate feature request. And I believe it’s been brought up before and rejected. The idea behind the UI editor is as I said earlier, it’s for people who want to use the UI and don’t care what the config looks like. As long as it does what they told it to do in the UI.
This does sound difficult. Perhaps consider an alternative approach to config organization? No one required you organize your config this way.
I like packages personally. I basically make a package for home automation project and group everything about it in a folder then use !include_dir_named. Seems to work pretty well.
Sure I guess I could make files smaller by putting each automation, script and sensor in its own file and using !include_dir_merge_list but I would never want to do that. Then I’d have to open so many files to change things. Plus I’d have to copy and paste so much stuff instead of reusing bits of config across automations, scripts and sensors using yaml anchors.
Actually, it is perfect to have everything in separate files.
I have folders for packages, notifications, scripts, automations etc. and each filled with multiple files.
Of course if I have a battery low warning it contains all battery powered devices. So I have one file for battery low and one for battery dead. So there is some merging there also. But always as cleanly as possible.
This also allows me to remove every package or notification that has become deprecated without removing any code. Simply move the file out of the setup.
And if I want to disable something (e.g. TRVs during summer), I simple move the file out of the folder and back in when I want to enable.
Takes seconds rather than the minutes it would take via UI.
Anyway, I still think that removing the comments is a bug. Sure, the goal is to edit the files. But a smart editor would not “damage” the original file by removing comments. Comments clearly and universally are accepted as good practive amongst all people working with code. Removing it due to UI editor usage is an oversight in programming of the editor.
YAML must be parsed into objects that the code then operates on. When you parse YAML comments are ignored (as expected since they are comments). Which means they are lost in the process of parsing and then serializing back out again.
Using the UI editors means you give up control over how your config looks.
HA is built around addon’s and integrations
I understand where you are coming from, but I don’t see a UI yaml editor as “basic functionality” to HA
it certainly feels more like an addon.
if i may suggest, click the install button in hacs for config editor, it will take 2 seconds, you will have the features you are looking for, and you don’t have to waste any more of your life debating about the legitimacy of basic functions of HA on the forums.
I mean I’m not a huge fan of this fr but I don’t understand how this suggestion is relevant let alone a solution. The author is asking for the ability to use the GUI editor in more places. You’re proposing they download a card that let’s them edit their config in yaml. Not really the same thing at all.
Also for reference that card is really only relevant to users on either a core or a container type installation, a minority according to analytics. Anyone on a supervised or OS install should just get the file editor addon. Or even better the studio code server addon since then you get the vscode experience and autocompeting.
But none of these help the author. Since all involve the user editing in yaml, not via the GUI editor.
I am using VSC. The difference is, that the UI editor is much more comfortable and requires no code writing.
So if I want a simple automation, I get a nice dropdown in the UI editor which I am not getting from VSC or other editors.
I often start an automation or script from the UI, then copy the code to a yaml file and then tweak it to my liking in an editor afterwards.
But I would like to be able to add e.g. an additional trigger via the UI to an existing automation. But I am not allowed, because my automations are not stored in a crowded automations.yaml but in separate yaml files.
