Wenn dem dann so wäre, würde ich nun bestenfalls ein Issue auf evcc aufmachen?
Was meinst Du dazu?
Die SFML Prognose passt ja zeitlich einwandfrei im HA-Energy Dashboard, aber nicht außerhalb in evcc. Wie ich gerade gesucht hatte, gab es schon ähnliche Timeshift Problemstellungen mit Prognosen anderer Lösungen wie Solcast, etc., im HA-Energy Dashboard…
P.S. Habe mit Hilfe der KI den Code für evcc nun gefixt - es wird nun “in evcc” automatisch plus 2 Std. für die Sommerzeit, bzw. plus 1. Std. für die Winterzeit als Offset aufgerechnet:
tariff: solar
forecast:
source: http
uri: "http://Home assistant IP:8123/api/states/sensor.solar_forecast_ml_evcc_solar_prognose"
headers:
Authorization: "Bearer xxxxx"
jq: |
(
now
| strflocaltime("%z")
| sub("(?<h>[+-][0-9]{2})(?<m>[0-9]{2})$"; "\(.h):\(.m)")
) as $tz
| .attributes.forecast
| map(
.start = (.start + $tz)
| .end = (.end + $tz)
)
| tostring
cache: 30m
Ich hoffe, das hält dann auch so über die Zeit, bzw. auch beim Wechsel zurück auf die Winterzeit…
@Tom-HA Erklärung der KI was gemacht wurde:
Lösung für 2-Stunden-Zeitversatz bei Solar Forecast ML / Home Assistant → evcc
Ich hatte bei der Einbindung der Solar-Forecast-ML-Prognose aus Home Assistant in evcc einen Zeitversatz von 2 Stunden. Der Peak wurde z. B. in evcc um 15:00 Uhr angezeigt, obwohl er laut Prognose um 13:00 Uhr liegen sollte.
Ursache war nicht der Sensor selbst, sondern die fehlende bzw. falsche Zeitzonenangabe in den Forecast-Zeitstempeln.
Home Assistant liefert die Zeiten z. B. so:
"start": "2026-04-25T13:00:00",
"end": "2026-04-25T13:30:00"
Wenn man in evcc einfach +00:00 anhängt, wird daraus UTC. In Deutschland während der Sommerzeit interpretiert evcc das dann korrekt als 15:00 Uhr lokale Zeit — daher der 2-Stunden-Shift.
Die Lösung ist, den aktuellen lokalen Offset von evcc per jq zu ermitteln und an die Zeitstempel anzuhängen:
tariff: solar
forecast:
source: http
uri: "http://HA-IP:8123/api/states/sensor.solar_forecast_ml_evcc_solar_prognose"
headers:
Authorization: "Bearer DEIN_TOKEN"
jq: |
(
now
| strflocaltime("%z")
| sub("(?<h>[+-][0-9]{2})(?<m>[0-9]{2})$"; "\(.h):\(.m)")
) as $tz
| .attributes.forecast
| map(
.start = (.start + $tz)
| .end = (.end + $tz)
)
| tostring
cache: 30m
Der Block macht keine Zeitumrechnung, sondern hängt nur den passenden lokalen Zeitzonen-Offset an.
Aus:
2026-04-25T13:00:00
wird im Sommer:
2026-04-25T13:00:00+02:00
und im Winter automatisch:
2026-12-25T13:00:00+01:00
Wichtig ist, dass evcc bzw. der Container die richtige Zeitzone verwendet, z. B.:
Europe/Berlin
Danach ggf. den evcc-Cache leeren, evcc neu starten oder testweise cache: 0s setzen. Bei mir verschwindet damit der 2-Stunden-Versatz, ohne dass in Home Assistant ein zusätzlicher Sensor per configuration.yaml nötig ist.