That will be impossible. The sensor naming of the core integration is completely different from the custom HACS one.
But the history of the DEV’s version will be saved, correct?
So basically this would be like adding a new solar panel string, and stop using the old one. Where the data that the old one collected is still in the history, but stops collecting data from the moment the switch takes place. And the new string takes over (with different entities).
So in the end of the year I have PV-data from 2 strings, the old one and the new one. Together they will accumulate to the total which the Enphase Envoy app will show for 2023? And from 2024 on I will only have the ‘new’ sting in Home Assistant?
In theory yes, but how this correlate with removing the old integration i don’t know… If you remove the old integration the sensors are gone too.
EDIT: sorry spoke too soon; the lifetime energy produced sensor has the same name on both integrations. So if you used that in the energy dashboard your statistic history is still available after migration
Ok here are the steps i took to succesfully have charge / discharge sensors availalble with the new core integration. You can ofcourse use your own helper naming.
Add the following helpers:
Combine state helper:
name: Encharge Total Power
characteristic: Sum
Precision: 2
Sensors: add all encharge power sensors from your batteries
Sensor Template:
name: Encharge Discharge Power
state template: {{(states('sensor.encharge_total_power') | float) if states('sensor.encharge_total_power') | int > 0 else 0 }}
unit of measurement: W
device class: Power
state class: Measurement
Sensor Template:
name: Encharge Charge Power
state template: {{(states('sensor.encharge_total_power') | float | abs) if states('sensor.encharge_total_power') | int < 1 else 0 }}
unit of measurement: W
device class: Power
state class: Measurement
Riemann sum integral sensor:
name: Encharge Discharge Energy
input Sensor: sensor.encharge_discharge_power
method: Left Riemann sum
precision: 2
prefix: none
time unit: Hours
Riemann sum integral sensor:
name: Encharge Charge Energy
input Sensor: sensor.encharge_charge_power
method: Left Riemann sum
precision: 2
prefix: none
time unit: Hours
Utility Meter:
name: Encharge Daily Discharge Energy
input sensor: sensor.encharge_discharge_energy
reset cycle: Daily
offset: 0
tariff: empty
net consumption: On
delta values: Off
periodically resetting: On
Utility Meter:
name: Encharge Daily Charge Energy
input sensor: sensor.encharge_charge_energy
reset cycle: Daily
offset: 0
tariff: empty
net consumption: On
delta values: Off
periodically resetting: On
After this, if batteries are not charging / discharging set both template sensors manually to 100 for a couple of minutes (don’t forget to reset!) to make sure the helpers depend on them have valid values.
Lastly add the utility meter helpers to the energy dashboard.
To keep battery statistics run the following SQL queries on the HA db:
UPDATE statistics
SET metadata_id = (SELECT id
FROM statistics_meta
WHERE statistic_id = 'sensor.encharge_daily_discharge_energy')
WHERE metadata_id = (SELECT id
FROM statistics_meta
WHERE statistic_id = 'sensor.envoy_xxxxxxxxxxxxx_battery_energy_charged')
UPDATE statistics
SET metadata_id = (SELECT id
FROM statistics_meta
WHERE statistic_id = 'sensor.encharge_daily_charge_energy')
WHERE metadata_id = (SELECT id
FROM statistics_meta
WHERE statistic_id = 'sensor.envoy_xxxxxxxxxxxxx_battery_energy_discharged')
2 Likes
The second post also implies that this does work. Also, I think essentially this should be possible, since the HACS integration ‘supersedes’ the internal integration. They are not completely different afaik.
Decided to bite the bullet and these are my findings so far;
- First create a full backup (I waited until the energy dashboard got it hourly update and made a back up straight after that).
- After the back up , follow the steps in the second post (delete the integration, restart HA…)
- The Enphase solar panels will be discovered automatically and a notification is given.
- Click the ‘Show discovered device’ (or something) in the notification and click ‘Configure’ in the integration screen where the Envoy Enphase Integrtion is discovered.
- Check the IP address that is show (should be the correct one) and fill in you Enphase Cloud user and password.
- After that all Enphase devices are visible and you are asked to add a room where these are located.
- Fill the rooms or leave blank and after that everything is OK and working.
What I have experienced is the following;
- The following entities are created;
(and with every ‘sensor.inverter_123456789’ an entity is created ‘_last_reported’) - The energy dashboard lifetime production entity from the old one is NOT the same as the ‘new entity’ so I had to add the new one (DO NOT DELETE THE OLD ONE, because this will delete the history from the energy dashboard of that ‘old’ entity. Be assured that it will not delete the data from the database so adding the old entity as a solar production, will make the history visible again).
- So now I have 2 entities in my energy dashboard, the old and the new one.
And for any custom cards or dashboards I have created in the past, I just had to select the new entity to replace the old one. But the cards and dashboards I have created do not show history or anything, therefore this issue described before does not apply here. But if you have custom cards with a history component, you will experience the same trouble as with the energy dashboard.
Do not know yet if there are more issues to follow, and I do not like having the old entity in my dahsboard while it does not do anything anymore other that for ‘history’ .
So not decided if I am going to do a roll back or just let this be.
Maybe someone knows how to rename the entity of the old data to the new entity, or another way to fix this?
Edit; did a roll back, mainly because I did not like the extra entity. Roll back was easy and making the switch to the core version was also easy. So if a solution is available I will try again.
1 Like
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 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:
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.
1 Like