Using Home Assistant to calculate my energy bill using data from my Solar Inverter

[del13r]

@Sddawson

Has it been running well for you so far?

It updates once an hour and takes a break from 7pm to 5am. I just checked my solcast dashboard.

API Usage

Daily Usage Limit
50 requests

Daily Usage Consumed
26 requests

The consumed usage does not reset until midnight UTC

It’s currently 8pm utc, I think it will make it another 4 hours before counter resets.

The description of the add on says

Modified from the great works of

• dannerph/homeassistant-solcast
• cjtapper/solcast-py
• home-assistant-libs/forecast_solar

Appears to combine elements form those 3 GitHub repos

[Sddawson]

@del13r

It updates once an hour and takes a break from 7pm to 5am. I just checked my solcast dashboard.

Ok, great. I’ll give it a go. It will be nice to have the forecast integrated with the Energy component. Thanks again.

[del13r]

@Sddawson

There seems to be an open issue with too many API calls.

I just did the sums.

There are 5 sensors and I am assuming each sensor consumes 1 api call.
(7pm) 19 - 5 (5am) = 14 active hours.
14 * 5 calls per hour = 70 requests per day.
if I change the slider to 2 hours per request, then it halves to 7 requests per day * 5 sensors = 35 requests per day.
Given the free accounts are limited to 50 per day, I am going with 2 hours on the slider.

[del13r]

@Sddawson

Has it been running well for you so far?

Not anymore. All my graphs are now in UTC time instead of +11hours

[Sddawson]

@del13r

There are 5 sensors and I am assuming each sensor consumes 1 api call.

I don’t think so. If you look at the REST call in the stuff I posted above, I think one api call gets all the data in one go. The other thread goes into a lot of detail on the data formats. If you look at Issues on the repo, there is more discussion on the frequency too.

@del13r

Not anymore. All my graphs are now in UTC time instead of +11hours

Hmmm - which graphs exactly?

[del13r]

appears to be a bug in home assistant.
The graphs show fine in iOS app.
while when accessing using web browser, the graphs are in UTC.

What graphs? all graphs. even the history tab is all in utc via web browser.

Same graph when viewed on my mobile via the iOS app which formats perfectly.

Timezone is correctly set however graphs are showing in UTC

My timezone is 11hours head of UTC so this result is correct [image] However, my graphs are all in UTC [image] What on earth is going on here?

[Sddawson]

@del13r

Same graph when viewed on my mobile via the iOS app which formats perfectly.

Every time you post something, I see something interesting! What do you have on your 1H, 12H, 24H tabs?

[del13r]

The same graphs with the same elements, just with a different history length (hours to show) for better clarity.

[Sddawson]

Always learning…

[Sddawson]

@del13r

And now my forecast works

I’ve been playing with the solcast integration. In the Energy graphs you included above, you showed one which was presumably for tomorrow, with a nice sloping graph of the forecast. Any idea how this is produced from the integration’s sensors, which don’t seem to provide enough data to do that?

[del13r]

@Sddawson

Any idea how this is produced from the integration’s sensors, which don’t seem to provide enough data to do that?

Pretty much have to learn python and pick apart the repo.

oziee/ha-solcast-solar/blob/06a974a1e41f6138c27bbaa7293e7ab439d5f59a/custom_components/solcast_solar/energy.py

Either that or ask oziee (Greg) · GitHub directly

[Sddawson]

@del13r

Pretty much have to learn python and pick apart the repo.

Yeh. Must be feeding the data directly to the Energy platform, and not creating sensors for it all (which is what the other method does). Oh well, moot point until the integration is behaving a little better. Hope it gets there.

[del13r]

Hey @Sddawson,

I had a rainly/low solar production day and thought I would show you what happened.

This is a typical sunny day where the hot water is done heating up by 11am.

This is a rainy day where I managed to still generate 12.6 kWh and every bit of it went to the hot water heater all day. I went out and checked the temp sensor late in the afternoon and the water was at 70 degrees celcius.

[Sddawson]

Thanks very much for taking the time to post that @del13r. I’m still thinking about this. It must be great to see as much production used as possible. Looking back, my bad, rainy day production tends to be soaked up pretty completely by the normal background use in my house, and, given I have a small water tank for the size of the household, it does still worry me a bit. It will all be down to whatever mitigating procedures are put in place by whatever system I’d use really. Although, granted, the number of days that are likely to be a problem are very small.

[del13r]

@del13r

Then I can finally follow up with the automation to reset the quarterly meters.

After I changed my electricity retailer, I am now on a rolling 28 day bill whereas previously I was on quarterly.
I have figured out how to add 28 days to the reset date once the current bill is finished and the reset is triggered.

I have added

  - service: input_datetime.set_datetime
    target:
      entity_id: input_datetime.de_monthly
    data:
      datetime: '{{ now().date() + timedelta(days=28) }}'

to my existing Meter Reset automation so that it now looks like this

alias: Monthly Meter Reset
description: ''
trigger:
  - platform: time
    at: input_datetime.de_monthly
condition: []
action:
  - service: utility_meter.reset
    target:
      entity_id:
        - utility_meter.monthly_energy
        - utility_meter.monthly_energy_export
  - service: notify.notify
    data:
      message: monthly meter reset
  - service: input_datetime.set_datetime
    target:
      entity_id: input_datetime.de_monthly
    data:
      datetime: '{{ now().date() + timedelta(days=28) }}'
mode: single

[Sddawson]

@del13r

I have figured out how to add 28 days to the reset date once the current bill is finished and the reset is triggered.

Nice. It is much appreciated that you keep us all up to date.

[del13r]

@Sddawson

Nice. It is much appreciated that you keep us all up to date.

I have also updated the same code in my Time of use seasons (seasons defined by the power company which effects what months have peak rates charged).

The reason why I am doing this automation is so I won’t have to remember to update the date/time helper manually myself.

In this case, I will be adding a year onto the existing helper.
Here is how I tested it and know ahead of time if it will work or not.

First I checked my logic
I went to developer tools / template /

{{ now().date() }}

result was 2021-12-09

Then I did this template

{{ now().date() + timedelta(days=365) }}

and result was 2022-12-09

Then I went to my 4 automations (1 for each season) and updated them to look like this one for example where peak tariffs are not charged for 2 months from April 1 onwards so that is why this automation disables 2 peak tariff related automations from running.

alias: TOU Autumn
description: ''
trigger:
  - platform: time
    at: input_datetime.autumn_tou
condition: []
action:
  - service: automation.turn_off
    target:
      entity_id:
        - automation.tariff_peak
        - automation.tariff_offpeak_weekday
  - service: input_datetime.set_datetime
    target:
      entity_id: input_datetime.autumn_tou
    data:
      datetime: '{{ now().date() + timedelta(days=365) }}'
mode: single

[del13r]

I have also ditched the 5 hour pool pump timer in favour of a history_stats sensor.
I found that if I rebooted Home Assistant, the timer status would be forgotten.

This new history_stats sensor records how long the pool pump has run for the last 24 hours from right now.

  - platform: history_stats
    name: Pool Pump Duration 24H
    entity_id: sensor.pool_pump_switch_time_based
    state: "on"
    type: time
    end: "{{ now() }}"
    duration:
      hours: 24      

As I just set it up today, the sensor has not recorded enough data yet, but effectively this is what it looks like

And then I can use logic in my automations to decide to make up for poor solar generation in the last 24 hours that prevented the pool pump from running long enough in the day.

This logic for example will return a true condition if the pool pump has run for less than 5 hours in the last 24 hours.

{{ states('sensor.pool_pump_duration_24h') | float < 5 }}

[Sddawson]

@del13r

I have also updated the same code in my Time of use seasons

@del13r

I have also ditched the 5 hour pool pump timer in favour of a history_stats sensor

Those are both very imaginative solutions. The use of the history_stats sensor is much neater than the timer. Didn’t know that sensor existed either, but then almost everything you come up with is news to me!

[del13r]

Here is my pool pump automation.

alias: Pool Pump on 2am
description: ''
trigger:
  - platform: time
    at: '02:00:00'
condition:
  - condition: or
    conditions:
      - condition: template
        value_template: '{{ states(''sensor.solcast_forecast_today'') | float < 30 }}'
      - condition: template
        value_template: '{{ states(''sensor.pool_pump_duration_24h'') | float < 5 }}'
action:
  - service: switch.turn_on
    target:
      entity_id: switch.sonoff_MACADDRESS
  - service: notify.notify
    data_template:
      message: >-
        Pool Pump on. Solar forecast {{ states('sensor.solcast_forecast_today')
        | int }} kWh, pump ran for {{ states('sensor.pool_pump_duration_24h') }}
        H / 24 H
mode: single

Here is what the message would look like if either condition was true when the trigger time occured.

Pool Pump on. Solar forecast 21 kWh, pump ran for 1.47 H / 24 H