"Client FHEM disconnected due to malformed packet"

[Beta-User]

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."

Nach Lektüre  dieses Beitrags habe ich jetzt zwar eine Ahnung, warum im Wiki steht, dass man zwei Pakete aus dem Gesamtpaket aus cpan holen soll. Allerdings stellt sich mir jetzt die Frage, warum wir nicht einfach "schon immer" die 2014-er Dateien durch die 2016-er ersetzt haben...

"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, [...]

Wenn es via cpan nicht so einfach geht, dann müsste es zumindest gehen, einfach _sämtliche .pm aus dem o.g. FHEM-Verzeichnis_ (und den Unterverzeichnissen) gegen die aktuellen auszutauschen? FHEM danach neu starten.

Geht auch aus FHEM heraus, z.B. für "Constants.pm" in die  FHEM-Kommandozeile werfen:

Code: [Auswählen]

"wget https://fastapi.metacpan.org/source/BEANZ/Net-MQTT-1.163170/lib/Net/MQTT/Constants.pm -O ./FHEM/lib/Net/MQTT/Constants.pm"
Vielleicht kann sich einer der Betroffenen mal die Mühe machen, das dann vollständig aufzudröseln und hier bereitzustellen?

[Master_Nick]

Ich versuche mal nach Feierabend da was zu schaffen.

Ich helfe gerne - es ist nur nicht wirklich mein Wissenstand ;-)
Also sofern ich fragen kann, wenn ich nicht weiter weiß - bin ich sehr gern bereit :-D :-D

Nun aber erstmal -> habt nen guten Tag.

[Beta-User]

Ich helfe gerne - es ist nur nicht wirklich mein Wissenstand ;-)

Das ganze ist auch in meinen Augen reichlich verworren...

Habe mal die sourcen durchgesehen, und die einzige "signifikante" Änderung war https://metacpan.org/release/BEANZ/Net-MQTT-1.163170/source/lib/Net/MQTT/Message/Connect.pm#L58

Bezeichnenderweise findet sich in Wiki zu Net::MQTT::Message (zu dem die Datei gehört) - genau "nichts"...

Dafür ist mir völlig unerklärlich, wieso da steht, man solle Net::MQTT::Simple installieren - soweit auf die Schnelle erkennbar, wird das weder für MQTT noch für MQTT_DEVICE via "use" eingebunden.

Meine Vermutung: "module-pluggable" macht im Hintergrund was komisches, was uns jetzt erst auf die Füße fällt. Der eigentliche Fix müßte aber darin bestehen, eine gültige ClientID zu übergeben, wozu ggf. "einfach nur" die aktualisierte "Connect.pm" ausreichend wäre...?

Code: [Auswählen]

"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"

[Lothar64]

Hallo,
ich habe beides mal ausprobiert, hat nicht geholfen.
Dann habe ich mal mit tcpdump den Netzwerkverkehr mit geschrieben und mit dem Mosquitto log zusammengeführt. Im log unten sind erst zwei subsribe Nachrichten zu sehen die erfolgreich bestätigt werden. Dann kommt ein lange Nachricht (85 Bytes) die nicht mit Suback bestätigt wird. Fhem sendet dann die nächste Subscribe Nachricht dann erfolgt der Connection Abbruch. Ich hoffe damit kann hier jemand den Fehler finden  .

Code: [Auswählen]

---------------------------------------------------------------------------
           
Mosquitto Log: 2021-09-08T18:17:18: Received SUBSCRIBE from NetMQTTpm7012
Mosquitto Log: 2021-09-08T18:17:18: tele/switch2/STATE (QoS 0)
Mosquitto Log: 2021-09-08T18:17:18: NetMQTTpm7012 0 tele/switch2/STATE
Mosquitto Log: 2021-09-08T18:17:18: tele/switch2/POWER (QoS 0)
Mosquitto Log: 2021-09-08T18:17:18: NetMQTTpm7012 0 tele/switch2/POWER
Mosquitto Log: 2021-09-08T18:17:18: Sending SUBACK to NetMQTTpm7012
             
2021-09-08 18:17:18.314382 IP 127.0.0.1.47938 > 127.0.0.1.1883: Flags [P.], seq 2008:2054, ack 140, win 512, options [nop,nop,TS val 1885499749 ecr 1885499733], length 46
    0x0000:  4500 0062 5540 4000 4006 e753 7f00 0001
    0x0010:  7f00 0001 bb42 075b 2d23 e7f2 43da 4c46
    0x0020:  8018 0200 fe56 0000 0101 080a 7062 7165
    0x0030:  7062 7155
    Daten:
             822c 35d0 0012
             7465 6c65 2f73 7769 7463 6832 2f53 5441 5445    tele/switch2/STATE
             0000 12
             7465 6c65 2f73 7769 7463 6832 2f50 4f57 4552    tele/switch2/POWER
             00
   
2021-09-08 18:17:18.315493 IP 127.0.0.1.1883 > 127.0.0.1.47938: Flags [P.], seq 140:146, ack 2054, win 512, options [nop,nop,TS val 1885499750 ecr 1885499749], length 6
    0x0000:  4500 003a 4fe7 4000 4006 ecd4 7f00 0001
    0x0010:  7f00 0001 075b bb42 43da 4c46 2d23 e820
    0x0020:  8018 0200 fe2e 0000 0101 080a 7062 7166
    0x0030:  7062 7165
    Daten:
             9004 35d0 0000         SUBACK = Bestätigung der SUBSCRIBE Nachricht
             
---------------------------------------------------------------------------

Mosquitto Log: 2021-09-08T18:17:18: Received SUBSCRIBE from NetMQTTpm7012
Mosquitto Log: 2021-09-08T18:17:18:     tele/switch3/STATE (QoS 0)
Mosquitto Log: 2021-09-08T18:17:18: NetMQTTpm7012 0 tele/switch3/STATE
Mosquitto Log: 2021-09-08T18:17:18:     tele/switch3/POWER (QoS 0)
Mosquitto Log: 2021-09-08T18:17:18: NetMQTTpm7012 0 tele/switch3/POWER
Mosquitto Log: 2021-09-08T18:17:18: Sending SUBACK to NetMQTTpm7012

2021-09-08 18:17:18.335955 IP 127.0.0.1.47938 > 127.0.0.1.1883: Flags [P.], seq 2054:2100, ack 146, win 512, options [nop,nop,TS val 1885499771 ecr 1885499750], length 46
    0x0000:  4500 0062 5541 4000 4006 e752 7f00 0001
    0x0010:  7f00 0001 bb42 075b 2d23 e820 43da 4c4c
    0x0020:  8018 0200 fe56 0000 0101 080a 7062 717b
    0x0030:  7062 7166
    Daten:
             822c 35d1 0012
             7465 6c65 2f73 7769 7463 6833 2f53 5441 5445   tele/switch3/STATE
             0000 12
             7465 6c65 2f73 7769 7463 6833 2f50 4f57 4552   tele/switch3/POWER
             00
   
2021-09-08 18:17:18.336965 IP 127.0.0.1.1883 > 127.0.0.1.47938: Flags [P.], seq 146:152, ack 2100, win 512, options [nop,nop,TS val 1885499772 ecr 1885499771], length 6
    0x0000:  4500 003a 4fe8 4000 4006 ecd3 7f00 0001
    0x0010:  7f00 0001 075b bb42 43da 4c4c 2d23 e84e
    0x0020:  8018 0200 fe2e 0000 0101 080a 7062 717c
    0x0030:  7062 717b
    Daten:
             9004 35d1 0000     SUBACK = Bestätigung der SUBSCRIBE Nachricht
             
---------------------------------------------------------------------------
 
Diese Nachrichte wird im Mosquitto log nicht mehr angezeigt!

2021-09-08 18:17:18.358950 IP 127.0.0.1.47938 > 127.0.0.1.1883: Flags [P.], seq 2100:2185, ack 152, win 512, options [nop,nop,TS val 1885499794 ecr 1885499772], length 85
    0x0000:  4500 0089 5542 4000 4006 e72a 7f00 0001
    0x0010:  7f00 0001 bb42 075b 2d23 e84e 43da 4c52
    0x0020:  8018 0200 fe7d 0000 0101 080a 7062 7192
    0x0030:  7062 717c
    Daten:
             8a53 35c8 0024
              s e n s o r s / e s p e a s y / W e m o s 2 3 / d h t / H u m i d i t y
             73656e736f72732f657370656173792f57656d6f7332332f6468742f48756d6964697479             
             0000 27
              s e n s o r s / e s p e a s y / W e m o s 2 3 / d h t / T e m p e r a t u r e
             73656e736f72732f657370656173792f57656d6f7332332f6468742f54656d7065726174757265
             00
   
Hier fehlt die SUBACK Bestätigungsnachricht!
Was die folgende Status? Netzwerknachricht bedeutet ist mir unbekannt.
   
2021-09-08 18:17:18.359623 IP 127.0.0.1.1883 > 127.0.0.1.47938: Flags [F.], seq 152, ack 2185, win 512, options [nop,nop,TS val 1885499795 ecr 1885499794], length 0
    0x0000:  4500 0034 4fe9 4000 4006 ecd8 7f00 0001
    0x0010:  7f00 0001 075b bb42 43da 4c52 2d23 e8a3
    0x0020:  8011 0200 fe28 0000 0101 080a 7062 7193
    0x0030:  7062 7192
   
---------------------------------------------------------------------------
   
Diese Nachrichte wird im Mosquitto log nicht mehr angezeigt!
Nächste SUBSCRIBE vom FHEM

2021-09-08 18:17:18.360766 IP 127.0.0.1.47938 > 127.0.0.1.1883: Flags [P.], seq 2185:2223, ack 153, win 512, options [nop,nop,TS val 1885499796 ecr 1885499795], length 38
    0x0000:  4500 005a 5543 4000 4006 e758 7f00 0001
    0x0010:  7f00 0001 bb42 075b 2d23 e8a3 43da 4c53
    0x0020:  8018 0200 fe4e 0000 0101 080a 7062 7194
    0x0030:  7062 7193
    Daten:
             8a24 35cb 001f
             7368 656c 6c69 6573 2f73 6865 6c6c 7931 2d31 3243 3438 432f 7265 6c61 792f 3000
   
2021-09-08 18:17:18.360929 IP 127.0.0.1.1883 > 127.0.0.1.47938: Flags [R], seq 1138379859, win 0, length 0
    0x0000:  4500 0028 0000 4000 4006 3cce 7f00 0001
    0x0010:  7f00 0001 075b bb42 43da 4c53 0000 0000
    0x0020:  5004 0000 5f13 0000

---------------------------------------------------------------------------

Ab hier Neuanmeldung von FHEM mit neuer Port Nummer   
Mosquitto Log: 2021-09-08T18:17:19: New connection from 127.0.0.1:47940 on port 1883.   

2021-09-08 18:17:19.720056 IP 127.0.0.1.47940 > 127.0.0.1.1883: Flags [S], seq 4085290582, win 65495, options [mss 65495,sackOK,TS val 1885501155 ecr 0,nop,wscale 7], length 0
    0x0000:  4500 003c 4d31 4000 4006 ef88 7f00 0001
    0x0010:  7f00 0001 bb44 075b f380 9656 0000 0000
    0x0020:  a002 ffd7 fe30 0000 0204 ffd7 0402 080a
    0x0030:  7062 76e3 0000 0000 0103 0307
2021-09-08 18:17:19.720198 IP 127.0.0.1.1883 > 127.0.0.1.47940: Flags [S.], seq 2840919241, ack 4085290583, win 65483, options [mss 65495,sackOK,TS val 1885501155 ecr 1885501155,nop,wscale 7], length 0
    0x0000:  4500 003c 0000 4000 4006 3cba 7f00 0001
    0x0010:  7f00 0001 075b bb44 a954 fcc9 f380 9657
    0x0020:  a012 ffcb fe30 0000 0204 ffd7 0402 080a
    0x0030:  7062 76e3 7062 76e3 0103 0307
2021-09-08 18:17:19.720314 IP 127.0.0.1.47940 > 127.0.0.1.1883: Flags [.], ack 1, win 512, options [nop,nop,TS val 1885501155 ecr 1885501155], length 0
    0x0000:  4500 0034 4d32 4000 4006 ef8f 7f00 0001
    0x0010:  7f00 0001 bb44 075b f380 9657 a954 fcca
    0x0020:  8010 0200 fe28 0000 0101 080a 7062 76e3
    0x0030:  7062 76e3
   
New connection zu Mosquitto mit User und Passwort
Mosquitto Log: 2021-09-08T18:17:19: New client connected from 127.0.0.1:47940 as NetMQTTpm7012 (p1, c1, k60, u'lst').   

2021-09-08 18:17:19.724398 IP 127.0.0.1.47940 > 127.0.0.1.1883: Flags [P.], seq 1:45, ack 1, win 512, options [nop,nop,TS val 1885501159 ecr 1885501155], length 44
    0x0000:  4500 0060 4d33 4000 4006 ef62 7f00 0001
    0x0010:  7f00 0001 bb44 075b f380 9657 a954 fcca
    0x0020:  8018 0200 fe54 0000 0101 080a 7062 76e7
    0x0030:  7062 76e3
    Daten:
             102a 0006 4d51 4973 6470 03c2
                        N e  t M  Q T  T p  m 7  0 1
    0x0040:  003c 000d 4e65 744d 5154 5470 6d37 3031
              2     l  s t       Passwort habe ich gelöscht
    0x0050:  3200 036c 7374 0008 ???? ???? ???? ????
   


Gruß
Lothar

[Beta-User]

Puh, ich schaue mir morgen mal an, ob es was ändert, wenn man da in Ready einen "Pseudo-Callback" wie bei MQTT2_CLIENT einbaut, der direkte Neuverbindungs-Versuch könnte ein Problem darstellen...?
(Wenn ich das richtig interpretiere, gab es bei MQTT2_CLIENT mal ähnliche Effekte: https://svn.fhem.de/trac/changeset/17706/trunk/fhem/FHEM/00_MQTT2_CLIENT.pm)

 Generelle Frage: Sind da wirklich Leerzeichen im Topic drin oder kommt das durch's editieren?

Und was bedeutet "beides"?

Constants.pm und Connect.pm via wget geholt?

[Lothar64]

Hallo,
die Leerzeichen sind nicht im Topic, das kommt vom Übersetzen der Hex Werte (2 Hex Zeichen pro Ascii).
Ich habe mit wget erst die Connect.pm geholt dann ausprobiert ob es läuft. Dann zusätzlich die Constants.pm und ausprobiert ob es hilft. In beiden Fällen gab es immer wieder die connection Abbrüche. Soll ich vielleicht mal probieren nur die Constants.pm zu tauschen?
Ich schaue mir auch gerade die Flags im Netzwerkprotokoll an, was die bedeuten.
Die Nachrichten mit der Länge 0 gibt es immer mal wieder im log, jedoch nur mit dem Flag [.]. Im Fehlerfall sind in der Nachricht mit der Länge 0 die Flags [F.] gesetzt.
[.] = Ack Bestätigungspaket erfolgreich empfangen
[F] = Verbindungsbeendigung
Das ist bisher alles was ich erkenne. Ob in der MQTT Nachricht vor den [F.] Flags etwas nicht IO ist weiß ich nicht. Da müsste ich mir erst mal das MQTT Protokoll reinziehen.
Gruß
Lothar

[Beta-User]

(Sorry für "vermutlich"):
irgendwie bin ich immer noch irritiert, dass und warum im Wiki (in Folge des besagten Threads?) steht, dass man Net::MQTT::Constants und Net::MQTT::Simple von cpan bräuchte.

Eigentlich sollte man mit einer "nackten Maschine" ohne diese cpan-libs starten und dann nur diese beiden Dateien in den FHEM-Ordner runterziehen, sonst kann man nicht sicher sein, dass da - warum auch immer - irgendwas aus "Simple" kommt. Wenn es "hakt", dann noch die lib-plugable (via apt-get).

Leider verstehe ich von diesem ganzen "Händeschütteln" so gut wie nichts, das da abläuft. Das Problem scheint irgendwie (auch) zu sein, dass der Reconnect zu früh kommt, wenn es irgendwo gewackelt hatte...

Und bis zu dem Punkt läuft es ja auch und Daten kommen rein, oder verstehe ich da was falsch?

[rudolfkoenig]

Beim gruebeln ueber den tcpdump ist mir ein Fehler im SUBACK von MQTT2_SERVER(!) aufgefallen.
Den habe ich jetzt gefixt, offensichtlich haben die bisherigen Clients den Fehler gnaedig verziehen

Warum der neue mosquitto ein Problem hat, habe ich noch nicht verstanden.

[Lothar64]

Hallo,
sorry für die Verwirrung. Ich habe Fhem vor ein paar Jahren aufgesetzt und es lief bisher ohne große Probleme. Wie ich es damals aufgesetzt habe weiß ich leider nicht mehr, d.h. ob ich mit cpan noch was hinzugefügt habe  .  Ich habe nur die beide "Reparaturversuche" in diesem Thread ausprobiert, in der Hoffnung das es hilft  .

Ich bin dabei die Nachricht vor dem Connection Abbruch zu Verstehen. Die Message Länge (2.Byte der Nutzdaten) ist ok. Das 3. und 4. Byte bin ich noch am nachlesen.
Was mir aber im ersten Message Byte komisch vorkommt ist der Wert 0x8a, alle anderen Subscribe Nachrichten haben den Wert 0x82. Im Protokoll (soweit ich das bisher gelesen habe!) muß im unteren Nibble eine 2 stehen, wenn es eine Subscribe Nachricht ist. Das sehe ich als ersten Ansatzpunkt zur Fehlersuche.

[Beta-User]

Habe jetzt mal mit cpan -l geschaut, was auf meiner Hauptmaschine (debian 10 auf x64) so alles vorhanden ist - Net::MQTT-Pakete waren nicht darunter.

Da ist im Moment nur der Constants-wget abgesetzt gewesen, danach hat sich (mit meiner Version von gestern) sowohl 00_MQTT anlegen lassen, wie auch ein MQTT_DEVICE:

Code: [Auswählen]

defmod 00_mqtt MQTT localhost:1884

setstate 00_mqtt opened
setstate 00_mqtt 2021-09-08 22:12:56 connection active
setstate 00_mqtt 2021-09-08 21:55:56 state opened
Kann aber nicht sagen, welche Mosquitto-Version das ist; was halt grade mit Debian-Buster so kommt...

Code: [Auswählen]

defmod m_old_test MQTT_DEVICE
attr m_old_test autoSubscribeReadings $SYS/broker/#
attr m_old_test subscribeReading_bytes_sent $SYS/broker/bytes/sent
attr m_old_test subscribeReading_publish_bytes_sent $SYS/broker/publish/bytes/sent

Gab ein paar warnings, die vermutlich mit den missgebildeten Reading-Namen zu tun haben:

Code: [Auswählen]

2021.09.08 22:00:18 1: PERL WARNING: Use of uninitialized value $1 in concatenation (.) or string at ./FHEM/10_MQTT_DEVICE.pm line 252. 2021.09.08 22:00:18 1: PERL WARNING: Use of uninitialized value $1 in concatenation (.) or string at ./FHEM/10_MQTT_DEVICE.pm line 253.Kurz: Ich gehe davon aus, dass mit der Installation von lib-pluggable-perl (das ist bei mir auch in der cpan-liste, kommt aber aus dem OS), und den beiden "wget-Dateien" eigentlich alles da ist, was man braucht. Sinnvollerweise sollte man die Pakete beide auf den aktuellen Stand bringen, aber "Simple" dürfte eine "Ente" sein, und warum im svn noch zusätzlich TopicStore.pm liegt, erschließt sich mir auch nicht...

Eventuell ist das Problem ja auch auf der Mosquitto-Seite? Hat danach mal jemand geschaut?

offensichtlich haben die bisherigen Clients den Fehler gnaedig verziehen

Mir ist auch völlig unklar, warum es anscheinend simple ESP-Geräte hinbekommen, sich mit Mosquitto sauber zu verbinden, aber Perl-libs damit ein massives Problem haben sollten... Ist doch keine Raketenwissenschaft, oder?
Der Verbindungsversuch auf localhost ist halt ggf. einfach nur sehr viel schneller als das, was ein ESP schafft?

[rudolfkoenig]

Nur um es klarzustellen: die Dateien in FHEM/lib/Net/MQTT/* werden mit FHEM ausgeliefert, weil damals der Autor des MQTT Moduls irgendwelche Anpassungen gemacht hat, die nicht so schnell ins CPAN geschafft haben, und mich ueberredet hat.

Aus heutiger Sicht wuerde ich das nicht mehr zulassen, und falls es sich rausstellt, dass mit den offiziellen CPAN Paketen das MQTT Modul lauffaehig ist, dann sollte das in dem commandref oder Wiki dokumentiert, und diese Dateien aus dem FHEM Repository entfernt werden.

[Lothar64]

Hallo,
ich habe es jetzt noch mal mit "attr global verbose 5" im Fhem mitgelogt.
Auch dort sehe ich jetzt die ganzen Nachrichten, die mit 0x8a beginnen. Hier ein Ausschnitt aus dem Log. wenn der ganze log benötigt wird bitte bescheid sagen.
Wer ist hier wissend über das MQTT Protokoll? Was sind das für Nachrichten, die mit 0x8a beginnen?

edit: Aus meiner Sicht sind die der Grund für das Problem. Wie kann man herausfinden wer die generiert? Dann finden wir hoffentlich auch den Grund für den Fehler.
Ich selbst weiß leider so gut wie nichts über Perl da benötige ich eure Hilfe.

Code: [Auswählen]

2021.09.08 22:30:36 5: MQTT mqtt message sent: Subscribe/at-least-once 367 tele/switch2/STATE/at-most-once,tele/switch2/POWER/at-most-once
2021.09.08 22:30:36 5: DevIo_SimpleWrite mqtt: 822c016f001274656c652f737769746368322f535441544500001274656c652f737769746368322f504f57455200
2021.09.08 22:30:36 5: Starting notify loop for Switch2, 1 event(s), first is transmission-state: subscribe sent
2021.09.08 22:30:36 5: End notify loop for Switch2
2021.09.08 22:30:36 5: MQTT mqtt message sent: Subscribe/at-least-once 368 tele/switch3/STATE/at-most-once,tele/switch3/POWER/at-most-once
2021.09.08 22:30:36 5: DevIo_SimpleWrite mqtt: 822c0170001274656c652f737769746368332f535441544500001274656c652f737769746368332f504f57455200
2021.09.08 22:30:36 5: Starting notify loop for Switch3, 1 event(s), first is transmission-state: subscribe sent
2021.09.08 22:30:36 5: End notify loop for Switch3
2021.09.08 22:30:36 5: DevIo_SimpleWrite mqtt: 8a7a015d002473656e736f72732f657370656173792f57656d6f7332342f626d652f507265737375726500002473656e736f72732f657370656173792f57656d6f7332342f626d652f48756d696469747900002773656e736f72732f657370656173792f57656d6f7332342f626d652f54656d706572617475726500
2021.09.08 22:30:36 5: DevIo_SimpleWrite mqtt: 8a53015e00242f686f6f6b732f646576696365732f362f53656e736f72446174612f48756d69646974790000272f686f6f6b732f646576696365732f362f53656e736f72446174612f54656d706572617475726500
2021.09.08 22:30:36 5: DevIo_SimpleWrite mqtt: 8a59015a002773656e736f72732f657370656173792f4553505f4561737931302f4448542f48756d696469747900002a73656e736f72732f657370656173792f4553505f4561737931302f4448542f54656d706572617475726500
2021.09.08 22:30:36 5: DevIo_SimpleWrite mqtt: 8a2c016f001274656c652f737769746368322f535441544500001274656c652f737769746368322f504f57455200
2021.09.08 22:30:36 5: DevIo_SimpleWrite mqtt: 8a4b016d001674656c652f736f6e6f6666706f77322f53454e534f5200001574656c652f736f6e6f6666706f77322f504f574552000015636d6e642f736f6e6f6666706f77322f504f57455200


[Beta-User]

Nur um es klarzustellen: die Dateien in FHEM/lib/Net/MQTT/* werden mit FHEM ausgeliefert, weil damals der Autor des MQTT Moduls irgendwelche Anpassungen gemacht hat, die nicht so schnell ins CPAN geschafft haben, und mich ueberredet hat.

Also:
- Meine Überprüfung von heute morgen ergab, dass die Unterschiede zwischen dem, was via cpan kommt und dem Stand im FHEM-svn (überraschend) minimal sind.
- vorhin habe ich dann den Net/MQTT-Zweig aus ./FHEM/lib gelöscht, und
- "irgendwie" nur versucht, auf dem dh-make-perl-Weg die "Constants" zu bauen. Das hat erst nicht geklappt (fehlte noch in @INC, die Dateien waren am falschen Ort), aber nachdem ich das nochmal auf dem sudo-Weg versucht hatte, war dann _alles_ (einschl. der eigentlich unnötigen TopicStore.pm) auch in @INC drin, also auch "Message";
- dh-make-perl hat auch verlauten lassen, dass lib-pluggable erforderlich sei (aber vorhanden).

Aus heutiger Sicht wuerde ich das nicht mehr zulassen, und falls es sich rausstellt, dass mit den offiziellen CPAN Paketen das MQTT Modul lauffaehig ist, dann sollte das in dem commandref oder Wiki dokumentiert, und diese Dateien aus dem FHEM Repository entfernt werden.

Ergo _glaube ich_, dass die Voraussetzungen zum löschen aus svn eigentlich gegeben sind, neben den vom damaligen Maintainer bereits ggf. "vorgreifend" eingepflegten Änderungen scheint es sich nur um zusätzliche Bugfixes zu handeln, die da eingepflegt wurden. Wir brauchen aber einen erklärbaren Weg,  wie ein "normaler User" das zuverlässig (und komplett) auf sein System bringt (vermutlich: cpan mit root-priveleges).
Man sollte nur ggf. diese eventuell etwas hemdsärmeligen Annahmen nochmal verifizieren ...

(Ich gehe davon aus, dass hexenmeister ggf. keine prinzipiellen Einwände hätte und kann das gerne in die "commandref - neu" aufnehmen, bin aber u.a. auch eine cpan-Niete...)

(Und von "unteren Nibble" habe ich auch (noch) keinen Schimmer...)

[Lothar64]

Hallo,

(Und von "unteren Nibble" habe ich auch (noch) keinen Schimmer...)

kein Problem, auch ich lerne jeden Tag in der Softwareentwicklung noch dazu, trotz meines Alters 
Im 1. Byte in der MQTT Message ist der Messagetyp enthalten. In den oberen 4 Bit ist der Typ der Message codiert, in den unteren 4 Bit (unteres Nibble) stehen die Flags. Die sind für jede Message im Protokoll definiert. Für das Suscribe Kommando (obere 4 Bits 1000) sollen in den unteren 4 Bits 0010 stehen. -> 1. Byte einer Subscribe Message muß 0x82 sein.
In Mosquitto wird beim Empfang einer ungültigen Message ein reconnect gemacht. Das ist das Verhalten so wie ich es sehe. Das Verhalten von Mosquitto ist also wie in der Doku beschriebn. Jemand sendet eine ungültige Nachricht (malformed packet) an Mosquitto.

[Beta-User]

...vielleicht verstehe ich das dann auch nochmal irgendwann, scheint ja doch nicht so schwer zu sein ...

Erst mal zurück zu Perl/FHEM:

Mit diesen zwei FHEM-Kommandofeldeingaben (mit Quotes) bekommt man neue Moduldateien zum Testen:

Code: [Auswählen]

"wget https://raw.githubusercontent.com/rejoe2/FHEM/master/00_MQTT.pm -O ./FHEM/00_MQTT.pm"
"wget https://raw.githubusercontent.com/rejoe2/FHEM/master/10_MQTT_DEVICE.pm -O ./FHEM/10_MQTT_DEVICE.pm"
MQTT_DEVICE ist nur hinsichtlich des Verhaltens bei autosubsribe im Code angepaßt (es gab da ein paar Warnings, wenn man das so stümperisch macht wie ich bei meinem Erstling...) sonst nur commandref-"id" (rudimentär) statt "name"), MQTT ist experimenteller (!) und kann eventuell auch nicht mit reload aktiviert werden (=> Neustart).
Neben einigem anderen Kleinigkeiten, die hier schon Thema waren, ist v.a. ein (Pseudo-) $callback für ReadyFn eingebaut, was hoffentlich dazu führt, dass die Verbindungsversuche nur noch alle 60 Sekunden effektiv aufgerufen werden. Mit meinem mosquitto habe ich zumindest für einen Testzeitraum von einigen Minuten keine offensichtlichen Probleme festgestellt , aber ob das schon ausreicht, um "neueste Mosquittos" in der Luft zu halten? Eventuelle Seiteneffekte sind daher ausdrücklich nicht ausgeschlossen...