From 20e084bbc893b102cce565ea6e13f61032cd426c Mon Sep 17 00:00:00 2001 From: "m0@nas" Date: Wed, 9 Sep 2026 18:15:16 +0200 Subject: [PATCH] Shelly: nur Komponenten ueber MQTT, die auch senden "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 --- README.md | 22 +++++++++++----- .../deviceDiscovery/modules/shelly_module.py | 25 ++++++++++++++++--- 2 files changed, 38 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 512a151..c3591c0 100644 --- a/README.md +++ b/README.md @@ -545,12 +545,22 @@ Zwei Eigenschaften, die man kennen muss: aktualisiert, neue kommen dazu. Abgebaute Geräte verschwinden nur über **Einstellungen → Geräte → Papierkorb** (und auch dort nur, wenn keine Automatik mehr auf sie zeigt). -* **Shelly, zwei Wege.** Alte Shellys können kein MQTT und bleiben beim - HTTP-Weg: in `actor_states.url` steht ein Feldname der JSON-Antwort. Neuere - (Gen2 mit eingeschaltetem `status_ntf`) melden von selbst an den Broker — - dann steht in `url` das Topic (`Power_EG/status/em:0`) und in `value_path` - der Schlüssel. Geschaltet werden auch sie weiter über HTTP. Der Runner teilt - seine Messwerte deshalb je Wert zu, nicht je Gerät. +* **Shelly, zwei Wege — und zwar je Komponente.** Alte Shellys können kein + MQTT und bleiben ganz beim HTTP-Weg: in `actor_states.url` steht ein + Feldname der JSON-Antwort. Bei Gen2-Geräten mit eingeschaltetem `status_ntf` + steht dagegen das Topic in `url` (`Power_EG/status/em:0`) und der Schlüssel + in `value_path`. + + Das gilt aber nur für Komponenten, die auch wirklich senden — die Liste + steht als `MQTT_KOMPONENTEN` in `modules/shelly_module.py` und enthält + heute `em` und `switch`. Der Pro 3EM etwa hat eine Temperaturkomponente im + RPC-Status, veröffentlicht sie aber nie; ein Messwert auf diesem Topic + bliebe für immer auf seinem letzten Wert stehen. Alles außerhalb der Liste + wird deshalb weiter abgefragt. Wer eine Komponente ergänzen will, hört + vorher mit (`mosquitto_sub -t '/#' -v`). + + Geschaltet werden auch die neuen Geräte über HTTP. Der Runner teilt seine + Messwerte deshalb je Wert zu, nicht je Gerät. --- diff --git a/restricted/deviceDiscovery/modules/shelly_module.py b/restricted/deviceDiscovery/modules/shelly_module.py index 3ce7d36..5aa02ac 100644 --- a/restricted/deviceDiscovery/modules/shelly_module.py +++ b/restricted/deviceDiscovery/modules/shelly_module.py @@ -232,6 +232,22 @@ class ShellyModule(BaseModule): """Prüft ob Shelly aktiviert ist""" return self.config.shelly_enable + # Welche Komponenten ihren Zustand von selbst an den Broker schicken. + # + # "status_ntf" am Geraet heisst nicht, dass jede Komponente etwas sendet - + # es heisst nur, dass gesendet werden darf. Nachgemessen am Pro 3EM: unter + # Power_EG/# kommen ausschliesslich em:0, emdata:0 und online. Die + # Temperatur der Endstufe (temperature:0) steht zwar im RPC-Status, wird + # aber nie veroeffentlicht - ein Messwert, der auf dieses Topic zeigte, + # bliebe fuer immer auf seinem letzten Wert stehen. + # + # Deshalb eine ausdrueckliche Liste statt "alles, was MQTT kann". Wer eine + # Komponente ergaenzen will, hoert vorher nach: + # mosquitto_sub -t '/#' -v + # und traegt sie hier ein, wenn sie tatsaechlich sendet. Alles andere + # bleibt beim Abfragen - langsamer, aber richtig. + MQTT_KOMPONENTEN = {"em", "switch"} + @staticmethod def _mqtt_praefix(device: Dict) -> Optional[str]: """ @@ -267,9 +283,11 @@ class ShellyModule(BaseModule): es das MQTT-Modul für alle anderen Geräte hält. Damit fällt für die neuen Geräte das Abfragen im Automatik-Runner weg; - die alten Shellys ohne MQTT bleiben unverändert beim HTTP-Weg. + die alten Shellys ohne MQTT bleiben unverändert beim HTTP-Weg - und + ebenso jede Komponente, die zwar am Gerät hängt, aber nichts sendet + (siehe MQTT_KOMPONENTEN). """ - if not praefix: + if not praefix or komponente not in ShellyModule.MQTT_KOMPONENTEN: return states topic = f"{praefix}/status/{komponente}:{index}" for state in states: @@ -333,7 +351,8 @@ class ShellyModule(BaseModule): # Messwerte Topics statt Feldnamen - siehe _adressiere(). praefix = self._mqtt_praefix(device) if praefix: - logger.info(f" {device_name}: Zustaende ueber MQTT ({praefix}/status/...)") + logger.info(f" {device_name}: {', '.join(sorted(self.MQTT_KOMPONENTEN))}" + f" ueber MQTT ({praefix}/status/...), der Rest ueber HTTP") # Switches als Aktoren switch_count = sum(1 for key in status.keys() if key.startswith('switch:'))