Envoy Battery not showing up to setup in Energy dashboard (charge/discharge).

[vazquezrodjoel]

The problem

When I go to setup the module on the Energy Dashboard per the instructions, I can setup the grid, solar panels, but I cant setup the Home Battery Storage because I cant see/find the battery energy charged nor the battery energy discharged. I cant also find it on the Enphase Envoy devices or Entities.

Note: I work in IT, but I'm not an expert on HA, so please be gentle with me :) . Let me know what info you might need from my end and how to get it right for you. Thanks

What version of Home Assistant Core has the issue?

core-2024.7.2

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Enphase Envoy

Link to integration documentation on our website

https://www.home-assistant.io/integrations/enphase_envoy#energy-dashboard

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @bdraco, @cgarwood, @joostlek, @catsmanac, mind taking a look at this issue as it has been labeled with an integration (enphase_envoy) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `enphase_envoy` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign enphase_envoy` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

enphase_envoy documentation enphase_envoy source _{^{(message by IssueLinks)}}

[catsmanac]

Hi @vazquezrodjoel, for battery charge/discharge values you need to have storage Current Transformers (CT) installed. If not these entities won't be available. To check your Envoy configuration you can inspect the diagnostic report.

When you inspect it look for the section envoy_properties and in there for ct_storage_meter. If that shows as null then no storage CT is detected or configured.

    "envoy_properties": {
      "envoy_firmware": "7.6.177",
      "part_number": "800-00654-r08",
      "envoy_model": "Envoy, phases: 3, phase mode: three, net-consumption CT, production CT",
      "supported_features": [
        "INVERTERS",
        "METERING",
        "TOTAL_CONSUMPTION",
        "NET_CONSUMPTION",
        "ENCHARGE",
        "PRODUCTION",
        "TARIFF",
        "THREEPHASE",
        "CTMETERS"
      ],
      "phase_mode": "three",
      "phase_count": 3,
      "active_phasecount": 3,
      "ct_count": 2,
      "ct_consumption_meter": "net-consumption",
      "ct_production_meter": "production",
      "ct_storage_meter": null

If you want me to inspect the file feel free to upload the diagnostics file as file by dragging it into the area right below a new comment box where it says:

[vazquezrodjoel]

config_entry-enphase_envoy-01J2KWMMDCMD8BZM8KC3MTKD4C (1).json

Ok, thanks a lot, I found it and it says NULL. I was expecting it to work since on the Enlighten app I can see the charge/discharge of the battery. I guess that is not necessarily true?!

[catsmanac]

You are right, not necessarily true. The Envoy interface HA can use does not provide access to all the data that is send to the Enlighten cloud, let alone it's poorly documented by Enphase. We have no clear picture what data is send and how Enphase calculates all details.

Without the storage CT, which btw are not often implemented, you have to do some custom calculations in HA using some templates. What is available for this is Power charge/discharge for each individual battery:

This is power, so you have to use a Riemann helper to calculate energy from the value. Then split in positive and negative changes to get battery charge/discharge. Since this value is per battery, you need to sum these over all batteries.

An alternative is to use the overall battery capacity status on the Envoy:

With these you can calculate Battery charge/discharge as a negative change is amount discharged since previous value, while a positive change is amount charged. Using templates you can create 2 new entities and use the with the energy dashboard.

Depending on what your need is, we probably can work out some example for this.

[vazquezrodjoel]

Well I would like to see the usage as close to real as possible. What I mean is that, since my grid bill (cost per kW) changes higher from 4pm-8pm Monday to Friday, I setup the system to use batteries during that time. On the Enlighten app I see the distribution right, but I would like to see is also on HA. Right now it shows like I shutdown basically the house, and I think that is for that missing piece. Any suggestions what can I do?

And thanks again.

[catsmanac]

To get the numbers you are looking for you need to create some calculations that use the battery data and produce amount charged / discharged. Look into templating and automations.

For instance, using the Available battery energy. When this value changes, calculate if it is a change up or down. When down add the amount of change to a new battery discharged entity. When value goes up, add the change to battery charged. This will give you the 2 values for the battery part of the energy panel.

As an alternative, sum the power of all Encharge devices. Then add a Riemann helper to calculate the energy charged/discharged from the power values. Then again detect and calculate positive and negative changes to feed to the energy dashboard as described above.

[FabFaeb]

I'm hopping in here since I'm having the exact same issue as @vazquezrodjoel: I would like to calculate battery charged and discharged based on the available battery sensor. @catsmanac where would you realize this? Would an automation make sense here? Or is it possible to add a template sensor with historical data somehow?

[catsmanac]

Hi @FabFaeb and @vazquezrodjoel, based on Available battery Energy I've tested a scenario that might work. Haven't looked at the scenario for using the Power values of the individual batteries yet. That could be an alternative.

• Any change in Available battery Energy implies that the battery charged or discharged with the amount of change
  • A positive change in value implies battery charged
  • A negative change in the value implies battery discharged
• When HA restarts the value will go to unknown or unavailable.
  • To detect change over the outage we need to have access to or remember the last value before the HA cycle.

We'll use a combination of automation, template sensors and an input_number to implement this.

1. Add number helper

In Settings / Devices & services / Helpers add a new helper of type number and give it some meaningful name. Make sure the set the Maximum value to the battery capacity. The number helper will be used to hold last good value of the Available battery Energy.

2. Create automation to copy the Available battery Energy to the number helper

In Settings / Automations & scenes / Automations add a new automation. Use the ⋮ at the right hand top and open the automation yaml editor and insert

description: Track Battery Energy Change
trigger:
  - platform: state
    entity_id:
      - sensor.envoy_<your_envoy_serial_number>_available_battery_energy
    not_to:
      - unknown
      - unavailable
condition: []
action:
  - service: input_number.set_value
    target:
      entity_id: input_number.<some_meaningful_name>
    data:
      value: "{{trigger.to_state.state | int(0)}}"
mode: single

Replace with the serial number of your envoy. Replace by the name you assigned to the Number helper. Then save the automation.

This should now start copying the values of the Available battery Energy into the some_meaningful_name Number, but only when the value updates, so may be a while when in stable battery condition.

3. Create template sensors to track battery charge and discharge.

If you have already templates defined in your configuration.yaml or a separate file, edit that file. If not yet edit configuration.yaml in the Home Assistant configuration folder. In there add:

template: !include templates.yaml

Then edit a new templates.yaml file in your configuration folder. Paste the template below:

- trigger:
    - platform: state
      entity_id: input_number.<some_meaningful_name>
      not_to:
        - unknown
        - unavailable
  sensor:
    - name: "Battery Lifetime Discharge"
      unique_id: battery_lifetime_discharge
      unit_of_measurement: "kWh"
      icon: mdi:battery
      state: "{{ this.state | int(0) + ([0, (trigger.to_state.state | int(0) - trigger.from_state.state | int(0)) * -1.0 ] | max | int(0))}}"
      state_class: measurement
    - name: "Battery Lifetime Charge"
      unique_id: battery_lifetime_charge
      unit_of_measurement: "kWh"
      icon: mdi:battery
      state: "{{ this.state | int(0) + ([0, (trigger.to_state.state | int(0) - trigger.from_state.state | int(0)) ]| max | int(0))}}"
      state_class: measurement

Replace by the name you assigned to the Number helper. Change the name: and unique_id: to your preference. Save the changed files.

4. Cycle Home assistant

To make the new templates active restarts Home Assistant after first verifying its a valid configuration in Developers Tools / Yaml.

This should start building lifetime charge and discharge data.

[FabFaeb]

Wow, thank you very much. I'll try this as soon as possible and let you know how it worked.

[catsmanac]

Curious to see if the values will be anywhere close to what Enphase reports, have no batteries myself.

[FabFaeb]

Just implemented it and it seems to work generally. Thanks a ton @catsmanac! However the unit in the "Battery Lifetime (Dis)Charge" sensors seems off - I guess this should be Wh and not kWh - right? However, the Energy Dashboard expects kWh, could this be fixed with a 0.001 factor in the template calculation? I'll report back on how accurate it is compared to the Enphase App once I had some battery charging and discharging!

[catsmanac]

That's really quick turn-around :-)

However the unit in the "Battery Lifetime (Dis)Charge" sensors seems off - I guess this should be Wh and not kWh - right?

Yes, good catch

However, the Energy Dashboard expects kWh, could this be fixed with a 0.001 factor in the template calculation?

If you replace the kWh units with the correct Wh units the energy dashboard may do the conversion for you, not sure.

Otherwise replace the * -1.0 by * -0.001 but also the int(0) by float(0) and round to to 3 decimals

state: "{{ this.state | float(0) + ([0, (trigger.to_state.state | float(0) - trigger.from_state.state | float(0)) * -0.001 ] | max | float(0) | round(3))}}"

state: "{{ this.state | float(0) + ([0, (trigger.to_state.state | float(0) - trigger.from_state.state | float(0)) * 0.001 ]| max | float(0) | round(3))}}"

[vazquezrodjoel]

Wow, thanks for that @catsmanac . So today I had finally some time to give this a try and I came up with this code. I'm tempted to try yours, but since it took me a good amount of time want to submit it to you so you can look at it and let me know any down sides or flaws. Please don't be afraid to tell me is total crap if it is ;). I'm no developer and just learning to play with HA. So what I did created 2 sensors as templates and assigned on the energy dashboard. It appears on the Energy Dashboard, and seems to be working... I think! :)

 - sensor:
      - name: "Battery Charge"
        unit_of_measurement: "Wh"
        unique_id: sensor.total_battery_in
        device_class: energy
        state_class: total
        state: >
          {% set power =  
            states('sensor.encharge_492240001112_power')|float(5) + 
            states('sensor.encharge_492240001159_power')|float(5) +
            states('sensor.encharge_492240001160_power')|float(5) +
            states('sensor.encharge_492240001161_power')|float(5) +
            states('sensor.encharge_492240001166_power')|float(5) +
            states('sensor.encharge_492240001167_power')|float(5) 
          %}
          {% if power < 0 %} 
            {{ power }} 
          {% else %} 
            0 
          {% endif %}

      - name: "Battery Discharge"
        unit_of_measurement: "Wh"
        unique_id: sensor.total_battery_out
        device_class: energy
        state_class: total
        state: >
          {% set power =  
            states('sensor.encharge_492240001112_power')|float(5) + 
            states('sensor.encharge_492240001159_power')|float(5) +
            states('sensor.encharge_492240001160_power')|float(5) +
            states('sensor.encharge_492240001161_power')|float(5) +
            states('sensor.encharge_492240001166_power')|float(5) +
            states('sensor.encharge_492240001167_power')|float(5) 
          %}
          {% if power > 0 %} 
            {{ power }} 
          {% else %} 
            0 
          {% endif %}

What you guys thing, should I just scrap it and use your solution?

Thanks again! really appreciated your help.

[catsmanac]

Nice to see the alternative option using the power sensors @vazquezrodjoel. Equally curious how that will work-out.

You need to add another step. What you summed is power, not yet energy. The Energy Dashboard wants energy as input, which is power over time. To calculate energy from power you use the Riemann helper.

To do so:

• Remove the 2 from the energy dashboard
• Change the unit_of_measurement on both your calculations from Wh to W.
• Change the state_class on both from total to measurement.
• Cycle HA to get changes in effect.
• In Settings / Devices & services / Helpers add 2 Integration - Riemann sum integral sensor helpers
  • first one for charge, name it to something meaningful like Battery Lifetime Energy Charged, specify your calculated Battery Charge as input sensor and left riemann sum as integration method. Use k (kilo)as the metric prefix and Hours for time period
  • for discharge same way using the battery discharge.

With that you get 2 sensors, say Battery lifetime energy charged and Battery lifetime energy discharged (or whatever names you used) that can be used with the energy dashboard.

[catsmanac]

@FabFaeb, the Number helper that is used to remember last good value can be changed from the HA dashboard, if you add it to the dashboard. Be aware that if you change it manually it will be seen as additional charge/discharge.

In my example the sensors have state_class: measurement, but @vazquezrodjoel example made me realize that you may want to change the 2 lifetime sensors to below device class and state_class.

        device_class: energy
        state_class: total-increasing

as the the numbers should be ever increasing for both sensors.

Also you don't need to use the multiplier as energy dashboard will accept Wh as well

[FabFaeb]

Thanks for the headsup @catsmanac - I wanted to report the device_class and state_class issues to you later on as well. I had some issues initially with the units but for now everything seems to work fine. I'll let you know after the weekend how accurate it seems to be!

[catsmanac]

Oh, and change device_class to Power @vazquezrodjoel .

[vazquezrodjoel]

got it, @catsmanac, I did the modifications provided and seems to be working, now I just get this message on the Energy Dashboard configuration.

I'm tempted to scratch my way and go with yours and try it out...

This is today, but on weekdays is where I use the most the batteries, unless grid goes out, so next week Ill see how it works really...

[catsmanac]

What we missed for the power charged is making it a positive number

- name: "Battery Charge"
        unit_of_measurement: "Wh"
        unique_id: sensor.total_battery_in
        device_class: energy
        state_class: total
        state: >
          {% set power =  
            states('sensor.encharge_492240001112_power')|float(5) + 
            states('sensor.encharge_492240001159_power')|float(5) +
            states('sensor.encharge_492240001160_power')|float(5) +
            states('sensor.encharge_492240001161_power')|float(5) +
            states('sensor.encharge_492240001166_power')|float(5) +
            states('sensor.encharge_492240001167_power')|float(5) 
          %}
          {% if power < 0 %} 
            {{ power }} 
          {% else %} 
            0 
          {% endif %}

This is the negative part of the power, but we want a positive number, so multiply it by -1.

          {% if power < 0 %} 
            {{ power * -1 }} 
          {% else %} 
            0 

The other feedback I forgot is on the float(5). That means it will use a default value of 5, not 5 decimals. You might want to use float(0) to have a default of 0.

Not sure about the device class error. Would expect the energy device class to be correct. Maybe remove the entities from the energy dashboard, restart HA and then re-add them again.

If you want to try the other way, it might be interesting to build it next to what you have now so we can compare them side-by-side. Obviously you can't add them both to the dashboard at the same time, but comparing results is possible. And you can switch the dashboard between them if you want. The dashboard works off the statistics data and use history from there. So when switching it will show that history. Might take an hour or so before it shows up at switch.

[FabFaeb]

As promised here are some results after a few days of usage with the solution provided by @catsmanac :	Date	Discharge from Enphase	Discharge from Homeassistant	Charge from Enphase	Charge from Homeassistant
31.07.2024	2,8 kWh	2,7 kWh	3,5 kWh	2,9 kWh
30.07.2024	2,3 kWh	2,3 kWh	3,5 kWh	2,9 kWh
29.07.2024	4,2 kWh	4,4 kWh	7,6 kWh	6,7 kWh
28.07.2024	5,6 kWh	5,5 kWh	3,7 kWh	3,2 kWh

So all in all it seems to be working reasonably well. For some reason the discharge is more precise as the charge which seems to be always 0,5-1 kWh too little. Again, thanks a lot to @catsmanac for coming up with this solution. If you want me to do some further tests feel free to contact me! :)

[ahullah]

Hey Folks, Thank you for this thread..... I just had my enphase kit installed and was wondering why i wasn't seeing all the sensor outputs in HA.... i still have a window to argue with octopus energy to get the 3rd CT installed as per this guide https://enphase.com/download/guidelines-current-transformer-ct-installation-tech-brief but the standard installer guide doesn't even refer to this as an option so I understand why my electricians were looking at me strangely when i was telling them something was missing. will keep pushing but glad you have this solution as an alternative. Cheers

PS if they don't do it I can see enphase CT's are cheap enough on ebay for me to have a stab at fitting it.... :)

[catsmanac]

Thanks for the feedback @FabFaeb.The charge offset might be conversion losses and/or own power usage, power that is used but not added to the available capacity. Maybe you can validate the available energy between HA en Enphase as well, if available in Enphase, at some moments when the battery is stable. Looking at the values this seems to be roughly a factor between 1.1 and 1.2. So you could use a correction factor of like 1.15 in your calculation of amount charged. Yes that's a brute force method and the needed factor may differ in time or depending on the actual battery load itself, don't know

The alternative is using the riemann method on the battery power as @vazquezrodjoel is trying. That would include these 'losses' I'm guessing.

[catsmanac]

Hi @ahullah, storage CT are indeed rarely installed going by the questions we got on the subject. The storage CT is a recent add to the integration only after we learned it was actually possible when stumbling over it in a reported issue.

Unlike single or split phase installation, using them in 3 phase installations is not even strait forward if possible at all, as the Envoy can only hook 6 CT and these would require 9 if all phases are to be monitored individually.

[vazquezrodjoel]

OK, Just and update just FYI, I let the system running for a few days, so far looks pretty close: Aug 1st:

Jul 31st:

[FabFaeb]

Thanks for the feedback @FabFaeb.The charge offset might be conversion losses and/or own power usage, power that is used but not added to the available capacity. Maybe you can validate the available energy between HA en Enphase as well, if available in Enphase, at some moments when the battery is stable. Looking at the values this seems to be roughly a factor between 1.1 and 1.2. So you could use a correction factor of like 1.15 in your calculation of amount charged. Yes that's a brute force method and the needed factor may differ in time or depending on the actual battery load itself, don't know

The alternative is using the riemann method on the battery power as @vazquezrodjoel is trying. That would include these 'losses' I'm guessing.

It looks like @vazquezrodjoel approach has some minor discrepancies in the "charged" value as well. So I guess your suggested "correction factor" might be the easiest solution? Where would I put that factor? Would this be sufficient in the battery lifetime charge template state? Or would a different place make more sense? {{ this.state | float(0) + ([0, (trigger.to_state.state | float(0) - trigger.from_state.state | float(0)) * 0.001 * 1.2 ]| max | float(0) | round(3))}}

[catsmanac]

So @vazquezrodjoel charge data is low as well. Don't know where that current is measured/calculated so interesting learning as well.

Or would a different place make more sense?

Where you have it is ok. Maybe use 1.15 and see how close it gets to the Enphase numbers.

[larvalgeek]

@catsmanac

I just wanted to say thank you for this writeup. I was able to get the battery charge and discharge to display, but I wanted to note that I am currently getting an error about the entities having an error

a state class 'measurement' but 'last_reset' is missing

in the following sensors

• sensor.battery_lifetime_discharge
• sensor.battery_lifetime_charge

My research (looking at other lifetime measurements offered by enphase) indicates that perhaps "state_class: total_increasing" might be a better fit, but I'm a super-noob - any guidance on resolving this error?

[catsmanac]

HI @larvalgeek, yes the lifetime values should be total-increasing as that is what they do. Think my original example had that wrong and it was corrected later. So your research was on the mark.

We probably should provide the final examples when these all work work fine so we have these in one overview. Might add them to the doc pages as well then.

[ahullah]

For reference this is what i am currently running and it seems to be behaving pretty well (still waiting for my 3rd CT from ebay to turn up however :) ) ` - trigger:

• platform: state entity_id: input_number.available_solar_battery_energy not_to:
  • unknown
  • unavailable sensor:
• name: "Battery Lifetime Discharge" unique_id: battery_lifetime_discharge unit_of_measurement: "Wh" icon: mdi:battery state: "{{ this.state | int(0) + ([0, (trigger.to_state.state | int(0) - trigger.from_state.state | int(0)) * -1.0 ] | max | int(0))}}" device_class: energy state_class: total_increasing
• name: "Battery Lifetime Charge" unique_id: battery_lifetime_charge unit_of_measurement: "Wh" icon: mdi:battery state: "{{ this.state | int(0) + ([0, (trigger.to_state.state | int(0) - trigger.from_state.state | int(0)) ]| max | int(0))}}" device_class: energy state_class: total_increasing`

[ahullah]

urgh that didnt paste very well

[catsmanac]

Another good example indeed @ahullah. THanks for sharing, think formatted it looks like this.

  - trigger: 
      - platform: state 
        entity_id: input_number.available_solar_battery_energy 
        not_to: 
          - unknown 
          - unavailable 
    sensor: 
      - name: "Battery Lifetime Discharge" 
        unique_id: battery_lifetime_discharge 
        unit_of_measurement: "Wh" 
        icon: mdi:battery 
        state: "{{ this.state | int(0) + ([0, (trigger.to_state.state | int(0) - trigger.from_state.state | int(0)) * -1.0 ] | max | int(0))}}" 
        device_class: energy 
        state_class: total_increasing 
      - name: "Battery Lifetime Charge" 
        unique_id: battery_lifetime_charge 
        unit_of_measurement: "Wh" 
        icon: mdi:battery 
        state: "{{ this.state | int(0) + ([0, (trigger.to_state.state | int(0) - trigger.from_state.state | int(0)) ]| max | int(0))}}" 
        device_class: energy 
        state_class: total_increasing

[Texass12]

Hello like-minded people, I'm still quite new to HM or am still a little confused as to what the best solution is. I have pretty much the same problem as some others here. You have an Enphase system installed, you think the cloud provides all the numbers and the entities also map them, but you can't track the batteries in the dashboard without the corresponding CT module. I have the power to grid data and the power from grid output from a Tasmota sensor and have integrated them into HM, this was already working for me before Enphase was installed. This data is exactly the same as the data provided by the Enphase Meter S Gateway (CT Production / CT Consumption). Unfortunately I can't display and integrate the battery in the dashboard, but that's my goal. The description at the beginning by catsmanac is great, but then it gets a little rough and I lose track, then there were a few additions and a few better variants and I was out and couldn't follow any more. Is it possible for one of you experts to create a step-by-step guide similar to the one described by catsmanac? That would be great and I'm convinced that it would really help a lot of people.

[catsmanac]

This is based on my original one using available battery energy which tracks changes in available battery energy as a measure for energy charged/discharged. I added the various feedback and corrections. It is still is subject to my typing errors of course. It does not fully match the Enphase App as it does not include conversion losses in and out of the storage. So there's correction factor to compensate for this.

1. Add number helper to hold last good value

In Settings / Devices & services / Helpers add a new helper of type number and give it some meaningful name (example uses some_meaninful_name). Make sure the set the Maximum value to the battery capacity.

The number helper will be used to hold last good value of the Available battery Energy. As input_number. is a Number, you can change the value from the user interface manually. Do NOT do that. Each change will result in energy charged/discharged values and will result in wrong values.

2. Add number helper for correction factor

In Settings / Devices & services / Helpers add a new helper of type number and give it some meaningful name (example uses correction_factor). Set the Minimum value to 100 and the Maximum value to 200.

The number helper will be used to apply a correction for conversion losses. After adding it, it should have the value of 100, which will result in a correction factor of 1. In practice you probably need to set it to somewhere between 110 and 120 to get same values as Enphase App.

If you want a different correction factor for charge and discharge, create another number for it, same process, different name.

3. Create automation to copy the Available battery Energy to the number helper

In Settings / Automations & scenes / Automations add a new automation. Use the ⋮ at the right hand top and open the automation yaml editor and insert

description: Track Battery Energy Change
trigger:
  - platform: state
    entity_id:
      - sensor.envoy_<your_envoy_serial_number>_available_battery_energy
    not_to:
      - unknown
      - unavailable
condition: []
action:
  - service: input_number.set_value
    target:
      entity_id: input_number.<some_meaningful_name>
    data:
      value: "{{trigger.to_state.state | int(0)}}"
mode: single

Replace with the serial number of your envoy. Replace by the name you assigned to the Number helper. Then save the automation.

This should now start copying the values of the Available battery Energy into the some_meaningful_name Number, but only when the value updates, so may be a while when in stable battery condition.

3. Create template sensors to track battery charge and discharge.

If you have already templates defined in your configuration.yaml or a separate file, edit that file. If not yet edit configuration.yaml in the Home Assistant configuration folder. In there add:

template: !include templates.yaml

Then edit a new templates.yaml file in your configuration folder. Paste the template below:

- trigger:
    - platform: state
      entity_id: input_number.<some_meaningful_name>
      not_to:
        - unknown
        - unavailable
  sensor:
    - name: "Battery Lifetime Discharge"
      unique_id: battery_lifetime_discharge
      unit_of_measurement: "Wh" 
      icon: mdi:battery 
      state: "{{ this.state | int(0) + ([0, (trigger.to_state.state | int(0) - trigger.from_state.state | int(0))  * input_number.correction_factor / -100.0] | max | int(0))}}" 
      device_class: energy 
      state_class: total_increasing 
    - name: "Battery Lifetime Charge"
      unique_id: battery_lifetime_charge
      unit_of_measurement: "Wh" 
      icon: mdi:battery 
      state: "{{ this.state | int(0) + ([0, (trigger.to_state.state | int(0) - trigger.from_state.state | int(0)) * input_number.correction_factor / 100.0]| max | int(0))}}" 
      device_class: energy 
      state_class: total_increasing

Replace by the name you assigned to the Number helper. Change the name: and unique_id: fields to your preferred names. Replace input_number.correction_factor by the ones you want to use. Save the changed files.

4. Cycle Home assistant

To make the new templates active restarts Home Assistant after first verifying its a valid configuration in Developers Tools / Yaml.

This should start building lifetime charge and discharge data.

5. Tune conversion loss corrections

With an initial value of 100 for the input_number.correction_factor the correction factor is 1.0. After some initial runtime you may note the the Enphase App reports different, probably higher, values. This is most probably caused by conversion losses. Tune the input_number.correction_factor as needed.

[catsmanac]

@home-assistant close