Der Geraetesuchlauf legt "Benachrichtigungen" an (benachrichtigung_module.py),
ein Kommando je Kanal. Damit kann jede Automatik melden, ohne dass Editor,
Zeitleiste oder Datenbank etwas davon wissen muessten.
Fuer die Meldung aufs Handy braucht es keine App: Der Browser meldet sich
unter Einstellungen -> Meldungen selbst an (sw.js, ajax/push.php), das Abo
steht in homeMesh.push_abos, verschickt wird vom Runner. Auf dem iPhone geht
es erst ab der Ablage auf dem Home-Bildschirm - der Reiter sagt das auch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Station haengt laengst am Websocket und wsMQTTbridge.py legt ihre
Felder unter weatherStation/# ab - nur wusste die Automatikdatenbank
nichts davon. Das neue Modul macht daraus ein Geraet mit elf
Messwerten: Aussentemperatur, Taupunkt, Feuchte, Druck, Wind, Boe und
die beiden Richtungen. Wie das Gartenwasser- und das
SolarManager-Modul sucht es nichts, sondern schreibt ein festes Geraet
hin; die Station meldet sich nicht per Home-Assistant-Discovery.
Gebraucht wird sie fuer den Hitzeschutz: dafuer ist die
Aussentemperatur die bessere Bedingung als die Raumtemperatur - ist es
drinnen schon warm, ist es zum Verschatten zu spaet. Und Wind gab es
hier bisher ueberhaupt nicht; ohne ihn laesst sich fuer Markise und
Sonnensegel kein Sturmschutz bauen.
Nicht dabei sind zwei Topics. IP ist keine Messung. Und QNH steht bei
uns gut hundert Hektopascal neben qff (1133 gegen 1023) und ist
offenbar nicht auf die Stationshoehe eingestellt - zwei Druecke
nebeneinander, von denen einer falsch ist, waeren im Editor eine Falle.
Dabei aufgefallen: der UPSERT schrieb unit = VALUES(unit)
bedingungslos. Ein Modul, das keine Einheit mitliefert, meint aber
"weiss ich nicht" und nicht "loesch die vorhandene" - am 10.09. hat ein
Suchlauf den drei Sonnensensoren ihr "Lux" genommen, weil das
Tahoma-Modul keine Einheiten kennt. Jetzt COALESCE, wie bei
current_value schon laenger.
config.ini liegt nicht im Git; der Abschnitt [wetterstation] muss dort
von Hand stehen, sonst bleibt das Modul aus.
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>
Die Shelly-Erkennung schrieb bisher fuer jedes Geraet eine HTTP-Adresse in
actor_states.url; der Automatik-Runner musste die Werte deshalb im Takt
abfragen, obwohl die Gen2-Geraete ihren Zustand ohnehin von sich aus an den
Broker melden. Sichtbar wurde das an den beiden Stromzaehlern: ihre Messwerte
standen nirgends als Topic, weshalb sie weder in den Kachelwerten noch im
Automatik-Editor auftauchten.
Gen2-Geraete werden jetzt nach ihrer MQTT-Einrichtung gefragt
(/rpc/Mqtt.GetConfig). Ist sie eingeschaltet, meldet das Geraet Statusaenderungen
und hat ein Topic-Praefix, so steht in url das Topic
(<praefix>/status/<komponente>:<index>) und in value_path der Schluessel in der
Nachricht. Fehlt eines davon - und bei allen Gen1-Geraeten, die kein MQTT
koennen - bleibt alles beim HTTP-Weg.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der SolarManager legt gut 130 Topics auf den Broker, aber er meldet sich
nicht per Home-Assistant-Discovery. Das MQTT-Modul findet ihn deshalb
nicht, und eine Automatik konnte weder auf den Netzbezug noch auf den
Ladestand der Batterie oder die Temperatur im Puffer reagieren.
Vier feste Geraete mit neun Messwerten, ausgewaehlt nach dem, was das
Realtime-SVG zeigt - von der PV nur die Summe. Alles anzulegen haette die
Auswahl im Editor unbrauchbar gemacht: jeder Wechselrichter einzeln, jeder
Phasenstrom, jede Vorlauftemperatur.
Netzanschluss Bezug, Einspeisung
Stromzaehler Obergeschoss Leistung
Solaranlage PV-Leistung, Batterie-Ladestand
Pufferspeicher drei Temperaturen, Heizstab-Leistung
Die beiden Modbus-Zaehler am Gen24 (meter0 am Hausanschluss, meter1 fuer
das Obergeschoss) gibt es nur ueber diesen Weg - sie sprechen sonst mit
niemandem. Die beiden Shelly EM3 bleiben dagegen aussen vor: die stehen
ueber die Home-Assistant-Discovery laengst als Power_EG_EM_0 und
Power_UG_EM_0 in der Tabelle. solarManager/eg waere ohnehin nicht
dasselbe, dort ist die Wallbox im Carport eingerechnet.
Beim Netzanschluss stehen Bezug und Einspeisung statt P_Grid: eine Zahl
mit Vorzeichen liest sich in einer Bedingung falsch herum. Beim
Obergeschoss geht das nicht, der Zaehler meldet Verbrauch negativ - das
steht als Warnung im Modul.
Alles nur zum Lesen. Geschaltet wird am SolarManager nichts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bisher entschied jede Arbeitsstation fuer sich, welche Zeilenenden ein
Commit bekommt: Git fuer Windows setzt core.autocrlf=input in seiner
System-Konfiguration, die NAS setzt nichts. Weil der Bestand ausserdem in
sich gemischt war - 34 PHP-Dateien mit LF, 30 mit CRLF -, gab es gar kein
richtiges Zeilenende, an das ein Werkzeug sich haette halten koennen. Jede
Ergaenzung mit LF in einer CRLF-Datei ergab eine gemischte Datei; helper.php
und js/solar/homeMQTT.js waren bereits so entstanden.
.gitattributes macht die Zeilenenden zur Eigenschaft des Repositorys. LF,
weil dieses Verzeichnis der Web-Ordner der NAS ist und von Linux
ausgeliefert wird - und weil Git fuer Windows mit "input" ohnehin schon
dorthin zeigt.
restricted/WebAuthn bleibt ausgenommen und damit byteweise so, wie die
Bibliothek geliefert wurde; darunter liegen 292 Zertifikate.
Von den 47 geaenderten Dateien wurde nachgerechnet keine einzige im Inhalt
angefasst - der Vergleich HEAD-ohne-CR gegen Index ist ueberall gleich.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Git fuer Windows setzt core.autocrlf=input in seiner System-Konfiguration,
die Synology-Seite hat das nicht. Dieselbe Arbeitskopie liegt auf beiden
Systemen - unter /volume1/web/smart und als Z:\ -, und die Datei war deshalb
im Arbeitsverzeichnis CRLF, im Repository aber LF: Windows sah sie sauber,
die NAS dauerhaft geaendert. Ein "git pull" dort waere daran haengengeblieben.
Jetzt liegt sie so im Repository, wie sie im Arbeitsverzeichnis steht - und
wie die uebrigen Discovery-Module, die ebenfalls mit CRLF eingecheckt sind.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Firmware der Ventilsteuerungen liefert seit heute ein retained
Gartenwasser/<x>/Running mit "running", "running<Ventil>" und "mode", dazu
das schon vorbereitete "daysSinceWatering<Ventil>" in LastWatering.
Der Messwert "Laufende Automatik" las diese Angabe bisher aus Timers und
weicht deshalb. Timers ist nicht retained und wird nur im Sekundentakt
gesendet, solange etwas laeuft: der Runner sah im Ruhezustand gar nichts
und behielt nach einem Lauf den zuletzt gesehenen Wert - also genau das
Gegenteil von verlaesslich. Running ist retained und faellt ueber eine
Last-Will-Nachricht auch dann auf false, wenn die Steuerung mitten im
Giessen wegbricht.
Neu sind damit je Steuerung "Bewaesserung laeuft" und "Laufender Modus",
dazu je Zone ein eigener Laufmerker - aber nur, wo eine Steuerung mehr als
eine Zone bedient. Bei "hinten" waere er derselbe Wert wie der Merker der
Steuerung, und ein Messwert, der nie etwas anderes sagt, macht die Auswahl
nur laenger.
"Bewaesserung laeuft = NEIN" ist der Waechter fuer jede Regel, die hier
etwas anstossen will: die Zonen einer Steuerung haengen an derselben
Leitung, zwei gleichzeitig gibt es nicht.
Die beiden alten Zeilen "Laufende Automatik" muessen von Hand aus
actor_states verschwinden - das Discovery schreibt nur mit ON DUPLICATE KEY
UPDATE und loescht nie.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Erster Teil der Ablosung von restricted/gartenbewaesserung/auto_watering.py.
Das Skript holt heute stuendlich den Regen, vergleicht ihn mit Schwellen
aus einer ZONES-Tabelle im Quelltext und schaltet selbst. Kuenftig
entscheidet der AutoAction-Runner, und die Schwellen stehen im Editor.
Dafuer legt ein neues Discovery-Modul drei Geraete an. Es sucht nichts,
sondern schreibt sie fest hin - wie das Logic-Modul auch:
* Die beiden ESP32-Ventilsteuerungen sprechen zwar MQTT, aber ohne
Home-Assistant-Discovery; das MQTT-Modul findet sie deshalb nicht.
* "Regen" ist gar kein Geraet, sondern das, was gatherRainData.py im
SolarManager von Open-Meteo holt und nach Wetter/Regen legt.
Je Steuerung entsteht ein Kommando "Automatik" mit dem Modus als
Parameter - ein Kommando ohne Parameter schickt im Runner eine leere
Nutzlast, der Klartext ("Hoch", "Trog", "Vorn") muss also der Parameter
sein. Dazu je Zone zwei Messwerte:
Bewaessert heute ersetzt die Zwoelf-Stunden-Sperre des Skripts;
"heute noch nicht" heisst hier "= 0". Die
Steuerung setzt den Wert um Mitternacht zurueck,
der Runner kann den mitgelieferten "wateringDay"
naemlich nicht pruefen.
Tage seit Bewaesserung ersetzt max_dry_days. Ein Zeitstempel nuetzte
nichts: der Runner vergleicht Datumsangaben nur
gegen einen festen Wert, "laenger als fuenf Tage
her" ist damit nicht formulierbar. Die Firmware
liefert deshalb gleich die Anzahl Tage.
Die Regensummen kommen als tage1 bis tage7 herein; welche davon als
Messwert auftauchen, entscheidet allein dieses Modul. Der Sammler
veroeffentlicht immer alle sieben, damit sich die beiden Repositorien
nicht ueber eine Fensterliste einigen muessen.
Die Logseite kennt rainOutput.log jetzt ebenfalls.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Manche Geraete schicken eine Zahl und meinen einen Zustand - der
go-eCharger etwa 2 fuer "Charging". Welche Zahl welchen Namen hat, steht im
value_template der Home-Assistant-Discovery als Werttabelle:
{{ ['Unknown','Idle','Charging','WaitCar','Complete','Error'][value_json|int] }}
Das ist kein Pfad in die Nutzlast, sondern eine Uebersetzung, und sie wurde
bisher verworfen. Jetzt landet sie in possible_values - in derselben
Schreibweise, die WLED fuer seine Effektliste schon benutzt, naemlich einer
Liste aus {Wert: Bezeichnung}. Damit versteht der Editor sie ohne
Zusatzarbeit und macht eine Auswahlliste daraus. Ein Versatz im Ausdruck
wandert in die Schluessel: aus [value_json|int-3] wird {"3":"Default"}.
Der Runner uebersetzt beim Lesen, eine Bedingung vergleicht also den
Klartext. Steht die Zahl nicht in der Tabelle, bleibt sie stehen - ein
erfundener Name waere schlimmer als ein roher Wert.
Dabei ist ein Folgefehler aufgefallen: Auswahlwerte in dieser Schreibweise
kamen im Editor als "[object Object]" an. Die alte addOptions kannte die
Form, der neue Modell-Aufbau nicht - aufgefallen ist es nie, weil WLED beim
Umbau abgeschaltet war. Der Katalog liefert Auswahlwerte jetzt einheitlich
als {value, label}, und zwar seitenrichtig:
Messwert angezeigt Charging, gespeichert Charging
(der Runner hat schon uebersetzt)
Parameter angezeigt Blink, gespeichert 1
(das Geraet will die Zahl)
Die Uebersicht loest die Bezeichnung ebenfalls auf: "Effekt (Blink)" statt
"Effekt (1)".
Nachgemessen: alle fuenf Werttabellen auf dem Broker richtig erkannt,
einschliesslich des Versatzes, kein Fehltreffer unter den 35 uebrigen
Vorlagen. Live liefert der go-eCharger jetzt Idle, Neutral, Auto, Eco und
None statt 1, 0, 0, 4, 0. Ein weiterer Discovery-Lauf aendert keine Zeile.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der go-eCharger schickt sechzehn Zahlen als JSON-Feld auf einem einzigen
Topic, die Wechselrichter und die WLAN-Felder machen es aehnlich. Welcher
Teil der Nutzlast gemeint ist, steht im value_template der
Home-Assistant-Discovery - das Modul las es bisher nur, um den Datentyp zu
raten, und warf es dann weg. Alle sechzehn Messwerte bekamen denselben
Rohtext.
actor_states hat jetzt eine Spalte value_path: ein Pfad in die Nutzlast, in
derselben Schreibweise, die WLED schon benutzt ("[4]", "ssid",
"seg[0].col[0]"). NULL heisst weiterhin: die ganze Nutzlast.
Gelesen wird aus dem Template nur der einfache Fall - ein Zugriff auf
value_json und was danach an Punkten und Klammern folgt. Von den 40
Vorlagen, die hier auf dem Broker liegen, sind 28 genau das. Die uebrigen
zwoelf sind entweder die ganze Nutzlast (dann ist NULL richtig) oder
Werttabellen wie ['Idle','Charging'][value_json|int] - das ist kein Pfad,
sondern eine Uebersetzung von Zahl nach Text, und dort bleibt es beim
bisherigen Verhalten. Kein einziger Fehltreffer: die Werttabellen liefern
sauber None statt eines erfundenen Pfades.
Die Pfad-Auswertung stand schon im WLED-Transport; sie ist jetzt eine
gemeinsame Funktion, die sich beide teilen. MQTT wertet die Nutzlast einmal
je Nachricht aus und verteilt sie danach an alle Messwerte des Topics.
Nachgemessen: die sechzehn nrg-Werte liefern jetzt sechzehn eigene Zahlen
statt sechzehnmal dasselbe, die Leseabdeckung bleibt bei 440 von 441, und
ein weiterer Discovery-Lauf aendert keine Zeile.
Die restlichen geteilten Topics sind kein Fehler: bei den Wechselrichtern
lesen "Limit Persistent" und "Limit NonPersistent" wirklich denselben Wert
und unterscheiden sich nur im Kommando-Topic, und beim Thermostat liest die
Klima-Entity dieselbe Temperatur wie der Sensor.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ein Lauf mit allen Modulen brachte 54 Geraete und 441 Messwerte - und fuenf
Fehler ans Licht, die vorher niemand sehen konnte, weil clear_tables die
Tabellen bei jedem Lauf geleert hat.
Vier davon sind Schluessel- und Upsert-Fehler derselben Familie:
* command_parameters war ueber (command_id, url) eindeutig. WLED-Parameter
haben keine URL - ihr Name ist der Platzhalter in der Kommando-Vorlage -,
und eine NULL kollidiert in MySQL nie. ON DUPLICATE KEY UPDATE griff
also nicht, und jeder Lauf legte dieselben Parameter erneut an: aus 18
wurden nach drei Laeufen 54. Schluessel jetzt (command_id,
parameter_name).
* actor_states war ueber (actor_id, url) eindeutig. Umgekehrtes Problem:
Messwerte, die sich ein Topic teilen, ueberschrieben einander. Der
go-eCharger schickt sechzehn Werte als JSON-Feld auf einem Topic - von
denen kam genau einer in der Datenbank an. Schluessel jetzt (actor_id,
state_name), das bringt 50 verlorene Messwerte zurueck.
* Kommandos, Messwerte und Parameter aktualisierten ihre URL beim
Wiederholungslauf nicht - sie stand nicht im UPDATE-Teil. Eine Korrektur
in einem Modul kam damit nie in einer bestehenden Datenbank an.
* Der Typ eines Kommando-Parameters wurde als Text in eine int-Spalte
geschrieben. MariaDB macht daraus stillschweigend 0, und 0 ist "bool" -
deshalb bot der Editor fuer die WLED-Helligkeit (0..255) ein Ja/Nein an.
Der fuenfte: die Shelly-Gen1-Relais hatten weder eine Kommando-URL noch eine
URL am Zustand. Ohne die weiss niemand, was zu schicken und wo nachzusehen
ist. Gen1 schaltet ueber ?turn=on|off|toggle und meldet sich in "ison".
Damit entfaellt auch die Uebersetzungstabelle im HTTPTransport: die
Zuordnung gehoert ins Geraetemodell, nicht in den Runner.
Zwei Luecken auf der Runner-Seite, die derselbe Lauf gezeigt hat:
* WLED liess sich gar nicht ansteuern - es gab keinen Transport dafuer.
Der neue nutzt die JSON-Vorlage aus command_url, fuellt die Platzhalter
und schickt sie am Stueck an /json/state.
* Tahoma wurde am Schema "io://" erkannt. Das Schema beschreibt aber die
Funkart: dieselbe Box liefert rts:// fuer die Dachfenster und
internal:// fuer die Alarmanlage. Drei von 22 Geraeten fielen durch.
Erkannt wird jetzt an der Box-Kennung in der URL.
Nachgemessen: zwei Laeufe hintereinander aendern keine einzige Zeile mehr,
die Geraete-IDs bleiben ueber Laeufe stabil (Voraussetzung fuer die
Fremdschluessel der Automatiken), alle 54 Geraete finden genau einen
Transport, und 440 der 441 Messwerte sind tatsaechlich lesbar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Neues stündliches Python-Script (restricted/gartenbewaesserung/auto_watering.py): holt Niederschlags-
und Sonnenuntergangsdaten von Open-Meteo, wertet je Zone (Hochbeete/Tröge/Garten vorn) individuelle
Regen-Schwellenwerte und Mindest-Bewässerungsdauern aus und startet bei Bedarf per MQTT den passenden
Automatik-Modus der Ventilsteuerung im Zeitraum vor Sonnenuntergang; veröffentlicht den Regen-Status
zusätzlich stündlich als retained MQTT-Nachricht je Zone.
- Web-UI: neue Bewässerungs-Steuerung/-Anzeige (ajax/watering.php, js/solar/solarMQTT.js,
assets/img/realtime.svg) inkl. Live-Status-Icons (aus/geplant/pausiert/aktiv per Farbe und Symbol).
- AutoAction-Regeleditor (ajax/actorDetails.php, sensorDetails.php, fillActorDD.php, fillSensorDD.php,
tahoma.php, AutoAction.php) liest Actor-/Sensor-Parameter jetzt live aus der homeMesh-Datenbank statt
aus stark vereinfachten Altfeldern, inkl. zugehöriger Anpassungen am Device-Discovery-Tooling
(restricted/deviceDiscovery/*, neues logic_module.py).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
adminandClaude Opus 5