Hallo zusammen,

ich würde gerne wissen, ob ich irgendwie eine alternative PV-Ertragsprognose nutzen kann. Die von forecast.solar ermittelten Werte sind oft leider sehr daneben (bei schlechtem Wetter oft 3-4x zu hoch, bei gutem Wetter dafür oft nur die Hälfte... :( )

Ich nutze im Home Assistant Solcast, was bei exakt gleicher Konfiguration wirklich extrem genaue Prognosen liefert.

Kann ich meine WARP3 irgendwie dazu bringen, entweder direkt oder über mein Home Assistant die Solcast-Daten zu nutzen?

Aktuell unterstützen wir nur die API von forecast.solar. Für die dynamischen Strompreise ist es geplant dass man anstatt die Strompreise von api.warp-charger.com zu pullen, diese auch per MQTT oder HTTP API rein-pushen kann. Würde sich sicher anbieten das für die PV-Ertragsprognose auch so anzubieten.

Am 12.2.2026 um 08:59 schrieb borg:

Aktuell unterstützen wir nur die API von forecast.solar. Für die dynamischen Strompreise ist es geplant dass man anstatt die Strompreise von api.warp-charger.com zu pullen, diese auch per MQTT oder HTTP API rein-pushen kann. Würde sich sicher anbieten das für die PV-Ertragsprognose auch so anzubieten.

Das wäre toll! Auf HomeAssistant gibt es ein Projekt eine lokale PV-Ertragsprognose mittels lokaler KI bereitzustellen:

Solar-Forecast-ML

Forum dazu

Hallo zusammen,
hallo @borg ,

mit der Firmware 2.10.0 scheint das Feature "Push API" bereits implementiert worden zu sein, zumindest sehe ich es in der Oberfläche und kann Daten auch grundsätzlich via MQTT an das entsprechende Topic `solar_forecast/planes/0/forecast_update` schicken. In meinem Fall verwende ich einen OpenMeteo-Forecast aus Home Assistant, der in 15-Minuten-Schritte aufgeteilt ist - dazu erhalte ich im Warp-System-Log dann jedoch:

[...]
2026-05-05 16:50:48,197 | mqtt             | On solar_forecast/planes/0/forecast_update: Only 60 minute resolution is supported

Das entsprechende "Fehler"-Handling finde ich auch im Code und wurde mit folgendem Commit reingebracht:

https://github.com/Tinkerforge/esp32-firmware/commit/93c40e2b2d95e8ec56e4b38a9cc7b2330da16190

Was ich dabei allerdings nicht verstehe: In der Dokumentation zum Endpunkt (hier) ist die Option resolution: 0 explizit aufgeführt:

Was ist der Grund für die Beschränkung auf 60 Minuten? Übersehe ich etwas?

Die Konfiguration für 15 Minuten hatten wir damals schon vorgesehen, das solar_forecast-Backend unterstützt aktuell allerdings nur 60 Minuten. Im Moment ist es auch nicht geplant das zu erweitern. Ich füge das noch in der Doku hinzu das 15-Minuten-Auflösung aktuell nicht unterstützt wird.

Danke für die Rückmeldung, das erklärt es. Sende ich die Daten in 60-Minuten-Auflösung von HA via MQTT an die WARP, so funktioniert es wie gewünscht und erwartet ☀️.

Für heute und morgen (mit leider recht regnerischem Ausblick):

Mal eine dumme Frage, eines noch nicht Warp Users:

Welchen Sinn hat die Prognose hier, weil die Ladung doch in der Regel anhand der gerade zur Verfügung stehenden PV Energie gesteuert wird, wenn PV Überschuss geladen wird.

Ich kenne die Prognose auch für SMA, aber da ist es ja auch hauptsächlich um zu sehen, was der Tag so bringt und eventuell für das prognosebasierte Laden des Heimspeichers.

Du kannst den Eco-Modus aktivieren und dort z.B. einstellen: "Ich möchte 4 Stunden Laden und ich fahre in 12 Stunden los". Der Eco-Modus würde dann anhand der PV-Ertragsprognose entscheiden wann geladen wird. Zum Beispiel könnte um 06:00 morgens der dynamische Strompreis sehr günstig sein. Wenn die PV-Ertragsprognose sagt es gibt keine Sonne, dann würde zu den Morgenstunden zum günstigen Preis geladen. Wenn die PV-Ertragsprognose sagt es wird Sonne geben, dann würde der WARP Charger auf die Sonne warten und den PV-Überschuss gegenüber den günstigen Preisen bevorzugen.

Mehr Infos hier: https://docs.warp-charger.com/de/docs/webinterface/energy_management/eco_mode

Am 6.5.2026 um 15:34 schrieb StS:

Danke für die Rückmeldung, das erklärt es. Sende ich die Daten in 60-Minuten-Auflösung von HA via MQTT an die WARP, so funktioniert es wie gewünscht und erwartet ☀️.

Für heute und morgen (mit leider recht regnerischem Ausblick):

Hallo StS:

Kannst du einem nicht so MQTT versierten HA User (z.B. mir ;-)) kurz and knackig erklären, wie du das Senden der Daten via MQTT an die WARP implementiert hast?

Mir fehlt der grundlegende Ansatz. Details kann ich mir sicherlich selber erschließen.

Danke :-)

bearbeitet May 11, 2026 at 08:1111. Mai 2026 von bsc76

Hi @bsc76 ,

in meinem Fall hole ich mir über die OpenMeteo-Integration (Link) in HomeAssistant die zusammengefassten Vorhersage-Daten für mein komplettes, verwinkeltes Dach (insgesamt sieben verschiedene Flächen) für die nächsten sieben Tage. Die Integration stellt diese Informationen in verschiedenen Entitäten bereit, unter anderem als

sensor.<bezeichner-des-dienstes>_energy_production_today
sensor.<bezeichner-des-dienstes>_energy_production_tomorrow
sensor.<bezeichner-des-dienstes>_energy_production_d2
sensor.<bezeichner-des-dienstes>_energy_production_d3
[...]

Innerhalb dieser Entitäten gibt es mehrere State-Attribute mit a) viertelstündlichen Leistungsvorhersagen (watts) und b) stündlichen Energie-Prognosen (wh_periods):

watts:
  "2026-05-15T00:00:00+02:00": 0
  "2026-05-15T00:15:00+02:00": 0
  "2026-05-15T00:30:00+02:00": 0
  [...]
wh_periods:
  "2026-05-15T00:00:00+02:00": 0
  "2026-05-15T01:00:00+02:00": 0
  "2026-05-15T02:00:00+02:00": 0
  "2026-05-15T03:00:00+02:00": 0
  "2026-05-15T04:00:00+02:00": 0
  "2026-05-15T05:00:00+02:00": 127.75
  "2026-05-15T06:00:00+02:00": 654.75
  [...]

Letztere nutze ich in einem Template-Sensor, um sie in das Format der Warp zu transformieren:

# NOTE: This file is included via !include ./templates/ in configuration.yaml, hence
#       we keep indentation one level down for proper format compatibility
  - sensor:
      - name: "OpenMeteo WARP Forecast"
        unique_id: custom__openmeteo_warp_forecast
        state: "OK"  # Placeholder state, since the data is in attributes
        attributes:
          forecasts: >
            {% set sensors = [
              'sensor.pv_dach_gesamt_energy_production_today',
              'sensor.pv_dach_gesamt_energy_production_tomorrow'
            ] %}
            {% set combined = namespace(value=[]) %}
            {% set start_of_today_in_minutes = (as_timestamp(today_at("00:01")) / 60) | round%}
            {% set resolution = 1 %} {## 0 = 15 minutes, 1 = 60 minutes ##}
            {% for sensor in sensors %}
              {% set forecasts = state_attr(sensor, 'wh_period') %}
              {% if forecasts is iterable and forecasts | length > 0 %}
                {% for wh_period_start, wh_period_value in forecasts.items() %}
                  {% set combined.value = combined.value + [wh_period_value | round] %}
                {% endfor %}
              {% endif %}
            {% endfor %}
            {% set result = {'first_date': start_of_today_in_minutes, 'resolution': resolution, 'forecast': combined.value} %}
            {{ result | tojson }}

Und die Daten dieses Ergebnis-Sensors schicke ich dann über eine Automatisierung stündlich an den dokumentierten MQTT-Endpunkt der Warp:

That's it :-).

(Ich mache das gleiche (in anderem Zielformat) im Übrigen auch für EVCC, das bei mir die eigentliche Lade-Steuerung und Optimierung vornimmt. Die Übertragung an die Warp ist für mich aktuell eher technische Spielerei.)