For this reason I have the old P1 DSMR integration still running (in error), I renamed the old entity’s to HISTORY etc. If I knew upfront how I should migrate to another integration without losing my history I would have. Now I have months of new history in the new integration (Slimmelezer+) so can’t do petro’s suggestion anymore.
1 Like
I just experienced this for the first time today. Luckily I was in an experimental stage so I only lost two days of data.
I don’t remember getting any warning so it would be nice if HA at least did that. I would have been a little annoyed if I lost a years worth of data.
Just to check; so the historical data will never be purged from the long term stats database?
Then second question: would it be possible to rename the old sensor to the name of the new sensor so that the two get merged (of course it will need some manual cleaning to remove duplicates)?
1 Like
would also love to know this “Then second question: would it be possible to rename the old sensor to the name of the new sensor so that the two get merged (of course it will need some manual cleaning to remove duplicates)?”
This! When the Fronius integration was upgraded I lost my previous solar data due to the entity name changing.
Sort of off topic… is it possible / can someone point me to the steps to import data into long term please? 
i.e. Is there a way to rename the old entity_id from a db backup, to match the new entity and then merge it with the current data. (At the time I tried a MariaDB export / entity_id rename / import - but it didn’t work.)
Just change the name of your new entity to your old entity. Otherwise what you’re doing is no easy feat and I doubt anyone would be willing to write a guide to adjust the database. It would cause all sorts of issues if you screwed something up.
1 Like
Tried that, but get ‘Entity with this ID is already registered’ so can’t rename it. Any other suggestions please?
So based on your suggestion and the error, the data from the old entity must still be in the statistics table - why wouldn’t it display it then?
old: sensor.energy_total_fronius_power_flow_0_http_192_168_1_25
new: sensor.energy_total_fronius_inverter_1_http_192_168_1_25
Rename or delet the old one first
Looks like again WTH when I rename an entity, most of the time it's history is lost? - #3 by Gonioul
Hi
realistic scenario:
I’m using HA mainly for energy monitoring and history data interests. For that purpose I’m using around 25 Shelly devices.
Now I started to migrate the firmware of these devices to Tasmota because of builtin Alexa emulation and because their App is utter garbage but I want to keep historical data in HA.
So basically I’d like to be able to delete the old Shelly instances of the devices but still be able to keep and display historical data.
For me, it would be absolutely sufficient to simply keep the old entities’ data and having the “new” Tasmota devices as new entities as I understand that merging data points could be very complicated, especially with the huge variety of devices available on the market.
Currently, I have just disabled the old device instances in the Shelly integration and everything seems to work so far. Although, I think that the now not anymore reporting devices will keep being displayed in the Energy Dashboard for all eternity of time, although they will always show 0 kWh.
Hi, and thank you for your time.
Two questions:
-
What about the unique_id? Do I also have to rename the unique_id of the new entity to match the old one’s?
-
Does the numerical state value of the new entity have to be the same the old one’s?
I ask the second question because I understand the energy dashboard calculates differences of values. So if the old entity was e.g. 1200 kWh and the new entity 10 kWh, it would mean a diminution of 1190 kWh, which makes no sense. Hoe would HA deal with that?
You can’t modify the unique_id, even in yaml you’re not modifying the whole unique_id as the integration appends information to it to keep it truely unique.
Not sure how “that makes no sense”. Things drop in kWh all the time. If your sensor is total increasing, then that would be different. And no, HA does not handle situations like that.
Thank you for your reply.
So, whe I want to replace a sensor for imported from grid energy in the dashbord, I only need to change the entity_id of the new sensor to match the old one’s ?
I must admit that the unique_id is quite enigmatic to me.
I use to always declare a unique_id when I create a sensor in yaml in order to be able to edit the sensor through the UI. When I delete this ensor by erasing the line in yaml and restart HA, does the unique_id survive anywhere in HA’s entrails?
I thought that the sensors used for grid energy imported/exported had to be total_increasing.
I am sorry for all these stupid questions but I have just completely screwed the communication between my HA instance (Synology VMM) and my database (MariaDB packet on Synology) by trying to change the sensor of grid imported energy. I have now restored backups and finally “only” lost 2 days of statistics. So I am now VERY careful and I want to be sure not to make the same mistakes.
Actually yes, it does. If a total_increasing sensor value decreases, then this is handled as a new meter cycle or a meter replacement. The deltas are calculated to make up for the difference.
So this scenario here:
is handled fine (as long as we’re talking about using the same entity_id for both the old and new meter). if the last total increasing value from the old meter was 1200 kWh and the first value from the new meter is 10 kWh, then this would be interpreted as 1210 kWh internally on the sum. See the developer docs here for more info, specifically the last example.
right but the display on the sensor itself on HA will not reflect that, only the LTS
Are you sure about this ? While I haven’t used the builtin energy graphs much (I use my own card for this), I don’t recall any anomalies with reset or decreasing total_increasing values. They seemed to be displayed as expected. If not, then this is a bug in the code displaying it.
Of course this will not show when displaying the raw unprocessed total_increasing data in a simple history line graph, as these don’t display the sum. But that’s not typically the way you would display energy data anyway.
Yes, for anything database related, you only need to change the entity_id as all the database information is tied to the entity_id.
That’s all it’s for.
Yes, in the config entry, you need to delete it in the UI and from yaml if you supplied a unique_id via yaml.
There’s multiple state_classes that work for LTS, it depends on how your sensor behaves. If your sensor itself just outputs kWh then you’d use measurement. If it outputs a total increasing value, then you’d use total_increasing.
Maybe you’re miss understanding how it behaves, maybe we are talking about 2 different things? The state_class drives how HA interprets the data in the energy tab & statistics. It does not alter what is displayed on the source sensor.
1 Like
I thought we were talking about the energy tab ? That’s what @protobock was referring to in this posts above.
Yeah, I edited my post above for clarity while you were replying.
I had it in my head that he was referencing the source sensors state
Ah well. At least the options he has and the resulting behavior after a meter change are cleared up now.
1 Like