MQTT2_SERVER und QoS

[arthur_dent_2015]

Moin zusammen,
ich habe mir ein Status Display (c't 18/2018) gebastelt welches über einen ESP8266 gesteuert wird. Über DOIF werden die einzelnen Dioden mit MQTT2_SERVER gesetzt. Wenn die Verbindung zum ESP abbricht zeigt das Display im Zweifelsfall falsche Stati an. Laut Commandref ist QoS 1 im MQTT2_SERVER implementiert, es steht nur nirgends wie man es einsetzt puplish -q 1 topic message funktioniert jedenfalls nicht. Ich habe schon etliche Möglichkeiten durchprobiert, keine hat funktioniert. Kann mir mal jemand verraten wie es geht? Und, ist QoS 1 überhaupt die Lösung für mein Problem? Wenn nein, was könnte die Lösung sein?
Danke & Gruß
Arthur

[rudolfkoenig]

Die verschiedenen QoS Stufen stehen fuer die Zustellsicherheit:
QoS 0: At most once delivery
QoS 1: At least once delivery
QoS 2: Exactly once delivery

Vermutlich willst du die retain Flag setzen, mit "set m2s publish -r topic value".

publish -r speichert in FHEM diesen Wert, und falls jemand nach dem Verbindungsaufbau dieses Topic abonniert, wird der letzte Wert gesendet.  Die Nachricht wird aber nicht mit dem Flag weitergegeben, das koennte man als Fehler werten.

[arthur_dent_2015]

Hallo Rudi,
wenn ich die Doku von MQ richtig verstanden habe, garantiert QoS 1 dass die Nachricht beim Client ankommt, sprich zwischengespeichert wird wenn keine Verbindung besteht. Retain speichert nur die letzte Nachricht an das topic zwischen. Bei 60 LED's hilft retain also nicht wirklich.
Wenn beides nicht die Lösung für mein Problem ist, hat jemand ne Idee wie ich 60 DOIF's mit checkall anwerfe, wenn der ESP wieder "present" ist? Ich seh den Wald für lauter Bäumen nicht....
Gruß
Arthur

[rudolfkoenig]

Hast du es mit retain getestet?
Wie sollen die Dioden gesetzt werden? Kannst du einen Beispiel nennen?

[arthur_dent_2015]

Ja, habe ich. Es wird definitiv nur die letzte message gespeichert. Die kommt dann aber auch an. Hier mal ein Beispiel DOIF:

Code Auswählen Erweitern


Internals:
   CFGFN     
   DEF        ([HM_Fensterkontakt_Az:state] eq "closed") ((set MQTT publish ledbar/lights 16,stop),(set MQTT publish ledbar/lights 16,0,10,0)) DOELSEIF ([HM_Fensterkontakt_Az:battery] ne "ok") ((set MQTT publish ledbar/lights 16,stop),(set MQTT publish ledbar/lights 16,blink,10,10,0)) DOELSE ((set MQTT publish ledbar/lights 16,stop),(set Mosquitto publish ledbar/lights 16,10,0,0))
   MODEL      FHEM
   NAME       StatusLED_16
   NR         1156
   NTFY_ORDER 50-StatusLED_16
   STATE      cmd_1
   TYPE       DOIF
   Helper:
     DBLOG:
       cmd:
         fhemlogDB:
           TIME       1537520108.61967
           VALUE      1
       cmd_event:
         fhemlogDB:
           TIME       1537520108.61967
           VALUE      StatusLED_16
       cmd_nr:
         fhemlogDB:
           TIME       1537520108.61967
           VALUE      1
       state:
         fhemlogDB:
           TIME       1537520108.61967
           VALUE      cmd_1
   READINGS:
     2018-09-21 10:55:08   cmd             1
     2018-09-21 10:55:08   cmd_event       StatusLED_16
     2018-09-21 10:55:08   cmd_nr          1
     2018-09-19 19:28:41   mode            enabled
     2018-09-21 10:55:08   state           cmd_1
   Regex:
   attr:
     cmdState:
     wait:
     waitdel:
   condition:
     0          ReadingValDoIf($hash,'HM_Fensterkontakt_Az','state') eq "closed"
     1          ReadingValDoIf($hash,'HM_Fensterkontakt_Az','battery') ne "ok"
   devices:
     0           HM_Fensterkontakt_Az
     1           HM_Fensterkontakt_Az
     all         HM_Fensterkontakt_Az
   do:
     0:
       0          (set MQTT publish ledbar/lights 16,stop),(set MQTT publish ledbar/lights 16,0,10,0)
     1:
       0          (set MQTT publish ledbar/lights 16,stop),(set MQTT publish ledbar/lights 16,blink,10,10,0)
     2:
       0          (set MQTT publish ledbar/lights 16,stop),(set Mosquitto publish ledbar/lights 16,10,0,0)
   helper:
     globalinit 1
     last_timer 0
     sleeptimer -1
     timerdev   
     timerevent
     timerevents
     timereventsState
     triggerDev
     DOIF_eventas:
       cmd_nr: 1
       cmd: 1
       cmd_event: StatusLED_16
       state: cmd_1
   internals:
   itimer:
   perlblock:
   readings:
     0           HM_Fensterkontakt_Az:state
     1           HM_Fensterkontakt_Az:battery
     all         HM_Fensterkontakt_Az:state HM_Fensterkontakt_Az:battery
   uiState:
   uiTable:
Attributes:
   do         always
   room       Status
   startup    sleep 4; set $SELF checkall


[rudolfkoenig]

Ja, habe ich. Es wird definitiv nur die letzte message gespeichert

Klar, ist ja auch so definiert, siehe http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc385349265
Funktioniert dein Vorhaben mit Mosquitto?
Werden fuer eine korrekte Darstellung nach dem Verbindungsaufbau beide Befehle (stop & 0,10,0) benoetigt? Falls ja, dann gehe ich von einem Firmwarefehler im Display aus.
Wieso werden im DOELSE Fall zwei unterschiedliche Instanzen (MQTT & Mosquitto) angesprochen?

Kannst du bitte einen "Fehlerhaften" reconnect mitschneiden? Dazu
- die drei auskommentierten Zeilen unter "Lowlevel debugging" in 00_MQTT2_SERVER aktivieren, und FHEM neu starten
- publish immer mit -r aufrufen
- "attr MQTT verbose 5" setzen

[arthur_dent_2015]

Funktioniert dein Vorhaben mit Mosquitto?

Da ich Mosquitto gerade entsorgt habe, keine Ahnung 

Werden fuer eine korrekte Darstellung nach dem Verbindungsaufbau beide Befehle (stop & 0,10,0) benoetigt? Falls ja, dann gehe ich von einem Firmwarefehler im Display aus.

Der stop cmd wird nur benötigt falls die LED vorher im blink oder fastblink war, daher sende ich ihn immer mit, könnt ja sein das....

Wieso werden im DOELSE Fall zwei unterschiedliche Instanzen (MQTT & Mosquitto) angesprochen?

ooooppppsss, Folge des Umstiegs auf MQTT2_SERVER, hab ich gepennt

Kannst du bitte einen "Fehlerhaften" reconnect mitschneiden? Dazu
- die drei auskommentierten Zeilen unter "Lowlevel debugging" in 00_MQTT2_SERVER aktivieren, und FHEM neu starten
- publish immer mit -r aufrufen
- "attr MQTT verbose 5" setzen

Setze ich mich heute Abend oder morgen mal ran. Da müssen 60 DOIF's angepasst werden....

Gebe es eine Möglichkeit die client ID's mit online / offline als reading zur Verfügung zu stellen?

[rudolfkoenig]

Gebe es eine Möglichkeit die client ID's mit online / offline als reading zur Verfügung zu stellen?

Ist nicht so einfach, welche Meldungen meinst du genau?

[arthur_dent_2015]

Beim connect eine clients am MQ meldet dieser sich ja mit einem Namen, in meinem Fall "ESP8266 client" (blöd wegen Leerzeichen, ist aber default im c't Sketch und lässt sich leicht ändern), und dem topic an. Sprich, MQ müsste diesen Namen kennen. Aus dem Namen ein reading generieren und mit online füllen und beim disconnect auf offline setzen.
Ich hab lowlevel debugging mal aktiviert und manuell ein paar mal publish -r abgesetzt, im Log ist davon nichts zu sehen... Der Server ist nur beim Start gesprächig, danach schreibt er nur noch ping requests ins Log.

Code Auswählen Erweitern


2018.09.21 16:48:32 5: (0)(4)MQTT(4)6(0)(15)(0)(14)ESP8266 Client(0)(13)ledbar/lights(0)(7)offline
2018.09.21 16:48:32 4: MQTT_192.168.2.143_49199 ESP8266 Client CONNECT V:4 keepAlive:15 LWT:ledbar/lights:offline [color=red]<<=== ich wüsste nicht dass ich irgendwo LWT gestzt habe!? [/color]
2018.09.21 16:48:32 2: sduino3: initialized. v3.3.3-dev_15.09.
2018.09.21 16:48:32 3: sduino3/init: enable receiver (XE)
2018.09.21 16:48:33 3: CUL_HM set Schalter_Az statusRequest
2018.09.21 16:48:33 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4584.
2018.09.21 16:48:33 3: CleanCar: Read callback: Error: read from http://www.clever-tanken.de:80 timed out
2018.09.21 16:48:33 4: Connection accepted from MQTT_192.168.2.143_49200
2018.09.21 16:48:34 5: (0)(6)MQIsdp(3)(2)(0)<(0)(19)mqtt_cdd8806.5c20b8
2018.09.21 16:48:34 4: MQTT_127.0.0.1_35234 mqtt_cdd8806.5c20b8 CONNECT V:3 keepAlive:60
2018.09.21 16:48:36 5: MQTT: dispatch ESP8266_Client:ledbar/lights:offline
2018.09.21 16:48:36 4: Connection closed for MQTT_192.168.2.143_49199: EOF
2018.09.21 16:48:36 3: CUL_HM set Schalter_Bad statusRequest
2018.09.21 16:48:36 4: Connection accepted from MQTT_192.168.2.143_49201
2018.09.21 16:48:37 4: Connection closed for MQTT_127.0.0.1_35234: EOF
2018.09.21 16:48:39 5: (0)(4)MQTT(4)6(0)(15)(0)(14)ESP8266 Client(0)(13)ledbar/lights(0)(7)offline
2018.09.21 16:48:39 4: MQTT_192.168.2.143_49200 ESP8266 Client CONNECT V:4 keepAlive:15 LWT:ledbar/lights:offline
2018.09.21 16:48:39 3: CUL_HM set Schalter_Ez statusRequest
2018.09.21 16:48:39 3: Jet_Laatzen: Read callback: Error: write to https://www.clever-tanken.de:443 timed out
2018.09.21 16:48:39 5: MQTT: dispatch ESP8266_Client:ledbar/lights:offline
2018.09.21 16:48:39 4: Connection closed for MQTT_192.168.2.143_49200: EOF
2018.09.21 16:48:40 5: (0)(4)MQTT(4)6(0)(15)(0)(14)ESP8266 Client(0)(13)ledbar/lights(0)(7)offline
2018.09.21 16:48:40 4: MQTT_192.168.2.143_49201 ESP8266 Client CONNECT V:4 keepAlive:15 LWT:ledbar/lights:offline
2018.09.21 16:48:41 4: Connection accepted from MQTT_127.0.0.1_35436
2018.09.21 16:48:42 3: CUL_HM set Schalter_Flur statusRequest
2018.09.21 16:48:42 5: (0)(6)MQIsdp(3)(2)(0)<(0)(19)mqtt_cdd8806.5c20b8
2018.09.21 16:48:42 4: MQTT_127.0.0.1_35436 mqtt_cdd8806.5c20b8 CONNECT V:3 keepAlive:60
2018.09.21 16:48:42 3: PCA301 Unknown device 0384EB, please define it
2018.09.21 16:48:42 4: Connection accepted from MQTT_192.168.2.143_49202
2018.09.21 16:48:42 5: MQTT: dispatch ESP8266_Client:ledbar/lights:offline
2018.09.21 16:48:42 4: Connection closed for MQTT_192.168.2.143_49201: EOF
2018.09.21 16:48:42 5: (0)(4)MQTT(4)6(0)(15)(0)(14)ESP8266 Client(0)(13)ledbar/lights(0)(7)offline
2018.09.21 16:48:42 4: MQTT_192.168.2.143_49202 ESP8266 Client CONNECT V:4 keepAlive:15 LWT:ledbar/lights:offline
2018.09.21 16:48:42 5: (138)e(0)*/SmartHome/Wetter/Kuehlschrank/temperature(2)(0)'/SmartHome/Wetter/Kuehlschrank/humidity(2)(0)./SmartHome/Wetter/Thermo_Sz_aussen/temperature(2)(0)+/SmartHome/Wetter/Thermo_Sz_aussen/humidity(2)(0)$/SmartHome/Wetter/Thermo_Sz/humidity(2)(0)'/SmartHome/Wetter/Thermo_Sz/temperature(2)(0)'/SmartHome/Wetter/Thermo_Wz/temperature(2)(0)'/SmartHome/Wetter/Thermo_Az/temperature(2)(0)(/SmartHome/Wetter/Thermo_Bad/temperature(2)(0)+/SmartHome/Wetter/Thermo_Balkon/temperature(2)(0)$/SmartHome/Wetter/Thermo_Wz/humidity(2)(0)%/SmartHome/Wetter/Thermo_Bad/humidity(2)(0)(/SmartHome/Wetter/Thermo_Balkon/humidity(2)(0)$/SmartHome/Wetter/Thermo_Az/humidity(2)(0)(31)/SmartHome/Somfy/Roll1/position(2)(0)(31)/SmartHome/Somfy/Roll2/position(2)(0)*/SmartHome/Transmitter/mapleCUN1/Teststate(2)(0)"/SmartHome/Transmitter/hmusb/state(2)
2018.09.21 16:48:42 4: MQTT_127.0.0.1_35436 mqtt_cdd8806.5c20b8 SUBSCRIBE
2018.09.21 16:48:42 4:   topic:/SmartHome/Wetter/Kuehlschrank/temperature qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Wetter/Kuehlschrank/humidity qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Wetter/Thermo_Sz_aussen/temperature qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Wetter/Thermo_Sz_aussen/humidity qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Wetter/Thermo_Sz/humidity qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Wetter/Thermo_Sz/temperature qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Wetter/Thermo_Wz/temperature qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Wetter/Thermo_Az/temperature qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Wetter/Thermo_Bad/temperature qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Wetter/Thermo_Balkon/temperature qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Wetter/Thermo_Wz/humidity qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Wetter/Thermo_Bad/humidity qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Wetter/Thermo_Balkon/humidity qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Wetter/Thermo_Az/humidity qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Somfy/Roll1/position qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Somfy/Roll2/position qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Transmitter/mapleCUN1/Teststate qos:2
2018.09.21 16:48:42 4:   topic:/SmartHome/Transmitter/hmusb/state qos:2
2018.09.21 16:48:42 3: PCA301 Unknown device 0451DB, please define it
2018.09.21 16:48:43 5: (0)(2)(0)(13)ledbar/lights(0)
2018.09.21 16:48:43 4: MQTT_192.168.2.143_49202 ESP8266 Client SUBSCRIBE
2018.09.21 16:48:43 4:   topic:ledbar/lights qos:0
2018.09.21 16:48:43 3: CUL_HM set Schalter_Kueche statusRequest
2018.09.21 16:48:43 1: PERL WARNING: Use of uninitialized value $dblogname in concatenation (.) or string at ./FHEM/93_DbRep.pm line 1365.
2018.09.21 16:48:43 1: PERL WARNING: Use of uninitialized value $dbconn in concatenation (.) or string at ./FHEM/93_DbRep.pm line 1372.
2018.09.21 16:48:43 2: DbRep fhemlogRep - Can't connect to data source 'dbi:' because I can't work out what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix and the DBI_DRIVER env var is not set) at ./FHEM/93_DbRep.pm line 1372.

2018.09.21 16:48:43 2: DbRep fhemlogRep - DB connect failed. Make sure credentials of database /opt/fhem/log/fhemlog.db are valid and database is reachable.
2018.09.21 16:48:44 3: CUL_HM set Schalter_Sz statusRequest
2018.09.21 16:48:45 3: CUL_HM set Schalter_Wz statusRequest
2018.09.21 16:48:47 4: PRESENCE (FritzBox) - rescheduling next check in 900 seconds
2018.09.21 16:48:55 4: HMLAN_ack: timeout - clear queue
2018.09.21 16:48:58 5:
2018.09.21 16:48:58 4: MQTT_192.168.2.143_49202 ESP8266 Client PINGREQ
2018.09.21 16:48:58 3: Watchdog BM_HM_Sz_wd triggered
2018.09.21 16:49:00 3: SGS7_WL absent
2018.09.21 16:49:13 5:
2018.09.21 16:49:13 4: MQTT_192.168.2.143_49202 ESP8266 Client PINGREQ
2018.09.21 16:49:14 3: Events from device HM_BM_Balkon:brightness: 168
2018.09.21 16:49:15 3: CUL_HM set HM_Sensor1 statusRequest
2018.09.21 16:49:26 3: Lichtsensor brightness: 2397.07
2018.09.21 16:49:28 5:
2018.09.21 16:49:28 4: MQTT_192.168.2.143_49202 ESP8266 Client PINGREQ
2018.09.21 16:49:33 3: Events from device BM_HM_Sz:brightness: 83
2018.09.21 16:49:42 5:
2018.09.21 16:49:42 4: MQTT_127.0.0.1_35436 mqtt_cdd8806.5c20b8 PINGREQ
2018.09.21 16:49:43 5:
2018.09.21 16:49:43 4: MQTT_192.168.2.143_49202 ESP8266 Client PINGREQ
2018.09.21 16:49:58 5:
2018.09.21 16:49:58 4: MQTT_192.168.2.143_49202 ESP8266 Client PINGREQ
2018.09.21 16:50:13 5:
2018.09.21 16:50:13 4: MQTT_192.168.2.143_49202 ESP8266 Client PINGREQ
2018.09.21 16:50:28 5:
2018.09.21 16:50:28 4: MQTT_192.168.2.143_49202 ESP8266 Client PINGREQ
2018.09.21 16:50:42 5:
2018.09.21 16:50:42 4: MQTT_127.0.0.1_35436 mqtt_cdd8806.5c20b8 PINGREQ
2018.09.21 16:50:43 5:
2018.09.21 16:50:43 4: MQTT_192.168.2.143_49202 ESP8266 Client PINGREQ
2018.09.21 16:50:58 5:
2018.09.21 16:50:58 4: MQTT_192.168.2.143_49202 ESP8266 Client PINGREQ
2018.09.21 16:51:13 5:
2018.09.21 16:51:13 4: MQTT_192.168.2.143_49202 ESP8266 Client PINGREQ
2018.09.21 16:51:28 5:
2018.09.21 16:51:28 4: MQTT_192.168.2.143_49202 ESP8266 Client PINGREQ
2018.09.21 16:51:43 5:
2018.09.21 16:51:43 4: MQTT_192.168.2.143_49202 ESP8266 Client PINGREQ
2018.09.21 16:51:43 5:
2018.09.21 16:51:43 4: MQTT_127.0.0.1_35436 mqtt_cdd8806.5c20b8 PINGREQ
2018.09.21 16:51:46 3: Lichtsensor brightness: 3437.79
2018.09.21 16:51:58 5:
2018.09.21 16:51:58 4: MQTT_192.168.2.143_49202 ESP8266 Client PINGREQ
2018.09.21 16:52:13 5:
2018.09.21 16:52:13 4: MQTT_192.168.2.143_49202 ESP8266 Client PINGREQ

Die DEF's von meinem MQTT2_SERVER sehen so aus:

Code Auswählen Erweitern


Internals:
   CFGFN     
   CONNECTS   6
   DEF        1883 global
   FD         50
   NAME       MQTT
   NR         1201
   PORT       1883
   STATE      Initialized
   TYPE       MQTT2_SERVER
   Helper:
     DBLOG:
       nrclients:
         fhemlogDB:
           TIME       1537541322.56142
           VALUE      2
       state:
         fhemlogDB:
           TIME       1537542021.52544
           VALUE      publish /SmartHome/Wetter/Thermo_Bad/humidity 65
   READINGS:
     [color=red]2018-09-21 16:51:36   RETAIN          {"ledbar/lights":"0,10,0,0"}[/color]
     2018-09-21 16:48:42   nrclients       2
     2018-09-21 16:47:44   state           Initialized
   clients:
     MQTT_127.0.0.1_35436 1
     MQTT_192.168.2.143_49202 1
   retain:
     ledbar/lights:
       ts         1537541496.54682
       val        0,10,0,0
Attributes:
   room       MQTT
   verbose    5


[rudolfkoenig]

Aus dem Namen ein reading generieren und mit online füllen und beim disconnect auf offline setzen.

Sowas wird mit MQTT ueber LWT realisiert: das Geraet setzt bei CONNECT LWT auf topic:offline, und nach Anmelden erfolgt ein PUBLISH fuer topic:online. Die Verwendung der clientId ist nicht MQTT konform, da es bei subscribe nicht spezifiziert werden kann, und nicht Teil der publish-Daten ist. Mit einem "normalen" MQTT-Server muss die Unterscheidung anhand topic passieren.

Die Auswertung in FHEM ist trivial: man setzt in MQTT2_SERVER autocreate, damit wird pro verbundenes MQTT-Geraet ein MQTT2_DEVICE erzeugt, und bei jeder neuen Nachricht ein passendes Reading angelegt, inkl. LWT. Ohne autocreate muss man das MQTT2_DEVICE selbst anlegen, und readingList selbst pflegen. Ich bin nicht ueberzeugt eine voll funktionsfaehige Alternative ohne MQTT2_DEVICE anzubieten.

Dein ledbar setzt zwar LWT, aber PUBLISH nach CONNECT sehe ich nicht, das waere ein Bug im Firmware. Das koennte man zwar mit MQTT2_SERVER umgehen, aber das waere nicht MQTT konform (s.o.), und ich will niemanden an MQTT2_SERVER binden Abgesehen davon muesste ich einen ReadingNamen ueberlegen, was kein MQTT Geraet als topic senden kann, und fuer alle "normalen" MQTT Geraete waere die Information doppelt vorhanden.

publish -r abgesetzt, im Log ist davon nichts zu sehen...

Das habe ich jetzt geaendert.

[arthur_dent_2015]

Hallo Rudi,
MQTT2_DEVICE hatte ich nicht auf dem Schirm. Das entspricht so in etwa ja meiner Idee, nur in einem anderen device. MQTT2_SERVER scheint aber noch Probleme mit dem autocreate zu haben. Für meinen ESP wurde ein device angelegt, für meinen Node Red client aber nicht.

Code Auswählen Erweitern


2018.09.21 21:47:37 5: MQTT: dispatch autocreate:ESP8266_Client:ledbar/lights:offline
2018.09.21 21:47:38 2: autocreate: define MQTT2_ESP8266_Client MQTT2_DEVICE ESP8266_Client
2018.09.21 21:47:38 2: autocreate: define FileLog_MQTT2_ESP8266_Client FileLog ./log/MQTT2_ESP8266_Client-%Y.log MQTT2_ESP8266_Client
2018.09.21 21:47:38 4: Connection closed for MQTT_192.168.2.143_49244: EOF

2018.09.21 21:47:42 4: Connection closed for MQTT_127.0.0.1_52594: EOF
2018.09.21 21:47:42 5: (0)(4)MQTT(4)6(0)(15)(0)(14)ESP8266 Client(0)(13)ledbar/lights(0)(7)offline
2018.09.21 21:47:42 4: MQTT_192.168.2.143_49245 ESP8266 Client CONNECT V:4 keepAlive:15 LWT:ledbar/lights:offline
2018.09.21 21:47:43 4: Connection accepted from MQTT_192.168.2.143_49246

2018.09.21 21:47:45 5: (0)(4)MQTT(4)6(0)(15)(0)(14)ESP8266 Client(0)(13)ledbar/lights(0)(7)offline
2018.09.21 21:47:45 4: MQTT_192.168.2.143_49246 ESP8266 Client CONNECT V:4 keepAlive:15 LWT:ledbar/lights:offline
2018.09.21 21:47:45 4: Closing second connection for ESP8266 Client/192.168.2.143 without lwt
2018.09.21 21:47:45 4: Connection closed for MQTT_192.168.2.143_49245: EOF

2018.09.21 21:47:47 5: MQTT: dispatch autocreate:ESP8266_Client:ledbar/lights:offline
2018.09.21 21:47:47 4: Connection closed for MQTT_192.168.2.143_49246: EOF
2018.09.21 21:47:47 3: PCA301 Unknown device 0384EB, please define it
2018.09.21 21:47:48 4: Connection accepted from MQTT_192.168.2.143_49247

2018.09.21 21:47:48 5: (0)(4)MQTT(4)6(0)(15)(0)(14)ESP8266 Client(0)(13)ledbar/lights(0)(7)offline
2018.09.21 21:47:48 4: MQTT_192.168.2.143_49247 ESP8266 Client CONNECT V:4 keepAlive:15 LWT:ledbar/lights:offline

2018.09.21 21:47:50 5: (0)(2)(0)(13)ledbar/lights(0)
2018.09.21 21:47:50 4: MQTT_192.168.2.143_49247 ESP8266 Client SUBSCRIBE
2018.09.21 21:47:50 4:   topic:ledbar/lights qos:0

2018.09.21 21:47:53 4: Connection accepted from MQTT_127.0.0.1_52722

2018.09.21 21:47:54 5: (0)(6)MQIsdp(3)(2)(0)<(0)(8)Node_Red
2018.09.21 21:47:54 4: MQTT_127.0.0.1_52722 Node_Red CONNECT V:3 keepAlive:60
2018.09.21 21:47:54 5: (136)S(0)*/SmartHome/Wetter/Kuehlschrank/temperature(2)
2018.09.21 21:47:54 4: MQTT_127.0.0.1_52722 Node_Red SUBSCRIBE
2018.09.21 21:47:54 4:   topic:/SmartHome/Wetter/Kuehlschrank/temperature qos:2
2018.09.21 21:47:54 5: (136)T(0)'/SmartHome/Wetter/Kuehlschrank/humidity(2)
2018.09.21 21:47:54 4: MQTT_127.0.0.1_52722 Node_Red SUBSCRIBE
2018.09.21 21:47:54 4:   topic:/SmartHome/Wetter/Kuehlschrank/humidity qos:2
2018.09.21 21:47:54 5: (136)U(0)./SmartHome/Wetter/Thermo_Sz_aussen/temperature(2)
2018.09.21 21:47:54 4: MQTT_127.0.0.1_52722 Node_Red SUBSCRIBE
2018.09.21 21:47:54 4:   topic:/SmartHome/Wetter/Thermo_Sz_aussen/temperature qos:2
2018.09.21 21:47:54 5: (136)V(0)+/SmartHome/Wetter/Thermo_Sz_aussen/humidity(2)


Ist ganz witzig dass meine Thermometer mit QoS 2 an Node Red senden obwohl ich das nirgends angebe und es im MQTT2_SERVER ja auch nicht implementiert ist...
Ich bin trotzdem wieder zu Mosquitto zurück gegangen und teste jetzt damit.
Gruß
Arthur

[rudolfkoenig]

MQTT2_SERVER scheint aber noch Probleme mit dem autocreate zu haben. Für meinen ESP wurde ein device angelegt, für meinen Node Red client aber nicht.

Das ist z.Zt. "works as designed": dein Node-Red Client will nur zuhoeren (SUBSCRIBE), und angelegt wird erst beim PUBLISH. Ein set mit passenden Topic wird aber an dem Node-Red Client weitergeschickt.

[psycho160]

Die verschiedenen QoS Stufen stehen fuer die Zustellsicherheit:
QoS 0: At most once delivery
QoS 1: At least once delivery
QoS 2: Exactly once delivery

Vermutlich willst du die retain Flag setzen, mit "set m2s publish -r topic value".

publish -r speichert in FHEM diesen Wert, und falls jemand nach dem Verbindungsaufbau dieses Topic abonniert, wird der letzte Wert gesendet.  Die Nachricht wird aber nicht mit dem Flag weitergegeben, das koennte man als Fehler werten.

Hallo, möchte hier nochmal nachhacken, in der Commandref ist wirklich nichts beschrieben wie ich etwas mit qos 1 publishe?!?

Ich schicke über ein MQTT2_DEVICE

Code Auswählen Erweitern

haus1_offen:noArg fhem/status/window/and_haus_unten:r offen

das per MQTT2_CLIENT die Nachricht an meinen Broker sendet. Soweit sogut. Was aber wenn mein Broker gerade nicht läuft oder nicht erreichbar ist? Die Nachrichten kommen jedenfalls nicht an wenn ich den broker wieder starte...

[rudolfkoenig]

Da die aktuelle MQTT2 Implementation auf TCP/IP angewiesen ist, besteht zwischen QoS 0 und QoS 1 kein Unterschied: TCP meldet selbst, wenn die Daten nicht abgeliefert werden koennen, und es wird ein disconnected Status gesetzt plus ein Event generiert.

Wenn nach broker restart die Nachrichten nicht ankommen, liegt das Problem anderswo, und QoS 1 wuerde nichts daran aendern.
Wenn das Problem reproduzierbar ist, dann haette ich gerne eine Anleitung zum Nachstellen.

[psycho160]

Ok ja ob es reproduzierbar ist kann ich nicht sagen aber was ich versuche:

1. Fhem Installation:
MQTT2_DEVICE -> MQTT2_Client (Verbunden zur 2. Fhem installation)

2.Fhem Installation:
MQTT2_SERVER -> MQTT2_DEVICE

Im normalbetrieb (alles online) kommen bei der 2. Fhem Installation alle Meldungen an ->OK
Drehe ich jetzt die Netzwerkkommunikation zwischen 1. FHEM und 2. FHEM ab und Publishe im 1. FHEM etwas über mein MQTT2_DEVICE. Der MQTT2_Client vom 1. sagt mich dann auch "disconnected". Passt soweit.

Dann drehe ich das Netzwerk wieder auf, alles geht auf "opened" aber das zuvor gepublishte kommt nicht bei dem MQTT2_SERVER der 2.FHEM Installation an.


Zum Besseren Verständnis:
Habe 2 Häuser und das eine ist mit LTE angebunden und da bricht öfters mal die Verbindung ab. Wenn gerade in diesem Moment eine Mqtt Nachricht kommt, geht die verloren...

[rudolfkoenig]

Dann drehe ich das Netzwerk wieder auf, alles geht auf "opened" aber das zuvor gepublishte kommt nicht bei dem MQTT2_SERVER der 2.FHEM Installation an.

MQTT2_CLIENT implementiert keine Warteschlange, und soweit ich weiss, auch andere MQTT-Clients machen das nicht. Mir ist kein Mechanismus bekannt, der fuer FHEM diese Funktionalitaet bereitstellt. Es waere mAn eine sinnvolle Erweiterung, weiss aber nicht wann/ob ich dazu komme.

[psycho160]

Ok danke für die Info mal, dann brauch ich nicht weiter zu debuggen. War mir eben wegen dem QoS nicht sicher ob ich was falsch mache.

Dachte QoS 1 stellt sicher das meine Nachricht ankommt, darum war ich verwirrt. Wäre aber auf jeden Fall toll wenn es sowas mal geben würde. Bis dahin kann ich nur hoffen, dass nicht ein Einbrecher genau in dem Moment kommt, wo der Link weg ist 

[rudolfkoenig]

Ich habe die Spec nochmal gelesen, und da steht:

When a Client reconnects with CleanSession set to 0, both the Client and Server MUST re-send any unacknowledged PUBLISH Packets (where QoS > 0)

insofern ist das Fehlen der Warteschlage bei QoS 1 ein Fehler. Es richtig zu loesen macht die Sache kompliziert, weil alle Messages persistent gespeichert werden muessen, was auch auf die Performance auswirkt. Vlt kann man mit einer unvolkommenen Loesung anfangen.

[psycho160]

Es richtig zu loesen macht die Sache kompliziert, weil alle Messages persistent gespeichert werden muessen, was auch auf die Performance auswirkt.

Kommt auf die Anzahl der generierten Messages an..

Vlt kann man mit einer unvolkommenen Loesung anfangen.

Vl. ja per attr dem Client sagen wieviele Messages er maximal speichern soll, die könnten ja in den Internals abgelegt werden (ja ich weiß das ist nicht 100% persistent aber mal ein anfang)
eventuell auch auf topic basis, das er nur die "wichtigen" speichert

[rudolfkoenig]

Ich habe jetzt eine erste Version von QoS=1 in MQTT2_CLIENT implementiert:

qosMaxQueueLength <number>
if set to a nonzero value, messages are published with QoS=1, and are kept in a memory-only buffer until acknowledged by the server. If there is no connection to the server, up to <number> messages are queued, and resent when the connection is esablished.

[psycho160]

CommandRef hört sich schon mal vielversprechend an. werds gleich testen.

[Beta-User]

@Rudi:Habe mir die Änderung mal angesehen, das ist ja im Prinzip sowas ähnliches wie die mit ACK versendeten Messages bei MySensors.

Mein Verständnis von Zeile 438ff ist, dass da einfach jede neue Message angehängt wird, bis eben die Queue voll ist, (erst) der überschießende Rest wird verworfen.

Da haben wir m.E. gleich zwei Probleme:
1. Eigentlich sollte eine neue Info die alte überschreiben, wenn sie auf denselben Topic geht, oder? (Vergleichbares macht https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/00_MYSENSORS.pm#L846). (OT: Das ist übrigens ein gutes Argument, um das "one-json-for-all-über einen einzigen Topic"-Design mancher Clients zu kritisieren, das mir vom Bauchgefühl her schon immer irgendwie suspekt war...)

2. Dem Gefühl nach sollten von den so vorgefilterten, nicht überschriebenen Messages immer die ältesten gelöscht werden und nicht die jüngsten verworfen, das ganze also eine Art rollierendes System sein. Oder gibt es da eine irgendwie geartete Vorgabe?

(Sorry, ist schon klar, dass das zusätzliche Last ist, v.a., wenn jemand große Daten an viele Topics zu verwalten hat und meint, eine lange Queue sei super...).

[psycho160]

Erster Test erfolgreich, damit ist vorerst mal die Zustellung bei mir sichergestellt.

.... Eigentlich sollte eine neue Info die alte überschreiben, wenn sie auf denselben Topic geht, oder?  ...

Stimmt, ist ein gutes Argument. Könnte aber auch sein, dass die Messages "dazwischen" auch relevant sind, wenn der Empfänger sie weiterverarbeitet.. Denke da z.B an eine Türe die aufgemacht wird -> Alarm auslösen sollte -> und wider zugemacht wird. Dann kommt beim Server aber nur "zu" an, was wieder etwas verschleiern würde... Nur so ein Gedanke

[Beta-User]

Stimmt, ist ein gutes Argument. Könnte aber auch sein, dass die Messages "dazwischen" auch relevant sind, wenn der Empfänger sie weiterverarbeitet.. Denke da z.B an eine Türe die aufgemacht wird -> Alarm auslösen sollte -> und wider zugemacht wird. Dann kommt beim Server aber nur "zu" an, was wieder etwas verschleiern würde... Nur so ein Gedanke

An sich ist der Gedanke richtig, aber:

MQTT-mäßig meine ich, dass die Alarmierung bei abgebrochener Verbindung eine Sache ist, die mit dem Stichwort "LWT" zu lösen sein sollte. Denn andererseits hilft es ja nichts, wenn man ggf. erst Stunden oder Tage später von einem Problem erfährt, das gar nicht mehr relevant ist.

Aber da sind wir recht schnell bei der Frage, für was MQTT als Protokoll Sinn macht und für was nicht... MMn. ist es eher zur leichtgewichtigen Datenübertragung und langfristigen Überwachung geeignet, und eher weniger im Rahmen einer Alarmanlage oä. Dies vor allem wegen der prinzipbedingten Lücken, die sich spätestens dann ergeben, wenn der Client (FHEM oder ein anderer) oder eventuell auch nur der Server (Broker) neu gestartet wird. Und bei Tasmota würde ich z.B. auch annehmen, dass der neue Status den alten überschreibt (sofern das Thema da derzeit überhaupt abgehandelt ist...?).

[psycho160]

MQTT-mäßig meine ich, dass die Alarmierung bei abgebrochener Verbindung eine Sache ist, die mit dem Stichwort "LWT" zu lösen sein sollte. Denn andererseits hilft es ja nichts, wenn man ggf. erst Stunden oder Tage später von einem Problem erfährt, das gar nicht mehr relevant ist.

Mit LWT wird aber nicht sichergestellt, das eine Message "ankommt". Darum gibt es ja QoS und QoS=1 besagt, ich will das meine Nachricht beim Broker ankommt, egal was passiert und wieviele Tage es dauert.

In meinem Fall ist es auch nicht direkt eine Alarmanalge, sondern nur das Status-Display. Aber um das geht es auch gar nicht, sondern die Implementierung von Rudi oder anderen sollte sich an die Specs von MQTT halten.

Für mich ist ja das was mit dem aktuellen Update jetzt dazu gekommen ist schon super und deckt nun (zumindest meine) Anforderung ab und wäre schön wenn auch andere noch davon profitieren.

[Beta-User]

Hmm, habe zwar auf die Schnelle nicht die Spec gefunden, sondern "nur" https://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages/, aber nach dem hast du recht, dass auch die "Zwischenmessages" zu queuen sein sollten:

The client must get all messages from a certain topic, even if it is offline. You want the broker to queue the messages for the client and deliver them as soon as the client is back online.

Es ist ausdrücklich von einem "certain topic" die Rede.

Daher stellt sich erst bei Resourcenlimitierung die Frage, wie gedroppt werden sollte, was dann ggf. ein komplexeres Thema wird (hier meine ich, dass neuer älter verdrängen sollte und dann bei "Ausgehen der topics" neuere ältere Topics verdrängen müßten, kann aber sein, dass es dazu auch abweichende Doku gibt...)

Was LWT angeht, ist klar, dass das eine etwas andere Frage ist, das sagt nur "Huston, wir haben..." und kann/soll dazu dienen, Schwachstellen (mehr oder weniger zeitnah) zu identifizieren.

[psycho160]

Daher stellt sich erst bei Resourcenlimitierung die Frage, wie gedroppt werden sollte, was dann ggf. ein komplexeres Thema wird (hier meine ich, dass neuer älter verdrängen sollte und dann bei "Ausgehen der topics" neuere ältere Topics verdrängen müßten, kann aber sein, dass es dazu auch abweichende Doku gibt...)

Ich hab es jetzt noch nicht genauer recherchiert in meinem System, aber ab wann sprechen wir denn von einer "Resourcenlimitierung"? Am Beispiel von einem Pi3 oder 4 denke ich müssen da schon einige 100 oder 1000 Messages in der Queue sein, dass sich hier performancemäßig etwas bemerkbar macht... Oder liege ich da falsch?

Ist vermutlich noch nicht real life getestet(tm) 

Nur so ne Idee:

Code Auswählen Erweitern

qosMaxQueueLength <topic1>:<number1> <topic2>:<number2>

Alles was nicht explizit in "qosMaxQueueLength" definiert wird als QoS=0 behandeln... Falls man ein MQTT Device hat was "spammt" kann man somit einen Überlauf abfangen

[Beta-User]

Na ja, wenn ich das heutige Attribut richtig verstanden habe, legt der user die Limitierung fest. Liegt die bei 10 oder 100 messages, kann es mit der Zeit schon eng werden, ohne dass der Server an sich irgendwie ins Schwitzen kommt. Auch  10000 Messages sind uU. schnell erreicht, da manche via MQTT_GENERAL_BRDIGE schlicht alle Events an einen externen Broker pusten. Hat man "gesprächige" Devices wie (z.B.) den ebus, Shelly@MQTT oder manche Wetterdienste, kann das schnell erreicht sein. Und dann gibt es noch "Spezialfälle", bei denen Bilddaten oder Logfiles via MQTT übertragen werden, bei denen größere Datenmengen zusammenkommen können (very un-mqtt-like imo, aber es wird eben gemacht oder zumindest angedacht.)

Ob die QoS über das  IO einstellen können sollte? Klingt für mich sehr kompliziert, und das ganze System für relativ wenige Anwendungsfälle mit vielen Prüfungen zu belasten, erscheint mir nicht optimal (obwohl es evtl. die "perfektere" Lösung wäre).
Der Weg, das über das einzelne Device einzustellen ist mit da irgendwie sympatischer; ist aber nur mal wieder mein "Bauchgefühl".

@Rudi:
Da wir es grade von MQTT_GENERAL_BRDIGE hatten: das erlaubt (auch) das Setzen der QoS-Flags. Bevor ich jetzt lange Code-Analysen anstelle die Frage, ob das von CLIENT irgendwie beachtet wird? (Wenn nein, sollte man dort ggf. die Doku anpassen; ich bin mir aber nicht sicher, ob 00_MQTT.pm sich da irgendwie anders verhält und das beachtet, _ glaube_ es aber eher nicht... Jedenfalls habe ich auf die Schnelle mit dem Suchwort qos via Trac nichts gefunden, was wie eine Queue@MySensors aussähe, das Ding geht also auch einfach von einer bestehenden Verbindung aus und schiebt es wohin (?), wenn diese nicht besteht...)
Ansonsten: in MQTT2_DEVICE ist mir zum Thema QoS bisher nichts aufgefallen, aber tendenziell würde ich annehmen, dass wenn, dann das Setzen des Flags eigentlich am besten bei der jeweiligen publish-Anweisung aufgehoben wäre (ähnlich :r)?

(Bin mir aber insgesamt unsicher; das ganze ist mal wieder sehr komplex, es wird vermutlich eine Unmenge Fragen dazu geben (je feiner man das einstellen kann, desto mehr) und  kaum jemand wird es wirklich brauchen... Aber wie hatte es neulich "jemand" formuliert: Man kann nie wissen, was am Ende rauskommt; plötzlich hat man doch ein weiteres IO-Modul für einen Client-TYPE usw, usf.. Daher wollte ich einfach meine Gedanken dazu mal aufschreiben.)

[rudolfkoenig]

Eigentlich sollte eine neue Info die alte überschreiben, wenn sie auf denselben Topic geht, oder?

Das ist mAn anwendungsspezifisch. Ich will die Sache nicht verkomplizieren, bevor ich konkrete Hinweise darauf habe, dass es noetig ist. Wer das Problem nicht mit qosMaxQueueLength 10000 loesen kann (entspricht ca 4MB), der moege sich mit Details melden.


MQTT_GENERAL_BRIDGE kann (genauso wie MQTT2_DEVICE) nur das retain Flag weitergeben.
In MQTT2_SERVICE habe ich nicht vor QoS=1 zu implementieren, da ich damit fuer alle unsauber beendete Clients eine Schlange speichern muesste. Ich behaupte, dass QoS=1 nicht fuer beliebig langes Zwischenspeichern bei Verbindungsproblemen gedacht ist, sondern zum Vermeiden von Paketverlusten bei UDP.

[psycho160]

Hallo,

seit der letzten Änderung (wo QoS 1 von Rudi implementiert wurde) scheint sich mein MQTT2_Client nach einiger Zeit "aufzuhängen". (siehe Log)

Mein Setup läuft einige Zeit, aber nach ca. paar Stunden sendet mein MQTT2_Client nichts mehr. Im Log steht discarding DISCONNECT (224)(0). HAt das was damit zu tun?

Man sieht auch im Log, dass meine Verbindung sehr instabil ist, aber das sollte doch für so geringe Datenmengen nicht relevant sein. Vermutlich mag der Client keine "unsauber" getrennten Verbindungen? Wenn ich FHEM neu starte läuft wieder alles.

Code Auswählen Erweitern

2020.07.02 06:19:21 1: 192.168.1.3:1883 reappeared (and_mqtt_client)
2020.07.02 06:20:11 1: 192.168.1.3:1883 disconnected, waiting to reappear (and_mqtt_client)
2020.07.02 06:20:14 1: 192.168.1.3:1883 reappeared (and_mqtt_client)
2020.07.02 06:21:02 1: 192.168.1.3:1883 disconnected, waiting to reappear (and_mqtt_client)
2020.07.02 06:21:03 1: 192.168.1.3:1883 reappeared (and_mqtt_client)


2020.07.02 06:21:52 1: 192.168.1.3:1883 disconnected, waiting to reappear (and_mqtt_client)
2020.07.02 06:21:53 1: 192.168.1.3:1883 reappeared (and_mqtt_client)
2020.07.02 06:22:43 1: 192.168.1.3:1883 disconnected, waiting to reappear (and_mqtt_client)
2020.07.02 06:22:43 5: and_mqtt_client: discarding DISCONNECT (224)(0)
2020.07.02 06:22:43 5: HttpUtils url=http://192.168.1.3:1883/
2020.07.02 06:22:43 4: IP: 192.168.1.3 -> 192.168.1.3
2020.07.02 06:22:46 5: and_mqtt_client: sending CONNECT (16)(29)(0)(6)MQIsdp(3)(2)(0)(30)(0)(15)and_mqtt_client
2020.07.02 06:22:46 5: SW: 101d00064d51497364700302001e000f616e645f6d7174745f636c69656e74
2020.07.02 06:22:46 1: 192.168.1.3:1883 reappeared (and_mqtt_client)
2020.07.02 06:23:15 3: MQTT2_DEVICE set mqtt_status_monitor and_water_on
2020.07.02 06:23:44 1: 192.168.1.3:1883 disconnected, waiting to reappear (and_mqtt_client)
2020.07.02 06:23:44 5: and_mqtt_client: discarding DISCONNECT (224)(0)
2020.07.02 06:23:44 5: HttpUtils url=http://192.168.1.3:1883/
2020.07.02 06:23:44 4: IP: 192.168.1.3 -> 192.168.1.3
2020.07.02 06:23:45 5: and_mqtt_client: sending CONNECT (16)(29)(0)(6)MQIsdp(3)(2)(0)(30)(0)(15)and_mqtt_client
2020.07.02 06:23:45 5: SW: 101d00064d51497364700302001e000f616e645f6d7174745f636c69656e74
2020.07.02 06:23:45 1: 192.168.1.3:1883 reappeared (and_mqtt_client)
2020.07.02 06:24:32 3: MQTT2_DEVICE set mqtt_status_monitor and_haus1_zu
2020.07.02 06:24:37 1: 192.168.1.3:1883 disconnected, waiting to reappear (and_mqtt_client)
2020.07.02 06:24:37 5: and_mqtt_client: discarding DISCONNECT (224)(0)
2020.07.02 06:24:37 5: HttpUtils url=http://192.168.1.3:1883/
2020.07.02 06:24:37 4: IP: 192.168.1.3 -> 192.168.1.3
2020.07.02 06:24:46 5: HttpUtils url=http://192.168.1.3:1883/
2020.07.02 06:24:46 4: IP: 192.168.1.3 -> 192.168.1.3
2020.07.02 06:24:46 5: and_mqtt_client: sending CONNECT (16)(29)(0)(6)MQIsdp(3)(2)(0)(30)(0)(15)and_mqtt_client
2020.07.02 06:24:46 5: SW: 101d00064d51497364700302001e000f616e645f6d7174745f636c69656e74
2020.07.02 06:24:46 1: 192.168.1.3:1883 reappeared (and_mqtt_client)
2020.07.02 06:25:35 1: 192.168.1.3:1883 disconnected, waiting to reappear (and_mqtt_client)
2020.07.02 06:25:35 5: and_mqtt_client: discarding DISCONNECT (224)(0)
2020.07.02 06:25:35 5: HttpUtils url=http://192.168.1.3:1883/
2020.07.02 06:25:35 4: IP: 192.168.1.3 -> 192.168.1.3
2020.07.02 06:25:37 5: and_mqtt_client: sending CONNECT (16)(29)(0)(6)MQIsdp(3)(2)(0)(30)(0)(15)and_mqtt_client
2020.07.02 06:25:37 5: SW: 101d00064d51497364700302001e000f616e645f6d7174745f636c69656e74
2020.07.02 06:25:37 1: 192.168.1.3:1883 reappeared (and_mqtt_client)
2020.07.02 06:25:38 5: and_mqtt_client: received RESERVED_0 (2)(0)(0) (2)(0)(0) (2)(0)(0) (2)(0)(0) (2)(0)(0) (2)(0)(0) (2)(0)(0) (2)(0)(0)
2020.07.02 06:25:38 1: M2: Unhandled packet RESERVED_0, disconneting and_mqtt_client
2020.07.02 06:25:38 5: and_mqtt_client: discarding DISCONNECT (224)(0)
2020.07.02 06:25:38 1: 192.168.1.3:1883 disconnected, waiting to reappear (and_mqtt_client)
2020.07.02 06:25:38 5: and_mqtt_client: received RESERVED_0
2020.07.02 06:25:38 1: M2: Unhandled packet RESERVED_0, disconneting and_mqtt_client
2020.07.02 06:25:38 5: and_mqtt_client: discarding DISCONNECT (224)(0)
2020.07.02 06:25:38 5: HttpUtils url=http://192.168.1.3:1883/
2020.07.02 06:25:38 4: IP: 192.168.1.3 -> 192.168.1.3
2020.07.02 06:25:40 5: and_mqtt_client: sending CONNECT (16)(29)(0)(6)MQIsdp(3)(2)(0)(30)(0)(15)and_mqtt_client
2020.07.02 06:25:40 5: SW: 101d00064d51497364700302001e000f616e645f6d7174745f636c69656e74
2020.07.02 06:25:40 1: 192.168.1.3:1883 reappeared (and_mqtt_client)

List meines IODevices:

Code Auswählen Erweitern

Internals:
   BUF          
   DEF        192.168.1.3:1883
   DeviceName 192.168.1.3:1883
   FD         16
   FUUID      5ef9ab6c-f33f-f34f-8edf-3f2fc62221cd4c73
   NAME       and_mqtt_client
   NR         70
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   and_mqtt_client
   connecting 2
   lastMsgTime 1593663938.25785
   nextOpenDelay 5
   qosCnt     12
   qosMaxQueueLength 10
   READINGS:
     2020-06-30 11:52:31   lastPublish     fhem/status/light/waterpump:waterpump
     2020-07-02 06:26:37   state           opened
   qosQueue:
Attributes:
   qosMaxQueueLength 10
   room       xSystem->MQTT
   verbose    5

[psycho160]

Konnte das Problem nun beheben, indem ich bei dem MQTT2_Client (der die instabile LTE Anbindung hat) nur jene Topics aboniere die wirklich nötig sind und nicht alle was der Server publisht.
Vermutlich hat sich der Client dann immer mal verabschiedet wenn er so viele Messages bekam (aufgrund von # als default). Weiß aber nicht ob das vor der Erweiterung von Rudi auch schon so war oder nicht, auf jeden Fall läuft es nun seit gestern was gut aussieht.

[rudolfkoenig]

Ich habe meinen Zweifel, dass das Problem mit der QoS Aenderung zu tun hat.
Laut Log schaut es so aus, dass in den Datenstrom Muell reinkommt.
Eine Moeglichkeit dafuer waere, dass der Zwischenpuffer beim Verbindungsaufbau nicht initialisiert wird.
Ich habe das nachgeholt und eingecheckt.

Die uebertragene Datenmenge zu reduzieren kann nie schaden, insb. bei einer wackeligen Leitung.

[Fuchsbau]

Hallo,
habe versucht das Attribut "qosMaxQueueLength"  auf MQTT2_Client zu setzten. Bekomme aber nur:
- MQTT2_MQTT2Client: unknown attribute qosMaxQueueLength. Type 'attr MQTT2_MQTT2Client ?' for a detailed list. -

Mache ich das, bekomme ich:

Code Auswählen Erweitern

MQTT2_MQTT2Client: unknown attribute ?, choose one of alias comment eventMap group room suppressReading userReadings verbose IODev autocreate bridgeRegexp devicetopic devPos disable disabledForIntervals getList imageLink jsonMap model periodicCmd readingList setExtensionsEvent setList setStateList event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat timestamp-on-change-reading ASC DbLogExclude DbLogInclude DbLogValueFn cmdIcon devStateIcon devStateIcon devStateStyle icon msgContactAudio msgContactLight msgContactMail msgContactPush msgContactScreen msgParams msgPriority msgRecipient msgRecipientAudio msgRecipientLight msgRecipientMail msgRecipientPush msgRecipientScreen msgRecipientText msgTitle msgTitleShrt msgType sortby webCmd webCmdLabel widgetOverride userattr

Die ersten Zeilen der 00_MQTT2_CLIENT.pm meiner FhemInstallation:

Code Auswählen Erweitern

##############################################
# $Id: 00_MQTT2_CLIENT.pm 22454 2020-07-23 16:36:36Z rudolfkoenig $
package main;

use strict;
use warnings;
use DevIo;

sub MQTT2_CLIENT_Read($@);
sub MQTT2_CLIENT_Write($$$);
sub MQTT2_CLIENT_Undef($@);
sub MQTT2_CLIENT_doPublish($@);
sub MQTT2_CLIENT_Disco($;$$);

# See also:
# http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html


Das ist augenscheinlich die neueste Version mit dem Attribut "qosMaxQueueLength".

Was kann man hier falsch machen?

[rudolfkoenig]

Dein MQTT2_MQTT2Client scheint ein MQTT2_DEVICE zu sein.
Ansonsten kann man noch etliches falsch machen, z.Bsp FHEM nach dem update nicht neu starten.

[Fuchsbau]

jo,  dem ist so.

Danke, für die schnelle Antwort.