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.
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.
I don’t know why I was thinking about the state of the sensor after re-reading his post
Wow!
I just want to thank you so much for your inputs. You are so helpful.
I think I am now ready to switch my sensors in the energy dashboard.
Just to triple check (I do not want to make the same mistake twice 
):
Is that correct?
The energy dashboard is maybe the biggest disappointment I have had with HA by now. I changed the source sensor as I moved from the cloud reading to local reading of the data.
I can not play with the sensor names as they come from different integrations. So I either have to keep not working sensor and unnecessary integration or loose my energy data so far.
To really make the Energy dashboard something more serious this history dependency to sensors need to be addressed.
At least I am moving to Influx + Grafana for my energy monitoring.
Hi. Every One has been sucessfull with that steps off 1st, modifying the energy source entity_id , then restart ha, then putting the old entity_id to the new source kWh sensor ?
For me didnt work, Lost all the data.
I am restoring a backup but what could have gone wrong?
The new source sensor is an utility_meter ( if i have to Change the source sensor in the future again i change the source from the utility meter to not mess again with this… mess 
)
could that be the reason? I think not because on the energy dashboard the new data appears without editing the energy dashboard…just the old data vanished.
Same here, it’s really annoying.
Well, in fact that did manage to work, but was not very smooth.
I changed the entity id of the old source off the energy dashboard, then restart ha. Created an utility meter and on the source off the utility meter put the new energy entity source, then rename the entity id of the utility meter sensor for the same has the old entity, then restart ha.
The energy dashboard started to using the utility meter data but cleared all the previous data.
I made a reboot of the host, meanwhile, but it stayed the same. Wait a bit, had two bars on the dashboard and no old data.
I thought " well going to use my backup , dont want to loose all my data" . Use the backup like this
Not selecting the HaOS because i had made an update after the backup.
And i was surprised that the change i have made on the entities stayed after restoring the backup and all the historical data have returned .
Here we can see when the data changed his Path…
Shame that i have now an utility meter with the name of an shellyEm.
So i lost the data since the hour that the backup was made until the hour i used that backup … but didnt Lost the changes i made on entity_ids in the same time.
For me is wierd but maybe someone knows what happened.
To avoid this in future you can use generic sensor names that reference the state of the actual sensor value.
so examples might be:
sensor.total_water_usage
sensor.total_solar_generated
sensor.total_gas_usage
sensor.total_grid_usage
Configure each one to use the actual device entity value you need.
E.g.
template:
- sensor:
- name: "Total Water Usage"
unique_id: "Total Water Usage"
unit_of_measurement: L
state_class: "total_increasing"
device_class: "water"
icon: mdi:gauge
state: "{{ (states.sensor.watermeter_xasdafasdf_total_water_usage.state }}"
In the energy dashboard, pick this one
sensor.total_water_usage
Not this one
sensor.watermeter_xasdafasdf_total_water_usage
This is great suggestion.
The issue is how to handle the historic data. DO you have any suggestion how to copy the data from the old sensor to the new “general” one?
state: "{{ (states('sensor.watermeter_xasdafasdf_total_water_usage') }}"
This only really helps if you realise at the start you should do this.
It’s still easiest to just rename the new entity ID to match the old name: No duplication of sensors or extra recorder exclusions.
I used this trick (template sensor) more or less the other way around. I replaced my solar inverter by micro inverters from Enphase. I also expanded my solar array. I liked the idea of conserving the old statistics separate from the new.
So, I removed the integration from the old inverter. Note: removing the integration does not delete the old statistics!
Then I added a template sensor with a unique_id and after a reload of template sensors, I changed the entity_id of the newly created sensor to the entity_id of the old.
template:
- sensor:
name: "Solax BCDxxxxx Total Energy (old)"
unique_id: something_unique_solax_bcd_old
unit_of_measurement: "kWh"
device_class: energy
icon: mdi:solar-power-variant
state: 12345
You cannot add the entity_id here, so you have to change that after the reload, which is possible as long as the old entity is gone and you assigned an unique_id to this new one.
State = last value of the old sensor.