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.).