Strange, do you use the UI to create automations or YAML?
I use YAML (and I have over 200)
Maybe there is a rogue one left some where? I am not that familiar with YAM automations as I use the UI. Maybe it is named something else and therefor it is not obvious what automation it is? 
In developer tools, click on the i in the circle next to the entity id.
Click the cog icon in the card that pops up. You have the option to delete or disable the entity there.
I don’t but in any case it doesn’t resolve the issue as to where this automation comes from.
In that case it is either defined in YAML or you have a corrupt .storage registry entry.
OK, thanks. I’m getting somewhere…
I have found this in core.restore_state.
What does it mean?
Where did it come from?
How can I fix it?
Can I simply delete the entry and things will sort themselves out?
{
"state": {
"entity_id": "automation.automation_27",
"state": "on",
"attributes": {
"last_triggered": "2021-10-01T23:00:00.033896+00:00",
"mode": "single",
"current": 0,
"friendly_name": "automation 27"
},
"last_changed": "2021-10-02T07:32:59.032760+00:00",
"last_updated": "2021-10-02T07:32:59.032760+00:00",
"context": {
"id": "e354ebbd51c9c863480c1419691e71de",
"parent_id": null,
"user_id": null
}
},
"last_seen": "2021-10-02T07:33:23.579873+00:00"
},
Make a backup, delete, restart HA and see if it works.
Yeah but with over 200 automations it might be hard to know if everything is working until I realise something isn’t!
If that is a restored version you might be able to delete it from the Configuration / Entities list. You may have to turn the filters off (top right) to see it.
It was used recently:
"last_triggered": "2021-10-01T23:00:00.033896+00:00",
What do you have with time triggers for 11pm?
Yes I thought of that…
But do you know what core.restore_state is?
It looks like some kind of saved state. Could I just remove all my packages, restart and then re-instate them all?
I’m not 100% sure why it is used but it stores deleted entities.
E.g. if I delete one of my YAML automations that has an id I have to restart then go to the unfiltered Configuration / Entities list and find the deleted automation there and remove it as well.
Hhhmmm…
I can’t delete it there because it doesn’t have a unique ID.
I’m still not sure how to get around this. Even if I look for all automations that are triggered at 00:00:00 (or 23:00:00) what then?
Ok,
I’ve been through all my automations and added an id to every one that didn’t have one. I’m not sure why I thought that might help but suffice to say it didn’t.
I then tried to add an id to automation_27 in core.restore_state but after a restart the id had been removed and I was back where I started.
It is a bit troubling that I have an automation that I can’t identify that is clearly being triggered (more than once1) and which I have no control over and have no idea what it is doing. I’m not suggesting this is anything nefarious but it does raise some questions.
At the very least about my ability to control my own config.
I actually think this is quite a serious question.
I have no idea where to raise it so that someone will listen (and quite possibly give a perfectly reasonable answer).
1 It may just be as you say a corruption and automation_27 is somehow a duplicate of an existing automation which would render it annoying but benign. However, what if I change the original to not be a mode of single?
Or worse still I change it to have different functionality, or remove it completely. It would still run under the guise of automation_27.
Like I said I think this is a serious issue.
You did that instead of what francisp suggested?
Kind of.
After what tom_l said I decided to look for some less nuclear options.
And then I realised that actually this might be an issue with quite serious implications (it might not but…) so I posted the above.
After posting above I went for what francisp suggested.
No change. I still have automation_27.
I don’t know if you have packages, but if you do, check them too.
I use packages exclusively.
What do you mean when you say to check them too?
I’ve found it.
I had an automation with no alias or id.
Stupid error on my part but I think this might be something worth catching in the config check?
Thanks for all the input.
I wouldn’t have found it without your suggestions.
For what it’s worth this was the giveaway (but I honestly don’t think it was there before I was messing with the storage file, I’m 99.9% certain I had no history information on that tab)
I still have it in core.restore_state despite manually deleting the entry before restart, which implies that the storage files are likely to grow forever rather like the Windows registry.