Mahlzeit!
In MQTT2_CLIENT gibt es für LWT bereits die Möglichkeit, das retain-flag zu setzen. Wenn ich nichts übersehen habe, ist das bei msgAfterConnect, msgAfterDisconnect nicht so. Könnte man das nachrüsten?
Patrick
Wenn Du mir den Anwendungsfall erklaerst...
Verstehe die Frage ehrlich gesagt nicht. Der Anwendungsfall ist das Festhalten des Status des MQTT2_CLIENT auf dem Broker also genau wie bei LWT.
Von unterwegs gesendet.
ZitatDer Anwendungsfall ist das Festhalten des Status des MQTT2_CLIENT auf dem Broker also genau wie bei LWT.
Sehe ich auch so.
Welchen Fall kann ich mit LWT nicht abdecken?
msgAfterConnect
/Edit: Streng genommen auch msgAfterDisconnect für den Fall, dass sauber disconnected wird und der Broker es sofort erfahren sollte.
Von unterwegs gesendet.
Der Broker (der seit 3.1 Server heisst) bekommt ein disconnect auch ohne retain.
Ich sehe immer noch keinen Anwendungsfall.
Hi!
Zitat von: rudolfkoenig am 04 Juli 2019, 08:13:46
Der Broker (der seit 3.1 Server heisst) bekommt ein disconnect auch ohne retain.
Darum geht es hier leider nicht.
Zitat von: rudolfkoenig am 04 Juli 2019, 08:13:46
Ich sehe immer noch keinen Anwendungsfall.
Ich bin mir ehrlich gesagt nicht sicher, ob ich das ändern kann, will aber gerne noch einen weiteren Versuch starten.
Anwendungsfall:
- Eine A verbindet sich in unregelmäßigen Abständen mit dem MQTT-Server und visualisiert den Verbindungsstatus einer FHEM-Instanz zu diesem Server. Eine Dauerhafte Verbindung von A mit dem Server besteht nicht.
- FHEM publisht diesen Verbindungsstatus auf dem MQTT-Server in einem Status-Topic. msgAfterConnect->online, msgAfterDisconnect->offline, LWT->offline
Ohne retain-Flag würde eine Verbindung der Anwendung A das Topic ggf. leer vorfinden obwohl der Server verbunden ist. Mit retain bei connect, disconnect und LWT.
msgAfterDisconnect ist übrigens für den Fall ebenfalls (inkl. retain) erforderlich, da der Will bei einem sauberen Disconnect auf dem Server verworfen wird.
Patrick
Diesen hypothetischen Fall verstehe ich, dessen praktischen Nutzen sehe ich aber nicht.
Da eine Implementierung aber vmtl. niemanden stoert, habe ich es hiermit gemacht.
Die beiden Attribute können ab sofort einen optionalen -r am Anfang haben, etwa in der Form "attr m2c msgAfterConnect -r topic message".