How to monitor Solarbank battery efficiency and health

[thomluther]

How to monitor Solarbank battery efficiency and health

The Solarbank itself does not provide any metrics to get an idea about the battery efficiency or its age and healthiness. Here I want to describe which metrics and entities I implemented to track both.

Solarbank battery age, healthiness and overall efficiency

First of all, I'm not a battery expert and there are probably many metrics required to estimate a proper fitness level for a battery over lifetime. From my base knowledge, following 2 fundamental metrics can help in this regard:

• Number of full charge/discharge cycles over lifetime
• Remaining battery capacity compared to its nominal capacity

Anker claims that their Solarbank E1600 LPFE battery will survive 6000 cycles while still providing 80% of the capacity. So how can you track that if you have no indications in the Anker App for it? And how can you track the efficiency of the battery to get an understanding of the energy loss that occurs by charging and discharging?
Using Home Assistant and the Anker Solix integration, you can establish template entities that will help tracking these metrics, at least at an approximate level.

Following is the implementation approach:

1. Create total increasing template entities for your charge and discharge energy of the Solarbank battery
2. Create utility meter helpers from the charge and discharge energies to reflect their totals
3. Create template sensor to calculate full discharge cycles from the total discharge energy
4. Create template sensor to calculate overall battery efficiency
5. Create trigger based template sensor to calculate discharge energy for last discharge interval and compare the change with the nominal energy change

When you created those entities and assigned them to your solarbank device, you will be able to track them with the other device entities provided by the integration. Following is an example with the created entities:

This was taken at the end of a cloudy day, where only 13% have been charged/discharged. And as you see in the daily efficiency, this can be really low if the battery just operates at the lower range compared to the overall efficiency.

The next sections will describe each implementation step for those additional solarbank entities in more detail.

1. Template entities for charge and discharge energy

Separate tracking for charge and discharge energy provides the base for many things that you want to monitor for your solarbank. For example, the HA energy dashboard requires separate total increasing energy entities to track battery charge and discharge energy. The recommended way to create a total increasing energy entity is to create a Riemann Integral helper over a power sensor that accumulates the energy (power over time) and is per definition a total increasing sensor. To make sure the integral value is really only increasing, you need to ensure that the source power entity only provides positive values. Since the Anker Solix integration only provides a single entity for the battery power which is positive for charging and negative for discharging power, you have to separate those values first with another set of template sensors. This approach is explained in the discussion thread for Solarbank integration into the Energy Dashboard.

At this point we assume you created your total increasing charge and discharge entities accordingly, and you hopefully integrated them properly into your energy dashboard. In the following section we will refer to them as:

• sensor.solarbank_charge_kwh
• sensor.solarbank_discharge_kwh

2. Utility meter helper to reflect total energies

While the previous entities already reflect an ever increasing energy value which is sufficient for the energy dashboard, they might not reflect the total value since your implementation of the sensors is somewhat delayed from the solarbank installation. Since it is not that easy to adjust or calibrate the total increasing entities, and doing the same could also mess up your continuous energy tracking in the dashboard, we create utility meter entities for the total increasing energies. Utility meter entities can be optionally reset at regular intervals, but can also be calibrated via a service (now action) to reflect to correct value. The recommended way to create those total energy utility meters is from the UI while using following settings:

• Name: Solarbank charge kWh total and Solarbank discharge kWh total
• Source sensor: sensor.solarbank_charge_kwh and sensor.solarbank_discharge_kwh
• Reset cycle: None
• You can use defaults for remaining fields

Once both utility meters are setup, they start increasing with their source entity. Next step is to calibrate both for the real value since the installation of the solarbank. Typically you can find the overall charge and discharge energy of your solarbank battery in the Anker mobile App, when you look at the energy statistics of your system. Make sure to select the full range since the installation to get the overall total amounts. With those amounts you can calibrate your total energy utility meters.
You can use the UI mode in the HA developer tools, services (now Actions) and then look for the utility_meter.calibrate service. Use it to calibrate both utility meters subsequently to their correct value. Here is the YAML code for this service as an example:

service: utility_meter.calibrate
target:
  entity_id: sensor.solarbank_charge_kwh_total
data:
  value: 123.456

Finally check in the developer tools that your calibrated utility meters now show the correct value. From this point on, they continue to represent the overall energies for your battery. However, they may differ slightly from the values in the Anker app after some time since the Anker cloud and the HA energy entities integrate separately from the provided/available power values.

3. Template sensor to calculate full discharge cycles from the total discharge energy

This is a simple template sensor that you can create in the UI. It simply divides the total discharge energy by the number of nominal energy for a full discharge cycle. You need to be aware, that there are various classifications what counts as full discharge cycle, and I have no clue what classifications where used for the Solarbank cycle specification. So it is an approximate value to give you a clue how many full cycles your solarbank battery may have been done. For simplicity I selected 90% of 1600 Wh assuming that 10 % SOC reserve is used, which resolves to 1340 Wh nominal per full discharge cycle. Of course, those nominal 1340 Wh cannot be discharged over lifetime during a full cycle after the battery capacity is degrading. So you can adjust this divider as desired to represent an average full discharge cycle.

When you create the template sensor from the UI helpers, e.g. sensor.solarbank_battery_cycles, you can use following templates considering that sensor.solarbank_discharge_kwh_total is the total discharge energy utility meter, that you created and calibrated earlier.

State template:

{% set new = states('sensor.solarbank_discharge_kwh_total')|float(0) %}
{{ this.state if new == 0 else (new/1340*1000)|round}}

Availability template in case you define the sensor via YAML:

{{has_value('sensor.solarbank_discharge_kwh_total')}}

The sensor unit should be set to %. The rest of the sensor definition you can declare as desired.

Hint:

Since the 2024.07 HA release, you can also assign any UI template entity to your Solarbank device, which will enable the display of this entity when you watch your solarbank device or when you filter for solarbank device entities. Following is just an example how your Solarbank device entities may look like after assigning additional UI template entities.

4. Template sensor to calculate overall battery efficiency

Creating an entity to reflect the overall battery efficiency is not that difficult once you have separate entities reflecting the total charge and discharge energy. Since those entities cover multiple cycles over time, the time difference you always have between the charge and later discharge energy can be ignored. This is completely different if you want to track efficiency for each battery cycle, which is explained further below.

When you create the template sensor from the UI helpers, e.g. sensor.solarbank_battery_efficiency, you can use following templates considering that sensor.solarbank_charge_kwh_total and sensor.solarbank_discharge_kwh_total are the total energy utility meters, which you created and calibrated earlier.

State template:

{% set charge = states('sensor.solarbank_charge_kwh_total')|float(0) %}
{% set discharge = states('sensor.solarbank_discharge_kwh_total')|float(0) %}
{{min(100,discharge/charge*100)|round(1) if charge > 0 else 0}}

Availability template in case you define the sensor via YAML:

{{has_value('sensor.solarbank_charge_kwh_total') and has_value('sensor.solarbank_discharge_kwh_total')}}

The sensor unit should be set to %. The rest of the sensor definition you can declare as desired.

5. Template sensor to calculate actual battery capacity

Following is the base concept to calculate an approximate remaining capacity for any battery. We know the nominal battery capacity of 1600 Wh for the solarbank. The SOC reflects the battery charge level, which is always 100 % when no more power can be loaded to the battery. However 100 % can mean the nominal capacity, maybe more if extra capacity is factored into the device, but for sure less when the capacity degrades over time. When you count the discharge energy for a discharge interval, you can compare how much energy you still got out of the battery for a certain discharge % and compare this energy with the nominal discharge energy assuming a new battery provides 1600 Wh for 100%.

First I implemented this calculation via input number helpers and an automation. But I quickly realized, that this entity needs long term recording, so it must be included in HA long term statistics to see how it evolves over months or years. Entities must comply certain requirements to be tracked in long term statistics. A main requirement is that it must be a sensor with a state class, that is either classified as total, total_increasing or measurement. That means input number helpers to store the calculated result from an automation do not make it into long term history tracking at all.

For that reason I implemented a trigger based template sensor which does the same and which is also recorded in long term statistics. So it should be possible to see the average capacity and its degradation over many months or years instead of just knowing an estimated actual value.
Since this is a trigger based template sensor, you cannot create it yet in the UI. You must create it in the configuration.yaml or a children file for template sensors, that is included into the configuration.yaml.

Following is the code. You need to replace following entities with yours:

• sensor.sb_e1600_mode for the solarbank status
• sensor.sb_e1600_state_of_charge for the solarbank battery SOC
• sensor.solarbank_discharge_kwh_total for the total discharge energy created earlier

I selected a device class of battery for the sensor, this will use automatic battery icons including coloring based on sensor value, but you can also skip the device class. Furthermore you can define a fixed icon if desired.

Note:

Even if the sensor value typically will be calculated maximum once per day when discharge is larger than defined significance of 20 %, you may see fluctuations in this value resulting from accuracy of your discharge energy aggregation, as well as from the actual accuracy of charge level percentage reflected by the solarbank. Any SOC percentage below 100 % may be offset and should typically recalibrate internally when there is a full charge/discharge cycle. The value must really be seen as a long term indication to understand how its value average and trend is evolving over months and years.

Expand to see sensor code

- template:
  # Sensor for Solarbank battery capacity estimation
  - trigger:
      # trigger when solarbank mode state changed
      - platform: state
        id: mode
        entity_id: sensor.sb_e1600_mode
        not_to:
          - "unknown"
          - "unavailable"
          - "undefined"
      # trigger for initial setting upon restart or template reload
      - platform: homeassistant
        event: start
        id: start
      - platform: event
        event_type: event_template_reloaded
        id: start
    action:
      - alias: "Wait until all required sensors are reloaded upon HA restart or template reload"
        wait_template: "{{has_value('sensor.solarbank_battery_capacity_remaining') and has_value('sensor.sb_e1600_mode') and has_value('sensor.solarbank_discharge_kwh_total') and has_value('sensor.sb_e1600_state_of_charge')}}"
        timeout: "00:00:30"
    sensor:
      - name: "Solarbank battery capacity remaining"
        unique_id: "solarbank-battery-capacity-remaining"
        unit_of_measurement: "%"
        device_class: "battery"
        state_class: "measurement"
        state: >
            {% set saved_soc = this.attributes.last_soc|default(0)|float(0) %}
            {% set saved_wh = this.attributes.last_discharge_wh|default(0)|float(0) %}
            {% set wh = states('sensor.solarbank_discharge_kwh_total')|float(0)*1000 %}
            {% set soc = states('sensor.sb_e1600_state_of_charge')|float(0) %}
            {% set mystate = this.state if this.state not in ["unknown","unavailable","undefined"] else 0 %}
            {% if trigger.id == 'mode' and trigger.to_state.state not in ["discharge","unknown","unavailable","undefined",none] and 0 < saved_wh < wh and (saved_soc-soc) >= 20 %}
              {# calculate new capacity percentage if at least 20% discharged for significance #}
              {% set mystate = ((wh-saved_wh)/(1600/100*(saved_soc-soc))*100)|round %}
            {% endif %}
            {{mystate}}
        attributes:
          last_soc: >
            {% set mystate = this.attributes.last_soc|default(0)|float(0) %}
            {% if trigger.id == 'mode' and trigger.to_state.state == "discharge" %}
                {# save new SOC when discharging starts at higher SOC #}
                {% set soc = states('sensor.sb_e1600_state_of_charge')|float(0) %}
                {% set mystate = soc if mystate < soc else mystate %}
            {% elif trigger.id == 'mode' %}
                {# reset saved discharge SOC if not discharging #}
                {% set mystate = 0 %}
            {% endif %}
            {{mystate|round}}
          last_discharge_wh: >
            {% set mystate = this.attributes.last_discharge_wh|default(0)|float(0) %}
            {% if trigger.id == 'mode' and trigger.to_state.state == "discharge" %}
                {# save new discharge Wh count when discharging starts at higher SOC #}
                {% set soc = states('sensor.sb_e1600_state_of_charge')|float(0) %}
                {% set wh = states('sensor.solarbank_discharge_kwh_total')|float(0)*1000 %}
                {% set mystate = wh if this.attributes.last_soc|default(0)|float(0) < soc else mystate %}
            {% elif trigger.id == 'mode' %}
                {# reset saved discharge Wh if not discharging #}
                {% set mystate = 0 %}
            {% endif %}
            {{mystate|round}}
        availability: "{{has_value('sensor.sb_e1600_mode') and has_value('sensor.solarbank_discharge_kwh_total') and has_value('sensor.sb_e1600_state_of_charge')}}"

Attention:

Trigger based template sensors will be initialized with a state of unknown during initial registration (HA restart or template sensor reload) until they are triggered the first time and can resolve their state. Also the sensor attributes may be undefined until triggered the first time. Therefore, the sensor templates must consider initial setup conditions properly with default statements to avoid errors in the HA logs when accessed sensor attributes are not defined yet.
Furthermore, when the templates are executed they have no access to the new state or attribute values that are actually being set for the sensor. In the templates you can only access the sensor state objects from before or after the trigger condition, but this is always before the new state or attributes are evaluated.

Solarbank battery cycle efficiency

As described in previous sections, the overall battery efficiency is easy to track. However, if you want to track the efficiency for each battery cycle it becomes more difficult. The reason is that you have to consider the time difference when the charge and discharge energies accumulate. Furthermore you cannot use daily utility meters which typically reset at a fixed time (usually midnight), because when you want to track a full 'solar' cycle that includes a battery, the battery discharge can extend until next day in the morning when solar production starts again. Therefore you need a capability to dynamically trigger a reset of the energy utility meters that are supposed to count entities based on a full solar cycle.

HA provides a service to reset a utility meter entity, however this only works against the select.* entity of a utility meter, which is only created when you define a utility meter with at least one tariff.

To summarize, for entities that you want to count for a full solar cycle, you need following:

1. A utility meter with one tariff without regular reset
2. An appropriate trigger to indicate the start of a new solar cycle. This of course must be triggered only once per day.
3. An automation that performs the utility meter reset via the service

1. Utility meter with tariff to count charge and discharge energy for a solar cycle

The required utility meters can be created easily from the UI as helper entities with following settings:

• name: Solarbank charge kWh and Solarbank discharge kWh
• source entity: sensor.solarbank_charge_kwh and sensor.solarbank_discharge_kwh
• reset cycle: None
• supported tariffs: solarcycle
• sensor always available: Can be switched ON

Keep the defaults for the other settings. This will create 2 entities for each utility meter. Following entities will be available once finished:

• select.solarbank_charge_kwh
  • sensor.solarbank_charge_kwh_solarcycle
• select.solarbank_discharge_kwh
  • sensor.solarbank_discharge_kwh_solarcycle

2. Trigger for new solar cycle start

A good trigger for the solar cycle start might be when your solarbank starts production again. It might be also when the sun exceeds a certain elevation. Or it might be when your inverter starts, which is for sure a good solar cycle trigger when the solarbank is not installed temporarily, for example in winter. Multiple triggers may be possible which you can use in the automation. Here I show you an example that I implemented in the form of a trigger based template sensor, which holds its last reset time stamp as state and provides an attribute that is indicating whether it was reset today or not. I use that as a common source for anything that needs to be triggered once for each solar cycle start and it allows easy monitoring when the start was triggered the last time.

Basically the sensor triggers when the solarbank mode changes into a state that indicates solar power. The other trigger comes from my inverter integration once the inverter becomes reachable, and another time based trigger after midnight. Those are required to trigger a potential solar cycle start when the solarbank is not installed or available.

Following are the entities that you need to replace in the template code:

• sensor.sb_e1600_mode for your solarbank mode entity
• binary_sensor.hoymiles_hm_600_reachable for your inverter powered on entity if applicable

If you don't have a proper entity to indicate an inverter start, you can also remove this reachable trigger and the associated statements in the state and attribute templates. You also need to keep in mind that the inverter will not start together with the solarbank, when any charge priority is configured with the MI80 or the 0 W output switch. In that case, the solarbank starts charging in the morning, but the inverter will stay off since it will not get any DC power until the solarbank starts bypassing PV power to the inverter. In that case, only the solarbank mode state change will be a trigger for the solar cycle start. So you must cover all mode states that may occur during potential solar production.

Expand to see sensor code

# Sensor for daily utility meter cycle restart, considering daily energy consumption may proceed until next day with battery
template:
  - trigger:
      # trigger when charging or bypass of Solarbank starts
      - platform: state
        id: charge
        entity_id: sensor.sb_e1600_mode
        to:
          - charge
          - charge_priority
          - charge_bypass
          - bypass
          - full_bypass
      # check if inverter went on
      - platform: state
        id: reachable
        entity_id: binary_sensor.hoymiles_hm_600_reachable
        to: "on"
      # trigger on new day to update boolean attribute today or reset if solarbank not discharging
      - platform: time
        id: newday
        at: "00:00:01"
    sensor:
      - name: "Solar cycle start"
        unique_id: "solar_cycle_start"
        icon: mdi:restore
        state: >
          {% set mystate = this.state %}
          {% if not has_value(this.entity_id) %}
            {# initial setting #}
            {% set mystate = now().isoformat() %}
          {% elif now().day != (mystate|as_datetime|as_local).day %}
            {# avoid state update when triggered by time platform but still discharging #}
            {% if trigger.id == 'charge' or (trigger.id == 'reachable' and not has_value('sensor.sb_e1600_mode')) or (trigger.id == 'newday' and not is_state('sensor.sb_e1600_mode','discharge')) %}
              {# reset when charging or bypass starts / inverter switches on the next day, or when next day and solarbank not discharging #}
              {% set mystate = now().isoformat() %}
            {% endif %}
          {% endif %}
          {{mystate}}
        attributes:
          today: >
            {# Boolean to indicate whether reset was done today #}
            {{not has_value(this.entity_id) or now().day == (this.state|as_datetime|as_local).day or
            ( trigger.id == 'newday' and not is_state('sensor.sb_e1600_mode','discharge')) or
            ( trigger.id == 'charge' and now().day != (this.state|as_datetime|as_local).day) or
            ( trigger.id == 'reachable' and not has_value('sensor.sb_e1600_mode'))}}

Note:

Trigger based template sensors can only be defined in configuration.yaml or an included child yaml. Those sensors will also be unknown until triggered the first time after initial load.

3. Automation to reset your solar cycle utility meters

Following automation can be used to reset your utility meters for each solar cycle start. It will cover also situations when a state change of the solar cycle start template sensor is triggered by template reload or HA restart actions.

Expand to see automation code

alias: Utility meter reset
description: Reset solar cycle utility meters
trigger:
  - platform: state
    alias: Solar cycle start changed
    id: reset
    entity_id:
      - sensor.solar_cycle_start
    not_to:
      - unavailable
      - unknown
condition: []
action:
  - alias: >-
      Ensure some delay in case reset was triggered by HA restart circumstances to ensure all entities have recovered their latest state
    delay:
      hours: 0
      minutes: 0
      seconds: 10
      milliseconds: 0
  - alias: Reset Solarbank daily discharge utility meter
    if:
      - alias: Check utility meter was not already reset today
        condition: template
        value_template: >-
          {% set lastreset = state_attr('sensor.solarbank_discharge_kwh_solarcycle','last_reset') %}
          {% set reset = states('sensor.solar_cycle_start') %}
          {{ reset not in ['unknown','unavailable'] and lastreset != None and (lastreset == '' or (lastreset|as_datetime|as_local).day != (reset|as_datetime|as_local).day) }}
    then:
      - alias: Reset select entity of utility meter
        service: utility_meter.reset
        data: {}
        target:
          entity_id:
            - select.solarbank_discharge_kwh
  - alias: Reset Solarbank daily charge utility meter
    if:
      - alias: Check utility meter was not already reset today
        condition: template
        value_template: >-
          {% set lastreset = state_attr('sensor.solarbank_charge_kwh_solarcycle','last_reset') %}
          {% set reset = states('sensor.solar_cycle_start') %}
          {{ reset not in ['unknown','unavailable'] and lastreset != None and (lastreset == '' or (lastreset|as_datetime|as_local).day != (reset|as_datetime|as_local).day) }}
    then:
      - alias: Reset select entity of utility meter
        service: utility_meter.reset
        data: {}
        target:
          entity_id:
            - select.solarbank_charge_kwh
mode: queued
max: 5

Template sensor for daily battery efficiency

When you create the template sensor from the UI helpers, e.g. sensor.solarbank_battery_efficiency_daily, you can use following templates considering that sensor.solarbank_charge_kwh_solarcycle and sensor.solarbank_discharge_kwh_solarcycle are the daily energy utility meters, which you created earlier.

State template:

{% set charge = states('sensor.solarbank_charge_kwh_solarcycle')|float(0) %}
{% set discharge = states('sensor.solarbank_discharge_kwh_solarcycle')|float(0) %}
{{min(100,discharge/charge*100)|round(1) if charge > 0 else 0}}```

Availability template in case you define the sensor via YAML:

{{has_value('sensor.solarbank_charge_kwh_solarcycle') and has_value('sensor.solarbank_discharge_kwh_solarcycle')}}

The sensor unit should be set to %. The rest of the sensor definition you can declare as desired.

When you have some history data available for this daily sensor, you can see how it increases from 0 % in the evening during discharge start until ~80% in the night/morning when the discharge is fully completed. At weak PV days, the battery efficiency can also be lower as seen at the last day of the history.

Attention:

In case the battery is not empty before next solar cycle starts, this energy is dropped during utility meter reset and may cause an efficiency offset for the current cycle calculation since you potentially discharge not only the new daily energy, but also the remaining energy from the previous day.

[Speedliner]

Great instructions, thank you very much!

Could you possibly also share the code for the dashboard or the other health sensors that you showed as examples above?

[thomluther]

Actually there is just one card I used for the screenshots, the other is the device view after you assigned any UI template sensors to your solarbank device.
For the dashboard card I used the custom card multiple-entity-row which you have to install first via HACS before you can use the custom card below:

type: entities
title: Solarbank Health & Efficency
entities:
  - type: custom:multiple-entity-row
    entity: sensor.solarbank_battery_efficiency_daily
    name: Efficiency
    icon: mdi:percent-box-outline
    secondary_info: Daily
    show_state: false
    entities:
      - entity: sensor.solarbank_charge_kwh_solarcycle
        name: Charge
        format: precision3
        styles:
          text-align: right
          font-size: 12px
          width: 80px
      - entity: sensor.solarbank_discharge_kwh_solarcycle
        name: Discharge
        format: precision3
        styles:
          text-align: right
          font-size: 12px
          width: 80px
      - entity: sensor.solarbank_battery_efficiency_daily
        name: Efficency
        format: precision1
        styles:
          text-align: right
          width: 60px
  - type: custom:multiple-entity-row
    entity: sensor.solarbank_battery_efficiency
    name: Efficiency
    secondary_info: Total
    show_state: false
    entities:
      - entity: sensor.solarbank_charge_kwh_total
        name: Charge
        format: precision3
        styles:
          text-align: right
          font-size: 12px
          width: 80px
      - entity: sensor.solarbank_discharge_kwh_total
        name: Discharge
        format: precision3
        styles:
          text-align: right
          font-size: 12px
          width: 80px
      - entity: sensor.solarbank_battery_efficiency
        name: Efficency
        format: precision1
        styles:
          text-align: right
          width: 60px
  - type: custom:multiple-entity-row
    entity: sensor.solarbank_battery_capacity_remaining
    name: Health
    icon: mdi:battery-heart-variant
    secondary_info: Battery
    show_state: false
    entities:
      - entity: sensor.sb_e1600_mode
        name: Mode
        styles:
          text-align: right
          width: 120px
      - entity: sensor.solarbank_battery_cycles
        name: Cycles
        format: precision0
        styles:
          text-align: right
          width: 60px
      - entity: solarbank-battery-capacity-remaining
        name: Capacity
        format: precision0
        styles:
          text-align: right
          width: 60px

[surfincool]

hi specialists.....
if it possible to get a step by step for the integration of this script......
it would be fine for me to see zyklen usw.
ok I can spend time to learn but there is no time.....

or is on YT a video...... maybe in German ...... to get the script into my HA

thanks
Eberhard

[thomluther]

@surfincool I don't think there is a specific video to explain all the documented steps for this in more detail.
But there are plenty of videos to learn HA basics for templates, helper, sensors etc. So when you learned the basics, and I strongly recommend to invest that time if you want to leverage HA capabilities, then it should be fairly simple to follow the instructions above hopefully.

[surfincool]

Hallo
Vielleicht ist das der richtige Weg........aber ich denke, du denkst zu prof. .....es wäre schön zu sehen, wie oft meine Batterien aufgeladen sind.... für mich ist es, darüber nachzudenken, ob es die Zeit zum Lernen oder die Zeit zum Klicken ist ....... du hast einen tollen Job mit der Integration gemacht (ich nehme meinen Hut ab)
But for u is the integration of the helpers a minimum of time....for me maybe weeks......
I can live without..... but it would be nice.

[thomluther]

Hi @surfincool , if you follow the instructions above, you should be able to create the necessary helpers. I documented all the parameters that should be changed from the defaults, so it should not be difficult, also for newbees.

[surfincool]

maybe ...... has one of the specialist´s time to make a video .......example-......1. go to ......2. do.....

[thomluther]

I updated the trigger based sensor for remaining capacity since there may be errors logged if the state is set to none as documented. This should be an accepted state for numeric sensors, but obviously it causes an exception in core for state evaluation. There is actually an issue open against core.
I set the state now to 0 if no previous value is available and also added triggers for HA restart or template reloads, so the sensor value does not remain unknown for long time. And with the wait for state action, it should hopefully remain always at last known value even across reloads and restarts in various situations. I want to avoid mainly that is may reset to 0 upon reloads or restarts, but setting it to none does not seem to be accepted while the issue is not fixed for numeric trigger based sensors.