"Client FHEM disconnected due to malformed packet"

Begonnen von Master_Nick, 06 September 2021, 21:26:43

Vorheriges Thema - Nächstes Thema

hexenmeister

Zitat von: Lothar64 am 11 September 2021, 22:49:48
In meinem Mosquitto log werden alle Subscribe Nachrichten nach einem connect zwei mal gesendet. Alle werden auch mittels Suback korrekt bestätigt.
Wer Fehler findet, darf sie natürlich behalten ;D

Du hast Recht, beim Connect werden schon alle subscriptions gesendet. Und dann ggf. an der Stelle noch mal.
Magst Du mal mit dieser Version ausprobieren? Jetzt sollten keine doppelten Subscriptions gesendet werden und alles andere hoffentlich auch noch funktionieren :)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Lothar64

@hexenmeister Jetzt werden die Subscriptions nur noch einmal gesendet  :).

Danke für deine/eure Arbeit

p.s.: die Hintergründe der verschiedenen Entwicklungen hier kenne ich nicht, biite nicht übel nehmen, wenn ich da was nicht passendes poste.

hexenmeister

Zitat von: Beta-User am 11 September 2021, 23:06:42
Um das aber klarzustellen: soweit ich das im Kopf habe, hat @hexenmeister die Module "nur" übernommen, weil er mit der "MQTT_GENERIC_BRIDGE" "sowieso" in MQTT unterwegs war und dann -mangels damals bestehender Alternativen - dann eben an den vorhandenen Code angedockt hat, an dem seit den Urzeiten kaum was passiert war.
Genauso war das auch. Der Ursprungsauthor hat sich irgendwann nicht mehr gemeldet, die Module wurden von einem anderen Entwickler übernommen und später (eben wegen der GENERIC_BRIDGE) von mir "geerbt".

Dank geht an Euch hier, den Support, was z.B. Beta-User hier bietet, kann ich zeittechnisch leider gar nicht leisten. Auch die Netztwekanalyse von Lothar64 hat das Problem scharf eingegrenzt und jetzt auch ein weiteres Bug gefunden :)

Ich selbst verwende MQTT_DEVICE und MQTT_BRIDGE schon lange gar nicht. MQTT läuft noch, weil ich dadurch zigbee angebunden habe (allerdings nur zur Befüllung der InfluxDB für Grafana, die ganze Steuerung läuft schon läönger nicht mehr in FHEM).
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Zitat von: Lothar64 am 11 September 2021, 23:22:20
p.s.: die Hintergründe der verschiedenen Entwicklungen hier kenne ich nicht, biite nicht übel nehmen, wenn ich da was nicht passendes poste.
Passender, als deine Log/Nachrichten-Analyse ginge gar nicht :D
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Beta-User

Zitat von: Lothar64 am 11 September 2021, 23:22:20
p.s.: die Hintergründe der verschiedenen Entwicklungen hier kenne ich nicht, biite nicht übel nehmen, wenn ich da was nicht passendes poste.
Paßt schon :) .
Wollte nur bei der Gelegenheit erläutern, warum das derzeit eigentlich so ein vermeintlich  "undurchschaubares Kuddelmuddel" mit so vielen Modulen ist...

Danke für's ausgiebige Mitwirken und Testen!
(Und eventuell weiß ich jetzt auch in 4 Wochen noch, was ein "unterer Nibble" ist ;D ).

@hexenmeister:
8) Cool, dass du das auch noch fixen konntest!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

hexenmeister

Zitat von: Beta-User am 11 September 2021, 23:29:39
Wollte nur bei der Gelegenheit erläutern, warum das derzeit eigentlich so ein vermeintlich  "undurchschaubares Kuddelmuddel" mit so vielen Modulen ist...
Fluch und Segen von FHEM
Offen, mächting, vielseitig, inhomogen und verbaut.
:(
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Beta-User

Effizient fehlt noch, oder?
(Wenn man die Stolperfallen vermeidet).....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

hexenmeister

Zitat von: Beta-User am 11 September 2021, 23:39:48
Effizient fehlt noch, oder?
(Wenn man die Stolperfallen vermeidet).....
Ja, mit einer Einschränkung: FHEM ist singlethreaded. Hat mich schon sehr gestört. Habe zeitlang als Workaround mehrere Instanzen parallel (für verschiedene Aufgaben) laufen lassen.
Ressourcen sind längst nicht mehr knapp, da habe Java oder JS basierte Systemen ihre Vorteile.
An FHEM schätze ich vor allem die Community. Und die Möglichkeit fast alles anschliessen zu können.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Beta-User

Zitat von: hexenmeister am 11 September 2021, 23:44:34
An FHEM schätze ich vor allem die Community. Und die Möglichkeit fast alles anschliessen zu können.
:) Dto.
Das mit dem "fast alles anschließen" ist vermutlich auch eine Folge dessen, dass man als Entwickler nicht allzu viele Vorgaben einhalten muss. Hat halt alles seine Vor- und Nachteile...

Ergo:  Jeder wie er es mag :) .

Ich finde Java-Code grausam zu lesen (bzw. habe wohl einfach keine Übung), (Python ist in der Hinsicht kaum besser) und fand es als Anfänger eigentlich ganz ok, dass ein PI 2 (erste Generation) so lahm war, dass ich die Stolperfallen auch gefunden habe... Das einfach mit "mehr Power/mehr Threads" zu überdecken, bereitet mir andersrum gewisse Bauschmerzen, und wenn dann irgendwo in den Weiten des Internet sowas geäußert wird wie "dann stürzt halt ein Thread mal ab, der kommt dann auch wieder...", klingt das unter qualitativen Gesichtspunkten auch erst mal nicht einladend ;D .

Na ja, am Ende muss man eben - unabhängig von der konkret eingesetzten Lösung - wissen, wie die Dinge funktionieren und wo die Haken und Ösen sind.

(Fast) back to topic:
- Net::MQTT::Simple werde ich aus dem Wiki werfen?
- Wenn jemand die These bestätigen kann, dass die Installation von Net::MQTT::Constants ausreicht, damit man die 2016-er Versionen des gesamten Pakets auf den Rechner bekommt (optimalerweise, aber nicht notewendigerweise einschl. lib-pluggable?) und ein funktionierendes cpan (?) - Kommando liefert, mit dem man das als nicht so erfahrener "cpanese" hinbekommt, würde ich vorschlagen, das in der commandref (+Wiki) so zu hinterlegen und die libs aus dem FHEM/lib-Verzeichnis auch direkt zu entfernen (=nur einfach nicht mehr mit FHEM ausliefern, es sollte also in bestehenden Installationen egal sein). (Vielleicht dar der 2-er Pi doch bald mal wieder aus der Kellerkiste..?)

Schönen Sonntag zusammen :)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

hexenmeister

Zitat von: Beta-User am 12 September 2021, 07:23:56
Das mit dem "fast alles anschließen" ist vermutlich auch eine Folge dessen, dass man als Entwickler nicht allzu viele Vorgaben einhalten muss. Hat halt alles seine Vor- und Nachteile...
Gute Frage... Viel Freiheit bringt zunächst schnelleres Wachstum, jedoch mit der Zeit steigt man immer schwerer durch...

Zitat von: Beta-User am 12 September 2021, 07:23:56
Ich finde Java-Code grausam zu lesen (bzw. habe wohl einfach keine Übung), (Python ist in der Hinsicht kaum besser)
Was man gewohnt ist. Ein gut strukturiertes Java-Projhekt, auch ein sehr großes, ist leichter zu überblicken, als manches kleines Perl-Modul ;D

Zitat von: Beta-User am 12 September 2021, 07:23:56
Das einfach mit "mehr Power/mehr Threads" zu überdecken, bereitet mir andersrum gewisse Bauschmerzen, und wenn dann irgendwo in den Weiten des Internet sowas geäußert wird wie "dann stürzt halt ein Thread mal ab, der kommt dann auch wieder...", klingt das unter qualitativen Gesichtspunkten auch erst mal nicht einladend ;D .
Das meinte ich nicht. Auf Qualität und Stabilität muss man schon achten, dennoch alles kann schon mal Abstürzen, vor allem, wenn man Plugins/Module von der ganzen Welt installieren kann. Aber es ist schon ein Unterschied, ob ein schlecht geschriebenes bzw. nicht ausreichend getestetes Modul den Server komplett runterreisst, oder nur sich selbst. Auch ist mir wichtig, dass parallele Aufgaben (z. B. Module für verschiedene Systeme) auch wirklich parallel laufen und nicht aufeinander warten müssen.
Außerdem wächst die Performance der modernen CPU durch immer mehr Kerne, und weniger durch Geschwindigkeit pro Kern. Singlethreaded Systeme profitieren also kaum davon.

Zitat von: Beta-User am 12 September 2021, 07:23:56
- Net::MQTT::Simple werde ich aus dem Wiki werfen?
Denke ja.

Zitat von: Beta-User am 12 September 2021, 07:23:56
- Wenn jemand die These bestätigen kann, dass die Installation von Net::MQTT::Constants ausreicht, damit man die 2016-er Versionen des gesamten Pakets auf den Rechner bekommt (optimalerweise, aber nicht notewendigerweise einschl. lib-pluggable?) und ein funktionierendes cpan (?) - Kommando liefert, mit dem man das als nicht so erfahrener "cpanese" hinbekommt, würde ich vorschlagen, das in der commandref (+Wiki) so zu hinterlegen und die libs aus dem FHEM/lib-Verzeichnis auch direkt zu entfernen (=nur einfach nicht mehr mit FHEM ausliefern, es sollte also in bestehenden Installationen egal sein). (Vielleicht dar der 2-er Pi doch bald mal wieder aus der Kellerkiste..?)
Eine VM zum Testen ist zwar schnell aufgesetzt, komme aber heute und die Wochen leider eher nicht zum Ausprobieren.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Master_Nick

Wow!

Da ist ja richtig was geschehen.
Sorry ab und an hab ich aktuell echt Schwierigkeiten Zeit zu finden - da hab ich gerade mal die Seiten nach meinem letzten Post gelesen.

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?

Vielen Dank erstmal für die Mühen @Beta-User und @Hexenmeister (lange nicht gelesen) :-)
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

Lothar64

Hallo, schalte doch mal in der Fhem.cfg den Loglevel für das MQTT Modul auf 5 ( "attr mqtt verbose 5" mqtt mit deinem MQTT define Namen austauschen ) und poste den log Ausschnitt. Vielleicht sieht mal dann schon den Grund warum es bei dir nicht funktioniert.

Master_Nick

Nabend Lothar,

also ich hab die ConfigDB am laufen - wie ich da nun außerhalb der UI ein spezielles Modul auf Loglevel Debug bringe - ich such gerade mal :-D
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

Lothar64

Wenn du Mosquitto benutzt hilft evtl auch "log_type all" in /etc/mosquitto/mosquitto.conf einzutragen. Dann den Entsprechenden Auschschniit aus "/var/log/mosquitto/mosquitto.log" posten