wecker.py hat genau das getan, was der AutoAction-Runner ohnehin kann -
nur mit allem doppelt: eigener Datenbank alarm, eigenem Feiertags- und
Ferienkalender neben calendar_days, eigenem UDP-Log auf Port 13377,
eigener Endlosschleife und einem Startskript samt naechtlichem Neustart
um drei.
Punkt fuer Punkt hatte der Runner die bessere Fassung schon: die Zeit
als Bedingung "um 05:50" mit Nachholfenster statt eines Vergleichs im
20-Sekunden-Takt, weekdays als Bitmaske statt sieben Spalten,
on_holiday/on_vacation gegen calendar_days statt gegen einen zweiten
Kalender, die steigende Flanke statt einer wecked-Spalte, und den
Versand mit einem Faden je Geraet statt fuenf HTTP-Versuchen im Abstand
von vier Sekunden.
Umgezogen ist die eine Weckzeit, die scharf war: 05:50, Mo-Fr, nicht in
den Ferien, nicht an Feiertagen, WLED-Preset 5 auf MenasHimmel. Die drei
anderen Zeilen in alarmtime standen auf onoff = -1.
wecker_zu_automatik.sql legt die Automatik an und beschreibt im Kopf,
wie dasselbe im Dashboard von Hand geht.
Die Datenbank alarm und der Abschnitt [alarm] in der config.ini bleiben
vorerst stehen - sie liest nur niemand mehr.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bisher gab es nur ein README zum Runner. Wer wissen wollte, welches
Skript eine Zahl liefert und wer sie weiterverwendet, musste sich das aus
Importen, Topic-Namen und Startskripten zusammensuchen - und hatte am
Ende trotzdem nicht gesehen, dass fuer einen Teil der Messwerte gar kein
Skript zustaendig ist.
Zwei Mermaid-Diagramme, geteilt am MQTT-Broker: das erste zeigt, woher
die Zahlen kommen, das zweite, wer sie benutzt. Dazu Tabellen, wem
welches Topic und welche Datenbank gehoert und was wann startet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
adminandClaude Opus 5