Gegenstueck zur Runner-Seite. Der Editor selbst braucht nichts: das
gerechnete Geraet "Automatiken" fuehrt jede Automatik als Messwert, und
der Geraetewaehler listet ohnehin Geraete und deren Messwerte. Neu sind
nur die Operatoren des Datentyps `elapsed` ("+", "ab +", "vor +") und
sein Eingabefeld.
Drei Stellen wissen trotzdem davon:
pruefeKreis() lehnt beim Speichern ab, was sich mittelbar selbst
ausloesen wuerde. Im Betrieb waere ein Kreis kaum zu bemerken - die
Sperrzeit begrenzt ihn auf eine Ausloesung je lockout_secs, und im
Protokoll sieht das aus wie eine Automatik, die halt oft laeuft.
deleteAutomation() fragt vorher. fk_cond_state steht auf ON DELETE
CASCADE, mit dem Messwert verschwaende also still die Bedingung des
Nachfolgers: aus "zehn Minuten nach dem Wecker UND es ist hell" wuerde
ein blosses "es ist hell", und der Rollladen fuehre ab morgen jeden Tag
bei Sonnenaufgang hoch. Bei der letzten Bedingung faengt der Runner das
ab, bei einer von zweien niemand. Zur Wahl stehen Abhaengen (Bedingung
raus, Nachfolger pausiert) und Mitloeschen; automatisch mitzuloeschen
waere die falsche Vorgabe.
Die Uebersicht rueckt Nachfolger unter ihren Ausloeser ein und zeigt sie
eingeklappt. Das ist nur die Darstellung - jeder Nachfolger bleibt eine
vollwertige Automatik mit eigener Pause, eigenen Rahmenbedingungen und
eigener Zeile im Protokoll. Sobald "gruppiert" auch "gehoert dazu"
hiesse, waere zu klaeren, wem die Pause gehoert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"status_ntf" am Geraet heisst nur, dass gesendet werden darf - nicht, dass
jede Komponente es tut. Der erste Suchlauf hat deshalb auch die
Temperaturkomponente der beiden Pro 3EM auf ein Topic gelegt
(Power_EG/status/temperature:0), und dort kam nie etwas an: unter Power_EG/#
sendet das Geraet ausschliesslich em:0, emdata:0 und online. Die beiden
Temperaturmesswerte waeren still auf ihrem letzten Wert stehengeblieben.
Jetzt entscheidet die Liste MQTT_KOMPONENTEN, welche Komponente ein Topic
bekommt - heute em und switch. Alles andere bleibt beim Abfragen: langsamer,
aber richtig. Nachgetragen wird per Hand, nachdem man mitgehoert hat; eine
automatische Erkennung waere unzuverlaessig, weil eine Komponente, die nur
bei Aenderung sendet, waehrend eines kurzen Lauschens nichts sagt.
Nach dem erneuten Suchlauf: die beiden EM-Zaehler kommen ueber den Broker,
die beiden Temperaturen und der Gen1-Handtuchtrockner werden abgefragt -
HTTP: 3 Messwerte an 3 Endpunkten statt vorher 35.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Das Repo hatte keine. Wer hier etwas suchte, musste sich von index.php aus
durchhangeln - und die Frage "welches Skript laedt eigentlich welche Daten"
war nur zu beantworten, indem man alle elf durchsah.
Die Datei beschreibt den Weg einer Anfrage (Router, Anmeldung, Vorlage,
Skripte), die Trennung der beiden Datenwege (laufende Werte ueber den Broker,
alles mit Verlauf ueber ajax/), die Seitenkarte mit Skripten, Endpunkten und
Topics je Seite, die JavaScript- und PHP-Schicht mit ihren Zustaendigkeiten,
die drei Datenbanken und vier Bausteine im Detail: Home-Kacheln, Raum-Modal,
Automatiken, Geraete-Erkennung. Dazu sieben Mermaid-Diagramme - Ablauf,
Datenwege, Abhaengigkeiten, Include-Graph, Tabellen, Kachelaufloesung,
Kommandoweg.
Am Ende zwei Tabellen fuer den taeglichen Gebrauch: "wo fange ich an, wenn
ich X aendern will" und die Pruefbefehle (php82 -l, node --check, readDB).
Gegenstueck ist die README im SolarManager-Repo; beide verweisen aufeinander,
damit man von jeder Seite aus zur anderen findet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
adminandClaude Opus 5