Autor Thema: Feature request MQTT2_CLIENT  (Gelesen 622 mal)

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7540
Feature request MQTT2_CLIENT
« am: 17 September 2020, 21:13:32 »
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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22944
Antw:Feature request MQTT2_CLIENT
« Antwort #1 am: 17 September 2020, 22:59:42 »
Bevor ich das einbaue: warum genau braucht man das?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11906
  • eigentlich eher "user" wie "developer"
Antw:Feature request MQTT2_CLIENT
« Antwort #2 am: 18 September 2020, 07:53:24 »
...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...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11906
  • eigentlich eher "user" wie "developer"
Antw:Feature request MQTT2_CLIENT
« Antwort #3 am: 18 September 2020, 08:14:36 »
...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).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7540
Antw:Feature request MQTT2_CLIENT
« Antwort #4 am: 18 September 2020, 09:05:14 »
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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22944
Antw:Feature request MQTT2_CLIENT
« Antwort #5 am: 18 September 2020, 20:42:55 »
Ich habe das Attribut disconnectAfter fuer MQTT2_CLIENT implementiert:
Zitat
if set, the connection will be closed after <seconds> of inactivity, and will be automatically reopened when sending a command.

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

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7540
Antw:Feature request MQTT2_CLIENT
« Antwort #6 am: 18 September 2020, 21:25:41 »
OK, Danke. Werden in den nächsten Tagen mal sehen, ob das wirkt.

LG

pah

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11906
  • eigentlich eher "user" wie "developer"
Antw:Feature request MQTT2_CLIENT
« Antwort #7 am: 18 September 2020, 21:53:00 »
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 :) .)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7540
Antw:Feature request MQTT2_CLIENT
« Antwort #8 am: 18 September 2020, 22:04:52 »
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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22944
Antw:Feature request MQTT2_CLIENT
« Antwort #9 am: 18 September 2020, 22:19:03 »
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.

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7540
Antw:Feature request MQTT2_CLIENT
« Antwort #10 am: 19 September 2020, 09:49:27 »
Bisher keine Nachbestellung, Lieferung war ok  ;D

Danke Dir, das scheint zu genügen.

LG

pah

 

decade-submarginal