Solcast Global Solar Power Forecast Integration

Feature Requests
334

Thank you, Francis, absolutely. Hit me up on the repo!

335

Iā€™ve put forward my repo (on 4.0.22) for inclusion in HACS. Thereā€™s a massive backlog, so I expect it will take a while - there are requests at least three weeks old in the queue.

In the meantime, so as not to slow down my submission when it reaches the front of the queue, Iā€™ll start a new branch now, and cherry-pick some of the 4.0.23 changes:

  • The fix to state_class= SensorStateClass.TOTAL
  • The improved handling of error codes
  • If polling api fails keep using current data

Iā€™m inclined to leave the API counter logic intact (as it currently is in place in 4.0.22

Iā€™ll update readme, and, in particular, include randomisation in fetch logic.

3 Likes
336

Iā€™m in the same boat, but you can add a second integration instance for this and then select both in Energy dashboard.
But this is probably a subject more to be discussed at Open-Meteo Solar Forecast - #3 by elRadix :slight_smile: Itā€™s working OK for me, looks promising.

337

Question for anyone who has been around for a while - any idea why the automatic polling was removed from ozieeā€™s Solcast Service?

I found when it was removed - it was last in 3.0.47 - around May last year. Does anyone recall any conversation around why?

Given the issues around randomising scheduling, Iā€™m trying to understand if it is worth re-including scheduling in the integration with randomisation, and the API counter, and a warning that if you restart HACS, youā€™ll probably hit your limit for that day (which, presumably, is no big deal).

Thanks in advance for any advice you can share.

1 Like
338

This was probably due to the decrease in API polling quota for hobbyists from 50 to 10 API calls a day. As one can hardly spread 10 calls across 24 hours, it was the right decision to leave the polling up the to the users. Everyone should prioritize those 10 calls as they see fit. HA offers more than enough capabilities for scheduling.

2 Likes
339

With some on only 10 api calls per day and others on 50 if I recall the suggestion was to push to a local automation running the service, which is what I have. Mine runs every half hour during the day (on an offset of x minutes into each half hour), and every 2h after dark. That sits me in inside my 50.

2 Likes
340

As a quick hotfix to the randomness it might just be worth adding a random 0-10min sleep timer on the update API call. Then anyone using the new version automatically has it.

3 Likes
341

@Swallowtail if you donā€™t mind, can you share more details on your implementation?

1 Like
342

Itā€™s nothing fancy. Runs at 22 and 52 mins past each hour in day, and every 2nd hour at 26 past at night. If Iā€™m at API limit already it does not run.

alias: "Energy: Solcast API update"
description: "Energy: Solcast API update"
trigger:
  - platform: time_pattern
    minutes: "22"
    id: "1"
  - platform: time_pattern
    minutes: "52"
    id: "1"
  - platform: time_pattern
    hours: /2
    minutes: "26"
    id: "2"
condition:
  - condition: numeric_state
    entity_id: sensor.solcast_pv_forecast_api_used
    below: sensor.solcast_pv_forecast_api_limit
action:
  - choose:
      - conditions:
          - condition: sun
            before: sunset
            after: sunrise
          - condition: trigger
            id:
              - "1"
        sequence:
          - service: solcast_solar.update_forecasts
            data: {}
      - conditions:
          - condition: sun
            before: sunrise
            after: sunset
          - condition: trigger
            id:
              - "2"
        sequence:
          - service: solcast_solar.update_forecasts
            data: {}
mode: restart
1 Like
343

I just added a random delay into the actions before it does anything like this :

delay: "{{ (range(0, 1)|random|int) }}:{{ (range(1, 30)|random|int) }}:00"

I do note the repository has disappeared in the last few days.

1 Like
344

Sorry, I am trying to follow along, which repo should we be migrating to?

1 Like
345

It seems that the integration no longer exists. The link on Github leads nowhere. Does anyone know what happened?

346

You will find the answer above.

1 Like
347

I uninstalled the old solcast repo, rebooted etc. Then added the new BJreplay however i cant get it to install in intregrations to configure it. I can see i have downloaded version 4.0.25 under Hacs frontend but i can not seems do anything else. what am i doing wrong.

I have solved my own question. However it may help others i added it to my Hacs through the link. It added it as a plugin not an integration, i deleted it and reinstalled it as an integration

2 Likes
348

Iā€™m in the same situation but your statement is not true - open-meteo does support multiple orientations - just add all your roofs (add your 1st set of panels then go back to the integration and add additional service then add your second etc)

2 Likes
349

Yes this was the reason for auto polling being removed ā€¦ the growing discrepancy between hobbyists with a different api cap - so Oziie posted something somewhere at the time that they would leave it to the end users to poll.

350

In case it helps to someoneā€¦
This code calculates when to update solcast data using limited API calls (10 in this case):

alias: Solcast update
description: ""
trigger:
  - platform: template
    value_template: >-
      {% set nr = as_datetime(state_attr('sun.sun','next_rising')) | as_local %}
      {% set ns = as_datetime(state_attr('sun.sun','next_setting')) | as_local
      %} {% set api_request_limit = 10 %} {% if nr > ns %}
        {% set nr = nr - timedelta(hours = 24) %} 
      {% endif %} {% set hours_difference = (ns - nr) %} {% set interval_hours =
      hours_difference / api_request_limit %} {% set ns = namespace(match =
      false) %} {% for i in range(api_request_limit) %}
        {% set start_time = nr + (i * interval_hours) %}
        {% if ((start_time - timedelta(seconds=30)) <= now()) and (now() <= (start_time + timedelta(seconds=30))) %}
          {% set ns.match = true %}
        {% endif %}
      {% endfor %} {{ ns.match }}
condition:
  - condition: sun
    before: sunset
    after: sunrise
action:
  - service: solcast_solar.update_forecasts
    data: {}
mode: single
351

I am on v4.0.23 as free user with automation that gets the data 10 times in a day. currently it seems working/running good. should I just wait for a new repo and then migrate? or are there any other suggested migration paths already?

1 Like
352

i think is best to wait.

353

Just great! Better using this compared to the limited api endpoint of solcast where you never know when they will shutdown their free service.

I configured it and the given data is very equally to solcast.

Only constraint is that two different arrays (one south one north) are not working. But could surely be requested as this dev is very responsive!

Thanks for sharing!