How did you get them to stack? I have your same original problem where the forecast graphs for the three pv_estimates show, but only one historical (not the 10 or 90).
type: custom:apexcharts-card
graph_span: 36h
span:
start: day
offset: '-6h'
header:
show: true
title: Solar Production vs. forecast
show_states: true
now:
show: true
label: now
apex_config:
legend:
show: false
series:
- entity: sensor.goodwe_ppv
stroke_width: 2
show:
extremas: false
color: '#FFF700'
name: Actual
unit: W
fill_raw: last
extend_to_end: false
group_by:
func: avg
duration: 30min
- entity: sensor.solcast_forecast_data
stroke_width: 2
show:
extremas: false
color: '#3498DB'
transform: return x * 1000;
name: Forecast
unit: W
fill_raw: last
extend_to_end: false
- entity: sensor.solcast_forecast_10
stroke_width: 2
show:
extremas: false
in_header: false
color: '#797D7F'
transform: return x * 1000;
name: Forecast 10
unit: W
fill_raw: last
extend_to_end: false
opacity: 0.4
- entity: sensor.solcast_forecast_90
stroke_width: 2
show:
extremas: false
in_header: false
color: '#797D7F'
transform: return x * 1000;
name: Forecast 90
unit: W
fill_raw: last
extend_to_end: false
opacity: 0.4
- entity: sensor.solcast_forecast_data
stroke_width: 2
show:
extremas: false
in_header: false
color: '#E74C3C'
type: line
extend_to_end: false
unit: W
data_generator: |
return entity.attributes.forecasts.map((entry) => {
return [new Date(entry.period_end), entry.pv_estimate*1000];
});
- entity: sensor.solcast_forecast_data
stroke_width: 2
show:
extremas: false
in_header: false
color: '#797D7F'
type: line
extend_to_end: false
unit: W
opacity: 0.4
data_generator: |
return entity.attributes.forecasts.map((entry) => {
return [new Date(entry.period_end), entry.pv_estimate10*1000];
});
- entity: sensor.solcast_forecast_data
stroke_width: 2
show:
extremas: false
in_header: false
color: '#797D7F'
type: line
extend_to_end: false
unit: W
opacity: 0.4
data_generator: |
return entity.attributes.forecasts.map((entry) => {
return [new Date(entry.period_end), entry.pv_estimate90*1000];
});
Just use the additional 10/90 sensors for historic data and then I guess you already have the additional data_generator sensors to get them for forecast.
I’ve added your sensor code, and most things look great. Thank you! Unless I’m missing something, though, there does seem to be one anomaly - the forecast power for the next 24 hours. I’ve attached a screenshot. This was taken at around 18.25 local time. Figures look very sane, except that the figure for the next 24 hours seems to be just double that for tomorrow. There could well be something I’m not understanding here though, because one measurement is energy, and the other power.
@safepay wondering whether you’ve looked into it. Seems to do most of what is implemented in this thread, with the exception of 10/90% probabilities, with the added advantage that it integrates with the Energy component, so the forecast shows on Energy’s solar graph.
It seems to be a little over-zealous with API calls at the moment (there’s an open issue). Someone also says it does 2 API calls every hour, one for live, one for forecast, but I thought the method on this thread did everything in one call. Is that right? Integration doesn’t poll overnight though.
You can install it using HACS by adding its Github page as a custom repository.
Hi again @safepay. I’ve been running the solcast integration in parallel for a little while now. Its older version, 1.0.5, as described on the thread, seems to be OK with api calls. Looking at its sensors has brought up a couple of issues.
A sensor called energy_production_forecast_today has a fixed value all day. The sensor solcast_forecast_energy_today in the templates above doesn’t. Is it right that it contains the forecast for the rest of today? I’m not sure which approach is the best, or whether the Energy platform on whose sensors you seem to have based the templates dictates one approach over the other.
The template sensors solcast_forecast_energy_current_hour and solcast_forecast_energy_next_hour contain very different values to the integration’s energy_this_hour and energy_next_hour. In fact, they are about half the integration’s values, and the integration’s values seem to make more sense. I can see the templates for these sensors above take the first two “slots” in the solcast data for the current hour, and the next two slots for the next hour, and then divides by two, eg:
- name: "Solcast Forecast Energy Current Hour"
unique_id: solcast_forecast_energy_current_hour
state: >
{% set ns = namespace (fc_energy_current = 0) %}
{% for i in range(0, 1) %}
{% set ns.fc_energy_current = ns.fc_energy_current + (states.sensor.solcast_forecast_data.attributes['forecasts'][i]['pv_estimate']/2)|float %}
{%- endfor %}
{{ ns.fc_energy_current|round(2) }}
unit_of_measurement: 'kWh'
device_class: energy
Given that it is calculating the power for an hour, I’m not sure it should be doing the division by two. Or am I way off here? Thank you.
