gatherForecastData.py holt alle zwanzig Minuten Stunden- und Tageswerte und
schreibt sie nach solarLog (weatherHours, weatherDays, weatherForecastLog,
weatherTilted). Grundlage des neuen Meteogramms im Web-Repository.
Kein Anbau an gatherRainData.py, obwohl es dieselbe Schnittstelle benutzt:
dessen Fehlerregel ist sicherheitsrelevant - es leert bei einer Stoerung
bewusst seine Werte, damit der Runner nicht auf eine alte "0,0 mm" hin
giesst. Hier gilt das Gegenteil, eine Vorhersage von vor zwei Stunden ist
brauchbar und wird nur als alt beschriftet. Zwei gegenlaeufige Fehlerregeln
in einer Schleife waeren eine Falle.
Es wird nichts geloescht. Die Tabellen sind zugleich ein Archiv: aus der
Einstrahlung und EnergyFlow_hourly.pv_kwh soll spaeter eine eigene
Ertragsprognose gerechnet werden. 8.760 Zeilen im Jahr kosten 1,5 MB.
wetterarchiv_nachtragen.py fuellt das Archiv rueckwirkend aus der
ERA5-Schnittstelle von Open-Meteo - 39.264 Stunden ab dem 02.04.2022, dem
Beginn von EnergyFlow_hourly. Damit ist die Korrelation sofort rechenbar
statt erst in einem Jahr.
Sonnenzeiten schreibt es dabei ausdruecklich nicht: die Archiv-Schnittstelle
rechnet alle Zeiten mit dem heute gueltigen Zeitzonenversatz um und meldet
das auch selbst ("utc_offset_seconds: 7200" fuer einen Dezembertag).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gatherBYDData.py fragt die BMU der HVM unter 192.168.16.254:8080 ab
(BE-Connect-Protokoll, nach ioBroker.bydhvs): Ladestand und SOH laut BMU,
128 Zellspannungen, 64 Temperaturen, Spreizung, Ausgleich, Fehlerbits,
Gesamtzaehler. Das Netzwerkmodul startet alle ~102 s neu und bedient nur
die ersten Verbindungen danach - eigene Klopf-Schleife, ein Satz etwa alle
100 s. Werte unter solarManager/byd/#, Historie in byd und byd_zellen.
tbatt kommt jetzt aus der BMU statt fest 0. mqttClient.publish legt ein
einzelnes Dataclass-Objekt in rtData als Untertopics ab.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- autoActions/README: Rahmen gilt heute oder am Vorabend fuer morgen,
vorabend.sql beim Einrichten, startSolarServer.sh startet drei Prozesse,
Beispiel der Verkettung wie die echten Automatiken, Neustart ueber SSH
- README: skoda_ladepunkte und skoda.conf, Werkzeuge-Tabelle, Datenbank
alarm ist geloescht
- config.ini.example: [alarm] und zeit.py entfernt, die gibt es nicht mehr
- Runner-Kopfkommentar verweist nicht mehr auf auto_watering.py
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Erster Teil der Abloesung von auto_watering.py im Web-Repo. Das Skript
dort entschied bisher selbst: stuendlich den Regen holen, mit Schwellen
aus einer ZONES-Tabelle vergleichen, schalten. Kuenftig entscheidet der
AutoAction-Runner, und die Schwellen stehen im Editor statt im Quelltext.
Dieser Sammler liefert dafuer nur noch die Zahl. Alle dreissig Minuten
holt er die Niederschlagsdaten von Open-Meteo und legt sie als retained
JSON nach Wetter/Regen:
{"tage1": 0.4, ..., "tage7": 3.4, "stand": "04.09.2026 09:00:00"}
"tageN" ist die Summe ueber N Tage, wobei der heutige, noch laufende Tag
als letzter zaehlt - dieselbe Rechnung wie accumulated_rain() im alten
Skript. Der heutige Tag kommt aus den Stundenwerten und nicht aus der
Tagessumme: die traegt die Vorhersage fuer den Rest des Tages mit, und
Regen, der erst am Abend kommen soll, hat eine Bewaesserung am Morgen
nicht zu verhindern.
Veroeffentlicht werden immer alle sieben Fenster. Welche davon als
Messwert auftauchen, entscheidet allein das Discovery-Modul im Web-Repo -
so muessen sich die beiden Repositorien nicht ueber eine Fensterliste
einigen, und eine vierte Zone mit einem vierten Zeitraum kostet hier
keine Aenderung.
Ein Dauerlaeufer und kein Cronjob, weil der alte Wert nicht einfach
stehenbleiben darf, wenn Open-Meteo ausfaellt: eine retained "0,0 mm" von
gestern wuerde den Runner bei naechster Gelegenheit giessen lassen. Der
letzte Wert gilt deshalb nur, solange er juenger als max_alter_stunden
ist, danach werden leere Werte geschickt - eine Bedingung auf einem
leeren Messwert gilt im Runner als nicht erfuellt. auto_watering.py tat
dasselbe, nur mit sys.exit(1).
Der Runner selbst bleibt unangetastet: Wetter/Regen ist fuer ihn ein ganz
gewoehnliches MQTT-Geraet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Erster Stand der Hintergrundprozesse, die auf der Synology unter
/volume1/homes/wagner/SolarManager laufen: der Manager selbst, die Sammler
je Geraet, die MQTT-Bruecke, der Wecker und - neu hinzugezogen - der
AutoAction-Runner, der als Hintergrundprozess hierher gehoert und nicht ins
Web-Verzeichnis.
Zugangsdaten stehen nicht mehr im Quelltext, sondern in config.ini, die
nicht mit eingecheckt wird. Vorlage ist config.ini.example, gelesen wird sie
von konfig.py. Betroffen waren solarManager.py (Datenbank und Wattpilot),
zeit.py, gatherWaterData.py, wecker.py und skoda_testdaten.py, das sich das
Passwort bisher aus dem Quelltext eines anderen Moduls herausgesucht hat.
Die Kia-Anbindung ist mit dem Fahrzeug entfallen: kiaTest.py,
gatherCarData.py und hyundai_kia_connect_api sind nicht mehr dabei, ebenso
gatherInverterData.py, auf das nur noch eine auskommentierte Zeile zeigte.
Die mitgelieferten Bibliotheken bleiben im Repository - die NAS hat kein
pip, sie muessen neben den Skripten liegen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
adminandClaude Opus 5