"Client FHEM disconnected due to malformed packet"

[Master_Nick]

Moinsen,

nachdem ich die neuste Mosquitto Version anfing zu nutzen ging die Verbindung zum MQTT Broker (mosquitto) über Module: 00_MQTT.pm  in FHEM nicht mehr 
Upzudaten ist aber laut FHEM gerade nichts.

Mosquitto Log:

mosquitto version 2.0.12

1630956257: New client connected from 10.42.0.254:44632 as FHEM (p1, c1, k60, u'fhem').
1630956257: Client FHEM disconnected due to malformed packet.

Ist da schon etwas bekannt?

[rudolfkoenig]

Was genau ist unter "MQTT Broker in FHEM" zu verstehen?

[jumbo256]

Das betrifft das MQTT-Modul, nicht MQTT2.

Ich habe das gleiche Problem.

[Master_Nick]

Was genau ist unter "MQTT Broker in FHEM" zu verstehen?

Moin :-)
Module: 00_MQTT.pm
Verbindet sich mit dem MQTT Broker - in meinem Fall Mosquitto.
Sorry ;-) hab tatsächlich mein alias genommen für die Meldung. Korrigiert.

[Beta-User]

Damit scheinen wir derzeit zwei Sach-Themen mit 00_MQTT.pm zu haben (vgl. auch https://forum.fhem.de/index.php/topic,122767.0.html):
- ein aktueller Mosquitto mag die Nachrichtenformate scheinbar nicht mehr. Vermutung: Das kommt aus den verwendeten Perl-Libs? Die, die mit FHEM ausgeliefert werden, stammen aus 2014;
- Wenn man User/Passwort gesetzt hat, läßt sich das nur via setKeyValue ändern, nicht mehr via defmod etc.
Das letztere Problem dürfte die im verlinkten Thread angehängte Fassung beseitigen (da ist im Code nur noch der Teil geändert), die dann auch eine commandref nach aktuellem "id"-Format mitbringt.

Vielleicht können die am Fortleben des 00_MQTT-Moduls interessierten mal nachsehen, ob es irgendwo in den Untiefen des inet aktuelleren Ersatz für die libs gibt, mit denen es wieder geht?

[Master_Nick]

Ist das MQTT2 denn kompatibel - also gibt es einen wirklichen Grund, dass alte weiter zu beleben - oder hätte ich einfach längst umsteigen sollen :-D

Nutze MQTT bei mir mit NodeRed, ioBroker, und diversen SonOff Devices und ESPs.

[Beta-User]

Ist das MQTT2 denn kompatibel - also gibt es einen wirklichen Grund, dass alte weiter zu beleben - oder hätte ich einfach längst umsteigen sollen :-D

MQTT2_CLIENT (als IO zu einem Mosquitto u.a.) kann keine MQTT_DEVICE-Geräte "versorgen", sondern funktioniert "nur" mit MQTT2_DEVICE und MQTT_GENERIC_BRIDGE (sowie RHASSPY).
Wenn du also bisher MQTT-Daten als MQTT_DEVICE in FHEM nutzt, müsstest du die erst durch MQTT2_DEVICE ersetzen (man kann "classic" und MQTT2_CLIENT auch parallel auf den Mosquitto ansetzen).

Nutze MQTT bei mir mit NodeRed, ioBroker, und diversen SonOff Devices und ESPs.

Der Teil sollte keine Schwierigkeiten machen, allerdings: Wenn du attrTemplate auf Tasmota- (SonOff-) Geräte "losläßt", senden die ab dann "on" etc. direkt in Kleinschreibung unter POWER1 statt POWER. (das mit attrTemplate ist aber kein "Muss", nur eine Hilfe...) Kann also sein, dass es dann erforderlich wird, in FHEM die Eventhandler entsprechend anzupassen; entsprechendes würde für "externe Mitlauscher" auch gelten.

[f-zappa]

Same here. Die schöne Lösung ist vermutlich wirklich, auf das MQTT2 umzusteigen. Ist in meinem Fall ein bisschen Handarbeit, weil mit der Zeit doch eine Menge Clients zusammengekommen sind.
Wer seinen mosquitto dockerized fährt, kann aber superschnell wieder ein laufendes System haben:

Code: [Auswählen]

services:
  mosquitto:
    #image: eclipse-mosquitto
    image: eclipse-mosquitto:1.6
Jetzt kann ich erst mal ganz in Ruhe auf MQTT2 umstellen :-)
Gruß, Uli

[Beta-User]

Na ja, es wäre schon schön zu wissen, ob es - neben einem vorübergehenden downgrade - auch andere Optionen gibt, das zu reparieren. Wenn nein, werden wir in schöner Regelmäßigkeit nämlich sonst User haben, die - typischerweise erzwungenermaßen kurzfristig wg. SD-Kartencrash - "nach Jahren mal wieder" eine Systemrenovierung angegehen, und dann alles von Grund auf neu bauen müssen.
Eigentlich kann das nichts großes sein...

Edit: Evtl. mal die Net::MQTT-Updates aus 11/2016 von https://metacpan.org/release/BEANZ/Net-MQTT-1.163170/source/lib/Net/MQTT holen?

Changes u.A. (https://metacpan.org/release/BEANZ/Net-MQTT-1.163170/changes):

1.143250  2014-11-21 23:04:32+00:00 Europe/London    - Fix default client id to meet spec. 1-23 characters from A-Za-z0-9.      Thanks to Richard Postlethwaite for the bug report.

[Master_Nick]

MQTT2_CLIENT (als IO zu einem Mosquitto u.a.) kann keine MQTT_DEVICE-Geräte "versorgen", sondern funktioniert "nur" mit MQTT2_DEVICE und MQTT_GENERIC_BRIDGE (sowie RHASSPY).
Wenn du also bisher MQTT-Daten als MQTT_DEVICE in FHEM nutzt, müsstest du die erst durch MQTT2_DEVICE ersetzen (man kann "classic" und MQTT2_CLIENT auch parallel auf den Mosquitto ansetzen).
Der Teil sollte keine Schwierigkeiten machen, allerdings: Wenn du attrTemplate auf Tasmota- (SonOff-) Geräte "losläßt", senden die ab dann "on" etc. direkt in Kleinschreibung unter POWER1 statt POWER. (das mit attrTemplate ist aber kein "Muss", nur eine Hilfe...) Kann also sein, dass es dann erforderlich wird, in FHEM die Eventhandler entsprechend anzupassen; entsprechendes würde für "externe Mitlauscher" auch gelten.

Achso vergessen dazu zu schreiben - nicht mit Tasmota sondern eigener Firmware.
Also da auch recht flexibel was sie schreiben würden.

Da wäre dann nun die Frage - will man es pflegen oder will man es abkündigen ;-)

Ich schaue mir das mal an, ob ich das in meiner Installation (FHEM Docker Image) testen kann mit der Net::MQTT-Updates aus 11/2016 - noch aber keinen Schimmer wie  ;-)

[Beta-User]

Achso vergessen dazu zu schreiben - nicht mit Tasmota sondern eigener Firmware.
Also da auch recht flexibel was sie schreiben würden.

MQTT2_DEVICE ist ähnlich flexibel wie MQTT_GENERIC_BRIDGE (das du afaik kennst) und kann daher praktisch aus allem irgendwas vernünftiges für FHEM machen...

Da wäre dann nun die Frage - will man es pflegen oder will man es abkündigen ;-)

Wer ist "man"...? Ich gehe davon aus, dass hexenmeister als aktueller Maintainer durchaus bereit ist, das weiter zu pflegen.

Dass man es als Neueinsteiger in das Thema MQTT vermutlich mit den MQTT2_.*-Modulen einfacher hat, ist vermutlich auch kein Geheimnis...

Ich schaue mir das mal an, ob ich das in meiner Installation testen kann mit der Net::MQTT-Updates aus 11/2016.

Eventuell sollte man künftig einfach Net::MQTT komplett von cpan installieren? (Und den Teil aus "lib" entfernen?)

[Master_Nick]

Yep die MQTT_GENERIC_BRIDGE kenn ich wohl ganz gut ;-)

Naja das war halt offen formuliert - ob es halt sinnvoll ist 2 Dinge zu pflegen, wenn das eine mehr kann und das alte mit abdeckt ;-)

Zum Cpan -> da müsste ich dann wohl mal das Dockerimage selber bauen oder schauen, ob ich am laufenden Container rumfrickeln kann :-D


*Edit also mit einem einfachen "cpan install Net::MQTT:simple" war es nicht getan :-D
Nachher nochmal etwas zeit investieren und einlesen - nun ersma Kids.

[Beta-User]

"simple" ist nur ein Teil, das ganze Paket scheint Net::MQTT zu heißen, und es liegen auszugsweise einige Dateien aus dem Paket in ./FHEM/lib/Net. Das Problem _könnte_ sein, dass die zu alt sind bzw. eben den genannten bugfix nicht enthalten, was jetzt zu Problemen führt.

Dieses Nebeneinander von cpan und Auslieferung via FHEM ist mAn. etwas undurchsichtig und wird afaik auch von den FHEM-Architekten nicht unbedingt als "mustergültig" angesehen. Wenn eine Komplettinstallation der Net::MQTT-cpan-Version hilft, wäre es ggf. sinnvoll, die libs aus FHEM auszubauen.

Ob jetzt MQTT2_CLIENT in allen Punkten abdecken kann, was 00_MQTT kann, kann ich nicht beurteilen. Es "kann" nicht alle Features von MQTT und auch die subscriptions werden anders gehandhabt...

[Master_Nick]

Stoße mit Net::MQTT genau auf das hier beschriebene: https://forum.fhem.de/index.php?topic=35201.0

"Could not expand [Net::MQTT]. Check the module name."


Leider wüsste ich jetzt auch nicht, wo ich mal temporär einfach libs aus FHEM entfernen könnte damit ich das rein installierte nutzen kann statt inkludiertes.
Da bin ich nicht wirklich im Thema.

[Lothar64]

Hallo,
ich habe jetzt auch das Problem mit dem connection Abbrüchen. Im Mosquitto log file steht auch "Client NetMQTTpm2874 disconnected due to malformed packet."
Ich hoffe ihr findet eine Lösung. Ich habe über die Jahre wo ich MQTT.pm benutze Wochen in die Konfiguration gesteckt ...
Gruß
Lothar
edit: wenn ihr logs braucht oder ich was ausprobieren soll, bitte schreibt das