Kein erneutes Senden eines Readings nach Empfang über mqttSubscribe

[eddi_g]

Hallo zusammen,

ich habe ein kleines Verständnisproblem mit MQTT und konnte bisher mit der Suche zu meinem Problem nichts finden.
Das grundsätzliche MQTT Setup funktioniert bei mir. Sprich ich kann aus FHEM heraus MQTT Nachrichten schicken und Empfangen.
Allerdings ist es so, dass wenn ein Reading über mqttSubscribe über stopic gesetzt wird, dieses Reading zwar aktualisiert wird, es aber nicht über mqttPublish erneut verschickt wird. So fehlt dem Sender eine Bestätigung, dass der Wert übernommen wurde.
Wenn ich das selbe Reading über die FHEM Oberfläche ändere, wird der Wert über mqtt korrekt verschickt und von den anderen Teilnehmern korrekt empfangen.

Ich bin mir nicht sicher welche Informationen bzw. Einstellungen relevant sind. Falls etwas fehlen sollte, kann ich es gerne nachreichen.

Code Auswählen Erweitern

mqttPublish
p01RoomTempDayHC1:topic={"$base/$name"}

Code Auswählen Erweitern

mqttSubscribe
p01RoomTempDayHC1:stopic={"$base/set/$name"}

Code Auswählen Erweitern

userattr
mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long

Code Auswählen Erweitern

# MQTT Client
define ha_MQTT2 MQTT2_CLIENT 192.168.1.11:1883
setuuid ha_MQTT2 65a5ae7b-f33f-1d40-dfaf-e1385ddb3cea1b58
attr ha_MQTT2 clientId fhem
attr ha_MQTT2 clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr ha_MQTT2 keepaliveTimeout 60
attr ha_MQTT2 msgAfterConnect -r fhem/connection/status connected
attr ha_MQTT2 msgBeforeDisconnect -r fhem/connection/status disconnected
attr ha_MQTT2 qosMaxQueueLength 100
attr ha_MQTT2 room MQTT
attr ha_MQTT2 subscriptions setByTheProgram
attr ha_MQTT2 username mqtt-fhem-user
# 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
Danke für eure Unterstützung.

[rudolfkoenig]

... wenn ein Reading über mqttSubscribe über stopic gesetzt wird, dieses Reading zwar aktualisiert wird, es aber nicht über mqttPublish erneut verschickt wird

Das waere die Aufgabe von MQTT_GENERIC_BRIDGE, es waere sinnvoll das im Betreff zu erwaehnen.

Ich finde uebrigens das beschriebene Verhalten richtig.
Ob es durch ein Attribut geaendert werden kann, ist mir nicht bekannt.

[eddi_g]

Hallo rudolfkoenig,

Danke für deine Rückmeldung.
Zum Betreff: mir sind die Zusammenhänge teilweise noch nicht klar
Daher wird es meiner Unwissenheit geschildert sein. Gerne kann ich den Betreff umbennen. Reicht es als Prefix einfach MQTT_GENERIC_BRIDGE einzutragen oder wie wäre dein Vorschlag?

Zum Verhalten:
Wenn es das gewünschte Verhalten ist, dann ist es für mich auch ok und ich könnte die Anforderung im HA einfach auf optimistic setzen, dann wird der Sollwert in HA auch gleich als Ist Wert übernommen.
Ich bin nur davon ausgegangen, dass fhem immer das reading verschickt, sobald es sich ändert. Unabhängig davon ob es über das webinterface oder über mqtt verändert wird.

[rudolfkoenig]

Reicht es als Prefix einfach MQTT_GENERIC_BRIDGE einzutragen oder wie wäre dein Vorschlag?

Das wie ist vmtl egal, viele Maintainer lesen nur die Ueberschrift, oder den Beitrag nicht in der Tiefe durch.

Ich bin nur davon ausgegangen, dass fhem immer das reading verschickt, sobald es sich ändert. Unabhängig davon ob es über das webinterface oder über mqtt verändert wird.

Das ist generell der Fall, aber speziell bei MQTT kann das gefaehrlich werden, weil so eine Edlosschleife entstehen kann.
Bei MQTT ist es auch nicht ueblich, das was reingekommen ist, unveraendert zurueckzuschicken.

[eddi_g]

Ich bin davon ausgegangen, dass genau aufgrund der Schleifen das Set topic (Empfangsnachricht) und das normale topic (Sendenachricht) unterschiedlich sind.

Vielleicht hat ja jemand doch einen Tipp, wie ich vielleicht auch anhand einem notify oder sowas ähnliches mein Ziel erreiche.
Es wäre mir lieber, wenn ich eine Bestätigung des Befehls erhalten würde.

[Beta-User]

Hier ist nicht klar, um was für ein Gerät es geht, da nur auszugsweise gepostet wurde (!?!).

Schau mal in die Attributhilfe zu "mqttForward".

[eddi_g]

Hallo zusammen,

ich habe mich eine weile mit dem Thema nicht mehr beschäftigen können. Daher habe ich nicht mehr geantwortet.

@Beta-User:
Ich möchte ausgewählte Signale und Parameter aus dem Gerät myTHZ aus FHEM zu Home Assistant schicken (das klappt bereits) und dann ein paar ausgewählte Parameter aus Home Assistant in myTHZ verändern. Auch dies klappt bereits.
Allerdings schickt FHEM mir nicht sofort die Aktualisierung der Parameter.

Ich habe nun beobachtet, dass wenn ich aus Home Assistant den Parameter verstelle, dieser direkt verschickt wird und auch in FHEM geändert wird. Auch der Zeitstempel auf der rechten Seite wird aktualisiert. Dieser Aktualisierung fehlen jedoch 3 Ausrufezeichen und der Zeitstempel ist nicht hervorgehoben.
Wenn nun ein Reading aus myTHZ ausgelesen wird, dann erkennt wohl FHEM auch eine Änderung der verstellten Parameter und schickt diese ebenfalls über MQTT heraus.
Leider passiert dies nicht direkt nach der Änderung über Home Assistant.

Ich hoffe ich konnte es halbwegs gut erklären. Ich bin leider nicht ganz sattelfest, was die Begriffe in FHEM betrifft. Tut mir leid.

Nach Änderung der Parameter über Home Assistant (über MQTT)
Du darfst diesen Dateianhang nicht ansehen.

Nachdem ein Reading aus der THZ ausgelesen wurde
Du darfst diesen Dateianhang nicht ansehen.

Die 4 Werte haben sich zwischen den Zeitpunkten nicht verändert, trotzdem werden diese als aktualisiert erachtet und dann auch per MQTT verschickt. Vorher leider nicht.
Habt ihr einen Tipp, welche Einstellung ich treffen kann, damit ein veränderter Wert direkt verschickt wird?

[Beta-User]

Ich hoffe ich konnte es halbwegs gut erklären. Ich bin leider nicht ganz sattelfest, was die Begriffe in FHEM betrifft. Tut mir leid.

Das ist nicht so sehr das Problem, aber bitte halte dich an die "üblichen Gepflogenheiten" hier, also tendenziell keine screenshots, siehe "angepinnte Beiträge" (MQTT und Anfängerfragen)...

Was Zeitstempel mit Ausrufezeichen angeht, ist das das erste Mal, das ich sowas bewußt sehe, keine Idee, wo das herkommt.

Und es ist m.E. auch "korrekt", dass der Änderungswunsch nicht direkt von FHEM@MQTT als "ok" quittiert wird, sondern erst die Aktualisierung auf der Hardware abgewartet wird. Ggf. kann man da was beschleunigen, aber dazu bräuchte man ggf. erst mal die Info, was das überhaupt für ein Dingens ist (list oä., s.o.).

[eddi_g]

Hallo zusammen, Hallo Beta-User, 

ich habe mich mit dem Thema eine Weile nicht beschäftigt und bin jetzt wieder dazu gekommen.

Von meiner Beobachtung her übernimmt die Hardware die über MQTT geforderten Werte. Also die Wärmepumpe beginnt zum Beispiel mit der Warmwasseraufbereitung.
Trotzdem werden die Werte über MQTT nicht aktualisiert.
Ich habe weitere "Tests" gemacht und folgendes festgestellt...

Laut der Wiki-Seite https://wiki.fhem.de/wiki/MQTT_GENERIC_BRIDGE wird stopic wie folgt behandelt:

attr myRGBLight mqttSubscribe state:stopic={"$base/$device"} pct|rgb:stopic={"$base/$device/$name"}
In obigem Beispiel haben wir in mqttSubscribe das Schlüsselwort stopic (die Kurzform von set-topic) verwendet. Dieses bewirkt bei einer entsprechenden MQTT-Nachricht dasselbe wie der FHEM-Befehl set <device> <reading> <value>, also set myRGBLight pct 70

Wenn ich nun über MQTT den Wert setze, dann wird der Wert zwar über stopic aktualisiert, ich kann jedoch im Event Monitor kein Event sehen.
Wenn ich nun lang genug warte, bis im THZ Modul beliebige Werte abgefragt werden, dann wird auch der geänderte Wert festgestellt (Vermutung) und es gibt dann eben auch zu diesem Wert eine Wertänderung. Daraufhin wird auch der Wert über MQTT aktualisiert.
Wenn ich nun den Wert nicht über MQTT, sondern direkt über einen set Befehl ändere, dann kann ich direkt im Event Monitor eine Änderung sehen und der Wert wird auch über MQTT aktualisiert.

Wenn ich es richtig interpretiere, dann ändert ein stopic zwar den Wert, das Gerät sendet jedoch kein Event und damit kann der Wert über MQTT nicht aktualisiert werden.

Anbei die vollständige Modulkonfiguration:

Code Auswählen Erweitern

# MQTT Client
define ha_MQTT2 MQTT2_CLIENT 127.0.0.1:1883
setuuid ha_MQTT2 65a5ae7b-f33f-1d40-dfaf-e1385ddb3cea1b58
attr ha_MQTT2 clientId fhem
attr ha_MQTT2 clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr ha_MQTT2 keepaliveTimeout 60
attr ha_MQTT2 msgAfterConnect -r fhem/connection/status connected
attr ha_MQTT2 msgBeforeDisconnect -r fhem/connection/status disconnected
attr ha_MQTT2 qosMaxQueueLength 100
attr ha_MQTT2 room MQTT
attr ha_MQTT2 subscriptions setByTheProgram
attr ha_MQTT2 username mqtt-fhem-user
# 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

# THZ504 Waermepumpe
define THZ504 THZ /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@115200
setuuid THZ504 65a59b7a-f33f-1d40-0085-4f75e6a35ffdc9a6
attr THZ504 userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr THZ504 devStateIcon opened:10px-kreis-gruen disconnected:10px-kreis-rot
attr THZ504 interval_sBoostDHWTotal 3600
attr THZ504 interval_sBoostHCTotal 3600
attr THZ504 interval_sDHW 300
attr THZ504 interval_sElectrDHWDay 3600
attr THZ504 interval_sElectrDHWTotal 3600
attr THZ504 interval_sElectrHCDay 3600
attr THZ504 interval_sElectrHCTotal 3600
attr THZ504 interval_sFan 300
attr THZ504 interval_sGlobal 300
attr THZ504 interval_sHC1 300
attr THZ504 interval_sHeatDHWDay 3600
attr THZ504 interval_sHeatDHWTotal 3600
attr THZ504 interval_sHeatHCDay 3600
attr THZ504 interval_sHeatHCTotal 3600
attr THZ504 interval_sHistory 28800
attr THZ504 interval_sLast10errors 28800
attr THZ504 mqttPublish UR.sHC1.insideTempRC|UR.sHC1.roomSetTemp|UR.sGlobal.relHumidity|UR.sHC1.outsideTemp|UR.sHC1.heatTemp|UR.sHC1.heatSetTemp|UR.sHC1.flowTemp|UR.sHC1.returnTemp|UR.sGlobal.flowRate|UR.sDHW.dhwTemp|UR.sDHW.dhwSetTemp|UR.sFan.pFanstageXAirflowInlet|UR.sFan.pFanstageXAirflowOutlet|UR.sHC1.hcBoosterStage|sHeatDHWDay|sHeatDHWTotal|sHeatHCDay|sHeatHCTotal|sBoostDHWTotal|sBoostHCTotal|sElectrDHWDay|sElectrDHWTotal|sElectrHCDay|sElectrHCTotal|p01RoomTempDayHC1|p01RoomTempDayHC1SummerMode|p02RoomTempNightHC1|p02RoomTempNightHC1SummerMode|p04DHWsetDayTemp|p05DHWsetNightTemp|dhwBoosterStage|p07FanStageDay|p08FanStageNight|UR.sGlobal.actualPower_Qc|UR.sGlobal.actualPower_Pel|UR.sGlobal.evuRelease:topic={"$base/$name"}
attr THZ504 mqttSubscribe p04DHWsetDayTemp|p05DHWsetNightTemp|p07FanStageDay|p08FanStageNight:stopic={"$base/set/$name"}
attr THZ504 room Heizung
attr THZ504 userReadings UR.sHC1.insideTempRC:sHC1.* {((split ' ',ReadingsVal("THZ504","sHC1",0))[27])}, UR.sHC1.roomSetTemp:sHC1.* {((split ' ',ReadingsVal("THZ504","sHC1",0))[21])}, UR.sGlobal.relHumidity:sGlobal.* {((split ' ',ReadingsVal("THZ504","sGlobal",0))[67])}, UR.sHC1.outsideTemp:sHC1.* {((split ' ',ReadingsVal("THZ504","sHC1",0))[1])}, UR.sHC1.heatTemp:sHC1.* {((split ' ',ReadingsVal("THZ504","sHC1",0))[13])}, UR.sHC1.heatSetTemp:sHC1.* {((split ' ',ReadingsVal("THZ504","sHC1",0))[11])}, UR.sHC1.flowTemp:sHC1.* {((split ' ',ReadingsVal("THZ504","sHC1",0))[9])}, UR.sHC1.returnTemp:sHC1.* {((split ' ',ReadingsVal("THZ504","sHC1",0))[5])}, UR.sGlobal.flowRate:sGlobal.* {((split ' ',ReadingsVal("THZ504","sGlobal",0))[87])}, UR.sDHW.dhwTemp:sDHW.* {((split ' ',ReadingsVal("THZ504","sDHW",0))[1])}, UR.sDHW.dhwSetTemp:sDHW.* {((split ' ',ReadingsVal("THZ504","sDHW",0))[5])}, UR.sFan.pFanstageXAirflowInlet:sFan.* {((split ' ',ReadingsVal("THZ504","sFan",0))[5])}, UR.sFan.pFanstageXAirflowOutlet:sFan.* {((split ' ',ReadingsVal("THZ504","sFan",0))[7])}, UR.sHC1.hcBoosterStage:sHC1.* {((split ' ',ReadingsVal("THZ504","sHC1",0))[37])}, UR.sGlobal.actualPower_Qc:sGlobal.* {((split ' ',ReadingsVal("THZ504","sGlobal",0))[75])}, UR.sGlobal.actualPower_Pel:sGlobal.* {((split ' ',ReadingsVal("THZ504","sGlobal",0))[77])}, UR.sGlobal.evuRelease:sGlobal.* {((split ' ',ReadingsVal("THZ504","sGlobal",0))[47])}


Kann mir jemand einen Tipp zum Signalablauf geben? Wann sollte nach dem Empfang des stopic ein Notify abgesetzt werden und durch welches Modul? 

[Jamo]

Hi,
in dem attribut

Code Auswählen Erweitern

attr THZ504 mqttSubscribe p04DHWsetDayTemp|p05DHWsetNightTemp|p07FanStageDay|p08FanStageNight:stopic={"$base/set/$name"}
ist das ,,set" zuviel, es muss laut Wiki (und bei mir ist es auch überall so) so lauten:

Code Auswählen Erweitern

attr THZ504 mqttSubscribe p04DHWsetDayTemp|p05DHWsetNightTemp|p07FanStageDay|p08FanStageNight:stopic={"$base/$name"}

und für das was Du machen willst, gibt es das attribut mqttforward im Device,  das ist aber per default schon richtig auf ,,all" gesetzt...

[eddi_g]

Hallo Jamo,
danke für deine Rückmeldung.
Nach meinem Verständnis muss da ein set mit rein, ansonsten würde ich ja die Daten im Kreis schicken.

Ich habe mal die beiden relevanten Zeilen gekürzt, um die Konfiguration nach meinem Verständnis aufzudröseln...

Code Auswählen Erweitern

attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
Als Beispiel nehme ich nur das Reading p04DHWsetDayTemp
Mit dieser Zeile wird der Wert des Readings p04DHWsetDayTemp auf dem Topic fhem/THZ504/p04DHWsetDayTemp veröffentlicht. Dies funktioniert auch soweit.

Code Auswählen Erweitern

attr THZ504 mqttPublish p04DHWsetDayTemp:topic={"$base/$name"}
Mit dieser Zeile wird ein neuer Wert über MQTT empfangen. Das heißt dieser Wert wird nicht vom FHEM geschrieben und sollte daher auch getrennt vom oberen topic sein...
In diesem Fall hört FHEM auf das Topic /fhem/THZ504/set/p04DHWsetDayTemp

Code Auswählen Erweitern

attr THZ504 mqttSubscribe p04DHWsetDayTemp:stopic={"$base/set/$name"}Über dieses Topic kommen dann neue Sollwerte für das Reading p04DHWsetDayTemp rein. Damit der Wert nicht im Kreis aktualisiert wird, sind der Ist-Wert und der Soll-Wert getrennt.
Auch dies funktioniert soweit.
Mein Problem ist nur, dass wenn ein neuer Soll-Wert reinkommt (über das Topic /fhem/THZ504/set/p04DHWsetDayTemp) das Reading im Gerät zwar aktualisiert wird, es aber kein Event auslöst und daher der MQTT Wert nicht aktualisiert wird. Der MQTT Wert wird erst dann aktualisiert, wenn das Modul THZ504 erneut über Polling irgendwelche anderen Readings aktualisiert und dann vermutlich auch feststellt, dass das Reading p04DHWsetDayTemp in der Zwischenzeit ebenfalls geändert wurde...

Vielleicht habe ich die Systematik auch falsch verstanden, dann bitte korrigieren.

Ich habe mal einen Beispiel Ablauf durchgeführt und den Event Monitor betrachtet:
2025-01-02 23:24:42 Das Reading p04DHWsetDayTemp wird über MQTT auf 35 geändert.
Im Eventlog ist nichts zu sehen, aber das aktualisierte Reading hat im Device diesen Zeitstempel und der Wert wurde übernommen.
Du darfst diesen Dateianhang nicht ansehen.
2025-01-02 23:25:06 Das Reading p99FanStageParty (willkürlich gewählt) wird über get ausgelesen.
Obwohl das Reading p99FanStageParty kein Event auslöst, wird eine Werteänderung von p04DHWsetDayTemp erkannt und der Wert über MQTT aktualisiert. (Im Event Log zu sehen)
Eigentlich hat sich zu diesem Zeitpunkt der Wert p04DHWsetDayTemp nicht geändert. 
Du darfst diesen Dateianhang nicht ansehen.
2025-01-02 23:25:27 Das Reading p04DHWsetDayTemp wird über set auf 40 geändert. Dies ist direkt im Event Log und in MQTT sichtbar.
Du darfst diesen Dateianhang nicht ansehen.

Auszug aus dem Eventlog ab 2025-01-02 23:24:00

Code Auswählen Erweitern

2025-01-02 23:25:06 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 2038
2025-01-02 23:25:06 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2025-01-02 23:25:06 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 92392
2025-01-02 23:25:06 THZ THZ504 p04DHWsetDayTemp: 35 °C
2025-01-02 23:25:27 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2025-01-02 23:25:27 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 92393
2025-01-02 23:25:27 THZ THZ504 p04DHWsetDayTemp: 40 °C

[Beta-User]

Nach meinem Verständnis muss da ein set mit rein, ansonsten würde ich ja die Daten im Kreis schicken.

Das muss dann da rein, wenn man sich nicht 1:1 an die Anleitung im Wiki hält und getrennte "$base" für sub und pub definiert. Da steht afair übrigens auch, dass "retain" nicht zu empfehlen ist...

Und es ist m.E. auch "korrekt", dass der Änderungswunsch nicht direkt von FHEM@MQTT als "ok" quittiert wird, sondern erst die Aktualisierung auf der Hardware abgewartet wird. Ggf. kann man da was beschleunigen, [...]

Der von dir beschriebene Ablauf ist genau das: Es wird eben erst später vom Gerät gelesen, wie die aktuellen Werte/Readings sind, ob das jetzt "per bulk" gelesen wird oder einzeln, ist egal, Hauptsache, nach dem Lesen wird der passende Trigger ausgelöst.

Man kann das auf zwei Arten lösen: Den Maintainer seiner Hardware bitten, bei solchen Änderungen direkt ein Bestätigungstelegramm zu schicken, oder eben FHEM so konfigurieren, dass direkt dann (z.B.) ein "get" hinterhergeschickt wird, um den Lesevorgang aktiv anzustoßen (=> Perl-Code in der setList einer "expression" (mit timer, der ggf. den get-Befehl verzögert; zumindest scheint THZ sowas zu kennen wie einen Abruf beim Gerät in Folge eines "get"-Befehls für das entsprechende Reading)). Bin nicht sicher, aber sowas müßte es z.B. bei ebus auch schon geben, das man hier ausschlachten könnte.

[eddi_g]

Hallo Beta-User,
ich kann dem letzten Absatz nicht ganz folgen 
Vielleicht kannst du mir Helfen meinen Knoten im Kopf zu lösen. Den Hinweis mit retain prüfe ich nochmal, danke.

Im MQTT GENERIC BRIDGE Wiki Eintrag ist folgendes zu finden:

topic, stopic und atopic
In obigem Beispiel haben wir in mqttSubscribe das Schlüsselwort stopic (die Kurzform von set-topic) verwendet. Dieses bewirkt bei einer entsprechenden MQTT-Nachricht dasselbe wie der FHEM-Befehl set <device> <reading> <value>, also set myRGBLight pct 70. Daneben gibt es die weiteren Schlüsselwörter topic und atopic.

Ich folgere daraus, dass ein stopic in FHEM einen SET Befehl ausführt.
Wenn ich nun direkt in FHEM einen SET Befehl ausführe, also zum Beispiel:

Code Auswählen Erweitern

set THZ504 p04DHWsetDayTemp 40dann wird der Wert aktualisiert, ein Event ausgelöst und auch direkt der MQTT Wert aktualisiert. Dass dies funktioniert, habe ich gestern mit dem Beispiel zum Zeitpunkt 2025-01-02 23:25:27 positiv geprüft.
Über stopic scheint es aber, zumindest bei mir, nicht zu funktionieren.

[Jamo]

Nach meinem Verständnis muss da ein set mit rein, ansonsten würde ich ja die Daten im Kreis schicken.

Hallo Eddi,
das glaube ich nicht. Dass funktioniert bei mir auch so ohne 'set', und ohne Schleife. Meiner Meinung hast Du im mqttSubscribe das 'set' zuviel.
Laut Wiki werden keine Schleifen erzeugt, weil die Schaltanweisung an einen anderen Topic geht (deswegen ja auch 'topic' und 'stopic').
Ich zitiere:
"Da wir oben in globalDefaults für sub:$base=mqttGenericBridge/set festgelegt haben, muss die Schaltanweisung allerdings an einen anderen Topic erfolgen als die Statusmeldung, die wir wegen des mqttPublish-Attributs erhalten - auf diese Weise können unbeabsichtigte Schleifen unterbunden werden."

Bei mir sieht das so aus, Beispiel Hue Lampe:

Code Auswählen Erweitern

attr group LAMPEN
attr model LCT010
attr mqttDefaults pub:qos=2 sub:qos=2 retain=1
attr mqttForward all
attr mqttPublish   pct:topic={"$base/$device/$name"}  state:topic={"$base/$device"}
attr mqttSubscribe pct:stopic={"$base/$device/$name"} state:stopic={"$base/$device"}

[Beta-User]

Ich habe mal die beiden relevanten Zeilen gekürzt, um die Konfiguration nach meinem Verständnis aufzudröseln...
Code Auswählen Erweitern

Code Auswählen Erweitern

attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}

Ist das jetzt gekürzt oder nicht?!? (Hier ist - nach dieser Angabe - "$base" einheitlich, man braucht also im Device eine Unterscheidung! Logisch ist das aber nicht, weil dann "$device" doppelt im Topic vorkommt! (Keine Ahnung, warum man sich als noob nicht schlicht an die Vorschläge im Wiki hält...))

Ergo: Was zeigt

Code Auswählen Erweitern

get mqttGeneric devinfo THZ504
Nach der bisherigen Schilderung war ich davon ausgegangen, dass der per MQTT gesendete neue Wert irgendwann tatsächlich am THZ ankam - war das jetzt so oder nicht? Wenn ja, ist stopic (unglücklich, aber) korrekt gesetzt.

Wenn nein, liegt es am Topic bzw. der Konfiguration der Gegenstelle. (Event-Analyse mit eigenen Devices mache ich ggf. erst, wenn dazu Infos geliefert wurden).