P10 sum

[dtswk]

Firstly thank you for the awesome resource..!

We are off grid so I make a lot of automations to run non critical workloads and very often use the P10 as the worst case call if I am going to risk running them before our batteries hit x percent.

I'm really new to HA but had a crack at writing some templates to create sums and thought I would share.

Maybe you would consider building in?

Matt

• name: "solcast_pv_forecast_p10_remaining_today"
  unique_id: "solcast_pv_forecast_p10_remaining_today"
  unit_of_measurement: "kWh"
  icon: mdi:solar-power
  state: >
  {% set data = state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedHourly') %}
  {% set result = data | map(attribute='period_start') | list %}
  {% set combined = data | map(attribute='pv_estimate10') | list %}
  {% set time_now = as_timestamp(now()) %}
  {% set ns = namespace(result=0) %}
  {% for item in data %}
  {% if as_timestamp(item.period_start) > as_timestamp(now()) %}
  {% set ns.result = ns.result + item.pv_estimate10 | float %}
  {% endif %}
  {% endfor %}
  {% set state = ns.result %}
  {{ state | round(1) }}

• name: "solcast_pv_forecast_p10_forecast_today"
  unique_id: "solcast_pv_forecast_p10_forecast_today"
  unit_of_measurement: "kWh"
  icon: mdi:solar-power
  state: >
  {% set data = state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedHourly') %}
  {% set result = data | map(attribute='period_start') | list %}
  {% set combined = data | map(attribute='pv_estimate10') | list %}
  {% set time_now = as_timestamp(now()) %}
  {% set ns = namespace(result=0) %}
  {% for item in data %}
  {% set ns.result = ns.result + item.pv_estimate10 | float %}
  {% endfor %}
  {% set state = ns.result %}
  {{ state | round(1) }}

• name: "solcast_pv_forecast_p10_tomorrow"
  unique_id: "solcast_pv_forecast_p10_tomorrow"
  unit_of_measurement: "kWh"
  icon: mdi:solar-power
  state: >
  {% set data = state_attr('sensor.solcast_pv_forecast_forecast_tomorrow', 'detailedHourly') %}
  {% set result = data | map(attribute='period_start') | list %}
  {% set combined = data | map(attribute='pv_estimate10') | list %}
  {% set time_now = as_timestamp(now()) %}
  {% set ns = namespace(result=0) %}
  {% for item in data %}
  {% set ns.result = ns.result + item.pv_estimate10 | float %}
  {% endfor %}
  {% set state = ns.result %}
  {{ state | round(1) }}

• name: "solcast_pv_forecast_p10_day_3"
  unique_id: "solcast_pv_forecast_p10_day_3"
  unit_of_measurement: "kWh"
  icon: mdi:solar-power
  state: >
  {% set data = state_attr('sensor.solcast_pv_forecast_forecast_day_3', 'detailedHourly') %}
  {% set result = data | map(attribute='period_start') | list %}
  {% set combined = data | map(attribute='pv_estimate10') | list %}
  {% set time_now = as_timestamp(now()) %}
  {% set ns = namespace(result=0) %}
  {% for item in data %}
  {% set ns.result = ns.result + item.pv_estimate10 | float %}
  {% endfor %}
  {% set state = ns.result %}
  {{ state | round(1) }}

[gcoan]

I asked a similar thing a while ago and Ozzee helped me craft template sensors for pv_10 today and tomorrow which is all I wanted to see.

He didn't want to add these to the core integration, think he wanted to keep it cleaner as these were easy for someone to create themselves if they wanted to, but it would be good if these were in the documentation to help others.

My template sensors were created through the Home Assistant UI rather than in configuration.yaml, and are quite a bit simpler:

{% set d = state_attr('sensor.solcast_pv_forecast_today', 'detailedHourly') %}
{{ (d | sum(attribute='pv_estimate10')) | round(2)  }}

I think it's doing the same?

[dtswk]

Thanks for sharing, that's a much nicer approach. The only thing that still might be helpful is the remaining for today as I discard anything that has gone past the time.

[dtswk]

Updated code :-)

• name: "solcast_pv_forecast_p10_remaining_today"
  unique_id: "solcast_pv_forecast_p10_remaining_today"
  unit_of_measurement: "kWh"
  icon: mdi:solar-power
  state: >
  {% set data = state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedHourly') %}
  {% set result = data | map(attribute='period_start') | list %}
  {% set combined = data | map(attribute='pv_estimate10') | list %}
  {% set time_now = as_timestamp(now()) %}
  {% set ns = namespace(result=0) %}
  {% for item in data %}
  {% if as_timestamp(item.period_start) > as_timestamp(now()) %}
  {% set ns.result = ns.result + item.pv_estimate10 | float %}
  {% endif %}
  {% endfor %}
  {% set state = ns.result %}
  {{ state | round(1) }}

• name: "solcast_pv_forecast_p10_forecast_today"
  unique_id: "solcast_pv_forecast_p10_forecast_today"
  unit_of_measurement: "kWh"
  icon: mdi:solar-power
  state: >
  {% set data = state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedHourly') %}
  {{ data | map(attribute='pv_estimate10') | sum | round(1) }}

• name: "solcast_pv_forecast_p10_tomorrow"
  unique_id: "solcast_pv_forecast_p10_tomorrow"
  unit_of_measurement: "kWh"
  icon: mdi:solar-power
  state: >
  {% set data = state_attr('sensor.solcast_pv_forecast_forecast_tomorrow', 'detailedHourly') %}
  {{ data | map(attribute='pv_estimate10') | sum | round(1) }}

• name: "solcast_pv_forecast_p10_day_3"
  unique_id: "solcast_pv_forecast_p10_day_3"
  unit_of_measurement: "kWh"
  icon: mdi:solar-power
  state: >
  {% set data = state_attr('sensor.solcast_pv_forecast_forecast_day_3', 'detailedHourly') %}
  {{ data | map(attribute='pv_estimate10') | sum | round(1) }}

[isorin]

@autoSteve Yeah, thanks for doing this, I was thinking to suppress the debug output for sensors as well.

[autoSteve]

PR #71 will likely become pre-release v4.0.36 unless something happens with v4.0.35. It's in final review state with BJ, and there's a healthy number of v.35 downloads to not indicate issues with that one, nor issues reported for v.31 GA, which has over 2,000 downloads.

For now, Independence Day: Resurgence, because July 4th. 🎆

[autoSteve]

Released.

[gcoan]

For now, Independence Day: Resurgence, because July 4th. 🎆

Over in Blighty all the talk is about the General Election that's also on today. All the talk is of a landslide victory for the left/centrist opposition party after 14 years of the right/centrist (but increasingly extreme right wing) Conservative party.

We shall see. Can hardly contain my excitement

[autoSteve]

[dtswk]

There you go :-) IMHO the P90 is generally less intresting as I think you would usually want to base on most likely which the standard forecast and maybe worst case if like me off grid so being paranoid. The the map method would work for both and you could easily setup a bunch of sensors based on P90. I "think" the loop is needed for the date comparison, I see there is a filter for map but haven't looked at it too closely.

[EddieSpaghettie]

Im confused : The above p10 calculation formula for me produces a number for remaining for today of : 5.7kw

If i set solcast to use : Forecast Estimate 10 (whuch i thought is the same) that creates a value of : 7.74kw

[dtswk]

Make sure both are remaining otherwise you are comparing the full day vs remaining

[autoSteve]

Or install 4.0.36 beta, recently released, @EddieSpaghettie, and use the pre-calculated values that are now attributes for all sensors. 😉

[EddieSpaghettie]

I am on 4.0.36beta and thats what im using. The pre-calculated is giving different to the formula above

[EddieSpaghettie]

This is what Im using:

{{ state_attr('sensor.solcast_pv_forecast_forecast_remaining_today', 'pv_estimate10') | float(0) }}
{{ states('sensor.solcast_pv_forecast_p10_remaining_today') | float(0) }}

Top Gives : 6.31now
Bottom Gives : 5.7

[EddieSpaghettie]

[EddieSpaghettie]

Can you perhaps post the formula from the code. Maybe there is something else different?

[autoSteve]

There is something off with the loop yaml is what I am thinking.

Like I said, the exact same code is calculating remaining today, just using a differing forecast value. If _use_data_field is None then it uses the currently selected estimate in get_forecast_pv_estimates(). Others can comment. I got nothin'

    def get_forecast_remaining_today(self, _use_data_field=None) -> float:
        """Return remaining forecasted production for today"""
        # time remaining today
        start_utc = self.get_now_utc()
        end_utc = self.get_day_start_utc() + timedelta(days=1)
        res = 0.5 * self.get_forecast_pv_estimates(start_utc, end_utc, site=None, _use_data_field=_use_data_field)
        return res

    def get_forecasts_remaining_today(self) -> Dict[str, Any]:
        res = {}
        for _data_field in ('pv_estimate', 'pv_estimate10', 'pv_estimate90'): res[_data_field] = self.get_forecast_remaining_today(_data_field)
        return res
...
(from get_forecast_pv_estimates()...)
            _data_field = self._use_data_field if _use_data_field is None else _use_data_field

[EddieSpaghettie]

Unless it has something to do with GMT Times? Im on GMT+2
Forecast Today/Tomorrow/Day After tomorrow are all the same. Is just remaining today thats not the same. Ill use the new built in one then rather. Thank you :)

[autoSteve]

GMT+10 here, so... It don't go weird here that I've noticed, being really from the future in Oz, but I'll keep an eye on it, which will be easier than GMT+2. Thx for the feedback @EddieSpaghettie.

[EddieSpaghettie]

[EddieSpaghettie]

I removed that yaml code completely. Will use the new built in ones you kindly provided in the latest beta!

[autoSteve]

(I really should round those real numbers to four decimal places. The imprecision makes my eye twitch...)

#goescode...

[autoSteve]

Done. In 4.0.next...

[EddieSpaghettie]

Whoop whoop

[dtswk]

Interesting, was fine for me in same timezone. Time comparison didn't honour timezone then?