[Gelöst] MQTT2 erkennt keine Devices - Teil #2

Begonnen von OdfFhem, 23 Dezember 2019, 07:09:10

Vorheriges Thema - Nächstes Thema

OdfFhem

@Otto123

Immer schön, wenn ein Thema erfolgreich abgeschlossen werden konnte; aber nicht, wenn auch noch eine Antwort aussteht. Daher mache ich mal einen Fortsetzungsbeitrag auf und schildere mein Vorgehen, dass zu meinen Beobachtungen geführt hat.

1) Auf dem Testsystem lösche ich alle MQTT2_DEVICEs

list TYPE=MQTT2.* TYPE

liefert nur noch den MQTT2_SERVER.

2) MQTT-Nachricht generieren mit

mosquitto_pub -h raspberrypi4test -t alarm_clock_mqtt/start -m "alarming" -i 1575756300715


3) Ich erhalte folgende Logeinträge und es sieht alles sehr gut aus ...

2019.12.23 06:18:10.916 4: Connection accepted from myMqttServer_172.26.0.1_43150
2019.12.23 06:18:10.921 5: in:  CONNECT: (16)(27)(0)(6)MQIsdp(3)(2)(0)<(0)(13)1575756300715
2019.12.23 06:18:10.922 4:   myMqttServer_172.26.0.1_43150 1575756300715 CONNECT V:3 keepAlive:60
2019.12.23 06:18:10.922 5: out: CONNACK:  (2)(0)(0)
2019.12.23 06:18:10.929 5: in:  PUBLISH: 0 (0)(22)alarm_clock_mqtt/startalarming
2019.12.23 06:18:10.929 4:   myMqttServer_172.26.0.1_43150 1575756300715 PUBLISH alarm_clock_mqtt/start:alarming
2019.12.23 06:18:10.934 5: myMqttServer: dispatch autocreate=simple\0001575756300715\000alarm_clock_mqtt/start\000alarming
2019.12.23 06:18:11.027 2: autocreate: define MQTT2_alarm_clock MQTT2_DEVICE alarm_clock myMqttServer
2019.12.23 06:18:11.029 2: autocreate: define FileLog_MQTT2_alarm_clock FileLog ./log/MQTT2_alarm_clock-%Y.log MQTT2_alarm_clock
2019.12.23 06:18:11.032 5: in:  DISCONNECT: (224)(0)
2019.12.23 06:18:11.032 4:   myMqttServer_172.26.0.1_43150 1575756300715 DISCONNECT


4) Ich lösche wieder alle MQTT2_DEVICEs, führe "Save config" aus und mache einen "shutdown restart". Anschließend liefert

list TYPE=MQTT2.* TYPE

erwartungsgemäß nur den MQTT2_SERVER.

5) Erneut MQTT-Nachricht generieren auf dem bereits oben verwendeten Weg

mosquitto_pub -h raspberrypi4test -t alarm_clock_mqtt/start -m "alarming" -i 1575756300715


6) Jetzt erhalte ich folgende Logeinträge und es sieht nicht mehr ganz so gut aus ...

2019.12.23 06:20:52.021 4: Connection accepted from myMqttServer_172.26.0.1_43280
2019.12.23 06:20:52.026 5: in:  CONNECT: (16)(27)(0)(6)MQIsdp(3)(2)(0)<(0)(13)1575756300715
2019.12.23 06:20:52.027 4:   myMqttServer_172.26.0.1_43280 1575756300715 CONNECT V:3 keepAlive:60
2019.12.23 06:20:52.027 5: out: CONNACK:  (2)(0)(0)
2019.12.23 06:20:52.063 5: in:  PUBLISH: 0 (0)(22)alarm_clock_mqtt/startalarming
2019.12.23 06:20:52.063 4:   myMqttServer_172.26.0.1_43280 1575756300715 PUBLISH alarm_clock_mqtt/start:alarming
2019.12.23 06:20:52.064 5: myMqttServer: dispatch autocreate=simple\0001575756300715\000alarm_clock_mqtt/start\000alarming
2019.12.23 06:20:52.148 5: in:  DISCONNECT: (224)(0)
2019.12.23 06:20:52.148 4:   myMqttServer_172.26.0.1_43280 1575756300715 DISCONNECT


7) EIn erneutes list

list TYPE=MQTT2.* TYPE

liefert lediglich den MQTT2_SERVER - war nach dem Logauszug aber auch zu erwarten.



Kannst Du mit meinem "Weg" auch bei Dir dieses Verhalten nachvollziehen?
(das FHEM-version-Kommando liefert bei mir "Latest Revision: 20679")

rudolfkoenig

Wenn ich FHEM mit folgender Konfiguration starte:attr global logfile -
attr global modpath .
define ac autocreate
define m2s MQTT2_SERVER 1883 global
und danachmosquitto_pub -h localhost -t alarm_clock_mqtt/start -m "alarming" -i 1575756300715
ausführe, dann wird bei mir MQTT2_1575756300715 angelegt.

Kannst Du deine Konfiguration soweit verschlanken, dass du uns was zum Nachstellen zeigen kannst?

Otto123

Mein Gänsebraten hat jetzt Prio :) da komm ich jetzt nicht sofort zum testen

Aber spontane "Idee"
Zitatautocreate: define FileLog_MQTT2_alarm_clock ....
FileLog auch gelöscht?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

OdfFhem

@Otto123

FileLog ist auch gelöscht. Der einzige Unterschied zwischen der ersten und der zweiten MQTT-Nachricht ist der dazwischenliegende FHEM-Neustart.

@rudolfkoenig

Wenn ich meine fhem.cfg mal aufs (vermutlich) Auffällige reduziere, bleiben meiner Meinung nach folgende Zeilen übrig:

define myMqttGateway MQTT irgendeinAndererRaspi:1883

define myMqttGenericBridge MQTT_GENERIC_BRIDGE mqtt NAME=mySysMon
attr myMqttGenericBridge IODev myMqttGateway

define myMqttServer MQTT2_SERVER 1883 global


Im Endeffekt muss es ja eigentlich daran liegen, dass beim autocreate das MQTT2_DEVICE-Modul noch nicht geladen ist und die vorhandene MQTT-Konstellation für Verwirrung sorgt. Lege ich nach dem Neustart irgendein x-beliebiges MQTT2_DEVICE an und lösche es im Zweifel auch wieder direkt, klappt das autocreate sofort wie gewünscht.

rudolfkoenig

Falls ein MQTT_GENERIC_BRIDGE definiert ist, dann gibt es kein Bedarf fuer autocreate, weil dieser die Events "verbraucht".

OdfFhem

@rudolfkoenig

Die Aussage kann ich jetzt (noch) nicht ganz nachvollziehen, denn

1) Im Logauszug kann man ja deutlich erkennen, dass der MQTT2_SERVER die Dispatch-Routine anstößt ... es wird aber nichts autocreated.
2) Wurde das MQTT2_DEVICE-Modul geladen, ist MQTT_GENERIC_BRIDGE ja immer noch definiert, aber es wird auch autocreated.

Ist das dann noch erklärbar?

rudolfkoenig

Ja :)

#1: Falls beide geladen sind, dann wird erst MQTT2_DEVICE aufgerufen, das, falls kein readingsList matcht und auch kein passendes clientId existiert, ein UNDEFINED Event generiert.
#2: Falls keiner der beiden Module geladen ist, dann wird MQTT2_DEVICE geladen, und mit #1 weitergemacht.
#3: Falls MQTT_GENERIC_BRIDGE geladen ist, dann darf dieses Modul entscheiden, was zu tun ist, und es erzeugt (offensichtlich) kein UNDEFINED.

OdfFhem

So erklärt, kann ich das Verhalten nachvollziehen und klingt für mich auch plausibel.

Erklärt vermutlich sogar die öfter im Forum diskutierten "Probleme" einiger Umsteiger von MQTT auf MQTT2; denn meist will nur die autom. Anlage des ersten MQTT2_DEVICE nicht klappen ...

Auf jeden Fall vielen Dank fürs "Licht ins Dunkel bringen"