adminandClaude Opus 5
64654ac629
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>
44 lines
2.0 KiB
Plaintext
44 lines
2.0 KiB
Plaintext
# Rotation der Logdateien des SolarManagers.
|
|
#
|
|
# Aufgerufen wird das ueber logs_rotieren.sh, einmal taeglich aus dem
|
|
# Aufgabenplaner. Nicht in /etc/logrotate.d abgelegt: das ist DSM-Gebiet und
|
|
# waere beim naechsten Systemupdate weg. Hier steht es neben den Prozessen,
|
|
# zu denen es gehoert, und liegt im selben Repository.
|
|
#
|
|
# copytruncate ist der Kern der Sache. Die Prozesse laufen monatelang durch
|
|
# und halten ihre Logdatei offen; niemand will sie fuer eine Rotation neu
|
|
# starten. Also wird der Inhalt weggeschrieben und die Datei geleert, statt
|
|
# sie umzubenennen - der Prozess merkt nichts davon. Voraussetzung ist, dass
|
|
# die Startskripte mit ">>" umleiten und nicht mit "&>", sonst schreibt der
|
|
# Prozess nach dem Leeren an seiner alten Stelle weiter und die Datei
|
|
# bekommt ein Loch aus Nullbytes. Genau deshalb wurde das dort umgestellt.
|
|
#
|
|
# Der Preis von copytruncate sind die Zeilen, die zwischen Kopieren und
|
|
# Leeren hereinkommen - die gehen verloren. Bei einem Betriebslog ist das
|
|
# der guenstigere Handel.
|
|
|
|
/volume1/homes/wagner/SolarManager/solarOutput.log
|
|
/volume1/homes/wagner/SolarManager/autoActions.log
|
|
/volume1/homes/wagner/SolarManager/rainOutput.log
|
|
/volume1/homes/wagner/SolarManager/wattpilotshell.log
|
|
/volume1/homes/wagner/SolarManager/wsMQTTbridge.log
|
|
/volume1/homes/wagner/SolarManager/wecker.log
|
|
{
|
|
daily
|
|
# Zwei Wochen zurueck. Weiter zurueck hat noch nie jemand gesucht, und
|
|
# was aelter ist, steht ohnehin als Messwert in der Datenbank.
|
|
rotate 14
|
|
# Zusaetzlich zur Tagesgrenze: was ueber 20 MB geht, wird sofort
|
|
# rotiert. Sonst koennte ein Prozess, der in eine Fehlerschleife
|
|
# geraet, an einem einzigen Tag das Volume fuellen.
|
|
maxsize 20M
|
|
compress
|
|
# Eine leere Datei zu rotieren bringt nichts ausser vierzehn leeren
|
|
# Archiven - der Wecker meldet an den meisten Tagen gar nichts.
|
|
notifempty
|
|
# Fehlt eine Datei, ist das kein Fehler: nicht jeder Prozess laeuft
|
|
# auf jedem System.
|
|
missingok
|
|
copytruncate
|
|
}
|