"Client FHEM disconnected due to malformed packet"

[Master_Nick]

Hab ich mal eingesetzt in die Config bei Mosquitto - geändert an der Ausgabe hat es für mich nicht wirklich was.

Code: [Auswählen]

1631477780: mosquitto version 2.0.12 running
1631477780: New connection from 192.168.0.7:57663 on port 1883.
......andere clients connecten und wären hier nur Platzraub ;-)
1631477897: New connection from 10.42.0.97:46942 on port 1883.
1631477897: New client connected from 10.42.0.97:46942 as FHEM (p1, c1, k60, u'fhem').
1631477897: Client FHEM disconnected due to malformed packet.
1631477899: New connection from 10.42.0.97:46964 on port 1883.
1631477899: New client connected from 10.42.0.97:46964 as FHEM (p1, c1, k60, u'fhem').
1631477899: Client FHEM disconnected due to malformed packet.
1631477900: New connection from 10.42.0.97:46992 on port 1883.
1631477900: New client connected from 10.42.0.97:46992 as FHEM (p1, c1, k60, u'fhem').
1631477900: Client FHEM disconnected due to malformed packet.

[Beta-User]

Unter configDB gibt's zum einen "search", und zum anderen: Wie wäre es mit einem beherzten "show TYPE=MQTT" + Einstellen auf der Detailseite in FHEMWEB...

Falls das Problem weiter besteht, bitte mal trunk/fhem/FHEM/00_MQTT.pm@24956 testen.

Die libs sind auf dem 2016-er Stand?

[Lothar64]

Da fehlt einiges. Bei mir sieht so ein log so aus.

Code: [Auswählen]

2021-09-08T18:00:30: New connection from 127.0.0.1:47214 on port 1883.
2021-09-08T18:00:30: New client connected from 127.0.0.1:47214 as NetMQTTpm7012 (p1, c1, k60, u'lst').
2021-09-08T18:00:30: No will message specified.
2021-09-08T18:00:30: Sending CONNACK to NetMQTTpm7012 (0, 0)
2021-09-08T18:00:30: Received PINGREQ from NetMQTTpm7012
2021-09-08T18:00:30: Sending PINGRESP to NetMQTTpm7012
2021-09-08T18:00:30: Received SUBSCRIBE from NetMQTTpm7012
2021-09-08T18:00:30: sensors/espeasy/ESP_Easy10/DHT/Humidity (QoS 0)
2021-09-08T18:00:30: NetMQTTpm7012 0 sensors/espeasy/ESP_Easy10/DHT/Humidity
2021-09-08T18:00:30: sensors/espeasy/ESP_Easy10/DHT/Temperature (QoS 0)
2021-09-08T18:00:30: NetMQTTpm7012 0 sensors/espeasy/ESP_Easy10/DHT/Temperature
2021-09-08T18:00:30: Sending SUBACK to NetMQTTpm7012
...
Mit der configDB kenne ich mich nicht aus. In Fhem.cfg muß das verbose attr nach dem define gesetzt werden (habe ich bei mir mal falsch gemacht).
Das sieht so aus als wenn der log level nicht übernommen wurde. Wenn man die hat wüsste man hoffentlich wo man anfangen könnte zu suchen.
Beta-User hat zeitgleich auch Hinweise gepostet 

[Master_Nick]

Unter configDB gibt's zum einen "search", und zum anderen: Wie wäre es mit einem beherzten "show TYPE=MQTT" + Einstellen auf der Detailseite in FHEMWEB...

Also ich hatte ihn so verstanden, dass ich das "Modul" an sich auf Verbose 5 setzen möge. Nicht jedes einzelne MQTT device.
Ansonsten den show Befehl kannte ich gar nicht :-) Hat aber nun die Augen geöffnet:

Das "Modul" ist das was direkt mit dem Mosquitto redet... sorry... ou man... ja klar den kann ich maximal einfach auf Verbose 5 stellen.. sorry :-D

Libs hab ich mittels der Downloads geupdatet - und werd jetzt erstmal wieder sauber auf den Stand ausm Repo gehen :-D

Und DANN... sag ich nochmal was Sache ist :-D

*Edit @Lothar das war das Mosquitto Log ;-)

[Beta-User]

Libs hab ich mittels der Downloads geupdatet - und werd jetzt erstmal wieder sauber auf den Stand ausm Repo gehen :-D

Nein! Die sollten die aktuellen aus cpan sein, bitte...

[Master_Nick]

Ich meinte mittels deiner Anweisungen in den Seiten zuvor.

"wget https://fastapi.metacpan.org/source/BEANZ/Net-MQTT-1.163170/lib/Net/MQTT/Constants.pm -O ./FHEM/lib/Net/MQTT/Constants.pm"

"wget https://fastapi.metacpan.org/source/BEANZ/Net-MQTT-1.163170/lib/Net/MQTT/Message/Connect.pm -O ./FHEM/lib/Net/MQTT/Message/Connect.pm"

Dann lass ich die so ;-)

[hexenmeister]

Also ich hatte jetzt verstanden es müsste wieder gehen - ich habe mein FHEM up to date gebracht - und es geht aber bei mir noch nicht :-D
Hab ich irgendwas an Content falsch verstanden?

Moin!
Nein, das muss schon richtig sein.
Prüfe bitte, ob die Datei 00_MQTT wirklich neu ist. Zeile 520 sollte so aussehen:

Code: [Auswählen]

$msg->{dup} = $msg->message_type == MQTT_PUBLISH;Sollte es so sein, lösche oder kommentiere diese Zeile bitte aus. Fallt das auch nicht hilft, haben wir in deinem Fall ein ganz anders gelagertest Problem.

P.S. Bin leider in den letzten 2 Jahren eher selten Zeit gefunden, mich um die Hausautomation zu kümmern und hier bin ich auch entsprechend selten. :/

[Master_Nick]

Ist die "korrekte" 00_MQTT.pm denn schon im repo oder soll ich die von den Seiten hier im Thread nutzen?

Ich denke sie ist nicht neu Zeile 520 ist bei mir :

Code: [Auswählen]

        }

;-)

[hexenmeister]

"wget https://fastapi.metacpan.org/source/BEANZ/Net-MQTT-1.163170/lib/Net/MQTT/Constants.pm -O ./FHEM/lib/Net/MQTT/Constants.pm"

"wget https://fastapi.metacpan.org/source/BEANZ/Net-MQTT-1.163170/lib/Net/MQTT/Message/Connect.pm -O ./FHEM/lib/Net/MQTT/Message/Connect.pm"

Unterschied zu dem, was in Repo sit, ist echt minimal.
Lediglich in Connect.pm wird beim Fehlen des ClientID (gestern haben wir ja darüber noch gerätselt, warum dabei Server die Verbindung nicht abbricht) ein anderes Defult genommen wird:
alt:

Code: [Auswählen]

sub client_id { shift->{client_id} || 'Net::MQTT::Message['.$$.']' }
neu:

Code: [Auswählen]

sub client_id { shift->{client_id} || 'NetMQTTpm'.$$ }

[hexenmeister]

Ist die "korrekte" 00_MQTT.pm denn schon im repo oder soll ich die von den Seiten hier im Thread nutzen?

Ich denke sie ist nicht neu Zeile 520 ist bei mir :

Code: [Auswählen]

        }

;-)

Ja, ich habe gerade auch in meiner Testinstallation extra Update gemacht. Die Version ist korrekt:  $Id: 00_MQTT.pm 24958 2021-09-11 21:28:10Z hexenmeister $
Deine jedoch leider nicht.
Werfe bitte probeweise die angehängte Datei rein.

[Master_Nick]

Nun läuft alles wunderbar.

Libs aus CPAN.
Und die Modul-Datei von dir.


Da war dann wohl was nicht richtig mit dem update Prozess gelaufen - ich kann es mir nicht wirklich erklären.
Aber top - vielen Dank!
Sorry wenn ich ein wenig Chaos rein brachte.

[hexenmeister]

Lag an der Datei, libs sollten auch alte funktionieren.
Bei Dir stimmt irgendwas mit Update nicht.
Aber immerhin läuft es erstmal wieder

[Master_Nick]

Lag an der Datei, libs sollten auch alte funktionieren.
Bei Dir stimmt irgendwas mit Update nicht.
Aber immerhin läuft es erstmal wieder

Jo hatte nun Beta-User so verstanden er hätte gern das ich die aktuellen nutze und schaue ob es geht, wahrscheinlich damit sie aus den inkludierten bald rausfliegen können.

Nein! Die sollten die aktuellen aus cpan sein, bitte...

Ja ich prüf mal was da schief gelaufen ist.

Vielen Dank erstmal.

Die Frage bleibt ja immer noch bei all dem.... steigt man nun dennoch um oder nicht? Das ist mir so total unklar... Es funktioniert ja 

[Beta-User]

Die Frage bleibt ja immer noch bei all dem.... steigt man nun dennoch um oder nicht? Das ist mir so total unklar... Es funktioniert ja 

Na ja, hexenmeister hatte schon vor langem geäußert, dass er selbst MQTT_DEVICE nicht nutzt, sondern den Teil mit dummy+MQTT_GENERIC_BRIDGE abfackelt, weil es flexibler ist.
MAn. ist MQTT2_DEVICE (für die Repräsentation von externer MQTT-Hardware) noch (einen Ticken) flexibler als dummy+MQTT_GENERIC_BRIDGE (vor allem gibt es weitaus mehr Einrichtungshilfen aka attrTemplate). Ergo würde ich empfehlen, für alles, was man ab jetzt neu in Betrieb nimmt, die 2-er Module nimmt (oder wer das kennt und schätzt, auch die dummy+MGB-Konstruktion, das kann man nämlich notfalls auch völlig stressfrei mit MQTT2_CLIENT betreiben). Tendenziell ist für die ersten Gehversuche mit MQTT2_DEVICE MQTT2_SERVER als IO deutlich einfacher, man kann die Geräte dann aber relativ leicht auf einen externen Server umziehen.

Abraten würde ich von externen Modulen wie dem XiaomiMQTTDevice (und TASMOTA_DEVICE), da macht es mAn. Sinn, aktiv nach MQTT2_DEVICE umzuziehen. Ein wichtiger patch für das Erstgenannte ist seit Wochen ein issue auf Github, den der Maintainer afaik immer noch nicht committet hat...

Für den Bestand an "klassischen" MQTT_DEVICE-Instanzen sehe ich im Moment keine Not...

Just my2ct.

[hexenmeister]

XiaomiMQTTDevice ist wohl der letzte Grund für mich, die alte MQTT IO zu verwenden. Mqtt2 bietet hier die gleiche Bequemlichkeit. Auch die Templates machen es nicht einfacher.
Vermutlich wird es am einfachsten sein, die zigbee subsystem in NodeRed zu verlagern.