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 
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;
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