Add "Solar Cost Saving" option to native Energy Dashboard

Feature Requests
33

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…

34

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:

Screenshot 2023-10-31 at 12.37.11
Screenshot 2023-10-31 at 12.37.11802×692 91.7 KB

*Its winter here, so not much sunlight

1 Like
35

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:

image
image568×593 24.4 KB

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
36

@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.

37

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.

38

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

39

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?

Screenshot_20240317-003543
Screenshot_20240317-0035431080×1275 102 KB

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.

40

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).

Screenshot 2024-03-17 11.08.55
Screenshot 2024-03-17 11.08.552488×950 169 KB

1 Like
41

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
42

What means it: - 0.00375 - 0.000875 - 0.04

43

Yes, this would be totally awesome to be implemented to native Energy dashboard as energy used as savings in house using entity as current electricity price like can be used for calculation on used energy for grid and sold energy to grid and shown and reduced from total sums in Sources…

Solar_Savings

44

Since your electricity consumer price seems to be 0.57 EUR / 6.17 kWh = 0.092 EUR/kWh, should not be the “Solar savings” amount be -8.6 kWh * 0.092 EUR/kWh = -0.79 EUR ? I mean what you save is the consumer price, right?

45

Calculating savings from solar PV (and batteries) is a bit of a dark art.

That’s because the tariff plan you would choose without solar PV (and/or battery) would likely be different, and also because the consumption patterns are going to be different with solar PV than without.

When you have solar PV you naturally shift discretionary loads to the daytime, which may have a different grid tariff to when it would have normally been run if you did not have solar PV, e.g. overnight.

IOW assigning the saving to the avoided grid tariff at time of consumption is a bit misleading. It really needs to be compared with what you would have done had you not had solar. And that’s all but impossible.

e.g. with solar PV our pool pump and water heating runs in the daytime. Without solar they would be run at other times when grid tariffs are cheapest. So in reality I’m offsetting the cost of consumption at the time of day they would have run, not when they actually run.

Sure, if you have a totally flat rate tariff then it will work but as soon as you move into the realm of time based tariffs and consumption patterns are altered, well then it starts to become little more than a feel good guesstimate.

46

I agree there are multiple ways of ‘accounting’ for solar/ battery benefits, but the savings are real so should be quantified.

image

I don’t think it is impossible, but there is some complexity.

My Default Market Offer 6 price for my region (Energex) is $2,052 for 4,600 kWh ~ 44.6c / kWh, so without solar/ batteries and on the default offer 10 kWh of water heating will have an operating cost of $4.46, lets call this the maximum savings as if you shop around you can do better than the DMO, but it is a benchmark. A simple assumption would be that my solar/ battery saves me ~ 44.6c / kWh.

If my solar system is generating and I don’t consume from the grid, I could export 10 kWh with a default 5c/ kWh feedin and generate 50c revenue or I could use that 10 kWh to heat my hot water, forego the 50c revenue and I have saved $4.46 - $0.50 = $3.96 against the DMO. If I’m on a spot price the feedin might be 1c for 5 kWh and 3c for the other 5 kWh, so the forgone revenue is $0.20 and my operating cost savings against the DMO are now $4.26.

If I consume 50/50 from the grid (5 kWh @ 44.6c/ kWh = $2.23) and solar (5 kWh @ 5c/ kWh = $0.25), then the operating cost savings are $4.46 - $2.23 - $0.25 = $1.98. If I consume 100% from the grid (10 kWh @ 44.6 c/ kWh = $4.46) then savings are $0.

The same can apply for a battery, costs can be the feed in price (say 5c/ kWh) of forgone revenue from not exporting and savings can be the cost of energy is you source from the battery (say 44.6 c/ kWh).

As I said this is just one method of accounting, which accommodates variable spot pricing and time-shifting loads, which I have implemented through a series of calculations and formula, which gives me a dashboard in Home Assistant.

There are other methods of accounting, and they have different assumptions and models, so lets get them implemented and reviewed so people can use the system that suits them.

47

I guess it comes down to what the purpose of the numbers are.

If you just want feel good numbers to brag about, then fine. But if it’s actually meant to be an honest appraisal of the real $ benefits of solar PV and/or battery, then it’s a misleading approach.

No one in their right mind is on the DMO, nor would someone with an electric water heater in the Energex region have it operating on the DMO peak tariff. It would most likely be on a controlled load off-peak tariff (T31 or T33), or at worst operating outside of the peak tariff period.

Using DMO as a baseline is just generating feel good numbers, the sort of tactic dodgy salesmen use to inflate the benefits of solar/batteries.

If you are going to compare water heater energy consumption costs, then at least use the baseline tariff most commonly used for heating water.

The comparison should be the bill difference between the optimal tariff plan for each scenario:

  • What the bill would have been had you not had solar PV and/or battery
  • What the bill actually is with solar PV and/or battery.

In each case people will have different consumption patterns and choose different tariff plans.

e.g. Because I have an EV I have access to a plan with super off-peak (i.e. free) energy in the middle of the day, so my middle of the day grid imports are high as I “load up” in that period. If I compared that altered consumption pattern with a regular tariff plan (let alone the DMO), then the cost differential would be large. I must be saving a lot, right?

But of course if I did not have access to a super off-peak tariff then I would not consume energy in the same manner. I would instead choose to consume it at other off-peak times.

So my savings are really the difference between those cheapest options in each case.

Likewise if I have a home battery and charge it with super off-peak power and then discharge it during peak period (which inevitably has an inflated peak tariff as that’s the way they work), my saving is not the difference between those tariffs. It’s has to be compared with the tariff plan I would have chosen if I did not have the battery, which would of course not have as high a peak tariff.

48

It would appear that some household are paying well above the DMO.

Whilst I don’t disagree that it should be easy to switch to a lower rate tariff the report would indicate that many don’t.

49

They are either vulnerable, lazy, or don’t care. Only the former I have sympathy for.

50

Yes, that was just quick mockup with paint to give an example, so savings in EUR was not correct :slight_smile:

So the self used energy savings would be calculated with same sensor as is currently used calculating current price from grid per hour:

image
image829×226 7.17 KB

51

Is it possible to get cost value as sensors?

image
image769×511 45.2 KB

2 Likes
52

What kind of sensor is this? : sensor.amber_vs_dmo_savings_daily