If it’s a yaml automation, changing the name will cause it to lose the history. If you add an id to the automation, changing the name via the UI will carry the history w/ the name change.
This is true for all yaml entities. No unique_id, no carry over.
Well, that’s the interesting part:
automations.yaml, I can find the automation by alias, and it has an id.That’s exactly not the way it happened for me.
So why doesn’t it work? Is an id in an automations.yaml not the same as an unique_id (as e. g. used for template entities)? Something’s different here…
Then you didn’t refresh the page after changing the entity_id. It’s a browser, when you change something like that, you have to refresh.
100 %: I refreshed, even [STRG] + [F5]. I even went to the logbook and history (in new browser tabs) - and nothing there.
Ok, I don’t know then. I’m just the messenger. If you found a bug write it up.
Would you (others, feel free too) be so kind to give this a test try on your system? As renaming the automation back to the old/original one, nothing is lost.
I’m sure you’re on the latest HA release. Because that’s the first thing devs come up with when filing a new issue.
And as mentioned: no deletion of this entity as first step (because automations behave different, scripts likely too). Maybe that’s the thing?
I don’t store history of my automations, sorry. There’s no reason to IMO.
What a pity. So different a people’s views on data - I can’t imagine not having the information when which automation fired because of which trigger etc. 
So maybe @Nerdix @zollak can test this? Just rename an automation.entity and see if /logbook and /history is kept after the renaming.
If the results are the same as for me, I’ll create an issue at GitHub.
None of what you just said is tracked by history or logbook. The history for an automation is just the on/off state.
I think you’re confusing related logbook entries with the automations history.
To clarify, all of what you mentioned is stored in the automations trace.
E.g. Here’s a trace on my automation that has history disabled
Yes… and that is part of the logbook. Which is empty after renaming the automation. We’ve been there few hours ago, have we? 
Rename your automation and check if you still see these logbook entries…
… no because I’m talking about history. Which has a literal meaning in HA. It refers to the information being stored in the database, specifically in the states table. The entity_id renaming mechanism only works for that.
Related logbook entries for automations are a loose reference, unrelated to history. Unrelated to this entire thread.
History:
Logbook:
You didn’t share a screenshot of logbook for the automation. It would simply show “automation enabled” and “automation disabled” logbook entries every time you enabled or disabled the automation.
Related:
Ah I see. So what’s your summary? “Works as designed” or “still worth raising an issue” because… wouldn’t it be nice to NOT loose the related logbook entries?
You won’t lose them, they are built in the fly. You probably need to exit and enter the dialog again them to appear. Or possibly restart.
Ik did the steps:
This did not work. The logs shows:
Logger: homeassistant.components.recorder.entity_registry
Source: components/recorder/entity_registry.py:66
Integration: Recorder (documentation, issues)
First occurred: 20:03:30 (1 occurrences)
Last logged: 20:03:30
Cannot migrate history for entity_id sensor.combimagnetron_energy to sensor.combimagnetron_summation_delivered because the new entity_id is already in use.
What did I do wrong and how can I correct it?
Thanks!
I am very interested about this. Currently I am using Shelly Pro 3EM device to measure my total power consumption from three main phases, and also my solar panel production. I have those in my Home Assistant energy panel and history available from October 2022. Now I am about to get a new energy meter with P1/HAN port (and I intend to plug in HomeWizard P1 meter (Order your Wi-Fi P1 meter here - HomeWizard) and use that for energy reading in Home Assistant instead.
So, when I do the switch, I would just like to keep my old energy consumption and solar production data. As a side note, I think if Home Assistant does not yet have some sort of “reassign history to another sensor” -type of procedure, it should have, as all sorts of devices will die eventually, and people buy replacements and want that old history data in Energy panels are still working.
thank you so much for this… it helped me a lot!
I can now assure based on latest tests that this is not the case. Instead, they are actually lost. At least in terms of “not accesible from the UI anymore”, probably still part of the recorder somewhere.
In detail: All log book entries prior to renaming an automation (likely the same for scripts) are lost/not shown anymore in the /logbook. No matter what is done, even a restart changes nothing.
Is that an issue from the HA point of view (one worthy to report)?
TBH I personally fear renaming plenty of my automations and scripts now as I won’t be able to access the log book entries for those for the last 2 weeks (my recorder retention time).
Why are you renaming the entity_id? This probably is a bug because there’s really no reason to rename an entity_id for an automation.
Outside that, the logbook related entities are still built on the fly. It’s possible that the link is broken when you change the entity_id of the automation.
OK if you now really come up with the “you are holding it wrong!” point I don’t think this discussion will continue to be productive in any way
It’s an entity, no matter of which domain. I was looking for a way forward. Obviously something is broken and different for the log book. You are right, there’s a missing link.
Then write up an issue. But it’s really odd that you’re renaming automation entity_id’s. There’s almost no reason for it. The sluggified name is good enough and there’s no reason to call out an automation in any service call unless you’re doing something odd.
Renaming entities keeps the relations working for me. 
Renaming automations could potentially break something. But I still have my doubts.
When you rename entity_id’s in general, you need to clear your cache and refresh the page because the frontend is holding on to an “UI element” that no longer has a reference. Clearing the cache and refreshing the page rebuilds that after you do the entity_id change.
There are some pages where you don’t have to clear the cache and refresh the page. Like the device page displaying entities. If you wait a bit, the entities will refresh after an entity_id rename.
