MQTT2_SERVER und QoS

Begonnen von arthur_dent_2015, 20 September 2018, 19:43:05

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten1 2 3 Alle
Benutzer-Aktionen

arthur_dent_2015

20 September 2018, 19:43:05
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

#1
20 September 2018, 20:20:01
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

#2
20 September 2018, 23:47:27
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

#3
21 September 2018, 07:13:15
Hast du es mit retain getestet?
Wie sollen die Dioden gesetzt werden? Kannst du einen Beispiel nennen?

arthur_dent_2015

#4
21 September 2018, 13:13:00
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

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

#5
21 September 2018, 13:39:45
ZitatJa, 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

#6
21 September 2018, 14:22:19
Zitat von: rudolfkoenig am 21 September 2018, 13:39:45
Funktioniert dein Vorhaben mit Mosquitto?
Da ich Mosquitto gerade entsorgt habe, keine Ahnung  :-[
Zitat von: rudolfkoenig am 21 September 2018, 13:39:45
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....
Zitat von: rudolfkoenig am 21 September 2018, 13:39:45
Wieso werden im DOELSE Fall zwei unterschiedliche Instanzen (MQTT & Mosquitto) angesprochen?
ooooppppsss, Folge des Umstiegs auf MQTT2_SERVER, hab ich gepennt :(
Zitat von: rudolfkoenig am 21 September 2018, 13:39:45
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

#7
21 September 2018, 14:46:35
ZitatGebe 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

#8
21 September 2018, 17:03:08
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

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

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

#9
21 September 2018, 20:13:05
ZitatAus 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.

Zitatpublish -r abgesetzt, im Log ist davon nichts zu sehen...
Das habe ich jetzt geaendert.

arthur_dent_2015

#10
24 September 2018, 16:50:50
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

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

#11
24 September 2018, 17:20:22
ZitatMQTT2_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

#12
22 Juni 2020, 10:20:55 Letzte Bearbeitung: 22 Juni 2020, 10:35:30 von psycho160
Zitat von: rudolfkoenig am 20 September 2018, 20:20:01
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
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...

- 2013@FHEM - 2020 Setup: Pi 4 4GB Systeme: Shelly, Tasmota, Zigbee und mittlerweile nur noch wenig Homematic. Entwicker von: tado-FHEM Modul (perlcritic 3 ^^)(https://git.wolfmajer.at/Public/FHEM-Tado)

rudolfkoenig

#13
22 Juni 2020, 11:28:28
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

#14
22 Juni 2020, 11:41:16
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...
- 2013@FHEM - 2020 Setup: Pi 4 4GB Systeme: Shelly, Tasmota, Zigbee und mittlerweile nur noch wenig Homematic. Entwicker von: tado-FHEM Modul (perlcritic 3 ^^)(https://git.wolfmajer.at/Public/FHEM-Tado)
Drucken
Nach oben Seiten1 2 3 Alle
Benutzer-Aktionen