Files

T

adminandClaude Opus 5 061dfa3fc5 Doku: Solar-Uebersicht beschrieben

Katalog und Renderer, die Elternbeziehung als Struktur, und wie aus Watt
eine Zahl, ein gestauchter Ring, ein Fluss mit Punktgroesse und Tempo, ein
Fuellstand und Plaketten werden. Dazu quer/hochkant, der Sekundentakt mit
seinen drei Sparmassnahmen und der Bearbeitungsmodus.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-21 08:11:39 +02:00

3.4 KiB

Raw Blame History

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
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_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

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 …“.

3.4 KiB Raw Blame History

Vertiefende Dokumentation

Die drei Prozesse, die zusammenspielen

Lesereihenfolge

3.4 KiB

Raw Blame History