Add "Solar Cost Saving" option to native Energy Dashboard

@severity8714 dane here. Looking for the exact same solution.

What is your nettopower_salg sensor?

Did you just use the Energi data service for price or hour? What about taxes and the above 7000 kr rule for taxation?

Super helpful If you are able to post/explain your solution

I haven’t done anything about the 7000 kr tax rule, since i really don’t expect me to have that amount of payback for my exported power.

My Nettopower_salg sensor is a template i created, using the nordpool integration to calculate the price.
This shows the current sales price to Nettopower, and also the sales price for the next 48 hours, as long as the nordpool sensor also has the next 48 hours (which it usually has)

  - platform: template
    sensors:
      nettopower_salg:
        value_template: '{{ (states("sensor.nordpool_kwh_dk2_dkk_5_10_0")|float - 0.00375 - 0.000875 - 0.04)|round(3, floor) }}'
        friendly_name: "Nettopower salgspris"
        unit_of_measurement: "DKK/kWh"
        unique_id: nettopower_salg
        attribute_templates:
          today: >
            {% if state_attr('sensor.nordpool_kwh_dk2_dkk_5_10_0', 'today') %}
              {% set ns = namespace(prices=[]) %}
              {% for h in range(24) %}
                {% set ns.prices = ns.prices + [(float(state_attr('sensor.nordpool_kwh_dk2_dkk_5_10_0', 'today')[h]) - 0.00375 - 0.000875 - 0.04) | round(3, floor)] %}
              {% endfor %}
              {{ ns.prices }}
            {% endif %}
          tomorrow: >
            {% if state_attr('sensor.nordpool_kwh_dk2_dkk_5_10_0', 'tomorrow') %}
              {% set ns = namespace(prices=[]) %}
              {% for h in range(24) %}
                {% set ns.prices = ns.prices + [(float(state_attr('sensor.nordpool_kwh_dk2_dkk_5_10_0', 'tomorrow')[h]) - 0.00375 - 0.000875 - 0.04) | round(3, floor)] %}
              {% endfor %}
              {{ ns.prices }}
            {% endif %}

Hi @markpurcell

I am trying something like this to use for as long this is not a standard option in the energy dashboard.

I am not getting there completely, I think.
Can you share the settings for the Riemann Sum integration and the Utility meters please?

Wouldn’t you also need to subtract the feed in tariff you provider would otherwise pay you for the electricity?

Not sure I fully understand the sensors here.

I would:
solar_energy_benefits = total_load_in_kWh - total_import_in_kWh

Total savings:
solar_money_benefit = increase_in_solar_energy_benefit * price_per_kWh + increase_in_export_to_grid * sales_price_per_kWh

However, how do we get the difference / the increase of the sensor since previous state update ?

I am trying this:

template:
  - sensor:
      - name: solar_consumption_total
        unit_of_measurement: kWh
        state: >
          {{ states('sensor.growatt_local_load_consumption_total')|float - states('sensor.growatt_import_from_grid_total')|float }}
        unique_id: solar_consumption_total
        state_class: 'total_increasing'

  - trigger:
      - platform: state
        entity_id: sensor.solar_consumption_total
    sensor:
      - name: solar_roi
        state: >
           {{ (this.state|float(0)) + ( ((trigger.to_state.state|float(0)) - (trigger.from_state.state|float(0))) * (states('sensor.el_indkob')|float(0)) ) }}
        unit_of_measurement: 'DKK'
        state_class: 'total_increasing'
        unique_id: solar_roi

Hi @markpurcell, thank you for sharing this.

I’ve defined the sensors as follows:

    - name: Solar Benefit
      unit_of_measurement: GBP/h
      state: >
        {{states('sensor.givtcp_ch23XXXX_solar_to_house')|float(0) * states('input_number.smart_meter_electricity_energy_import_rate_peak')|float(0)/1000
        + states('sensor.givtcp_ch23XXXX_solar_to_battery')|float(0) * states('input_number.smart_meter_electricity_energy_import_rate_peak')|float(0)/1000
        + states('sensor.givtcp_ch23XXXX_solar_to_grid')|float(0) * states('input_number.smart_meter_electricity_energy_export')|float(0)/1000}}

    - name: Battery Benefit
      unit_of_measurement: GBP/h
      state: >
        {{states('sensor.givtcp_ch23XXXX_battery_to_grid')|float(0) * states('input_number.smart_meter_electricity_energy_export')|float(0)/1000
        - states('sensor.givtcp_ch23XXXX_grid_to_battery')|float(0) * states('input_number.smart_meter_electricity_energy_import_rate_offpeak')|float(0)/1000
        + states('sensor.givtcp_ch23XXXX_battery_to_house')|float(0) * states('input_number.smart_meter_electricity_energy_import_rate_peak')|float(0)/1000}}

    - name: battery+solar benefit
      unit_of_measurement: GBP/h
      state: >
        {{states('sensor.battery_benefit')|float(0) + states('sensor.solar_benefit')|float(0)}}

Please can you explain why are you deduct the solar to battery cost from the battery benefit?

states('sensor.givtcp_ch23XXXX_solar_to_battery')|float(0) * states('input_number.smart_meter_electricity_energy_import_rate_peak')|float(0)/1000

I have also defined the associated utility meters…

Created the APEX chart…

What is driving me nuts is why doesn’t the monthly battery+solar benefit = monthly battery benefit +monthly solar benefit?

Also is the Riemann Sum integration calculation solely used to track total benefits?

Appreciate all your help with this :slight_smile:

Maybe a worked example with numbers will help with my logic. I’m not totally convinced this is the only solution but it works for me.

Say I have the following conditions;

Buy cost from grid 40¢/ kWh
Sell price to grid 10¢/ kWh

Case 1:

Solar production 3kW
Solar2house consumption 1 kW
Solar2grid export 1 kW
Solar2batt consumption 1 kW

The benefits from solar in an hour are:

I don’t have to buy from the grid

Solar2house * buy = 40¢/ hr

plus what I export

Solar2grid * sell = 10¢/ hr

plus what I store in my battery, which I could of exported to the grid

Solar2batt * sell = 10¢/ hr

The battery in the hour isn’t giving me any benefits, in fact it is costing me as what I could of exported to the grid I’m saving for later.

minus the cost of not exporting to the grid

Solar2batt * sell = -10¢/ hr

So overall in that hour my total benefit is:
40 + 10 + 10 - 10 = 50¢/ hr

Case 2 in the second hour

Solar production 0W
Batt2house consumption 1 kW

Battery benefits

I don’t have to buy from grid

Batt2house * sell = 40¢/ hr

So my total benefits for the two hours with a battery and solar are:

50¢ + 40¢ = 90¢

The solar benefits over the two hours have been 60¢ and the battery benefit has been -10+40 = 30¢.

My house has consumed 2 kWh, I have exported 2 kWh to the grid and my battery still has 2 kWh left.

Thanks Mark, appreciate it.

Are you able to shed any light on these?

Glad you got there in the end, with 2023.9 just release we can also do the templates as helpers as well.

Can you unpack the individual numbers and show the graphs to see where there is an inconsistency.

Multiplying the power (kW) by the variable cost ($/ KWh) gives you an instant savings value of how much you are saving at any point in time ($/h).

The Riemann sum is then used to calculate (add up) the integral over a period of time say one hour or one day, which gives you the total cost/ savings over that period

I am trying to make my own “solar saving sensors” but have issues with the Riemann sum integration that perhaps someone have a good answer to…

As an example:
I have made a sensor that calculates the energy cost my PV is putting in my battery bank

      - unique_id: pv_to_batt
        name: pv_to_batt  
        unit_of_measurement: 'kr'
        device_class: monetary
        state: >
          {% set batt = states('sensor.battery_charge_discharge_power')|float %}
          {% set price = states('sensor.electricity_price')|float %}
          {% set batt_charging = batt > 0 %}
          {% set pv2batt = batt if batt_charging else 0 %}
          {{ pv2batt * price *0.001 }}
        availability: >
          {% set sstate = states('sensor.battery_charge_discharge_power') %}
          {{ sstate != 'unavailable' and sstate != 'unknown' }}

That part works fine but its the integral that follows thats giving me issues

  - platform: integration
    unique_id: pv2batt_integral
    source: sensor.pv_to_batt
    name: test_pv_to_batt_integral
    round: 2
    method:
      left

The integral is always adding a “unit_time” prefix to the sensor.

pv_batt_issue_1

So in this case its an “h” as its the default, so its presented as “krh”
Been trying to get around this by playing with the “unit_time” variable but without success.

Any suggestions :grimacing:

edit: I mean without cheating and using the customizing function ofc…

Thanks for the solar benefit calculation and apexchart codes. It didi the trick.

To give a little back I saw that you limited the graph to show up to 50, because otherwise monthly number will raise it to 390 in your example. There a trick to avoid it and still use dynamic scaling. Use second y-axis, show: false and assign first axis to the daily data and second axis to the monthly data.

yaxis:
  - id: first
    decimals: 2
  - id: second
    show: false

series:
  - entity: sensor.pv_own_usage_benefit_daily
    yaxis_id: first
    ...
  - entity: sensor.pv_to_grid_benefit_daily
    yaxis_id: first
    ...
  - entity: sensor.total_pv_monthly_benefit
    yaxis_id: second
    ...

I’m using similar similar approach, but calculating solar energy own use saving (electricity price including VAT + nwtwork Tariffs) and sold to grid (electricity price without VAT). I live in Estonia and we have nordpool hour by hour pricices for electricity. Anyway, my outcome:

*Its winter here, so not much sunlight

1 Like

zeronounours is very much on the topic of LTS, he has published multiple components in HACS that help us create and show long term statistics ourselves like the Energy Dashboard does.

Using his components I was able to create the entities to keep track of cost of total energy usage and compensation for self-used energy. Together with cost of imported energy and compensation for exported energy already tracked by the Energy Dashboard this results in an overview like this:


The bottom two being what I didn’t have to pay for energy used by my household, and the money I got back for my over-produced energy. Together these are what I earned in one day towards my investments for my solar installation. Once I’ve got more data I will be able to select it for a longer period too.

2 Likes

@rrozema That’s nice, but since I do not want to hazzle around with HA, but stability is for me #1 priority, I do not use HACS. I only use the plain official standard HA. I think this missing cost saving should be added to the standard energy dashboard.

And then the next person wants to do similar things for their battery investment and needs even other entities tracked. Please aim for a more generic solution -alike zeronounours’- than just adding this one entity to the dashboard.

I posted my journey to solve this here: Any good ideas are welcome. Nordpool Energy Price per hour - #492 by arva

Awesome job Mark.

I think I’ve set the templates, reiman, and utility meters up correctly, but noticed that when my battery is charging at night the benefit goes negative. Does that line up with your logic?

My hope is to eventually get a countdown till the system has paid for itself, but given this is my first time using templates that may be overly ambitious.

Yes that is how it is supposed to work.

When charging your battery there is a cost involved, so the benefit goes down. Hopefully you charge during the cheap times/ excess solar.

Then when you eventually discharge from your battery you make the benefits, hopefully when the price is higher, so overall your battery costs should be lower than the benefits for each day which means you are in front.

Your solar benefits should only ever increase, as you typically don’t pay for exports (although we do in Australia sometimes have negative feed in prices).

1 Like

That makes total sense, my battery charges overnight at 7p per kWh and discharges during the 30p period so there should be some nice value there too offset the “cost”. Thanks again!

1 Like