- 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>
Mit next_day = 1 gelten Wochentage, Ferien und Feiertage fuer morgen
(gemeinter_tag). kalender() merkt sich dafuer heute und morgen und haelt
einen fehlgeschlagenen Abruf nicht mehr den ganzen Tag fest. Uhrzeit,
Zeitfenster und once_per_day bleiben beim heutigen Tag. vorabend.sql legt
die Spalte an.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"An Wochenenden und Feiertagen" liess sich bisher gar nicht schreiben.
Die Wochentagsmaske kennt nur Samstag und Sonntag, und ein Feiertag am
Dienstag ist fuer sie eben ein Dienstag; on_holiday war ja/nein und
konnte nur wegnehmen, nie hinzufuegen.
on_vacation und on_holiday tragen deshalb jetzt drei Werte: 0 nie,
1 egal (Vorgabe), 2 zusaetzlich. Der dritte zaehlt wie ein angehakter
Wochentag - Sa+So angehakt und "Feiertage: zusaetzlich" ergibt den
gewuenschten Fall, und mit gar keinem angehakten Tag sogar "nur an
Feiertagen".
In tag_passt() wird erst geoeffnet, dann gesperrt: ein Verbot schlaegt
eine Erweiterung. Wer in den Ferien nie laeuft und an Feiertagen
zusaetzlich, laeuft an einem Feiertag in den Ferien nicht - andersherum
liesse sich "nie" nicht mehr verlassen.
Dazu once_per_day: nach dem Ausloesen bis Mitternacht Ruhe. Fuer alles,
was man hinterher von Hand wieder anders stellt - ein Rollladen, den man
um acht zugezogen hat, soll nicht um neun von selbst wieder auffahren,
weil eine Wolke weiterzieht und die Helligkeitsschwelle ein zweites Mal
steigt. Die Sperrzeit taugte dafuer nicht: sie zaehlt Sekunden und
muesste auf 86400 stehen, womit eine Automatik, die heute um 07:00:05
lief, morgen um 07:00:00 noch gesperrt waere und einen ganzen Tag
ausfiele. Gefragt wird deshalb nach dem Datum von last_run - dieselbe
Funktion, die auch force_once benutzt, nur mit umgekehrtem Vorzeichen.
Die Spalten bleiben TINYINT und tragen die 2 ohne Weiteres; die
vorhandenen Zeilen stehen auf 0 oder 1 und behalten damit genau ihre
bisherige Bedeutung. Umzurechnen gibt es nichts. rahmen_erweitern.sql
setzt nur Kommentare und legt once_per_day an.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Anlass: "zehn Minuten nach dem Wecker den Rollladen hoch, aber nur wenn
es dann schon hell ist". Als Verzoegerung an der Aktion war das nicht zu
haben - die Zusatzbedingung gilt erst zum spaeteren Zeitpunkt, und eine
verzoegerte Aktion, die selbst noch Bedingungen prueft, braeuchte ein
zweites Bedingungssystem neben dem ersten. Der zweite Schritt ist also
eine eigene Automatik; was ihr fehlte, war nur ein Bezug auf die erste.
Den gibt jetzt das gerechnete Geraet "Automatiken", Gegenstueck zum
vorhandenen "Zeitpunkt": jede Automatik ist dort ein Messwert, ihr Wert
der Zeitpunkt der letzten Ausloesung. Der Editor braucht dafuer keine
Zeile - er listet Geraete und deren Messwerte.
Der neue Datentyp `elapsed` verhaelt sich dazu wie `deltatime` zum
Sonnenaufgang: "+ 00:10", "ab + 00:10", "vor + 00:10". Ein Minus gibt es
nicht. Gerechnet wird mit dem echten Abstand statt mit der Uhrzeit
innerhalb des Tages - sonst machte ein Lauf von vorgestern die Bedingung
heute wahr. Die offene Form endet trotzdem am Tagesrand, genau wie
"ab 16:30".
Ausgewertet wird topologisch, Ausloeser vor Nachfolger; nur so wirkt ein
Versatz von null noch im selben Takt. Eine pausierte Automatik haelt ihre
Nachfolger mit an: geladen werden nur die aktiven, und der Transport
liefert fuer alle uebrigen einen leeren Wert.
Die Messwerte pflegt ausloeser_nachfuehren() - fuer JEDE Automatik, auch
fuer pausierte. Sonst loeschte ein Pausieren ueber fk_cond_state
ON DELETE CASCADE die Bedingung des Nachfolgers, still. Geloescht wird
nur, was keine Bedingung mehr benutzt.
automatik_ausloeser.sql legt Datentyp und Geraet an.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Schreibweg wattpilot/properties/<schluessel>/set war unbenutzbar. Die
Bibliothek reichte Zahlen als Zeichenkette an die Wallbox weiter
("value must be uint8_t"), griff bei unbekannten Namen und bei
Eigenschaften ohne rw-Angabe ungeprueft zu - ftt und fte haben keine, ein
Klick auf die Ladeplanung haette den paho-Callback getoetet - und meldete
nichts zurueck.
Jetzt bekommt der Wert den Typ aus der API-Beschreibung, so dass die
Wallbox 'lmo = 4' genauso nimmt wie 'lmo = Awattar'. Unbekanntes und
Schreibgeschuetztes wird abgelehnt statt zu werfen, und das Ergebnis geht
auf <schluessel>/result - genau wie es der go-e tut. Damit laesst sich das
Dashboard auf einen Weg fuer beide Wallboxen umstellen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
'lot' steht in der API-Beschreibung als jsonType integer, die Firmware
schickt aber ein Objekt. Die Bibliothek reicht es unveraendert an paho
weiter, paho nimmt nur Skalare - und die Ausnahme riss dieselbe Schleife
mit wie der KeyError auf unbekannte Felder. Im rotierten Log machte
dieser zweite Fehler 1.264.882 von 2.985.071 Zeilen aus.
mqtt_get_encoded_property wird jetzt ebenfalls ersetzt: was nach der
Kodierung kein Skalar ist, geht als JSON hinaus, einmalig mit Warnung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Wallbox schickt 34 Statusfelder, die die API-Beschreibung von
wattpilot 0.2 nicht kennt. Die Bibliothek schlug jedes Feld ungeprueft
nach und lief in einen KeyError, der die restliche Schleife mitriss -
alle Werte hinter dem unbekannten Feld derselben Nachricht kamen nie
beim MQTT-Broker an. Im Dauerbetrieb traf es alle 15 Sekunden fhz, lps
und tpcm, nach einem Verbindungsaufbau deutlich mehr; sichtbar war es
nur als Fehlerpaar 'clea' im Log, rund ein MB am Tag.
wattpilot_bruecke.py ersetzt die betroffene Funktion zur Laufzeit und
ueberspringt unbekannte Felder, jedes einmal mit einer Warnung. Die
Reparatur steht hier und nicht in site-packages, weil eine
Neuinstallation sie dort spurlos zurueckdrehen wuerde und wattpilot 0.2
seit Mai 2022 die letzte Veroeffentlichung ist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
wattpilotshell.log hatte 329 MB erreicht - die wattpilotshell meldet
seit Monaten im Sekundentakt denselben Verbindungsfehler, und rotiert
wurde nie. logs_rotieren.sh mit logrotate.conf raeumt das jetzt taeglich
auf: vierzehn Staende, alles ueber 20 MB sofort, damit ein Prozess in
einer Fehlerschleife nicht an einem Tag das Volume fuellt. Der erste Lauf
hat aus den 329 MB 61 KB gemacht, verloren ist nichts.
Nicht in /etc/logrotate.d abgelegt - das ist DSM-Gebiet und beim
naechsten Systemupdate weg. Der Zustand kommt aus einer eigenen Datei
statt aus /var/lib/logrotate, wo der von DSM liegt.
Die Startskripte leiten dafuer mit ">>" um statt mit "&>". Die Prozesse
laufen monatelang durch und sollen fuer eine Rotation nicht neu starten
muessen, deshalb copytruncate - der Inhalt wird weggeschrieben und die
Datei geleert, waehrend sie offen bleibt. Ohne Anhaengemodus schriebe der
Prozess danach an seiner alten Stelle weiter und die Datei bekaeme vorn
ein Loch aus Nullbytes.
Nebenbei behoben: startWecker.sh leerte seine Logdatei bei jedem Start,
und gestartet wird der Wecker jede Nacht um drei. Was er am Vortag
gemeldet hatte, war morgens nicht mehr nachzulesen.
Die Skripte bekommen ausserdem ihr Ausfuehrungsrecht in den Index - ueber
die Windows-Freigabe sieht Git keine Unix-Rechte, ein frischer Checkout
haette sie nicht starten koennen.
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