Der Gegenspieler zur Sperre, direkt daneben: die bremst die Wiederholung, die Haltezeit den ersten Lauf. Damit lassen sich Dauerzustände abfragen, die in einem einzelnen Messwert nicht zu sehen sind - "der Wasserzähler läuft seit einer halben Stunde ohne Pause". Gespeichert wird in automations.hold_secs (haltezeit.sql im SolarManager), gezählt wird im Runner. Angeboten werden feste Stufen, wie bei der Sperre: eine weitere ist eine Zeile in haltezeitChoices(). 0 ist die Vorgabe und heißt "sofort" - vorhandene Automatiken ändern sich nicht. 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 …“.