Feature request MQTT2_CLIENT

[Prof. Dr. Peter Henning]

Bei der Verwendung des Moduls mit Roomba-Staubsaugerrobotern haben wir festgestellt, dass die Roboter unerwünschterweise bereits in einen aktiven Zustand versetzt werden wenn sich der MQTT2_CLIENT mit dem internen Broker des Roboters verbindet. Ein "disable=1" hilft dagegen nicht. Könnte man ein "set connected" und "set disconnected" ins Modul einbauen?

LG

pah

[rudolfkoenig]

Bevor ich das einbaue: warum genau braucht man das?

[Beta-User]

...das wissen wir eigentlich vermutlich noch nicht so genau...

Der Bezugspunkt der Anfrage ist der: https://forum.fhem.de/index.php/topic,114166.0.html

Wenn ich es richtig interpretiere: Der auf dem Gerät implementierte Server erwartet eigentlich immer nur kurze Verbindungen vom jeweiligen Client, die dann auch wieder geschlossen werden.

Damit dient "CLIENT" eigentlich nicht mehr als "stehende Verbindung" zu einem "normalen Broker" (falls es sowas gibt), sondern eher als Bindeglied zu "eigenwilligen" Serverimplementierungen.

Das "set <client> connect/disconnect" wäre daher evtl. nur der Einstieg, was man evtl. am Ende braucht, ist ein automatischer connect, wenn ein MQTT2_DEVICE über das IO was senden will und/oder sowas wie ein periodicConnect-Attribut ("attr <client> periodicConnect 60 2"), mit dem man z.B. ein Intervall und eine Verbindungsdauer angeben könnte.

Ist aber erst mal nur eine Vermutung, in welche Richtung es gehen könnte...

[Beta-User]

...kaum geschrieben, schon ziehen die Gedanken weiter...

Dem Bauchgefühl nach ist es eher so, dass man die Kontrolle über CLIENT in diesen Fällen eigentlich an DEVICE abgibt, CLIENT ist in diesen Fällen nur eine Art untergeordnetes "Hilfsdevice".

Damit würde es reichen, am CLIENT nur anzugeben, wie lange er ggf. nach einer Sendeanweisung die Verbindung noch offenhalten soll (keepalive). Alles andere könnte man dann z.B. über eine LWT-Funktionalität/periodicCmd am DEVICE regeln.

(Das ist zugegebenermaßen etwas abstrakt formuliert, wie immer: fragen, falls das unverständlicher Kauderwelsch sein sollte).

[Prof. Dr. Peter Henning]

Ich würde das sogar noch weiter treiben: Nicht am CLIENT muss eingestellt werden, wie lange sein KeepAlive dauern soll. Sondern das wäre am DEVICE zu machen, welches dies dann dem CLIENT mitteilt.


LG

pah

[rudolfkoenig]

Ich habe das Attribut disconnectAfter fuer MQTT2_CLIENT implementiert:

if set, the connection will be closed after <seconds> of inactivity, and will be automatically reopened when sending a command.

Nicht am CLIENT muss eingestellt werden, wie lange sein KeepAlive dauern soll. Sondern das wäre am DEVICE zu machen, welches dies dann dem CLIENT mitteilt.

Das ist mir aus mehreren Gruenden zu bunt: bei mehreren angeschlossenen MQTT2_DEVICE Instanzen das Richtige zu berechnen geht sicher schief, weiterhin kennt MQTT2_SERVER sowas nicht.

[Prof. Dr. Peter Henning]

OK, Danke. Werden in den nächsten Tagen mal sehen, ob das wirkt.

LG

pah

[Beta-User]

bei mehreren angeschlossenen MQTT2_DEVICE Instanzen das Richtige zu berechnen geht sicher schief, weiterhin kennt MQTT2_SERVER sowas nicht.

An Probleme mit MQTT2_SERVER hatte ich auch schon gedacht, aber das erste ist eigentlich auch schon ausreichend.

Es wird  vermutlich mal wieder nicht so ganz einfach den Usern zu erklären, warum welches Attribut auf welcher Ebene angesiedelt ist, aber eigentlich ist es logisch, dass das Verhalten (dieses Teilbereichs) von FHEM als MQTT-Client an CLIENT einzustellen ist, immer getreu dem Motto "ein Programm, eine Funktion".

(Etwas OT und im Moment auch ohne praktische Anwendung, aber weil mir heute morgen schon das Stichwort LWT im Kopf rumgespukt war: Das wäre "eigentlich" doch auch eine typische Client-Funktionalität? Mein erster Gedanke war, dass sich das ohne weiteres auch über periodicCmd bei MQTT2_DEVICE abbilden liese, aber lt. https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament/ scheint es aber so zu sein, dass das genau 1 Topic pro Client ist (ergo wären mehrere DEVICE-Instanzen, die sich da in die Quere kommen könnten ein Problem?) und Auslöser für das Ausliefern dann ein "disconnected ungracefully" sein soll - demnach hätte es nicht unbedingt was mit einem Zeitablauf zu tun, sondern eher mit der Art und Weise des Verbindens?
Es würde mich überraschen, wenn der Roomba irgendwas damit anfängt, von daher  nochmal: ist derzeit nicht wichtig! Bin jetzt erst mal gespannt, ob das disconnectAfter im konkreten Anwendungfall den Nagel auf den Kopf trifft .)

[Prof. Dr. Peter Henning]

Na ja, wir müssen erst noch ausprobieren, ob eine abgesandte Message dann den Roomba auch wieder aufweckt. In dem nicht mehr lauffähigen Roomba980-Modul wird ein explizierter Connect gemacht.

LG

pah

[rudolfkoenig]

Nach Aufbau der TCP Verbindung wird erst ein CONNECT geschickt, sonst muss jeder MQTT Server die Verbindung schliessen. Solange die Verbindung nicht mit CONNACK bestaetigt wurde, werden die Befehle gesammelt. Auch das Ende der Verbindung wird "richtig" mit DISCONNECT signalisiert.

Ist zwar Overhead, aber was tut man nicht alles, damit die LEDs ausgehen

Bin gespannt, ob noch eine "Bestellung" reinkommt, damit dieser Timeout den ankommenden Traffic ignoriert.

[Prof. Dr. Peter Henning]

Bisher keine Nachbestellung, Lieferung war ok 

Danke Dir, das scheint zu genügen.

LG

pah