Forecast.Solar 'list' object has no attribute 'items'

We are working on better error handling in this situation.

What about restarting home Assistant?

Does that make another call?

I suspect so, but I’m not sure :thinking:

I definitely didn’t add it twelve times

Neither did I. I’m happy to try again once some fixes have been applied. Now that I’ve seen the map, I can tell it isn’t going to give me any data over here in the land of the long white cloud, but testing that situation is worth doing and I’m happy to do it

Then it is also a mystery to me, after an hour you should at least receive data.

Also from Aotearoa / NZ and very interested in experimenting/testing this integration. It’s the long white cloud but the sun does shine here! On start up and after day or so I have:
Retrying setup: Error occurred while communicating with Forecast.Solar API
I am using public version without specific API key.

I understand we are off the map, so will be interested if there are future developments.

In the next core release there will be a better error exception handling and more!

I am in Australia too, but I don’t think this is the issue. My home pin/GPS location is less than 1km away from a pin located on their public map, so it should easily be able to adjust to that - yet I am still getting the same error. I have even signed up for the lowest tier account to see if that would fix it, and it has not.

The map only shows where certain requests come from (globally), it’s not a map that shows the coverage of the API. If your location is not in the colored area on this map, then you are outside the zone where data is available.

Ohh, super lame. Guess they won’t get my 12EUR a year then.

Pretty poor to have an integration that has no mention of being restricted to pretty much the Northern Hemisphere in its README.

I’m sure a lot of people are wasting their time with this with the advent of the Energy panel in the latest release.

The rest of the world exists too…

Vote for a SolCast integration:

4 Likes

There is a PR open, so it’s possible that the information will be included this week.

Personally, there’s not much I can do about the lack of global coverage for this integration. If there are other APIs that could possibly fill in the parts that are missing on data coverage, then I’d like to take a look at that and work on integrating it with Home Assistant.

Not sure about this.

There is a custom component.

If this is viable, then it would be nice to see the Energy Panel use multiple options that cover the whole planet.

2 Likes

SolCast looks great! Hopefully it can get integrated to the energy dash :slight_smile:

Thanks to resource: https://api.solcast.com.au/rooftop_sites/SOLCAST_RESOURCE_ID/forecasts?format=json&api_key=SOLCAST_API_KEY

I can get Solcast data from their API using the following code (I changed to the new template format from the original post):

sensor:
  - platform: rest
    name: solcast_forecast_data
    json_attributes:
      - forecasts
    resource: https://api.solcast.com.au/rooftop_sites/SOLCAST_RESOURCE_ID/forecasts?format=json&api_key=SOLCAST_API_KEY
    method: GET
    value_template: "OK"
    scan_interval: 01:00
    force_update: true

template:
  - sensor:
      - name: "Solcast Forecast Today"
        unit_of_measurement: "kWh"
        device_class: energy
        state: >
          {% set ns = namespace (fc_today = 0) %}
          {% for forecast in state_attr('sensor.solcast_forecast_data', 'forecasts')|default('variable is not defined') %}
            {% set daydiff = as_local(strptime(forecast.period_end, '%Y-%m-%dT%H:%M:%S.%f0Z').replace(tzinfo=utcnow().tzinfo)).date() - as_local(utcnow()).date() %} 
            {% if daydiff.days == 0 %}
              {% set ns.fc_today = ns.fc_today + (forecast.pv_estimate/2)|float %}
            {%- endif %}
          {%- endfor %}
          {{ ns.fc_today|round(2) }}
      - name: "Solcast Forecast Tomorrow"
        unit_of_measurement: "kWh"
        device_class: energy
        state: >
          {% set ns = namespace (fc_tommorrow = 0) %}
          {% for forecast in state_attr('sensor.solcast_forecast_data', 'forecasts')|default('variable is not defined') %}
            {% set daydiff = as_local(strptime(forecast.period_end, '%Y-%m-%dT%H:%M:%S.%f0Z').replace(tzinfo=utcnow().tzinfo)).date() - as_local(utcnow()).date() %} 
            {% if daydiff.days == 1 %}
              {% set ns.fc_tommorrow = ns.fc_tommorrow + (forecast.pv_estimate/2)|float %}
            {%- endif %}
          {%- endfor %}
          {{ ns.fc_tommorrow|round(2) }}
      - name: "Solcast Forecast Tomorrow"
        unit_of_measurement: "kWh"
        state: >

The unknown is which sensor(s) the Energy Panel needs to be able to work.

In my other post I have mimiced the Forecast.Solar sensors.

It would be better if the Energy Panel config allowed the selection of specific sensors, rather than forcing selection of a particular implementation. Then the Energy Panel could work with Custom Integrations, Rest integrations, as well as alternative Integrations.

Vote for a SolCast integration:

2 Likes

The websites map SHOWS Australia and New Zealand as being available. Why do that if they can’t support;

image

You are misinterpreting the map. This does not show which locations are supported, but shows where requests to the API come from.

1 Like

Don’t forget to vote for a SolCast integration to solve this problem:

2 Likes