adminandClaude Opus 5
b40feeea23
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>
66 lines
2.5 KiB
Bash
Executable File
66 lines
2.5 KiB
Bash
Executable File
#!/bin/bash
|
|
# Startet die Dauerprozesse des SolarManagers neu:
|
|
#
|
|
# solarManager.py Messwerte einsammeln, Wallbox und
|
|
# Heizung regeln
|
|
# autoActions/autoaction_runner.py die Automatiken aus dem Web-UI
|
|
# auswerten und die Kommandos schicken
|
|
# gatherRainData.py die Regenmenge von Open-Meteo holen und
|
|
# nach Wetter/Regen legen, damit die
|
|
# Bewaesserungs-Automatiken sie als
|
|
# Messwert bekommen
|
|
#
|
|
# Aufgerufen wird das Skript vom Aufgabenplaner beim Hochfahren (als root),
|
|
# es laesst sich aber jederzeit auch von Hand starten: eine schon laufende
|
|
# Instanz wird vorher beendet. Beim Runner ist das wichtig - zwei Instanzen
|
|
# wuerden jedes Kommando doppelt schicken und sich ausserdem gegenseitig vom
|
|
# MQTT-Broker werfen, weil beide dieselbe Client-Kennung benutzen.
|
|
|
|
BASIS="/volume1/homes/wagner/SolarManager"
|
|
PYTHON="/usr/bin/python3"
|
|
|
|
cd "$BASIS" || { echo "$BASIS gibt es nicht"; exit 1; }
|
|
|
|
# Sucht die laufenden Prozesse, auf deren Kommandozeile das Muster passt.
|
|
suchen() {
|
|
ps aux | grep -- "$1" | grep -v grep | awk '{print $2}'
|
|
}
|
|
|
|
# Beendet sie und wartet darauf: erst freundlich mit SIGTERM, nach fuenf
|
|
# Sekunden mit Gewalt. Das Warten ist kein Luxus - startete die neue Instanz,
|
|
# waehrend die alte noch am Broker haengt, wuerde sie sofort wieder getrennt.
|
|
beenden() {
|
|
pids=$(suchen "$1")
|
|
[ -z "$pids" ] && return
|
|
|
|
echo "Beende $1 (PID $pids)"
|
|
kill $pids 2>/dev/null
|
|
|
|
for versuch in 1 2 3 4 5; do
|
|
sleep 1
|
|
pids=$(suchen "$1")
|
|
[ -z "$pids" ] && return
|
|
done
|
|
|
|
echo " reagiert nicht, jetzt mit SIGKILL"
|
|
kill -9 $pids 2>/dev/null
|
|
sleep 1
|
|
}
|
|
|
|
starte() {
|
|
beenden "$1"
|
|
echo "Starte $1, Ausgabe nach $2"
|
|
# Angehaengt, nicht ueberschrieben. Zwei Gruende: nach einem Neustart
|
|
# will man sehen, warum der alte Lauf aufgehoert hat, und logrotate
|
|
# arbeitet hier mit copytruncate - es leert die Datei, waehrend der
|
|
# Prozess sie offen haelt. Beim Ueberschreiben stuende dessen
|
|
# Schreibmarke danach weit hinten, und die Datei bekaeme ein Loch aus
|
|
# Nullbytes in der Groesse des bisherigen Inhalts.
|
|
"$PYTHON" "$1" >> "$2" 2>&1 &
|
|
}
|
|
|
|
starte "solarManager.py" "solarOutput.log"
|
|
starte "autoActions/autoaction_runner.py" "autoActions.log"
|
|
starte "gatherRainData.py" "rainOutput.log"
|
|
starte "gatherForecastData.py" "forecastOutput.log"
|