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 <noreply@anthropic.com>

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 '<präfix>/#' -v`).
+
+  Geschaltet werden auch die neuen Geräte über HTTP. Der Runner teilt seine
+  Messwerte deshalb je Wert zu, nicht je Gerät.
 
 ---
 

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 '<praefix>/#' -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:'))