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>
45 lines
2.0 KiB
Plaintext
45 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/forecastOutput.log
|
|
/volume1/homes/wagner/SolarManager/wattpilotshell.log
|
|
/volume1/homes/wagner/SolarManager/wsMQTTbridge.log
|
|
{
|
|
monthly
|
|
# 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 10M
|
|
compress
|
|
# Eine leere Datei zu rotieren bringt nichts ausser vierzehn leeren
|
|
# Archiven, und mehrere dieser Prozesse melden an den meisten Tagen
|
|
# gar nichts.
|
|
notifempty
|
|
# Fehlt eine Datei, ist das kein Fehler: nicht jeder Prozess laeuft
|
|
# auf jedem System.
|
|
missingok
|
|
copytruncate
|
|
}
|