adminandClaude Opus 5
b6ff7c6ad9
doku/meteogramm.md: der Weg der Daten, welche Groessen links vom Jetzt-Strich gemessen und welche vorhergesagt sind, die vier Tabellen samt der Regel, dass nichts geloescht wird, das Tupel-Schema des Endpunkts, das Katalog-Vokabular mit dem Dreizeiler "so kommt eine Spur dazu", und die beiden Entscheidungen beim Zeichnen (ein SVG ueber alle Felder, Wolkenband als Farbverlauf statt als Raster). Dazu zwei Fallen, die sonst niemand wiederfindet: die Archiv-Schnittstelle von Open-Meteo rechnet alle Zeiten mit dem heute gueltigen Zeitzonenversatz um, und die Spaltenlage des Endpunkts steht an zwei Stellen und muss zueinander passen. Richtiggestellt: doku/datenbank.md und README.md nannten Open-Meteo als Quelle von weatherHours/weatherDays. Das war nie so - es war OpenWeatherMap, und seit dem 27.10.2024 gar nichts mehr. Beide Zeilen warfen ausserdem Messung und Vorhersage in einen Topf; sie sind jetzt getrennt, mit dem richtigen Schreiber je Tabelle. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
86 lines
3.8 KiB
Markdown
86 lines
3.8 KiB
Markdown
# Vertiefende Dokumentation
|
|
|
|
Die [README im Wurzelverzeichnis](../README.md) 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](automatiken.md) | Die Automatiken (AutoActions): Datenmodell, Editor, Runner, wie eine Bedingung wirklich ausgewertet wird, Verkettung, Sperren, Fehlerbilder |
|
|
| [zeitleiste.md](zeitleiste.md) | Die Zeitleiste der Automatiken: wie der Server den Tag ausrechnet und wie der Browser ihn zeichnet |
|
|
| [benachrichtigungen.md](benachrichtigungen.md) | Meldungen aus Automatiken: Web Push ohne App, E-Mail, das Gerät „Benachrichtigungen“ |
|
|
| [meteogramm.md](meteogramm.md) | Das eigene Meteogramm: Vorhersage und eigene Messung in einem Bild, Katalog und Renderer, das Wetterarchiv |
|
|
| [uebersicht.md](uebersicht.md) | Die Solar-Übersicht: Katalog und Renderer, wie aus Watt ein Ring, ein Fluss und ein Füllstand wird |
|
|
| [byd.md](byd.md) | Die Batterie bis zur Zelle: das nachgebaute BMU-Protokoll, das Zeitfenster des Netzwerkmoduls, Byte-Lagen, Historie, Anzeige |
|
|
| [datenbank.md](datenbank.md) | Die drei Schemata: wer was schreibt, wie Messreihen verdichtet werden, welche Tabelle man für welche Auswertung nimmt |
|
|
| [einstellungen.md](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.
|
|
|
|
```mermaid
|
|
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_value` pflegt 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
|
|
|
|
1. [README](../README.md), Abschnitt „Auf einen Blick“ — Seiten und Dateien.
|
|
2. [automatiken.md](automatiken.md) — das Regelwerk und seine Ausführung.
|
|
3. [zeitleiste.md](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 …“.
|