That is strange, the old lifetime sensor on my system was the same as the new one. I did not have to configure anything in the energy dashboard apart from the battery sensors…
EDIT: oh and in my previous post i explained how to update a changed sensor naming by executing some SQL queries. You can use the SQLLite Web addon for that.
That did the trick. I added the Enphase integration via the core integration like in my previous post.
The entities that are created are something like;
sensor.envoy_**123344567789_**lifetime_energy_production
sensor.inverter_12233445567
etc.
I compared these with the entities that I had when I had the DEV-version working.
I found out that I had to change the entities to the following;
sensor.envoy_**enphase_s_**lifetime_energy_production
sensor.**envoy_enphase_s_**inverter_12233445567
After I changed the entity names to the ones that were similar to the ones in DEV, everything started working again.
The only difference still is that ‘_lifetime_energy_production’ in DEV was an entity measured in Wh, while the Core-version measures it in mWh.
I changed this back to Wh, and have to test whether or not this impacts that energy dashboard and history when I change it to mWh. Because when I looked at the history while it was still mWh, the history was in Wh and therefor dropping from 3.000.000 (Wh) way down to 3.000 (which is mWh). So it appeared that the history tabel doesn’t work well with changing the measurement. Will test this later on (or if anyone knows the answer, feel free to answer this question).
Sorry for the chaotic break down or incomplete explanations. In a hurry and will add more info later…
Edit after few hours operational; everything works fine and the core integration continues its data collection on the historic entities, so transition is seamless.
Only remaining question is what happens with the new and historic data combined when I change the measurement of ‘sensor.envoy_enphase_s_lifetime_energy_production’ from Wh to mWh.
Will try that tomorrow when sun us up again and everything is active.
Had the same issue that the production sensor wasn’t the same anymore. So I was lacking the historical production data.
The old sensor was id 184 (in my DB) and the new one was 514. So I ran a query to merge the statistics
184 sensor.envoy_122205017648_today_s_energy_production
514 sensor.envoy_122205017648_energy_production_today
Query to update stats
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.
Yes, only lifetime production sensor name does match between intgrations…
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.
I updated to version 2023.9.3, rebooted. But, Enphase is not auto-detected.
Do I need to delete the HACS DEV integration first to get it auto-detected?
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?
Not sure if I understand you correctly, but did you rename your new entities to the name which this entity had in DEV. Like stated in above quote?
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 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.
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:
logbook:
exclude:
entities:
- sensor.enpower_xxx_last_reported
- sensor.encharge_xxx_last_reported
recorder:
exclude:
entities:
- sensor.enpower_xxx_last_reported
- sensor.encharge_xxx_last_reported
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.
To get grid import/export and battery charge/discharge from the core HA Envoy component here is my configuration.
This is adapted from other posts, but I thought I would post it using the up to date template sensor format and without any unnecessary steps.
Just replace the XXXXXXXXXXXX with your own number from your own sensors.
First, create a helper from the UI to sum the power of all your batteries:
Call it “Encharge Total Power”. sensor.encharge_total_power
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.
Grid import/export is now available in 2024.3 core as net consumption and net production.
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.
I have used GitHub - briancmpbll/home_assistant_custom_envoy for a long time but since finding this statement in the Changelog about half a year back, I stopped updating:
I am still on v0.0.15 and I am wondering what shall I do? Shall I remove the HACS integration and switch over to the official one? Or shall I upgrade?
Will I use data in any case? Under no circumstances I would want to loose data.
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.
A late experience triggered by the HA update to 2024.10. The core integration does not have a stateclass for the ‘last 7 day’ values and as a result does not write these to the statistics.
With the release of HA 2024.10 you may see a repair popping up
for the last_seven_days_production entity and the option to remove the old statistics.
The statistics for the ‘last 7 days’ values stopped recording in the statistics with the migration to core, not with the 2024.10 version.
With the 2024.10 release there are now checks for old statistics data without a associated entity or no entities without a stateclass. Hence the repair for the ‘last 7 days’ entity.
The entity was already listed under ‘developer tools’ / ‘statistics’ with state class '' of this entity not supported and based on this you may have corrected this already using the ‘FIX ISSUE’ option.
