[FEATURE] Stored Energy Cost Sensor (€/kWh) for Dynamic Battery Strategies

[rrozema]

Area of the proposal

Sensors, entities, or statistics

What problem would this solve?

To optimize dynamic energy management and accelerate ROI, users need to know the actual "cost price" of the energy currently stored in their battery.

Comparing this internal cost price against real-time grid import rates and export/feed-in tariffs allows Home Assistant (and automation strategies) to make smarter decisions—such as determining whether it is profitable to discharge to the grid, power household loads, or preserve the stored energy for upcoming peak prices.

Proposed solution

Add a new sensor (e.g., sensor.battery_stored_energy_cost) that continuously tracks the weighted average cost price of the energy currently stored in the battery, expressed in currency/kWh (e.g., €/kWh).

Why track €/kWh instead of cumulative total spent (€)?

• Invariance during discharge: When the battery discharges, the remaining energy retains the exact same cost per kWh. Only the total kWh count changes, meaning this sensor only needs updating during charging cycles.

• Modular & robust: Adding/removing battery units or recalibrating capacity won't corrupt historical cumulative cost tracking.

• Simple total value calculation: The instantaneous value of the energy inside the battery is simply:
  $$\text{Total Value (€)} = \text{Stored Energy Cost (€/kWh)} \times \text{Current Battery Energy (kWh)}$$

Calculation Logic during Charging

When the battery is charging ($\Delta E_{\text{in}} > 0$), the new stored energy cost per kWh ($C_{\text{new}}$) is calculated as a weighted average:
$$C_{\text{new}} = \frac{(E_{\text{old}} \times C_{\text{old}}) + (\Delta E_{\text{in}} \times P_{\text{charge}})}{E_{\text{old}} + \Delta E_{\text{in}}}$$

Where:
$E_{\text{old}}$ = Stored energy prior to charging step ($\text{kWh}$)
$C_{\text{old}}$ = Previous stored energy cost ($\text{€/kWh}$)
$\Delta E_{\text{in}}$ = Energy added in this step ($\text{kWh}$)
$P_{\text{charge}}$ = Instantaneous charge price ($\text{€/kWh}$)

Determining Instantaneous Charge Price ($P_{\text{charge}}$):

The price depends on the source powering the charge cycle:

1. 100% Solar / PV: $P_{\text{charge}} = \text{Export Tariff}$ (the opportunity cost of not exporting to the grid).
2. 100% Grid: $P_{\text{charge}} = \text{Import Tariff}$ (the active spot/contract rate including taxes/fees).
3. Mixed (PV + Grid): Weighted ratio based on current solar power generation vs. active grid import power:
   $$P_{\text{charge}} = \left( \frac{\text{Power}{\text{PV}}}{\text{Power}{\text{Total In}}} \times \text{Export Tariff} \right) + \left( \frac{\text{Power}{\text{Grid}}}{\text{Power}{\text{Total In}}} \times \text{Import Tariff} \right)$$

Example use case

Key Benefits & Use Cases

Arbitrage Decision Making: Discharge to the grid only when $\text{Export Price} > \text{Stored Energy Cost} + \text{Battery Degradation Margin}$.
Load Management: Avoid using battery energy for non-critical loads if the current grid import price happens to be lower than what it cost to charge the battery in the first place.
ROI Tracking & Strategy Optimization: Provides exact financial insight into charging efficiency and payback performance over time.

Who would benefit from this?

Most Omnibattery users

Alternatives or workarounds

No response

Additional context

No response

Confirmations

• I searched existing discussions and did not find the same proposal.
• This is a general feature idea, not a request to support a new battery brand or model.
• I understand that community interest and technical feasibility influence prioritization, and that no delivery date is guaranteed.
• I removed passwords, tokens, API keys, complete serial numbers, IP addresses, and other sensitive information.

[github-actions[bot]]

Thanks for the suggestion! 🙌

Here's how this works:

• Vote by clicking 👍 on the original post — not in the comments
• The more votes an idea gets, the higher it moves in the priority queue
• I review feature ideas periodically and implement the ones that benefit the most users

If your idea is very specific to your setup, it may not make it into the core integration — I'll try to suggest a workaround in that case.

Feel free to discuss details or alternatives below.

[TobiS87]

I have that loigic implemented in a pretty extensive AppDaemon Script. There are a few caveats to consider - eg the batteries efficiency and charging state (due to the discharge and charge prices being dependant on another you need to know if you want to discharge your energy or charge the battery). Therefore I am also calculating the saved amount of money due to the solar power and the cheaper energy stored and consumed when normally higher grid prices would be valid. Furthermore you have to consider jitter and calibrate the prices often due to the sensors not always being in sync with the batterie's SOC.

Furthermore I define to max grid charge price depending on the P85 highest Tibber Prices.

Could surely be implemented in the integration itself but surely needs more work than solely implementing a few Formulars.

[rrozema]

This suggestion is to define a way to keep track of a price for the energy stored in our batteries. In itself this suggestion doesn't do anything with that information yet.
Having a price for the energy can indeed enable a host of other features, but for now let's first define how to keep track of the value of the energy, what you can do once that price is known is a next step.

I too do have built something like this using 2 separate template sensors:

1. A sensor for the price for energy used, which takes the price for energy imported, the price for energy exported plus the power currently supplied by my solar and the power currently imported.
2. A sensor that takes the energy charged into the battery and the previous price for energy used to calculate the charging costs as per my suggestion above.

I have found however that many people only keep track of the accumulated costs and accumulated profits and don't keep track of the actual value for a battery's content. And consequently they need complex decisions to build a price based control methos. f.e. using fixed price levels or an average for the day like you do. This suggestion aims to create a unified method to keep track of the actual cost of the energy charged when we charged the battery, so we can properly determine if and how big a profit or loss we will make when we discharge the battery now, simply by comparing the charging costs with the current price because the sensor has the exact same unit of measurement: euro/kWh.

I did intentionally not share my implementation for the both sensors yet. I'm hoping to first get the discussion going on how to properly determine and keep track of a price for the energy once it is in our battery. The core of this suggestion is to keep track of the price in euro/kWh, instead of tracking the value of the total energy in euros like most people seem to do.

[rrozema]

I've implemented mine as a trigger template sensor as follows

template:
  - trigger:
      - trigger: state
        entity_id:
          - sensor.zendure_solarflow_1_stored_energy
        not_to:
          - "unavailable"
          - "unknown"
    sensor:
      - name: "Zendure Solarflow charging costs"
        unique_id: "f997992b-ddf1-44ed-8104-edffa5e68319"
        state: |-
          {%  set efficiency = 0.9025 %}
          {%  set current_price = states("sensor.electricity_meter_current_price_for_energy_used") | float %}
          {%  set costs_old = this.state | float(current_price * (1/efficiency)) %}
          {%  set soc_new = trigger.to_state.state | float %}
          {%  if this.attributes.soc is defined %}
          {%    set soc_old = this.attributes.soc | float(soc_new) %}
          {%  else %}
          {%    set soc_old = float(soc_new) %}
          {%  endif %}
          {%  set soc_delta = (soc_new - soc_old) | round(5) %}
          {% if soc_new <= 0.0 or soc_delta <= 0.0 %}
            {{ costs_old }}
          {% else %}
            {{ (((costs_old * soc_old) + (current_price * (1/efficiency) * soc_delta)) / soc_new) | round(10) }}
          {% endif %}
        state_class: measurement
        unit_of_measurement: "EUR/kWh"
        attributes:
          efficiency: |-
            {{ 0.9025 }}
          soc: |-
            {{ trigger.to_state.state | float }}
          price: |-
            {%  set current_price = states("sensor.electricity_meter_current_price_for_energy_used") | float %}
            {%  if this.attributes.price is defined %}
            {%    set price_old = this.attributes.price | float(current_price) %}
            {%  else %}
            {%    set price_old = float(current_price) %}
            {%  endif %}
            {%  set soc_new = trigger.to_state.state | float %}
            {%  if this.attributes.soc is defined %}
            {%    set soc_old = this.attributes.soc | float(soc_new) %}
            {%  else %}
            {%    set soc_old = soc_new %}
            {%  endif %}
            {%  set soc_delta = (soc_new - soc_old) | round(5) %}
            {% if soc_new <= 0.0 or soc_delta <= 0.0 %}
              {{ price_old }}
            {% else %}
              {{ (((price_old * soc_old) + (current_price * soc_delta)) / soc_new) | round(10) }}
            {% endif %}

Using this sensor I can easily see that today is a terrible day for my ROI on the battery: due to a solar deficit predictive charging had to charge from the grid while prices were rather high, resulting in the charging costs to rise to 0,3087eur/kWh. Luckily the prices will go up somewhat during the night, so I can still make some money when discharging the battery while the prices are higher than that:

[ffunes]

Hi,

I will implement the Stored Energy Cost sensor in Omnibattery 1.5.0.

My proposed definition is a persistent weighted-average cost in currency/kWh for the energy currently stored in each battery, plus an optional system aggregate. Charging contributions would include the source price and configured efficiency. Discharging would reduce the stored quantity without changing the remaining average cost.

Before implementation, please confirm:

1. Should the value be calculated on the AC side, including charge/discharge losses, or on the battery/DC side?
2. Should solar energy be valued at zero cost, at its current export opportunity value, or according to the effective “energy used” price from the discussion?
3. Should grid charging always use the all-in import price from [FEATURE] Support Separate Import and Export Electricity Prices #326?
4. Do you want one sensor per battery, one aggregate sensor, or both?
5. What should the sensor report after a restart, battery replacement or an unavailable initial state: restore the last value, become unknown, or reset?
6. Should the currency and unit be derived from the configured price source, rather than being fixed to EUR/kWh?

These decisions are important because “stored energy cost” and “stored energy opportunity value” can produce different results for solar-charged energy.

[rrozema]

As I commented before, I would rather have these calculations as a separate integration and not include the calculations into the omnibattery integration itself. Omnibattery should only be configured to read the sensors output by such integration. The 4 sensors I think the Omnibattery integration should take:

• imported energy price
• exported energy price
• battery energy price
• used energy price
  By putting the price calculations into a separate integration a user could later decide to create/use alternate integrations for different types of calculations, integrations per specific energy provider (f.e. in case they have some wild calculation method or whatever), etc. Plus, it saves you, @ffunes, of having to implement the calculations for each country, energy provider's situation, plus having to maintain them. Plus, if anyone's specific set of country, energy provider, etc. rules does not match those in available in any of the integrations, they can still implement their own rules for the prices using for example template sensors.

To answer your questions: in my opinion (and as demonstrated in #237):
1 - AC side (that's the only figure that matters financially). DC-fed solar energy can be valued at the same export price but with a different efficiency as DC power only needs to be converted once.

2 - solar energy should be valued at the "export price", i.e. the value that one would receive were all of the solar energy exported to the grid. Including taxes and surcharges per kWh, but without any additional periodical surcharges. This is for dynamic contracts most of the times the "import price" minus some fee for the energy provider. For variable and fixed contracts this is most of the times some contractually set tariff. I would suggest to let the user define and select a sensor and take the sensor's value instead of trying to implement logic that tries to catch all possible types of calculations.

3 - The price at which we charge our batteries is the same as the "price for energy used". The price for energy used can be calculated by first determining the ratio for each of the possible 3 sources for our energy, resulting in 4 different prices:
a - "import price" = price set by the energy provider for energy taken from the grid, measured as positive by one's whole-house metering (P1 meter)
b - "export price" = price set by the energy provider for energy put back into the grid, measured as negative by one's whole-house metering (P1 meter).
c - "battery price" = Floating average of the costs for charging the energy currently in the battery, includes the Round-Trip efficiency losses for losses both while charging and discharging the battery.
d - "used energy price" = the price for energy used in our house. Calculated from the previous 3 prices: If 100% of the power comes from the grid, the used price will be the import price, if 100% of the power used comes from solar, it will be the import price, if 100% comes from the battery, it will be the battery price. If a mix of the sources is used, that mix will have the value of the ratio between the sources that provide the power: f.e. 50% solar + 50% grid: used price is 0.5 * import price + 0.5 * export price.

The battery is always charged at the price for energy used. Like you described, the battery price only changes when the battery is charged. Discharging only changes the SOC, not the price of the energy in the battery. To calculate the total value of the energy in the battery you can just multiply the battery price (in Eur/kWh) with the current energy level (in kWh).

As can be easily seen, there is a circular dependency in this definition: the "battery price" depends on the price used and the "price for energy used" depends on the "battery price". There is however a ratio in the calculation in the "price for energy used": initially there will be no output from the battery, so the ratio for battery power will be 0, so the price for energy used can be calculated from export and import price alone. Only when the battery starts discharging the battery power will be > 0 and only then the battery price will be a component of the price for energy used.

4 - Aggregate sensors should be used by Omnibattery: always exactly 4 sensors should be configured there. A "prices integration" however can be setup alike the energy dashboard where there can be 0 or more sets of batteries, 0 or more grid connections and 0 or more solar connections can be configured. Even 0 or more generators can be configured for people that are fully off-grid and have no grid connection at all (this will then determine the import price based on fuel/kWh and fuel price). Internally the calculations are done on those configured components. But no matter the number or type of components configured the integration will always output the 4 sensors for import, export, battery and used energy prices. If you change the configuration, the output sensors will still be the same.

5 - restore last value.

6 - Currency should be the same on all 4 sensors used as an input to omnibattery. Currency can potentially be determined from the Home Assistant global setting for currency? So EUR/kWh or €/kWh or $/kWh or whatever currency is set there. The selection list for the 4 sensors can then be reduced to only show sensors that have the currency + '/kWh' as their unit_of_measurement.

[rrozema]

I found some problems in my implementation of the charge costs sensor. I will fix this and let you know what changed.

One problem is that currently the sensor uses the price for energy used in the home as the price for energy charged into the battery. This is conceptually wrong, resulting in the battery charging costs to be too low depending if home usage fully consumed the solar energy or not: the energy used to charge the battery is not from the home's used energy, it is from what's left over after the home's consumers have taken their part. Self-sufficiency is prio 1, charging the battery is prio 2 so if prio 1 used up all available cheap solar energy, the battery will be charged off of more expensive imported energy: the price for energy to charge will be higher than current implementation gives.

Another problem is with negative prices. In the current implementation efficiency further reduces the charging costs when prices are negative. That can never be the case, so I need to change that so that efficiency always works towards 0 never away from it.

[rrozema]

Here's a jinja script demonstrating how to determine the price of the energy charged into a battery. In this demo charging the battery is at priority 2, after house usage is subtracted from the energy available. By separating the energy sources we can determine exactly what the price is, no matter if the energy put into the battery is partly sourced from another battery, solar or the grid or a mix of these three. This concept is agnostic of the type of contract: it works for variable, fixed and dynamic contracts because it calculates the price depending on the mix of energy sources used to feed the battery.

To run this demo script, please paste it into your template editor or a markdown card, and replace the sensor names in the top 8 lines for the matching sensor names in your system. The top 5 are power sensors (W or kW), the 3 last ones are prices in eur/kWh. A sensor for the last one is most likely not available yet in your system (because to have that you'll need the logic in place we're trying to define here), for the purpose of running this demo you can set some fixed value at the line
{% set price_battery_out = states(battery_out_price_entity) | float %}.

          {% set import_entity = 'sensor.electricity_meter_power_consumption' %}
          {% set export_entity = 'sensor.electricity_meter_power_production' %}
          {% set production_entity = 'sensor.power_produced' %}
          {% set battery_out_entity = 'sensor.omnibattery_system_discharge_power' %}
          {% set battery_in_entity = 'sensor.omnibattery_system_charge_power' %}

          {% set import_price_entity = 'sensor.electricity_meter_energy_consumption_price' %}
          {% set export_price_entity = 'sensor.electricity_meter_energy_production_compensation' %}
          {% set battery_out_price_entity = 'sensor.zendure_solarflow_charging_costs' %}
           
          {% set unit_map = {'mW': 0.001, 'W': 1.0, 'kW': 1000.0, 'MW': 1000000.0} %}
                               
          {# grid import #}
          {% set import_unit = state_attr(import_entity, 'unit_of_measurement') %}
          {% set power_import = (states(import_entity) | float(0)) * (unit_map.get(import_unit, 0)) %}
          {% set price_import = states(import_price_entity) | float %}
           
          {# grid export #}
          {% set export_unit = state_attr(export_entity, 'unit_of_measurement') %}
          {% set power_export = (states(export_entity) | float(0)) * (unit_map.get(export_unit, 0)) %}
          {% set price_export = states(export_price_entity) | float %}
           
          {# solar production #}
          {% set production_unit = state_attr(production_entity, 'unit_of_measurement') %}
          {% set power_production = (states(production_entity) | float(0)) * (unit_map.get(production_unit, 0)) %}
           
          {# battery out #}
          {% set battery_out_unit = state_attr(battery_out_entity, 'unit_of_measurement') %}
          {% set power_battery_out = (states(battery_out_entity) | float(0)) * (unit_map.get(battery_out_unit, 0)) %}
          {% set price_battery_out = states(battery_out_price_entity) | float %}
         
          {# battery in #}
          {%- set battery_in_unit = state_attr(battery_in_entity, 'unit_of_measurement') %}
          {%- set power_battery_in = (states(battery_in_entity) | float(0)) * (unit_map.get(battery_in_unit, 0)) %}

          {%- set prio_1_total = max(0.0, (power_battery_out + power_production + power_import) - (power_battery_in + power_export)) | round(3) %}
          {%- set prio_1_battery = max(0.0, min( power_battery_out, prio_1_total)) | round(3) %}
          {%- set prio_1_solar = max(0.0, min( power_production, (prio_1_total - prio_1_battery))) | round(3) %}
          {%- set prio_1_grid = max(0.0, min( power_import, (prio_1_total - (prio_1_battery + prio_1_solar)))) | round(3) %}

          {%- set price_prio_1 = None if prio_1_total == 0.0 else ((prio_1_battery / prio_1_total) * price_battery_out) + ((prio_1_solar / prio_1_total) * price_export) + ((prio_1_grid / prio_1_total) * price_import) %}
           
          {%- set prio_1_total_left = max( 0.0, (power_import + power_production + power_battery_out) - prio_1_total) %}
          {%- set prio_1_battery_left = max( 0.0, power_battery_out - prio_1_battery) %}
          {%- set prio_1_solar_left = max( 0.0, power_production - prio_1_solar) %}
          {%- set prio_1_grid_left = max( 0.0,(power_import - prio_1_grid)) %}

---- Prio 1: Home usage ----------
total:    {{ prio_1_total }}W @ {{ price_prio_1 | round(4) if price_prio_1 | is_number else 'unavailable' }} leaving {{ prio_1_total_left }}W
battery:  {{ prio_1_battery }}W @ {{ price_battery_out | round(4) }} leaving {{ prio_1_battery_left }}W
solar:    {{ prio_1_solar }}W @ {{ price_export | round(4) }} leaving {{ prio_1_solar_left }}W
grid:     {{ prio_1_grid }}W @ {{ price_import | round(4) }} leaving {{ prio_1_grid_left }}W

          {%- set prio_2_total = min( prio_1_total_left, power_battery_in) | round(3) %}
          {%- set prio_2_battery = max( 0.0, min( prio_1_battery_left, prio_2_total)) | round(3) %}
          {%- set prio_2_solar = max( 0.0, min( prio_1_solar_left, (prio_2_total - prio_2_battery))) | round(3) %}
          {%- set prio_2_grid = max( 0.0, min( prio_1_grid_left, (prio_2_total - (prio_2_battery + prio_2_solar)))) | round(3) %}

          {%- set price_prio_2 = None if prio_2_total == 0.0 else ((prio_2_battery / prio_2_total) * price_battery_out) + ((prio_2_solar / prio_2_total) * price_export) + ((prio_2_grid / prio_2_total) * price_import) %}

          {%- set prio_2_total_left = max( 0.0, (prio_1_total_left - prio_2_total)) %}
          {%- set prio_2_battery_left = max( 0.0, (prio_1_battery_left - prio_2_battery)) %}
          {%- set prio_2_solar_left = max( 0.0, (prio_1_solar_left - prio_2_solar)) %}
          {%- set prio_2_grid_left = max( 0.0, (prio_1_grid_left - prio_2_grid)) %}

----- Prio 2: Battery charging ---
total:    {{ prio_2_total }}W @ {{ price_prio_2 | round(4) if price_prio_2 | is_number else 'unavailable' }} leaving {{ prio_2_total_left }}W
battery:  {{ prio_2_battery }}W @ {{ price_battery_out | round(4) }} leaving {{ prio_2_battery_left}}W
solar:    {{ prio_2_solar }}W @ {{ price_export | round(4) }} leaving {{ prio_2_solar_left }}W
grid:     {{ prio_2_grid }}W @ {{ price_import | round(4) }} leaving {{ prio_2_grid_left }}W

          {%- set prio_3_total = min( prio_2_total_left, power_export) %}
          {%- set prio_3_battery = max( 0.0, min( prio_2_battery_left, prio_3_total)) %}
          {%- set prio_3_solar = max( 0.0, min( prio_2_solar_left, (prio_3_total - prio_3_battery))) %}
          {%- set prio_3_grid = max( 0.0, min( prio_2_grid_left, (prio_3_total - (prio_3_battery + prio_3_solar)))) %}

          {%- set price_prio_3 = None if prio_3_total == 0.0 else ((prio_3_battery / prio_3_total) * price_battery_out) + ((prio_3_solar / prio_3_total) * price_export) + ((prio_3_grid / prio_3_total) * price_import) %}

----- Prio 3: Export -------------
total:    {{ prio_3_total }}W @ {{ price_prio_3 | round(4) if price_prio_3 | is_number else 'unavailable' }} actual selling price {{price_export }}
battery:  {{ prio_3_battery }}W @ {{ price_battery_out | round(4) }}
solar:    {{ prio_3_solar }}W @ {{ price_export | round(4) }}
grid:     {{ prio_3_grid }}W @ {{ price_import | round(4) }}

This outputs something like

---- Prio 1: Home usage ----------
total: 1307.0W @ 0.1664 leaving 1974.0W
battery: 0.0W @ 0.1691 leaving 0.0W
solar: 664.0W @ 0.1532 leaving 0.0W
grid: 643.0W @ 0.18 leaving 1974.0W

----- Prio 2: Battery charging ---
total: 1974.0W @ 0.18 leaving 0.0W
battery: 0.0W @ 0.1691 leaving 0.0W
solar: 0.0W @ 0.1532 leaving 0.0W
grid: 1974.0W @ 0.18 leaving 0.0W

----- Prio 3: Export -------------
total: 0.0W @ unavailable actual selling price 0.1532
battery: 0.0W @ 0.1691
solar: 0.0W @ 0.1532
grid: 0.0W @ 0.18

Where prio 1 is the price for the energy used in the house (self consumption has highest priority). Then at Prio 2 is my battery: everything that is left after house consumption is subtracted from the original sources can be used for charging the battery. Then what is still left after the battery was charged must be exported at prio 3 (or dumped in case of an off-grid installation).
For every priority the demo shows how much W was used from each of the 3 sources Battery, Solar and Grid, plus the price for energy from that source. Then to get the price for the total the individual prices are summed per the ratio of each source in the total. Since the mixes are different for each priority, the total price will be different too.

So the 1307W used in my house costs 0.1664 eur/kWh, while the 1974W put into my battery costs 0.18 eur/kWh, because all energy available from my solar was already used by my house. I don't currently export any left-over energy, so there is currently no price for that (or we would have a divide by zero error).