Rename entity ids and retain statistics

[herrfelix]

How can I rename entity IDs without losing historical statistics?
When i change the ID, all the statistics of this sensor are gone. I can undo the name change and the statistics are back. But i need another ID name.

[tom_l]

At the moment there is no way to do this (without some serious database manipulation). LTS are tied to the entity_id.

[AngellusMortis]

That is not correct. It was actually added in a recent release (cannot remember the one). If you rename an entity, as long as the destination entity ID does not have statistics they will be transfered. You can use the statistics tab on the dev tools to delete existing statistics for missing entity IDs before renaming.

I recently had to do a bunch of thing since I got a new home energy monitoring system. Just make sure you are at least 2024.3.1 otherwise, you could accidently corrupt your recorder database.

[tom_l]

@AngellusMortis

as long as the destination entity ID does not have statistics they will be transfered

I certainly did not know that. Thanks for the info.

I did a test on an entity I don’t particularly care about the history of, making sure to use a a never before used entity_id and it did appear to work.

Maybe that’s why this isn’t working then:

@herrfelix

When i change the ID, all the statistics of this sensor are gone.

Shame it is no use for actually replacing a device/entity, as that will have existing LTS and states that need to be kept, and this is the most common use case encountered on the form.

[DvdNwk]

@tom_l

Shame it is no use for actually replacing a device/entity

I don’t care that much about statistics (yet), so I do it for different reasons, but it could help here as well:
<< pointers / aliases / delegation >>.

What I mean: create a template sensor that is “purpose type” (like sensor.kitchen_thermometer). Point it at the real sensor (like sensor.sonoff_thermometer_number_13).

When you change the real thermometer (because it broke, or you moved it, or whatev) → you just change the definition of template sensor.

I’m certain you personally know you can do that, but I’m mentioning it for others.

Plus, it is kinda cumberstone to do right now → manually creating template sensors for each and every entity you wanna have a proper separation of concerns… Well, I hope I can fix that in the future :>

[PeteRage]

There are two ways that stuff can be linked via and entity id or via a guid. In the prior database schema entity id was the key; now there is a lookup table from entity_id to ID (int) and the ID is used as the key for the data. Note, this ID is not the unique_id of the entity from the registry. It a self incrementing integer identifier - such that the first entity will have id 1, second 2, etc.

The problem before was renaming the entity id would cause the loss of all recorder data (well it really wasn’t lost as it’s still in the database). With the lookup table this is no longer a problem.

As far as I can tell deleting the entity id does not cause the entity to be removed from the lookup table, so if you replace a device and use the same entity id it should not create a new guid and the old data will be linked in. I have not tested; this is based on examination of the schema and recorder code.

[tom_l]

@PeteRage

As far as I can tell deleting the entity id does not cause the entity to be removed from the lookup table, so if you replace a device and use the same entity id it should not create a new guid and the old data will be linked in. I have not tested; this is based on examination of the schema and recorder code.

There’s a lot of evidence on this forum that this does not work.

[AngellusMortis]

@tom_l

Shame it is no use for actually replacing a device/entity, as that will have existing LTS and states that need to be kept, and this is the most common use case encountered on the form.

You can and that is what I did. Say you have sensor.a and sensor.b for energy monitoring. sensor.b is the new one to replace sensor.a. Since it is a straight replacement, the data should be the “same”, at least the historical (LTS) data.

To move the LTS from sensor.a to sensor_b (requires 2024.3.1 or newer):

1. Remove or disable the integration providing sensor.a, it must be providing no state. If you press e and search for the entity (or go to states under developer tools), it must not appear.
2. If you go to Developer Tools → Statistics, you should now have an error with a button to Fix the statistics because the entity has no state (DO NOT FIX as they will delete the statstics)
3. Rename sensor.b to sensor.a
4. Go back to Developer Tools → Statistics. You should no longer see an error for sensor.a, but there should be one for sensor.b. That is because the LTS for sensor.b were not moved over since there was already LTS for sensor.a.
5. “Fix” the issue for sensor.b and delete all of the LTS. This is just the LTS that has been created since you added sensor.b to the system, not all of your important historical data (still on sensor.a).
6. Rename sensor.a back to sensor.b. All of the LTS should now show up under sensor.b.
7. Anywhere that references sensor.a by entity name (Energy Dashboard) should be updated to sensor.b. It should still now show the original LTS.
8. You can now re-enable the integration providing the original sensor_a if you want to keep it and only disabled it before.

This is how I migrated my whole Energy Dashboard from IottaWatt to a SPAN Panel. I did it for nearly 20 entities, so it definitely works. I definitely recommend doing a simple backup of your recorder database before getting started in case something goes wrong or you rename the entity to the wrong thing and mess everything up.

If you do not have at least 2024.3.1, when you rename an entity to another entity ID that has LTS, it will instantly corrupt your database (not actually corrupted, just thinks its corrupted since the UPDATE failed to update the LTS). 2024.3.1 fixes that bug.

[herrfelix]

The subject seems complicated to me.
I currently have two applications:

1. Case
   I want to rename an entity ID from entities I created myself in a yaml in ESPHome. This isn’t about the GUI without losing all the statistics. This is probably just about the way @AngellusMortis described (i guess).

EDIT: Small note: The sensors I read via Modbus and an ESP32 do not appear in the developer tools under statistics at all. So I can’t compile statistics. Or I don’t understand.

2. Case
   I want to rename an entity ID that is provided by a helper. I can just do that through the GUI, the statistics will be preserved. BUT: If, for example, I have this statistics displayed in the dashboard via the mini-graph-card, then after the renaming, the only thing that comes out is bullshit.

Original statistic:

Original statistic in a mini-graph-card (grey bars):

Statistic in a mini-graph-card after the renaming (grey bars):

The result for me is that in both cases I can either rename the entities very complicated or not at all without fear of losing the statistics.

[tom_l]

@AngellusMortis

If you do not have at least 2024.3.1, when you rename an entity to another entity ID that has LTS, it will instantly corrupt your database

Ok, the reports of replacements I found not working were prior to 2024.3.1, so that was probably the issue.

Thanks for the method clarification. I’ve bookmarked it and will let others know when they ask. And they will ask.

[AngellusMortis]

It works prior to 2024.3.1, but like I said, it corrupts the database. I actually did most of the migration on 2024.2.x. I think the actual migrating of the LTS feature was added in 2023.4 or something. I could not find it from a quick search, but I think it has been there a while. You just kind of nuke the whole recorder unless the destination entity ID has no LTS already (prior to 2024.3.1).

[tom_l]

It seems this actually fails at the moment because no history or LTS are currently moved when you rename an entity, see: "New entity_id is already in use" error when renaming any entity · Issue #115747 · home-assistant/core · GitHub