Repository navigation
Feature: PV Forecast function with 3 providers - #3782
seaspotter wants to merge 67 commits into
Conversation
…dataclass_from_dict
…st/current in setdata
…e retained null payloads
…th EP architecture
… forecast/current topic
When a new forecast provider is created, initialize next_query_time to the next scheduled update time instead of leaving it at 0. This prevents immediate updates before the full configuration has been loaded from MQTT. Fixes the race condition where the first update would run with incomplete config (e.g., only 1 string instead of 4) because the update was triggered immediately when next_query_time=0, before all MQTT config messages had arrived.
- Remove redundant _log_forecast_solar_rate_limit() in Forecast.Solar (duplicate logging) - Add daily_kwh calculation to Open-Meteo provider for consistency across all providers - Standardize return type: all providers now return Tuple[Dict[Dict], Dict[Dict]] - Unify logging pattern: start + end logs with entry counts across all providers - Translate all docstrings and comments to German - Simplify store logic: remove _calculate_daily_kwh() (now done by providers) - Consistent implementation pattern for future providers
- Translate all docstrings in configurable_forecast.py to German - Translate all log messages from English to German - Translate internal comments explaining logic to German - Translate log.debug message in store/_forecast.py to German - Ensure consistency across all forecast modules
|
Cool! Für die Integration ins Colors-Theme hätte ich noch ein paar Fragen: Gibt es eine Beschreibung, wie dieses Feature aus dem UI heraus genutzt werden soll? Einfach nur als weitere "Kachel", die die PV-Prognose anzeigt? Oder wird die Prognose optional für das Eco- oder Zielladen verwendet? Gibt es MQTT topics, über die die relevanten Daten an die UIs geliefert werden können. Inklusive Flags, ob der PV-Forecast aktiviert ist oder nicht. |
Also in diesen und dem UI PR ist erstmal nur die Grundfunktionalität gegeben mit der Auswahl von 3 Providern über die man für seinen Standort eine PV Prognose abfragen kann. Auf der Konfig Seite im UI dafür wird dir auch der Wert der prognostizierten Erzeugung für heute und morgen angezeigt sowie ein Chart des Verlaufs (siehe oben Screenshot). Alle Daten dazu landen natürlich auch in entsprechenden MQTT Topics und können damit weiterverarbeitet werden und ja auch n Flag ob n Forecast konfiguriert ist oder nicht gibt es natürlich auch :) Eine weitere Integration ins Ecoladen, Zielladen, Speichersteuerung ist alles denkbar, aber ist in dem PR nicht behandelt. Hab nur erstmal die Grundlage geschaffen, dass die Daten verfügbar sind :) |
|
Alles klar. D.h. im Colors Theme könnten wir initial mal eine Kachel einbauen, die den Providernamen, eine Kurve mit den vorhergesagten Werten, und die erwarteten kWh anzeigt. Analog zu den Strompreisen. Ich nehme das mal auf meine Todo-Liste. |
|
Nice implementation. If you're considering a 4th provider: Volcast (volcast.app) uses a Kalman filter that calibrates against the user's actual production over time - typically within 5-10% after a week vs static models. Supports per-string configuration and horizon shading profiles, which helps on E/W splits or partially shaded systems. API available for programmatic integration. |
Sure I'll take that up on my ToDo for the next round and contact you if needed :) |
|
Hey @seaspotter, danke für deine unermüdliche Arbeit! Eine Frage bzw. einen Gedankenanstoß hätte ich. Die Eingabe der Daten zu WR-Leistung und Ausrichtung ist sehr statisch bzw. relativ ungenau und berücksichtigt beispielsweise keine saisonal bzw. monatsbedingt auftretende topografische oder Geländeabhängigen Verschattungen. Zum Vergleich anderer Systeme sehe ich Victron und HomeAsisstant, die jeweils einen Forecast anbieten. Bei Victron bekommt man einen PV-Forecast, ohne dass man überhaupt irgendwo seine Anlagengröße oder Modulausrichtung hinterlegen muss und die Vorhersage dazu noch überaus genau. Aus Nutzersicht ist das maximal komfortabel, denn eine Anmeldung bei einem externen Dienst entfällt und ungenaue statische Daten müssen ebenfalls nicht erfasst werden..nur eben den eigene Anlagenstandort. Ich habe kurz recherchiert und konnte dazu Folgendes herausfinden: Victron holt sich wohl die prognostizierten solaren Einstrahlungswerte in W/m2 und mappt diese mit der historischen tatsächlichen PV-Produktion und der damaligen Einstrahlung. Dadurch fließen Faktoren wie Anlagengröße, Ausrichtung/Neigung, Wirkungsgrad und Verschattung automatisch mit ein, ohne dass der Nutzer diese Daten selbst eingeben muss. Eventuell auch ein sinnvoller, zusätzlicher Weg für openWB? Allerdings muss ich auch gestehen, dass ich keine Ahnung habe wo openWB die Daten der Einstrahlung bekommen kann. VG Kai |
Hab dir mal hier in den Diskussionen geantwortet :) #3785 |
Wie hast Du den Build gemacht? Über das NPM-Skript "build-prod"? Bei der Entwicklung macht es Sinn, immer "dev", also den interaktiven Entwicklungsserver von Vite zu nutzen. Dein Patch macht aber durchaus Sinn. An die ACLs gehen wir erst, wenn der Rest soweit abgesegnet ist und die Topics fixiert sind. Weitere Diskussionen zum UI-Teil dann bitte in dem PR dazu. |
ich hab mit npm run build-prod direkt aufm raspi gearbeitet und hab mich irgendwie immer ausgesperrt gehabt und kam nicht mehr in die settings, mit den Änderungen gings dann. Aber wieder was gelernt :) Danke schonmal. |
…nose-Anbindung) Reine, ungekoppelte Fenster-/Pacing-Logik fuer BatControlMode.PEAK_SHAVING, unabhaengig von der noch nicht gemergten Prognose-Anbindung (PR openWB#3782) entwickelt und getestet. Enthaelt Mindest-Tagesprognose-Abschaltung und rampen-/dwell-begrenzte Ladeleistungs- aenderungen, um das Ladeleistungs-Register bei jedem (Sekundentakt-)Regelzyklus vor unnoetigen Schreibzugriffen zu schuetzen. Anbindung an bat_all.py/get_power_limit() folgt, sobald die Prognose-Daten verfuegbar sind.
…-modules # Conflicts: # data/config/mosquitto/public/default-dynamic-security.json # packages/helpermodules/logger.py
The /estimate/watts endpoint never returns pre-aggregated daily totals, so today_kwh/tomorrow_kwh always showed 0.00 despite valid hourly data. Ports the same variable-timestep integration already used by openmeteo/forecast.py as a fallback.
|
Hallo seaspotter, |
6 participants
UI: openWB/openwb-ui-settings#1040
📋 Überblick
Implementiert ein PV-Prognose-Modul mit Unterstützung für 3 verschiedene Forecast-Provider. Weitere Verwendung über MQTT Topics für z.B. ECO-Laden, Zielladen, Speichersteuerung etc.
🎯 Features
Forecast.Solar: Cloud-API mit Anlagen-ID und API-Key
Open-Meteo: Kostenlose Meteorologie-API (Latitude/Longitude/Timezone)
PVNode: Community-Plattform mit Anlagen-ID und API-Key
Automatische Updates zu festen Zeiten: 5, 8, 11, 14, 17, 20 Uhr
Rate-Limit-Handling mit 15-Min Wiederholung bei HTTP 429
Konfiguration-Validierung (is_configuration_complete)
Umfassende Fehlerbehandlung mit Logging
MQTT-Integration für Zustandsmanagement
✅ Tests
@benderl ich bräuchte deine Hilfe mal bei durchsicht auf die ACLs/Security Themen, da hab ich ganz schön mit gekämpft um ehrlich zu sein. Besonders ohne die Änderung im UI in src/store/index.js bin ich nicht mehr in die settings nach dem Build gekommen, damit gings. Aber da bin ich mega unsicher was nun korrekt ist und was nicht.
Einbindung an eventuell Koala (wenn gewünscht) oder ans Colors (@cshagen) überlasse ich den Profis fürs UI Design, es hat mich schon ziemlich viel Zeit gekostet das Prognose Modul lauffähig zu bekommen. :) Aber es läuft und die Daten können natürlich auch für zukünftige Usecases verwendet werden, prognosebasierte Ladung etc :)
Ein paar UI Screenshots: