MQTT - Retain nur für bestimmte Publish-Ausgaben

Begonnen von Reinerlein, 25 Februar 2017, 14:14:52

Vorheriges Thema - Nächstes Thema

Reinerlein

Hallo,

ich weiß nicht, wer jetzt "offiziell" am MQTT-Modul arbeitet, aber ich hätte eine Frage/Featureidee:

Ich habe mir meine ESP8266-Devices mittels einer eigenen MQTT-Implementierung und Nutzung von MQTT_DEVICE an Fhem angebunden.
Nun habe ich mir auch einen Statusrequest (analog zu anderen Systemen wie Homematic oder so) gebaut, wo das Device mit dem aktuellen Zustand antwortet (wenn es denn erreichbar ist).
Da ich für das Fhem-Device Retain aktiviert habe, damit der ESP bei einer Netzunterbrechung oder einem Ausfall den letzten Zustand wiederholt bekommt, bekommt er auch die Statusabfrage vom letzten Fhem Neustart wiederholt.

Das bedeutet, dass ich nach einem Neustart des ESP zweimal für jeden "Kanal" eine aktuelle Antwort bekomme (einmal für das letzte Setzen des Kanals, und einmal für den Statusrequest), obwohl ich die beide eigentlich gar nicht brauche.
Bei einem Fhem Neustart setze ich ja wieder einen Statusrequest ab, und erhalte damit sauber den letzten Zustand.

Nun könnte man sagen, dass die doppelte Antwort ja nicht so wichtig ist, aber etwas unschön ist es doch :).
Ein Lösung wäre, wenn man irgendwie das Retain nicht immer für alle Publish-Ausgaben verwendet, sondern konfigurieren könnte, dass es für bestimmte nicht, oder eben nur bestimmte verwendet werden soll.

Hier mal mein Device:

Internals:
   IODev      mqtt
   NAME       vorgarten_Einfahrt
   NR         1695
   STATE      off
   TYPE       MQTT_DEVICE
   qos        0
   retain     1
   Readings:
     2017-02-25 13:02:07   state           off
     2017-02-25 13:01:58   statusrequest   .
     2017-02-25 13:02:07   transmission-state incoming publish received
   Message_ids:
   Publishsets:
     :
       topic      sensors/cmd/aussen_Einfahrt_Switch_01/Ch2
       values:
         set_on
         set_off
     Statusrequest:
       topic      sensors/cmd/aussen_Einfahrt_Switch_01/Ch2/statusrequest
       values:
   Sets:
     set_off
     set_on
     statusrequest
   subscribe:
     sensors/aussen_Einfahrt_Switch_01/Ch2
   subscribeExpr:
     ^sensors\/aussen_Einfahrt_Switch_01\/Ch2$
   Subscribereadings:
     sensors/aussen_Einfahrt_Switch_01/Ch2 state
Attributes:
   IODev      mqtt
   eventMap   { dev=>{}, usr=>{"on"=>"set_on", "off"=>"set_off", "statusrequest" => "statusrequest ."} }
   publishSet set_on set_off sensors/cmd/aussen_Einfahrt_Switch_01/Ch2
   publishSet_statusrequest sensors/cmd/aussen_Einfahrt_Switch_01/Ch2/statusrequest
   retain     1
   stateFormat state
   subscribeReading_state sensors/aussen_Einfahrt_Switch_01/Ch2
   webCmd     statusrequest:on:off


Alternativ könnte ich "statusrequest" auch als Message an das Topic "/Ch2" senden (und nicht als eigenes Topic), dann wird es wegen des Retain aber blöd, da es den letzten "set_"-Befehl überschreibt, und der ESP dann nur noch Statusrequests erhält, und eben nicht mehr den letzten gewünschten Zustand herstellen kann...

Alles etwas komplex, aber ich hoffe, einigermaßen verständlich geschrieben zu haben, um was es mir geht...

Danke schon mal.

Grüße
Reinerlein

PatrickR

Hallo Reiner!

Zunächst: Ich gebe Dir voll und ganz Recht mit dem retain. Das sollte möglich sein.

Zu deinem konkreten Problem: Ich habe ein Setup ähnlich Deines und es ohne aktive Statusanfrage gelöst. Ich nehme mal an, dass Deine Motivation für das aktive Pollen ist, dass Du damit sicher stellst, dass das Gerät nicht unerwartet ausgefallen ist. Alle anderen Fälle werden ja freundlicherweise durch den mosquitto mitprotokolliert und bei entsprechenden Subscribes angefragt. Für den Ausfall sieht MQTT LWT vor (http://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament), was in meinem Fall sehr zuverlässig funktioniert.

Damit keine Missverständnisse aufkommen: Ich bin nicht der Modulentwickler.

Patrick
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

Reinerlein

Hi Patrick,

den Last-Will habe ich schon in Verwendung :)
Es geht um Zustandsänderungen am ESP während Fhem gerade nicht aktiv war, z.B. während eine Neustarts oder einer ungewollten Downphase.
Dazu habe ich ein Notify an global:INITIALIZED gehangen, welches nach einem Fhem Neustart alle ESPs nach dem aktuellen Zustand abfragt.
Es gibt halt ein paar Schaltzustände, die sich innerhalb des ESPs aktualisieren, z.B. eine Art on-for-timer, wo mir am Ende dann der neue Zustand mitgeteilt wird, und den Fhem dann halt nicht mitbekommt, wenn es gerade indisponiert war :)

Grüße
Reiner