School of Hard Knocks: the Automation Editor

I just learned something the hard way about the Automation Editor.

I have a test system where I experiment with configurations, automations, etc. I’ve always used the VS Code editor and not the Automation Editor.

My automations.yaml contains many, many automations that were created in the course of helping other people solve their automation issues. These many automations were commented out.

Today I used the Automation Editor to create one simple automation … and saved it. It didn’t just append the new automation to automations.yaml, it also deleted all the comments. So all of the commented out automations were deleted; dozens and dozens of automations instantly removed.

As luck would not have it, this is my test system … where I rarely do backups. So my library of handy automations is now history.

I’m still in the denial stage, believing that there may be some way to recover the original file, but my rational mind knows that it is gone. I need time to mourn the loss of all of that work … and start backing up my test system on a regular basis.

That’s the first, and last, time I use the Automation Editor …


EDIT 1

Some good news to report. I managed to recover what appears to be, at first glance, most if not all of the deleted automations.

After an Internet search for ‘recover overwritten file Ubuntu’, I ran the following command:

sudo grep -I -a -B100 -A100 'trigger' /dev/sda1 | strings | /var/tmp/my-recovered-file

which produced an enormous file (~2 GB). I opened it with VS Code and proceeded to search for remnants of my lost automations. Basically that meant looking for lines starting with the # comment character. I found a contiguous stretch of commented YAML automation code (about 1974 lines). I’m not certain it is all of the original automations file but it certainly appears to be. Either way, it’s far better than nothing.

EDIT 2

In fact, I found six instances of the original automations file’s contents. Two instances contain 1986 lines which leads me to believe I’ve recovered most of the original file. It’s going to be a good day after all …

2 Likes

Yeah, all auto generated yaml files remove comments in HA. Including lovelace.

1 Like

What I originally understood was it didn’t support the creation of comments. I now understand it will remove any existing comments. That’s downright evil.

Ideally it should take the ‘do no harm’ approach and simply ignore existing comments. Anyway, hard lesson learned with only some minor bruising inflicted.

IMVHO, this should be reported as a bug…

You mean feature request. A bug is an unintended error. From the beginning comments purposely have not been supported.

is it documented clearly in any place?

yes…

thank you :slight_smile:

Yeah !
I’ve been bleating on to people about doing backups for decades (well 2 anyway … hey it counts as plural).
And (as I posted on the forum) not long ago, I ‘cleaned up’ some disk space and deleted ALL my old config (not all of which I had migrated to Hassio and lovelace AND packages (love those) )
I was similarly gutted, and similarly I then found an alternate backup on my server.
Greatly relieved but conscious of the fact that it can happen to anyone and that having second thoughts 1/2 a second AFTER you hit the button is not soon enough.
I did read a thread about a guy who automated his backups, automated his backups of his backups, and even managed to automate the pruning of his backups. He also did it to his google drive rather than github.
I must dig that out.

You could argue that comments do no harm other than file bloat.
So it should ‘at least’ be a ‘selectable’ option (default to DO NOT REMOVE COMMENTS).
Also my configuration file is 27 lines long, is 532 bytes in size, and yet consumes 1,048,576 bytes of disk space due to file system allocation.

Well, I think the real reason comments were ignored is based on how hard it would be to maintain comments and automations inside a file that changes.

Okay I accept that as its hard to know when you add stuff, where the comments go in relation to what’s there. Let alone the operations deleted and new ones added.
But it does know what is a contiguous block and so could keep them with that same block
And I’d rather have to puzzle which comment went with what bit of code, and have a clue as to what I thought was difficult enough to require a comment etc. than no clue at all.
Still as Taras says, I’ll keep clear.
It’s no real skin off my nose as it doesn’t seem to like packages.
And I simply don’t trust it.
We spent half of yesterday (though @TinyDoT stayed with it and got it working, while I went to bed) helping a guy who thought the automation manager was the only way to go and just looking at it mangle our code time after time.

Yeah, no Fan of the Automation Editor here.

Or literally any other GUI editor in HA. they all have irritating down-sides and very few, if any, up-sides

this is just one more nail in the coffin of using the editors. as if I needed any more.

Actually I was just reading the docs on this today and it says in the docs it does this.

Well that is so, but if you just look in the gui and think “oh I’ll use this automation editor, that looks cool” there is no warning.

As everyone in this thread knows, no one reads the bloody docs.

3 Likes

I fully admit to not being aware of that clearly documented detail. Nevertheless, silently destroying existing data during a purported “Save” operation must be someone’s idea of a bad joke.

The ‘do no harm’ approach would mean either ignoring existing comments (don’t display them … and don’t delete them) or creating a copy of the file (*.bkp1) before overwriting it.

I’m not defending my lack of awareness but, having had some professional experience with software design, it’s a flawed design choice to quietly delete existing data. Documenting this behavior doesn’t make it the right decision (insert reference to Vogon Contructors and Earth’s demolition here).

I split up my automations so they all have their own .yaml file. Comments allowed and editing through the Automation Editor not possible. Keeps all the automations clean.

automation: !include_dir_merge_list automations

1 Like

I feel your pain but it’s like the lovelace GUI and raw editor…

‘do no harm’ approach would be code heavy. Which is why they avoided it. Imagine editing an existing automation and you changed trigger types, going from 3 triggers to 1. You had a comment between each trigger. Where do you place the comments now that there is only 1 trigger? Also, now you gotta maintain the comments by going the ‘no comment’ approach.