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.
mqttPublish
p01RoomTempDayHC1:topic={"$base/$name"}
mqttSubscribe
p01RoomTempDayHC1:stopic={"$base/set/$name"}
userattr
mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
# 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.
Zitat... 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.
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.
ZitatReicht 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.
ZitatIch 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.
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.
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".
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)
2024-09-24 21_27_29-Home, Sweet Home.png
Nachdem ein Reading aus der THZ ausgelesen wurde
2024-09-24 21_29_37-Home, Sweet Home.png
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?
Zitat von: eddi_g am 24 September 2024, 21:35:30Ich 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.).
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:
Zitatattr 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:
# 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?
Hi,
in dem attribut
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:
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...
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...
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.
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
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.
2025-01-02 23_24_51-Home, Sweet Home und 2 weitere Seiten - Persönlich – Microsoft� Edge.png
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.
2025-01-02 23_25_12-Home, Sweet Home und 2 weitere Seiten - Persönlich – Microsoft� Edge.png
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.
2025-01-02 23_25_37-Home, Sweet Home und 2 weitere Seiten - Persönlich – Microsoft� Edge.png
Auszug aus dem Eventlog ab 2025-01-02 23:24:00
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
Zitat von: eddi_g am 02 Januar 2025, 23:10:53Nach 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...
Zitat von: Beta-User am 06 Oktober 2024, 09:00:18Und 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.
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:
Zitattopic, 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:
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.
Zitat von: eddi_g am 02 Januar 2025, 23:10:53Nach 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:
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"}
Zitat von: eddi_g am 02 Januar 2025, 23:10:53Ich 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"}
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
get mqttGeneric devinfo THZ504Nach 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).
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:
# 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)
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
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)
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):
user@some_machine:~/FHEM$ mosquitto_pub -h <MQTT-Server-IP> -p 1883 -t MGB1/set/Licht_Essen/brightness -m 139
Subscribe:
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:
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_tempHabe 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:
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...
Zitat von: eddi_g am 04 Januar 2025, 00:18:53Die 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?
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:
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:
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:
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:
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:
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
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
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...
2025-01-04 19_24_27-_neu 8 - Notepad++.png
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?
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...
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
if (!defined($err)) {Nach Fehlern im vorangegangen Code abfragt. Diese Zeile habe ich einfach mit
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:
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.
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 ..