UPDATE statistics
SET metadata_id = 514
WHERE metadata_id = 184 AND start_ts NOT IN
(SELECT s.start_ts FROM
(SELECT start_ts FROM statistics
WHERE metadata_id = 184) s
INNER JOIN
(SELECT start_ts FROM statistics
WHERE metadata_id = 514) t ON s.start_ts = t.start_ts)
well I just tried it as well but by simply removing the hacs integration and ignoring the pop-up (I made a snapshot so I could easily revert back). I restarted and I had the main integration. Now with a device for each inverter and for the totals, but all entity_id’s were still correct. Looks like it worked seamlessly that way.
Energy history also seems fine.
did it as well the easy way by just deleting the HACS integration, ignoring the warning and rebooting.
Most of the sensors are back and working. Only all the sensors for single phases L1, L2 ,L3 import and export are gone as well as all day / lifetime values. But I was anyway not using them.
On the other hand I now see when there was the last communication from every single inverter.
Migration from DEV to core was ideal because there seem to be more accurate readings for battery charge/discharge (thank you @posixx and @JHurk)
One issue I’ve been running into with the migration is the grid consumption / grid export integration into the energy dashboard. with DEV we used the Lifetime Net Consumption (grid consumption) and Lifetime Net Production (grid export) - but with the new core integration, it seems like these entities are no longer active
Has anyone gotten the Grid Consumption/Grid Export working with the energy dashboard?
Can someone help me? I switched today, and from what I checked, it works fine. All the history data of Energy dashboard are still there. However, for the today data, they are wrong because of incorrect Riemann helper that I use. I have corrected the helper, but the incorrect data are still in the database.
How to delete the data of today? Or replace it with “0”. It seems I cannot figure it out.
In the Energy Dashboard, I use entity “sensor.solar_panel_production”, the metadata_id is 168.
not sure if this is what your asking, but in the developer tools there’s a statistics entry. The right most button allows you to fix erroneous sums for long term statistics (the interface isn’t great though).
Otherwise you’ll have to manually adjust the database entries, which I always find a hassle but is covered here and there on this forum.
Thanks for explanation and description. Using the drop method of just removing the custom integration in HACS and ignoring the warning and restart HA worked fine. It found what I had, no issues with history, names or UOM.
On a test system I also tested removing the Enphase Envoy device, then remove the custom integration in HACS and restart HA.
The fundamental difference is that all entities move to the deleted_entities list.
It found the Envoy and entities again, but it restarted history/states for all inverters from scratch as entity_id for the inverters has different name scheme. The unique_id would be the same but original gets lost when deleting the device.
The other entities where found ok, no restart of histort, same entity_id name scheme.
Also some display quirks with UOM for overall energy as these are changed to kWh or MWh. Data is still in Wh in history, but in history display, if old and new data is in view, it doesn’t scale nice, if only one UOM is in vision no problem. More a history trend display issue I think as I verified the database has all data correctly.
The history restart for the inverters can be prevented by changing the entity_id of the inverters before deleting the envoy device (from e.g. sensor.envoy_123456789012_inverter_122334400001 to sensor.inverter_122334400001). That may be painful or not depending what all is using the inverter.
The drop method avoids the issues found in the test. But the learning from the test is that when using the drop method, the entity_id’s of the inverters differ from from the scheme of the core integration.
Not an issue as all is working fine.
If the envoy gets ever deleted and re-added the inverters will restart history as described
Just that you are aware!
The test suggests that a future surprise can be prevented by changing the entity_id of the inverters after using the dropmethod (no need to do it beforehand). Whether that is correct probably depends on each individual situation as well as the effort involved for such a change. Not recommending for or against it now.
As mentioned, just that you are aware. Haven’t made up my mind yet what and if I will change anything.
For anyone with the DEV version and 5P batteries, you are missing good additional details that core provides. This includes battery temperature, grid controls, and the ability to change your battery use profile. I’m glad I switched! Creating the battery charging/discharging helpers is not fun, but works (thanks @posixx )
Suggestion to save on your database size and logbook spam, add to your config file:
Finally, for those that have been frustrated that Enphase does not allow a max battery charge limit, it’s not directly possible with this integration, but maybe indirectly. This would be by using the charge modes and an automation. E.g. in self consumption mode at night, and a max reserve limit of 80%, the battery will stay at this level since it will only charge during the day. During the day, setting the battery to grid charge mode with a time of use that only allows for charging at night due to configuring the right plans this way for lower night rates, could work. Need to try it out…
Multiphase support available in DEV has been added to HA Core integration in 2024.2 as well. It adds l1/l2/l3 entities just as in DEV originally added by @posixx, if you have Envoy metered with enabled CT on more then 1 phase.
Then create the template sensors in configuration.yaml:
template:
- sensor:
name: Envoy Grid Import Power
unique_id: grid_import_power
state_class: measurement
icon: mdi:transmission-tower
unit_of_measurement: kW
device_class: power
state: >
{{ [0, states('sensor.envoy_XXXXXXXXXXXX_current_power_consumption') | float(0) - states('sensor.envoy_XXXXXXXXXXXX_current_power_production') | float(0) ] | max }}
- sensor:
name: Envoy Grid Export Power
unique_id: grid_export_power
state_class: measurement
icon: mdi:transmission-tower
unit_of_measurement: kW
device_class: power
state: >
{{ [0, states('sensor.envoy_XXXXXXXXXXXX_current_power_production') | float(0) - states('sensor.envoy_XXXXXXXXXXXX_current_power_consumption') | float(0) ] | max }}
- sensor:
name: Encharge Discharge Power
unique_id: encharge_discharge_power
icon: mdi:battery
unit_of_measurement: W
device_class: power
state_class: measurement
state: >
{{(states('sensor.encharge_total_power') | float) if states('sensor.encharge_total_power') | int > 0 else 0 }}
- sensor:
name: Encharge Charge Power
unique_id: encharge_charge_power
icon: mdi:battery
unit_of_measurement: W
device_class: power
state_class: measurement
state: >
{{(states('sensor.encharge_total_power') | float | abs) if states('sensor.encharge_total_power') | int < 1 else 0 }}
Then create the sensors lower down in configuration.yaml to convert from kW to kWh:
sensor:
- platform: integration
unique_id: grid_import_energy
name: Envoy Grid Import Energy
source: sensor.envoy_grid_import_power
unit_time: h
method: left
- platform: integration
unique_id: grid_export_energy
name: Envoy Grid Export Energy
source: sensor.envoy_grid_export_power
unit_time: h
method: left
- platform: integration
unique_id: encharge_charge_power
name: Encharge Charge Energy
source: sensor.encharge_charge_power
unit_time: h
method: left
- platform: integration
unique_id: encharge_discharge_power
name: Encharge Discharge Energy
source: sensor.encharge_discharge_power
unit_time: h
method: left
Then you can add the energy sensors to your Energy Panel.
Note. You don’t need to worry about resetting the counts every night because the Enery Panel manages this for you from lifetime sensors. You would only do that if you wanted a daily total for your own reasons.
For those that want to run the HA core integration but can’t because they still have an Envoy legacy with firmware <3.9 there’s a custom integration enphase_envoy_legacy_support that does not replace the HA Core but is installed as a separate custom integration with name ha_enphase_envoy_with_legacy and registers the required webscraper with the HA Core Enphase Envoy integration. All communication and processing is done by the HA Core integration and it enables running Legacy Envoy, either alone or in mixed environment with newer models, all served by the HA Core integration.
Since the days I wrote that piece of literature, the HA core integration also has grid import and export as mentioned in one of the topics in this thread. The HA Core version has the same naming scheme for grid import and export as the one in the (DEV) v0.0.19 release. Which is different from the v0.0.17 release.
Since you are still on v0.0.15 its a mute point as you don’t have the grid import export entities anyway. But if you decide to upgrade the (DEV) version you need 0.0.19 for compatible naming scheme for energy import and export to switch.
As you can read from other replies in the thread, generically there’s no data loss, provided you use the drop the HACS Enphase Envoy custom integration method. This is valid for the energy import export entities as well, if you would have them. If you have a battery there will be changes as the (DEV) version calculates battery charge/discharge from change in State of Charge of the battery. The core version does not have that calculation, but on the other hand provides more control over the battery and switches.
Do not delete the Envoy device from HA, as I described above, the history for the inverters will start from scratch again, but not the other entities.
AND make a backup before you start, also from the database if you run a separate database server like MariaDB, just in case lightning strikes.
As for switch or upgrade, that depends on what you have and if you did any customization. If you have battery I think Core has more features. Otherwise they are close. I have no developments plans for (DEV), don’t know if others have. If bug or issues occurs I still assist with (DEV) as I do on Core. But new features will be in core as far as I’m concerned.
