WTH is it so hard to control how old entity data is treated when you rename an entity?

It’s not clear from the UI what happens when you rename an entity with historical data; it’s also not configurable. Figuring out what it’s usually going to do took a bunch of conversations on discord; I never found it in the documentation (though it could be there now).

It would be great if there was an (optional) UI element that let you configure it. When I rename an entity, sometimes it makes sense to rename the historical data (fixing spelling); sometimes it does not (repurposing a device). Similarly, sometimes when you delete an entity you want to keep the history (device replacement) and sometimes you don’t (device no longer needed).

The UI would probably be slightly more complex for renaming a device with multiple entities, but still seems possible.

Thanks!

If by “rename” you mean “change entity_id” - check here.
In short - changing “entity_id” causes a new series of data in DB.

It doesn’t do that anymore, it just updates the metadata key’s value. Each entity id has an associated metadata key, right now its just an integer. So the states table’s “label” is just an integer. There’s a separate table that stores the entity_id in relation to the metadata key. So when you update the entity_id, the relation is just updated and nothing in the history changes.

e.g.

time (below), metadata key → 24 72
2024-10-10 00:00:00 1 7
2024-10-10 01:00:00 3 4
2024-10-10 02:00:00 4 9
etc etc etc
entity_id metadata key
sensor.abc 24
sensor.xyz 72
etc etc

OK, then how you can explain this gap:
image
and another entity_id (renamed) filled DB within this gap.

This is probably how it is supposed to work, otherwise there is no need to use metadata_id as a key. But in fact i got this:
image
More description was provided here.

These are tests with 2024.12.
If it was changed - then it happened recently.

This was changed mid 2023.

And what?)
These are screenshots from DB.

The entity_id conversion was changed in 2023, that’s what I’m saying. It’s not a recent change, your history will follow your entity_id renaming using the system outlined above.

But it does not.
The history has a gap.
This gap was filled by another entity.
And there 2 different metadata_id for different entity_id (old & new).

Not sure what to tell you. This was added along time ago and it works, whatever you’re doing to rename the entity_id doesn’t allow the function to work.

If you go into the cog wheel on any entity, and adjust the entity_id, the history will follow. Full stop.

This means it’s restricted to UI created entities (or unique_id entities).

I am renaming this entity in more-info.
You have not read the link I provided, it was all described there with screenshots.

It should work, but is currently bugged. "New entity_id is already in use" error when renaming any entity · Issue #115747 · home-assistant/core · GitHub

Then there’s a bug, write it up.

EDIT: Looks like it’s already written up.

EDIT2: And just to prove to you that it was added a long time ago, march 19th 2023 Here’s the PR

1 Like

I would definitely agree that using metadata_id as a key was supposed to keep a history consistent after renaming entity_id (wrote here, by the way).
But now we have what we have. Bug or not, no idea.

Thanks for posting a link to PR.

is it retaining the history? No → bug.

Well, technically - yes, a bug)))).
But - it has some positive outcome in some cases.

Can you post a link here?

BTW, I have not seen this “New entity_id is already in use” error when testing with renaming entity_id. Saying this with confidence since I definitely checked Log.

I assumed that was the bug that was written up. I have not searched for an issue

Then maybe you are hitting yet another bug.

The bottom line is that the history transfer is not working currently. But the LTS should transfer just fine.

At least that is how it behaved the last time I checked.

1 Like

Same here, I’ve even made guides for people so that they could transfer history from 1 entity to another by abusing this system.

OK, I will try to find this issue if it is registered.
Honestly, in a normal scenario I usually rename entity_ids right after installing an integration providing these entities when there is no history accumulated yet. But this functionality should predictably work.