Implement entity schema migrations

[canton7]

The aim here:

• We have integration entities which really should be replaced by totals read directly from the inverter
• We have some inconsistent naming of entity ids which we should probably fix
• We should not break anyone who is already using this integration: this could break their automations etc, and could remove statistic history which they might care about. This includes if they remove/readd this integration, as that's the only supported way to change some settings

I think the best way to do this is:

1. Every entity gets tagged with a range of schema versions it supports. The constant LATEST refers to the latest version.
2. We create an entity which holds the current schema version. This is a RestoreEntity. This is not linked to any device -- it applies across all devices.
3. On startup, we manually load the state of this entity (we can't wait for it to be loaded by HA), then we only load entities whose version range includes this version
4. We provide a button/box in the options flow to manually change the entity schema version if required

---

1. We can't store the version in the main config entry, otherwise it gets lost if the use removes/re-adds
2. I don't think we can store it in a separate config entry (although we can create additional config entries), as HA will try and load us from that
3. We can create a manual store ourselves, but then we need to be able to remove it properly, etc...
4. A RestoreEntity means that the version is automatically cleared up a week after this entity is removed, which feels like a sensible approach

[canton7]

I think we should do this soon: people keep being confused by the integration sensors, which is entirely avoidable if we read the totals directly from the inverter

[TonyM1958]

For consistency, where you have the inverter_Totals, consider using these as the source for the utility_meters so the _daily values track the _Today values shown in the app.

[canton7]

I'm not sure I follow I'm afraid. Why have a utility meter when you have the _Today registers?

[TonyM1958]

As I understand it (may be wrong...), because:

• people are familiar with those sensors and have already built them into their dashboards
• the Today and Total values may not be available with some connection types so you can revert the source without people having to update where they have the utility meter in their dashboards
• utility meters are handled as long term statistics and get stored for a longer period than the history sensor
• it removes the need to read the Today sensors all together as the utility meters give exactly the same values

[canton7]

people are familiar with those sensors and have already built them into their dashboards

I don't think there's any difference? They're both sensor types, just provided by different integrations (the utility meter is provided by a built-in component, but it's still just a sensor).

the Today and Total values may not be available with some connection types so you can revert the source without people having to update where they have the utility meter in their dashboards

We already give people polyfills in some cases. Again it's still a sensor -- it doesn't matter to HA whether the value is being provided by our subclass of SensorEntity, or the utility_meter's subclass of SensorEntity. I'm not sure what you mean by "revert the source"?

utility meters are handled as long term statistics and get stored for a longer period than the history sensor

HA tracks long-term statistics for any sensor with the right state_class: https://developers.home-assistant.io/docs/core/entity/sensor/#long-term-statistics

it removes the need to read the Today sensors all together as the utility meters give exactly the same values

We can read all of these sensors in a single read anyway, for almost 0 extra cost.