Wonach man sucht, haengt am Messwert: eine offene Tuer faellt nach zwei Minuten auf, ein laufender Wasserhahn erst nach Stunden. Eine Stufenliste traf damit immer nur die Haelfte der Faelle. Das Feld nimmt Minuten, das Modell rechnet in Sekunden weiter. Die Kopfzeile des Rahmens rechnet beim Tippen mit - aus "210" wird dort "erst nach 3,5 Std.", also steht die lesbare Fassung neben der eingebbaren. haltezeitPruefen() ersetzt die Whitelist: nicht unter null, nicht ueber einen Tag, auf ganze Minuten gerundet. Sekunden gewinnen hier nichts, die Messwerte kommen viel seltener. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vertiefende Dokumentation
Die README im Wurzelverzeichnis beschreibt das Ganze: welche Seite es gibt, welche Datei was tut, wo eine Zahl herkommt. Sie ist die Landkarte.
Hier liegen die Tiefenbohrungen — für die Teile, bei denen die Landkarte nicht reicht, weil das Verhalten aus dem Zusammenspiel mehrerer Prozesse entsteht und die Regeln nicht aus dem Quelltext einer einzelnen Datei abzulesen sind.
| Dokument | Worum es geht |
|---|---|
| automatiken.md | Die Automatiken (AutoActions): Datenmodell, Editor, Runner, wie eine Bedingung wirklich ausgewertet wird, Verkettung, Sperren, Fehlerbilder |
| zeitleiste.md | Die Zeitleiste der Automatiken: wie der Server den Tag ausrechnet und wie der Browser ihn zeichnet |
| benachrichtigungen.md | Meldungen aus Automatiken: Web Push ohne App, E-Mail, das Gerät „Benachrichtigungen“ |
| uebersicht.md | Die Solar-Übersicht: Katalog und Renderer, wie aus Watt ein Ring, ein Fluss und ein Füllstand wird |
| datenbank.md | Die drei Schemata: wer was schreibt, wie Messreihen verdichtet werden, welche Tabelle man für welche Auswertung nimmt |
| einstellungen.md | Die Einstellungsseite: was jeder Reiter speichert, welche Regeln das Modell durchsetzt und was die Seite bewusst nicht kann |
Die drei Prozesse, die zusammenspielen
Nichts hier ist eine einzelne Anwendung. Drei Dinge laufen gleichzeitig, und sie reden nur über MQTT und über die Datenbanken miteinander — nie direkt.
flowchart LR
subgraph Browser["Browser"]
UI["Weboberfläche<br/><small>PHP + JS, /volume1/web/smart</small>"]
end
subgraph NAS["NAS, Hintergrundprozesse (SolarManager)"]
RUN["autoaction_runner.py<br/><small>führt Automatiken aus</small>"]
SM["solarManager.py<br/><small>sammelt Anlagenwerte</small>"]
SK["gatherSkodaData.py<br/><small>Fahrzeug</small>"]
end
subgraph Speicher["Speicher"]
MQTT[["MQTT-Broker<br/><small>alles Aktuelle</small>"]]
HM[("homeMesh<br/><small>Geräte, Automatiken, Grundriss</small>")]
SL[("solarLog<br/><small>Messreihen, Sonnenzeiten</small>")]
end
subgraph Geraete["Geräte"]
TAH["Tahoma-Box<br/><small>Jalousien</small>"]
SHE["Shelly, WLED, ESP32"]
end
UI -- "liest/schreibt Regeln" --> HM
UI -- "abonniert" --> MQTT
UI -- "schaltet von Hand" --> TAH & SHE
RUN -- "Regelwerk" --> HM
RUN -- "Messwerte zurück" --> HM
RUN -- "Sonnenzeiten" --> SL
RUN -- "hört + schaltet" --> MQTT
RUN -- "liest + schaltet" --> TAH & SHE
SM --> MQTT & SL
SK --> SL
Wichtig für das Verständnis aller folgenden Kapitel:
- Die Weboberfläche schaltet nichts von selbst. Sie beschreibt, was
gelten soll (
homeMesh), und zeigt, was ist. Ausgeführt wird im Runner. actor_states.current_valuepflegt der Runner. Ohne ihn stünde dort der Wert vom Tag des Gerätesuchlaufs. Deshalb zeigt auch der Editor aktuelle Zahlen, obwohl er nur eine Tabelle liest.- Der Runner ist ein Dauerprozess, kein Cronjob — er braucht den
Vorzustand (
cond_met), um steigende Flanken zu erkennen.
Lesereihenfolge
- README, Abschnitt „Auf einen Blick“ — Seiten und Dateien.
- automatiken.md — das Regelwerk und seine Ausführung.
- zeitleiste.md — die Darstellung desselben Regelwerks über einen Tag.
Wer nur etwas ändern will, findet die Einstiegspunkte am Ende beider Dokumente unter „Wo fange ich an, wenn ich …“.