Ironically, I was keenly aware of that behavior with the Lovelace editor but foolishly unaware of it with Automation Editor.
I’m using this:
lovelace:
mode: yaml
which effectively blocks usage of ‘Configure UI’.
If maintaining comments is deemed to be onerous then there is even a simpler way to avoid silently purging them.
The Automation Editor already sifts through the automations file so detecting the presence of existing comments is trivial. Simply warn the user that saving the new automation will involve some loss of data:
WARNING
Your automations file contains comments.
All comments will be deleted.
Do you wish to continue?
Yes No
I’d rather click No and lose the newly created automation than lose all annotations.
Even the Vogons provided a two-minute warning …
1 Like
Oh yeah, I totally agree. I’m just explaining as a developer why something was done. I have a feeling that the automation editor will be revamped down the road. To a point where they don’t even show up in yaml, and yaml will be used for the complicated stuff.
1 Like
Petro,
We’re not blaming you, and your “playing the devil’s advocate” is appreciated to put the whole discussion in context.
But to continue Taras’s Douglas Adams quotes : -
“You’ll be first up against the wall when the revolution comes” ; - }
And that’s one reason why I don’t use that one either. 
1 Like
Just to clear some bits out. I’m that guy who was helped by Mutt and TinyDoT to get my lights on when you open my gate after 00:00 and with an extra rule for sunset.
Let me go back to the start with my first automation part trough the UI and for turning lights on and of perfect. Just two or so rules fine. But after that I went into the deep with TinyDoT to make the extra parts for dimming the lights etc and finally the gate part. At nice and tidy trough the tekst writer I already where using.
After posting my complete yaml file Mutt was and still is thinking I thought the only way of getting automation in was trough the automation editor. I have tried to explain several times this was not the case and the programmed by the manager was the old part I still had to clean up.
@Mutt The yaml file is now clean in a way I like it and programmed trough a tekst editor
Did you also know when you have written your automation.yaml file trough the tekst editor and you open once the file in the automation editor it will also add ID numbers. So no editor for me.
Cheers
I’m really split here.
I think to have undertaken an automation editor in the first place that (for some people) produces working code, is an awesome accomplishment. It is a touch flawed, as this discussion here proves. But the concept clearly is to allow newbies (I was one not so long ago and from the daft things I still do, some might say I still am, especially when compared to you guys) to write some simple automations.
Since the introduction of packages, I think the game has changed significantly.
Here is the radical contentious bit !
I think that a default installation should be to run ONLY with packages with a default folder to store such.
There can be a “backward compatibility mode” to allow some to stay either monolithic or with sensor/input_boolean/automation/script etc. files. Whilst allowing them to migrate if they so wish.
But if we can move towards a common, flexible format, it will be easier to manage, easier to help newbies, easier to share code, adapt code understand code etc.
The automation editor, will ask if you want to start a new file or work on an existing. On save, will issue a “warning, this will erase all comments, click ‘Save’ to continue, your current file will be backed up to : - *.bak001” etc. “Click ‘Temp’ to save as a work in progress”. Click Cancel to cancel.
This will cause a proliferation of files, both yaml and backups - that’s just down to the user to merge/purge/manage.
There should also be a straight editor, so it’s built in, we’d all be familiar with it even if we personally use something else. This would also ease helping newbies, get them used to the environment AND give everybody a means of adapting something if they were out/not at their workstation.
I’m hoping that either someone has a better idea or reasons why the above won’t work.
Let the fighting commence ; - )
(credit for ideas stolen from the posts above, to the respective contributors)
Better still, it’s the same editor, but you change its mode from ‘simple edit’ to ‘create entities’ or ‘script’ or ‘automation’ whatever. Big header saying “current mode”
I’m not sure that I understand your definition of “packages”. How are you using them now and how do you expect them to work after your proposed change?
Exactly the same.
You can put pretty much anything in a package.
A default folder allows (given samba they can use /config as a base) all new installations to look in /config/packages (or whatever) it’s recursive and you can implement folders to organise your stuff (how is this different from what most people are doing right now ?)
This is just to make the devs (I read this morning (can’t remember the thread but I think one of the people was JRanier or similar (don’t think it was jramer though)) about how devevelopment is being directed towards newbies at the expense of more seasoned members) … make the devs aware of the issues being faced by newbies (I think the are, but of the levels of frustration and time being consumed just covering the basics) and possibly if they continue their work on a editor, they can continue that development, allow a transition for newbies, a transition for people not on packages and business as usual for progressive mid to high level users (should have insulted everyone there : - ))) didn’t mean to but you get the idea).
The file structure could be moddified to include ALL areas of a file zones, groups, binary sensors, automations etc. etc. Just blank underneath each : -
input_boolean:
input_number:
automation:
zone:
etc.
If you went to the editor, it could ask if you want a new file or existing.
You have modes at the top (bottom, side whatever)
I ask for input boolean, it goes to that section and says, “create” (& “or edit” if an input boolean exists)
asks for an id, a friendly name, initial state, icon, ok and bingo in it goes,
An automation, the same (but more complex obviously)
The point is that everyone will have the same file formats as they are all working to:
homeassistant:
packages: !include_dir_named packages
or whatever they go with
but the point is less problems having to sort out dictionaries or is it lists or maybe named or …
support would be so much easier if you can say, “show me what you’ve got” - “and what’s it doing wrong ?” - “ah ! what you need is this”, “use your editor in raw mode and paste this over the offending automation” or even “here’s your whole package back, backup you current and replace it with this”
I don’t expect this to be bullet proof but it allows people to do what they want, but guides newbies into best practice (whatever that may be), then the rest of us to find our own spot in that landscape.
I’m already there as I’m a package evangelist, it took me 3 years to get here, and I wish I had been forced down this route from the get go. (I know they weren’t available then).
The ability to reuse code, or copy and adapt is fantastic.
My $0.02 anyway ; - (
Mutt
P.S. (semi-related) I just read your post on a thread about re-naming entities after z-wave inclusion, I see where you were coming from. but now I have entity naming notes, and I just cut and paste from the notes and it takes less than 2 mins a node, (plus another 2 mins when the interval/previous reading sensors pop up a month later) but it’s easy, fairly painless, fairly obvious and most importantly common to all users. (What do you think of it now ?)
I use packages as well for times when it logically makes sense to use them. As when there are several components working together towards a common goal and it would be more difficult to maintain if all of those components were spread over several different files.
So, using that conditional use of packages and the current ability to split up the config into directories/files as a starting point I’m not sure that forcing everything into different packages is a solution. I think it just gives a similar functionality to what we have now but it takes away the “logic” and usefulness of using packages as they were intended. And you would potentially end up with a ton of package files in which there is a bunch of “dead” entries that aren’t used that you would need to wade through later to find what you actually want to see (how many “input_datetime:” or “zone:” sections would ever be used?).
I can agree, tho, that an editor of some kind could be set up to leverage the !include directive and force all edits into an included directory/file in the proper proper domain. And that may make it easier for new people to get a grasp on how the config is structured in HA.
However, as of right now, unless i’m mistaken, the GUI editors aren’t supposed to edit any yaml files in the config directory. They are only supposed to edit files in the .storage section. (But I think the automation editor edits config yaml files so I don’t think that is a hard and fast rule. 
)
So if the trend continues to keep the editors files in .storage, and we aren’t supposed to be entering those areas and editing things or copying/pasting in those files then I’m not sure how a GUI editor for everything would be feasible.
That’s not even considering that some of the files in .storage aren’t stored as yaml or that there is currently no way to preserve formatting and/or comments. That would then make this kind of system definitely fall under the idea of sacrificing the desires of experienced users in an attempt to make it easier for new people.
Something like that could be done I guess but not without completely redesigning/changing how things are currently set up.
That’s what I had assumed and that’s why I blindly used it … resulting in the following (painful) discovery:
I can confirm that it definitely uses a YAML file (whichever one is designated to store automations). You could’ve blown me over with a feather when I opened my automations YAML file to discover it contained a fraction of its original content.
I’d like to think I said something like:
“Oh, I see. It doesn’t use a .storage file.”
but in reality it was just one short word of Germanic origin.
1 Like
Hmmm! Of germanic origin … Can’t think of a word that it ‘might’ rhyme with but does it begin with “sch”…
Must be school, cos that’s what you called the thread. 
I have been routing round since this and found a thread where @flamingm0e was becoming irate with someone as they kept complaining about having to get an editor (Atom in this case) and he pointed out that CONFIGURATOR was an option straight in front of them.
Its been in front of me for god knows how long but I only discovered it last night (talk about being blind).
First, I don’t think my idea, or any idea for that matter, is a final solution, it hasn’t been kicked around long enough and all the negative sides explored. Or alternatives considered.
But not sure how this would impede advanced users as they would have the option of turning off ‘recommended settings’ or whatever (doesn’t matter as this would just affect the editor and you probably wouldn’t be using that anyway.
Besides, I’m sure the devs have a plan, and my chances of affecting that are slim to none. 
nah, it’s all good 
configurator, atom, vs-code and the like are text editors not gui editors. No different really from ssh’ing in and using a decent commandline editor.
But the subject of this thread is the gui editor.
Nick, technically it’s the automation editor, but Taras’s objection was to the way it behaved. But the editor is part of a suite that is growing and will (in my opinion) cover them all.
Looks like comments,descriptions are coming to the automation editor possibly.
https://github.com/home-assistant/home-assistant-polymer/pull/3723
1 Like
Quite the coincidence, nevertheless, it’s a welcome improvement.
I’m curious to know how it will handle a file containing 100+ contiguous lines of comments. Displaying that in the GUI may be awkward. The examples shown suggest the comment is understood to be associated with a specific automation. In my case, the many lines of comments were not part of any automation (they were automations that had been commented out).
Whenever this new feature sees daylight, I’ll test it (now that I have backups of my automation file).
you haven’t mentioned either way but from your posts I assume you don’t split your config up using !includes?
Not that it solves the original problem (but that may possibly be solved soon anyway) but it would be one possible fix to save all of your commented automations while still being able to edit your usual automations via the automations editor.
The only thing I’m not sure of is if the automation editor would be able to use an automation.yaml file that is buried under a different directory and not at the default location in the root of your config directory. I kind of assume that it won’t tho (and to me that’s another problem with all of the editors in that they all create one huge monolithic file that will eventually become unreadable even if it is well commented).
But, and I can’t find it in the docs right now, I think there is a way to use “automations.yaml” for the editor and an “automation_old.yaml” for non-editor manipulated automations. So it might also work with using !includes, as well.
Thank you for the suggestion and this may indeed be a possible solution but, quite honestly, I do not intend to use the Automation Editor. For my purposes, it offers no compelling advantages over VS Code (with the Home Assistant plug-in).
The only reason I got into this mess was because I intended to help someone and needed to confirm that the id option was automatically created by the Automation Editor (and only used by it as well). I confirmed what I already knew about id and also learned that the Automation Editor is a very effective tool for purging all existing comments. I can joke about it now only because I was able to recover the data.
FWIW, my production system has only 5 simple automations. That’s because all my home automation logic still resides on a completely separate, and different, home automation system (Premise).
In contrast, my test system contains 153 automations and all are commented out. These are automations I created for other users (while assisting them here on the forum). Once I’m done with an automation, I comment it out and may refer to it later to help answer someone else’s question. This simple system served me well for many months, up until the moment I tried the Comment Eraser …