Kein erneutes Senden eines Readings nach Empfang über mqttSubscribe

[eddi_g]

Hallo Beta-User,

du hast die Schilderungen richtig verstanden.
FHEM sendet die Readings korrekt über MQTT und die Readings können auch korrekt von FHEM über MQTT empfangen und die Readings werden auch anschließend direkt auf den MQTT Vorgabewert geändert.
Was nicht funktioniert, ist das erneute Senden des Readings, nachdem es über stopic verändert wurde. Die Aktualisierung passiert dann nach unbestimmter Zeit, wenn ein anderes Reading, aus welchen Gründen auch immer, gelesen wird.

Die vollständige Modulkonfiguration (THZ, MQTT2_CLIENT, MQTT_GENERIC_BRIDGE) findest du im Beitrag vom 02.Januar 2025, 11:40:28
Aus meiner Sicht sind diese Zeilen hier relevant
Definition der MQTT Bridge: 

Code Auswählen Erweitern

# MQTT Bridge
define mqttGeneric MQTT_GENERIC_BRIDGE
setuuid mqttGeneric 65ad5105-f33f-1d40-1005-98b232c0f27ef20b
attr mqttGeneric IODev ha_MQTT2
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
attr mqttGeneric icon mqtt_bridge_2
attr mqttGeneric room MQTT
attr mqttGeneric stateFormat in: incoming-count out: outgoing-count devices: device-count
attr mqttGeneric verbose 0
mqttPublish und mqttSubscribe (oben im Post sind die Zeilen im original zu finden, hier lediglich auf das Signal p04DHWsetDayTemp, da dieses nun mehrmals als Beispiel verwendet wurde)

Code Auswählen Erweitern

attr THZ504 mqttPublish p04DHWsetDayTemp:topic={"$base/$name"}
attr THZ504 mqttSubscribe p04DHWsetDayTemp:stopic={"$base/set/$name"}Da die Variable $base bereits das $device beinhaltet, habe ich im Gerät selber die Variable $device nicht erneut verwendet.

Im MQTT Explorer finde ich auch alle Werte wo ich sie erwarte...
fhem/THZ504/Readings
fhem/THZ504/set/Readings

Und hier noch die Infos zu deiner Anfrage bezüglich get mqttGeneric devinfo THZ504

Code Auswählen Erweitern

THZ504
  publish:
    UR.sDHW.dhwSetTemp => fhem/THZ504/UR.sDHW.dhwSetTemp (mode: R; qos: 0; retain)
    UR.sDHW.dhwTemp  => fhem/THZ504/UR.sDHW.dhwTemp (mode: R; qos: 0; retain)
    UR.sDisplay.boosterHC => fhem/THZ504/UR.sDisplay.boosterHC (mode: R; qos: 0; retain)
    UR.sDisplay.compressor => fhem/THZ504/UR.sDisplay.compressor (mode: R; qos: 0; retain)
    UR.sDisplay.cooling => fhem/THZ504/UR.sDisplay.cooling (mode: R; qos: 0; retain)
    UR.sDisplay.defrost => fhem/THZ504/UR.sDisplay.defrost (mode: R; qos: 0; retain)
    UR.sDisplay.filterBoth => fhem/THZ504/UR.sDisplay.filterBoth (mode: R; qos: 0; retain)
    UR.sDisplay.filterDown => fhem/THZ504/UR.sDisplay.filterDown (mode: R; qos: 0; retain)
    UR.sDisplay.filterUp => fhem/THZ504/UR.sDisplay.filterUp (mode: R; qos: 0; retain)
    UR.sDisplay.heatingDHW => fhem/THZ504/UR.sDisplay.heatingDHW (mode: R; qos: 0; retain)
    UR.sDisplay.heatingHC => fhem/THZ504/UR.sDisplay.heatingHC (mode: R; qos: 0; retain)
    UR.sDisplay.pumpHC => fhem/THZ504/UR.sDisplay.pumpHC (mode: R; qos: 0; retain)
    UR.sDisplay.service => fhem/THZ504/UR.sDisplay.service (mode: R; qos: 0; retain)
    UR.sDisplay.switchingProg => fhem/THZ504/UR.sDisplay.switchingProg (mode: R; qos: 0; retain)
    UR.sDisplay.ventStage => fhem/THZ504/UR.sDisplay.ventStage (mode: R; qos: 0; retain)
    UR.sFan.pFanstageXAirflowInlet => fhem/THZ504/UR.sFan.pFanstageXAirflowInlet (mode: R; qos: 0; retain)
    UR.sFan.pFanstageXAirflowOutlet => fhem/THZ504/UR.sFan.pFanstageXAirflowOutlet (mode: R; qos: 0; retain)
    UR.sGlobal.actualPower_Pel => fhem/THZ504/UR.sGlobal.actualPower_Pel (mode: R; qos: 0; retain)
    UR.sGlobal.actualPower_Qc => fhem/THZ504/UR.sGlobal.actualPower_Qc (mode: R; qos: 0; retain)
    UR.sGlobal.boosterStage1 => fhem/THZ504/UR.sGlobal.boosterStage1 (mode: R; qos: 0; retain)
    UR.sGlobal.boosterStage2 => fhem/THZ504/UR.sGlobal.boosterStage2 (mode: R; qos: 0; retain)
    UR.sGlobal.boosterStage3 => fhem/THZ504/UR.sGlobal.boosterStage3 (mode: R; qos: 0; retain)
    UR.sGlobal.flowRate => fhem/THZ504/UR.sGlobal.flowRate (mode: R; qos: 0; retain)
    UR.sGlobal.heatingCircuitPump => fhem/THZ504/UR.sGlobal.heatingCircuitPump (mode: R; qos: 0; retain)
    UR.sGlobal.outside_tempFiltered => fhem/THZ504/UR.sGlobal.outside_tempFiltered (mode: R; qos: 0; retain)
    UR.sGlobal.relHumidity => fhem/THZ504/UR.sGlobal.relHumidity (mode: R; qos: 0; retain)
    UR.sHC1.flowTemp => fhem/THZ504/UR.sHC1.flowTemp (mode: R; qos: 0; retain)
    UR.sHC1.hcBoosterStage => fhem/THZ504/UR.sHC1.hcBoosterStage (mode: R; qos: 0; retain)
    UR.sHC1.heatSetTemp => fhem/THZ504/UR.sHC1.heatSetTemp (mode: R; qos: 0; retain)
    UR.sHC1.heatTemp => fhem/THZ504/UR.sHC1.heatTemp (mode: R; qos: 0; retain)
    UR.sHC1.insideTempRC => fhem/THZ504/UR.sHC1.insideTempRC (mode: R; qos: 0; retain)
    UR.sHC1.integralHeat => fhem/THZ504/UR.sHC1.integralHeat (mode: R; qos: 0; retain)
    UR.sHC1.outsideTemp => fhem/THZ504/UR.sHC1.outsideTemp (mode: R; qos: 0; retain)
    UR.sHC1.returnTemp => fhem/THZ504/UR.sHC1.returnTemp (mode: R; qos: 0; retain)
    UR.sHC1.roomSetTemp => fhem/THZ504/UR.sHC1.roomSetTemp (mode: R; qos: 0; retain)
    UR.sHC1.seasonMode => fhem/THZ504/UR.sHC1.seasonMode (mode: R; qos: 0; retain)
    dhwBoosterStage  => fhem/THZ504/dhwBoosterStage (mode: R; qos: 0; retain)
    p01RoomTempDayHC1 => fhem/THZ504/p01RoomTempDayHC1 (mode: R; qos: 0; retain)
    p01RoomTempDayHC1SummerMode => fhem/THZ504/p01RoomTempDayHC1SummerMode (mode: R; qos: 0; retain)
    p02RoomTempNightHC1 => fhem/THZ504/p02RoomTempNightHC1 (mode: R; qos: 0; retain)
    p02RoomTempNightHC1SummerMode => fhem/THZ504/p02RoomTempNightHC1SummerMode (mode: R; qos: 0; retain)
    p04DHWsetDayTemp => fhem/THZ504/p04DHWsetDayTemp (mode: R; qos: 0; retain)
    p05DHWsetNightTemp => fhem/THZ504/p05DHWsetNightTemp (mode: R; qos: 0; retain)
    p07FanStageDay   => fhem/THZ504/p07FanStageDay (mode: R; qos: 0; retain)
    p08FanStageNight => fhem/THZ504/p08FanStageNight (mode: R; qos: 0; retain)
    p89DHWeco        => fhem/THZ504/p89DHWeco (mode: R; qos: 0; retain)
    pOpMode          => fhem/THZ504/pOpMode (mode: R; qos: 0; retain)
    sBoostDHWTotal   => fhem/THZ504/sBoostDHWTotal (mode: R; qos: 0; retain)
    sBoostHCTotal    => fhem/THZ504/sBoostHCTotal (mode: R; qos: 0; retain)
    sElectrDHWDay    => fhem/THZ504/sElectrDHWDay (mode: R; qos: 0; retain)
    sElectrDHWTotal  => fhem/THZ504/sElectrDHWTotal (mode: R; qos: 0; retain)
    sElectrHCDay     => fhem/THZ504/sElectrHCDay (mode: R; qos: 0; retain)
    sElectrHCTotal   => fhem/THZ504/sElectrHCTotal (mode: R; qos: 0; retain)
    sHeatDHWDay      => fhem/THZ504/sHeatDHWDay (mode: R; qos: 0; retain)
    sHeatDHWTotal    => fhem/THZ504/sHeatDHWTotal (mode: R; qos: 0; retain)
    sHeatHCDay       => fhem/THZ504/sHeatHCDay (mode: R; qos: 0; retain)
    sHeatHCTotal     => fhem/THZ504/sHeatHCTotal (mode: R; qos: 0; retain)
    state            => fhem/THZ504/status (mode: R; qos: 0; retain)
  subscribe:
    p01RoomTempDayHC1 <= fhem/THZ504/set/+ (mode: S)
    p01RoomTempDayHC1SummerMode <= fhem/THZ504/set/+ (mode: S)
    p02RoomTempNightHC1 <= fhem/THZ504/set/+ (mode: S)
    p02RoomTempNightHC1SummerMode <= fhem/THZ504/set/+ (mode: S)
    p04DHWsetDayTemp <= fhem/THZ504/set/+ (mode: S)
    p05DHWsetNightTemp <= fhem/THZ504/set/+ (mode: S)
    p07FanStageDay   <= fhem/THZ504/set/+ (mode: S)
    p08FanStageNight <= fhem/THZ504/set/+ (mode: S)
    p75passiveCooling <= fhem/THZ504/set/+ (mode: S)
    p89DHWeco        <= fhem/THZ504/set/+ (mode: S)
    p99startUnschedVent <= fhem/THZ504/set/+ (mode: S)
    pOpMode          <= fhem/THZ504/set/+ (mode: S)

[Beta-User]

Also - hier mein heutiger Versuch (version MQTT_GE.* => 10_MQTT_GENERIC_BRIDGE.pm 25117 2021-10-25 11:05:19Z hexenmeister):

Publish (für sowas finde ich Tools besser, bei denen man den Verlauf sehen kann):

Code Auswählen Erweitern

user@some_machine:~/FHEM$ mosquitto_pub -h <MQTT-Server-IP> -p 1883 -t MGB1/set/Licht_Essen/brightness  -m 139
Subscribe:

Code Auswählen Erweitern

user@some_machine:~/FHEM$ mosquitto_sub -h <MQTT-Server-IP> -p 1883 -t MGB1/# -v
MGB1/set/Licht_Essen/brightness 139
MGB1/Licht_Essen/brightness set brightness 139
MGB1/Licht_Essen/brightness 139
MGB1/Licht_Essen on
("set brightness bla" als Zwischeninfo ist mir bisher nicht aufgefallen, aber das ist unschön! Passiert aber auch, wenn man das via FHEMWEB direkt macht, ist ein MQTT2_DEVICE (zigbee2mqtt), mit gesetzter setStateList => nicht unser Problem)

Event-Monitor:

Code Auswählen Erweitern

2025-01-04 06:12:39 MQTT2_DEVICE Licht_Essen brightness: set brightness 139
2025-01-04 06:12:39 MQTT2_DEVICE Licht_Essen brightness: 139
2025-01-04 06:12:39 MQTT2_DEVICE Licht_Essen on
2025-01-04 06:12:39 MQTT2_DEVICE Licht_Essen ct: 370
2025-01-04 06:12:39 MQTT2_DEVICE Licht_Essen color_mode: color_temp
Habe wegen des "Datenwegs" dann noch die subscription etwas geändert, dann sieht man (da alle Wege "in MQTT" sind) besser, wie der (m.E. korrekte) Ablauf ist:

Code Auswählen Erweitern

mosquitto_sub -h <MQTT-Server-IP> -p 1883 -t MGB1/# -v -t zigbee2mqtt/Esstisch/#
MGB1/set/Licht_Essen/brightness 139
zigbee2mqtt/Esstisch/set {"state":"on","brightness":139}
MGB1/Licht_Essen/brightness set brightness 139
zigbee2mqtt/Esstisch {"brightness":139,"color_mode":"color_temp","color_temp":370,"state":"ON"}
MGB1/Licht_Essen/brightness 139
MGB1/Licht_Essen on
Ist m.E. selbsterklärend: Die empfangene Info wird korrekt in einen "normalen" set-Befehl umgewandelt, dann an das Gerät geschickt, (diese blöde Zwischeninfo wird in das Reading geschrieben und per MQTT versendet,) und dann kommt die Antwort "erledigt" zurück und wird dann wieder via MGB weitergeleitet. Passiert bei zigbee(2mqtt) dann halt in Sekundenbruchteilen.

Kurz: Im Moment habe ich keine Idee, warum das Auslesen des neuen Werts bei dir so lange dauert, wenn die Anweisung via MQTT (MGB) kam. Auch der Quellcode von THZ hat mir dazu zumindest auf die Schnelle keinen Aufschluss gegeben...

Die vollständige Modulkonfiguration (THZ, MQTT2_CLIENT, MQTT_GENERIC_BRIDGE) findest du im Beitrag vom 02.Januar 2025, 11:40:28

War vom letzten Post ausgegangen. Generell: cfg-Auszüge sind nicht erwünscht, das empfohlene Mittel ist "copy for forum", list oder (mir persönlich am liebsten) ein raw-list. Da du anscheinend einen anderen skin verwendest, hast du dazu vermutlich kein direktes drop-down unter den Devices, ein raw-list bekäme man dann per "list -r <device-name>" .

Da ich im Moment zum Testen nur noch einen (CUL_HM-) Rollladen hätte, verkneife ich mir das erst mal noch, aber der Ablauf dürfte (bis auf eine (TYPE_bedingt)andere Zwischeninfo im Reading) derselbe sein.

Hast du ggf. noch ein anderes Device, an dem du das bei dir nachstellen könntest?

[eddi_g]

Hallo Beta-User,
danke für deinen Versuch. Wenn ich es richtige deute, dann funktioniert bei dir genau das, was ich erreichen möchte.
Kannst du noch deine MQTT_GENERIC_BRIDGE Konfiguration teilen?

Noch eine Frage: Wie konntest es bewerkstelligen, beim mosquitto_sub auch noch den internen FHEM Ablauf zu loggen?

Also bei mir ist es noch so:
Wenn ich folgenden Befehl bei mir auf dem Rechner eingebe:

Code Auswählen Erweitern

mosquitto_sub -h 192.168.1.11 -p 1883 -t fhem/THZ504/p04DHWsetDayTemp -v Dann kann ich beliebig oft in FHEM den Befehl ausführen:

Code Auswählen Erweitern

set THZ504 p04DHWsetDayTemp xDabei muss x jeweils geändert werden, dann sehe ich die Änderung auf dem Rechner immer sofort.
Gleiche Werte werden nicht erneut gesendet. Muss vermutlich so sein, da event-on-change kein Event auslöst, da der Wert sich nicht ändert.

Mache ich das Gleiche über MQTT, also auf dem Rechner den folgenden Befehl eingebe:

Code Auswählen Erweitern

mosquitto_pub -h 192.168.1.11 -p 1883 -t fhem/THZ504/set/p04DHWsetDayTemp -m xund x wieder entsprechend anpassen, dann wird das Reading p04DHWsetDayTemp im THZ Modul direkt übernommen und dieser Wert auch an die Heizung über die serielle Schnittstelle weitergegeben, allerdings wird der Wert in der mosquitto_sub Konsole auf dem Rechner erst zu einem späteren Zeitpunkt aktualisiert.

Was ich noch nicht so ganz verstehe...
Die MQTT_GENERIC_BRIDGE schafft es das Reading zu aktualisieren. Laut Wiki wird dabei der folgende Befehl ausgeführt:

Code Auswählen Erweitern

set THZ504 p04DHWsetDayTemp x
Es wird bei der Aktualisierung des Readings im THZ Modul allerdings kein Event ausgelöst. Diesen müsste nach meinem Verständnis das THZ Gerät generieren. Als Folge kann auch der MQTT Wert nicht aktualisiert werden.
Wenn ich denselben Befehl über das Web-Interface in die FHEM-Console eingebe, dann löst das Modul THZ ein Event aus und der MQTT Wert wird direkt aktualisiert.

Demnach muss es einen Unterschied im set Befehl über die Konsole und dem MQTT_GENERIC_BRIDGE set Befehl geben. Oder bin ich auf dem Holzweg?

Update...
Es gibt bei den Modulen den verbose Parameter. Ich habe den Parameter im MQTT_GENERIC_BRIDGE und im THZ Modul auf den Wert 5 (DEBUG) gestellt und das Log beobachtet, während ich die Werte verstellt habe.

Immer wenn ich den Wert fhem/THZ504/set/p04DHWsetDayTemp über MQTT aktualisiere, bekomme ich im Log die folgende Fehlermeldung:

Code Auswählen Erweitern

2025.01.04 17:51:25 5: MQTT_GENERIC_BRIDGE: [mqttGeneric] Parse (MQTT2_CLIENT : 'ha_MQTT2'): Msg: fhem/THZ504/set/p04DHWsetDayTemp => 38
2025.01.04 17:51:26 1: MQTT_GENERIC_BRIDGE: [mqttGeneric] setUpdate: error in set command: 38 °CIch habe dann versucht den Wert über das Topic auch als String zu schicken, indem ich "" um die Zahl gesetzt habe oder auch mit Einheit also 38 °C
Das Ergebnis war immer gleich.
Anschließend habe ich dann einen Parameter ohne Einheit gesucht und habe mich dann für den Parameter p89DHWeco entschieden. Dieser Parameter nimmt nur Werte 0 und 1 an.
Auch hier habe ich eine ähnliche Fehlermeldung bekommen.
fhem/THZ504/set/p89DHWeco 1

Code Auswählen Erweitern

2025.01.04 18:42:29 5: MQTT_GENERIC_BRIDGE: [mqttGeneric] Parse (MQTT2_CLIENT : 'ha_MQTT2'): Msg: fhem/THZ504/set/p89DHWeco => 1
2025.01.04 18:42:29 1: MQTT_GENERIC_BRIDGE: [mqttGeneric] setUpdate: error in set command: 1

Allerdings bekomme ich keine Fehlermeldung, wenn der Wert mit 0 über MQTT verschickt wird.
fhem/THZ504/set/p89DHWeco 0

Code Auswählen Erweitern

2025.01.04 18:42:48 5: MQTT_GENERIC_BRIDGE: [mqttGeneric] Parse (MQTT2_CLIENT : 'ha_MQTT2'): Msg: fhem/THZ504/set/p89DHWeco => 0
2025.01.04 18:42:48 5: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGeneric] publish: fhem/THZ504/p89DHWeco => 1 (qos: 0, retain: 1
2025.01.04 18:42:48 5: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGeneric] publish: fhem/THZ504/p89DHWeco => 0 (qos: 0, retain: 1Es ist zu erkennen, dass fhem dann zunächst den Wert mit 1 und dann mit 0 verschickt.

Anschließend habe ich die Logs des THZ Moduls näher angeschaut und hier habe ich mich auf p89DHWeco mit dem Wert 1 konzentriert.
Einmal habe ich über MQTT den Wert p89DHWeco auf 1 gesetzt und einmal über den Befehl set fhem/THZ504/p89DHWeco 1
Anschließend habe ich den Log-Auszug rauskopiert und verglichen. Die Logs sind identisch, bis auf die erwarteten Unterschiede aufgrund der unterschiedlichen Befehlsquellen...
Du darfst diesen Dateianhang nicht ansehen.
Die Reaktion des THZ Moduls aufgrund eines Änderungswunsches des Parameters p89DWHeco = 1 ist gleich.
Wie kann ich herausfinden, warum die MQTT_GENERIC_BRIDGE einen Fehler erkennt und warum es zu keinem notify kommt?

[eddi_g]

Hallo zusammen,
ich habe jetzt einfach im PERL Modul 10_MQTT_GENERIC_BRIDGE.pm nach dem Text "setUpdate: error in set command" gesucht.
Da ich kein PERL kann, weiß ich leider nicht was diese Zeilen im Detail bedeuten...

Code Auswählen Erweitern

  if($mode eq 'S') {
    my $err;
    my @args = split ("[ \t]+",$message);
    #Log3($hash->{NAME},1,"MQTT_GENERIC_BRIDGE:DEBUG:> [$hash->{NAME}] mqttGenericBridge_triggeredReading=".Dumper($dhash->{'.mqttGenericBridge_triggeredReading'}));
    if(($reading eq '') or ($reading eq 'state')) {
      $dhash->{'.mqttGenericBridge_triggeredReading'}="state" if !$doForward;
      $dhash->{'.mqttGenericBridge_triggeredReading_val'}=$message if !$doForward;
      #$err = DoSet($device,$message);
      $err = DoSet($device,@args);
    } else {
      $dhash->{'.mqttGenericBridge_triggeredReading'}=$reading if !$doForward;
      $dhash->{'.mqttGenericBridge_triggeredReading_val'}=$message if !$doForward;
      #$err = DoSet($device,$reading,$message);
      $err = DoSet($device,$reading,@args);
    }
    #if (!defined($err)) {
    if (1) {
      $hash->{+HELPER}->{+HS_PROP_NAME_UPDATE_S_CNT}++;
      readingsSingleUpdate($hash,"updated-set-count",$hash->{+HELPER}->{+HS_PROP_NAME_UPDATE_S_CNT},1);
      return;
    }
    Log3($hash->{NAME},1,"MQTT_GENERIC_BRIDGE: [$hash->{NAME}] setUpdate: error in set command: ".$err);
    return "error in set command: $err";Ich vermute, dass die Zeile

Code Auswählen Erweitern

if (!defined($err)) {Nach Fehlern im vorangegangen Code abfragt. Diese Zeile habe ich einfach mit

Code Auswählen Erweitern

if (1) {
ersetzt und das Modul neu geladen. Wenn nun neue Werte über MQTT reinkommen, werden diese sofort aktualisiert.
Interessant ist auch, dass die Variable $err stets den empfangenen MQTT Wert erhält. Weiterhin gehe ich davon aus, dass eine 0 als false interpretiert wird und es deshalb bei MQTT Werten mit 0 auch davor geklappt hat. Mit allen anderen Werten nicht.
Beispiele:

Code Auswählen Erweitern

2025.01.04 17:53:55 1: MQTT_GENERIC_BRIDGE: [mqttGeneric] setUpdate: error in set command: 39 °C
2025.01.04 17:56:04 1: MQTT_GENERIC_BRIDGE: [mqttGeneric] setUpdate: error in set command: 39 °C
2025.01.04 17:56:31 1: MQTT_GENERIC_BRIDGE: [mqttGeneric] setUpdate: error in set command: 39 °C
2025.01.04 17:57:06 1: MQTT_GENERIC_BRIDGE: [mqttGeneric] setUpdate: error in set command: 35 °C
2025.01.04 18:00:52 1: MQTT_GENERIC_BRIDGE: [mqttGeneric] setUpdate: error in set command: 1
2025.01.04 18:02:06 1: MQTT_GENERIC_BRIDGE: [mqttGeneric] setUpdate: error in set command: 1
2025.01.04 18:02:46 1: MQTT_GENERIC_BRIDGE: [mqttGeneric] setUpdate: error in set command: 1
2025.01.04 18:15:02 1: MQTT_GENERIC_BRIDGE: [mqttGeneric] setUpdate: error in set command: 1Was ich noch nicht verstehe ist, warum es bei den anderen funktioniert und bei mir nicht.

Da ich nicht genau weiß was diese Zeile macht, habe ich meine Änderung wieder rückgängig gemacht.

[Beta-User]

Normalerweise sollte die SetFn eines Moduls "nichts" (echtes undef) zurück geben.
Das macht THZ anscheinend anders.

Bitte den Maintainer (immi) informieren, siehe zu den (aktuellen) Vorgaben https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Set

Nachtrag: vielleicht auch gleich per Attribut bestellen, welche Einzlreadings man haben mag. Diese userAttr-Orgie sieht jedenfalls auf die Schnelle grausam aus ..