Solcast Global Solar Power Forecast Integration

Feature Requests
331

An open source solution does sound attractive. I had a quick look at the open-metro integration code and from what I could see it only supports a single set of panel orientations. Same with forecast.solar, single set.

I have panels on both sides of my roof and need a forecast for both arrays which solcast supports (although it does consume 2 API calls to retrieve the two data sets).

At the moment therefore I think I’ll stick with solcast and hope we agree on one main repository - there seems to be several offers at the moment

2 Likes
332

the values haven’t updated for me since one hour ago unfortunately - they are still zero. I will monitor the difference to solcast and the true yield for a week or so and the decide.

333

@andreas-bulling
@geoffreycoan

please report any issue or feature request to meteo forecast dev and support him
he also just started with his project

4 Likes
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