"Client FHEM disconnected due to malformed packet"

[Beta-User]

Jetzt habe ich das mit den libs nochmal auf einem Testsystem versucht. Mit dem jetzt noch im Wiki aufgeführten einen Befehl bekommt man alles notwendige, einschließlich Module::Pluggable.

Damit sehe ich eigentlich keine Veranlassung mehr, diese libs mit FHEM auszuliefern.

Anbei daher ein Patch, damit etwas mehr dazu auch in der commandref zu finden ist und kurze Hinweise in "CHANGED".

@Rudi: von mir aus kannst du das "Net"-Verzeichnis und gleich noch das leere "Device" vom svn löschen - unterstellt, meine Wahrnehmung ist richtig, dass dadurch nichts auf vorhandenen Installationen gelöscht wird und das nur Neuinstallationen nach dem nächsten Versionswechsel effektiv treffen wird.

Nachtrag: Anbei dann noch die entsprechenden Änderungen in MAINTAINER.txt, falls das so umgesetzt würde.

[pjakobs]

meine fhem Instanz war jetzt seit einigen Tagen enorm instabil, wurde nach ein paar zig Stunden sehr sehr langsam und irgenwann half nur noch, fhem neu zu starten.
Ein bisschen troubleshooting zeigte, dass das mqtt modul absurd viel Zeit in Events "verbriet" - und ich denke, genau das hier war die Ursache.
Ich habe jetzt mal das Modul aus Kommentar #37 installiert und zumindest Mosquitto schimpft jetzt nicht mehr.

grüße

pj

[Master_Nick]

Moin @pjakobs - ja das klingt sehr nach dem was hier gefixt wurde 

[Master_Nick]

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. 

Den Gedanken mit dem zigbee subsystem würde ich gerne verstehen. Wie meinst du das?
Also ich habe Zigbee mittels ioBroker laufend und hab dann von dort in MQTT die Geräte rein gebracht und verarbeite einiges teils direkt in ioBroker und einiges nutze ich aber innerhalb FHEM.
Du würdest nun FHEM komplett von MQTT trennen?

Ebenso noch die Frage an Beta-User:

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.

Was meinst du mit externem Server? Ähnlich dessen was Hexenmeister meint?

[Beta-User]

Ebenso noch die Frage an Beta-User: Was meinst du mit externem Server? Ähnlich dessen was Hexenmeister meint?

Kurzformel:
MQTT2_SERVER = (Mosquitto + MQTT2_CLIENT).
Ist (wie z.B. FHEMWEB) ein in FHEM integrierter Serverdienst.
Da dieser die "Herkunft" der Daten kennt (weil er auch die Clients verwaltet), kann MQTT2_SERVER dann gleich alle Daten aus einer Quelle je in ein eigenes MQTT2_DEVICE weitergeben. Bei MQTT2_CLIENT braucht man dazu Hilfsmittel oder muss alles (wie bei MQTT-Classic) mehr oder weniger von Hand machen.

Bzgl. Zigbee:
Die Vorteile von NodeRed in diesem Zusammenhang würden mich auch interessieren.
Aus User-Sicht glaube ich, dass es sehr darauf ankommt, wie man das Gesamtsystem aufbaut. In der Handhabung in FHEM finde ich die Kombination aus deconz und HUEBridge die vermutlich einfachste, wer (sowieso auch) MQTT braucht, fährt vermutlich mit zigbee2mqtt (auf einem modernen Interface-Chip!) am besten. Die Kritik (?) an attrTemplate bei MQTT2_DEVICE kann ich nicht so recht nachvollziehen, es wird halt relativ viel automatisch gemacht, was aus Sicht der meisten User hilfreich ist. Über Details kann man immer streiten, und möglicherweise ist manches auch verbesserungsfähig, aber "irgendwie" muss man die Daten aus dem JSON eben (in FHEM) in die FHEM-üblichen Perl-Strukturen überführen, und da ist nach meinen etwas angegrauten Erfahrungen damit eigentlich nur die Großschreibung für ON/OFF etwas hinderlich...

[Master_Nick]

Kurzformel:
MQTT2_SERVER = (Mosquitto + MQTT2_CLIENT).
Ist (wie z.B. FHEMWEB) ein in FHEM integrierter Serverdienst.
Da dieser die "Herkunft" der Daten kennt (weil er auch die Clients verwaltet), kann MQTT2_SERVER dann gleich alle Daten aus einer Quelle je in ein eigenes MQTT2_DEVICE weitergeben. Bei MQTT2_CLIENT braucht man dazu Hilfsmittel oder muss alles (wie bei MQTT-Classic) mehr oder weniger von Hand machen.

Das klingt ja verdammt interessant und gut! Danke dir!

[Beta-User]

Das klingt ja verdammt interessant und gut! Danke dir!

Aus User-Sicht geht es mAn. kaum komfortabler, ein Schnelleinstieg ist in https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele zu finden.

Meine einzige persönliche Kritik im Hinblick auf die aktuelle Integration des MQTT-Protokolls in FHEM besteht darin, dass mich sehr wundert, wie wenig Rückmeldung zu meiner ständigen Aufforderung kommt, doch mal Vorschläge für (sinnvolle!) defaults der event-on-change-reading-Attribut-Familie zu machen, um die teils extrem vielen "unnötigen" Events zu reduzieren...
Könnte man per attrTemplate direkt mit ausliefern.

[rudolfkoenig]

@Rudi: von mir aus kannst du das "Net"-Verzeichnis und gleich noch das leere "Device" vom svn löschen

Erledigt, und ich habe gerade auch fhemupdate.pl @ fhem_wiki angestossen, damit sollte update dieses Verzeichnis nicht mehr ausliefern.
Bei der Erstinstallation aus .tar.gz werden die Dateien zwar immer noch angelegt, es wird Zeit ein neues Paket (6.1) zu erstellen.

[Beta-User]

thx!

@hexenmeister: Evtl. sollte man auch MQTT_BRIDGE vor 6.1 noch nach contrib (dort gleich: deprecated?) verschieben? Und entsprechende Hinweise dann auch in CHANGED und UPGRADE einpflegen?

@Rudi:
Bitte aber mit dem neuen Paket noch warten, bis zumindest CUL_HM wieder funktional ist, zumindest nach meinem Verständnis gibt es noch was in Richtung AES zu tun.
(OT. Schaust du dir mal das "next" in MQTT2_SERVER #495 an?)

Evtl. könnte man auch ein (Plan-) Datum setzen mit der Bitte an alle, die commandrefs nochmal durchzusehen wg. der "id"-Geschichte?

[hexenmeister]

Den Gedanken mit dem zigbee subsystem würde ich gerne verstehen. Wie meinst du das?
Also ich habe Zigbee mittels ioBroker laufend und hab dann von dort in MQTT die Geräte rein gebracht und verarbeite einiges teils direkt in ioBroker und einiges nutze ich aber innerhalb FHEM.
Du würdest nun FHEM komplett von MQTT trennen?

Naja, aktuell läuft bei mir zigbee2mqtt und in dem FHEM das entsprechende Zigbee-Modul. Die Geräte werden in FHEM angelegt (automatisch), diese gebe ich mittels MQTT_GENERIC_BRIDGE wiederum per MQTT in "die Ganze Welt" jedoch in einem mir bequemmen Format (damit alle Geräte, umabhängig davon, ob ZigBee, Tasmota oder HomeMatic gleichartig per MQTT bedient werden können). Darauf greift die Business logic in NodeRed (Automatismen, Routinen und Formatieren/Schreiben in InfluxDB für Grafana). Also mein "ZigBee-Subsystem" ist die Kette CC2538-Stick->z2m->FHEM->NodeRed. Eigentlich ist hier der FHEM überflüssig. Hat aber historische Gründe (Logik war in FHEM und es gab kein NodeRed) und funktioniert an sich recht gut. Bei Neuaufbau würde ich die Kette natürlich kürzen.

[hexenmeister]

Bzgl. Zigbee:
Die Vorteile von NodeRed in diesem Zusammenhang würden mich auch interessieren.
Aus User-Sicht glaube ich, dass es sehr darauf ankommt, wie man das Gesamtsystem aufbaut. In der Handhabung in FHEM finde ich die Kombination aus deconz und HUEBridge die vermutlich einfachste, wer (sowieso auch) MQTT braucht, fährt vermutlich mit zigbee2mqtt (auf einem modernen Interface-Chip!) am besten. Die Kritik (?) an attrTemplate bei MQTT2_DEVICE kann ich nicht so recht nachvollziehen, es wird halt relativ viel automatisch gemacht, was aus Sicht der meisten User hilfreich ist. Über Details kann man immer streiten, und möglicherweise ist manches auch verbesserungsfähig, aber "irgendwie" muss man die Daten aus dem JSON eben (in FHEM) in die FHEM-üblichen Perl-Strukturen überführen, und da ist nach meinen etwas angegrauten Erfahrungen damit eigentlich nur die Großschreibung für ON/OFF etwas hinderlich...

Die Vorteile ist eine Ansichtssache.
Nodered schätze ich für Stabilität - es kann kein langsam laufendes Task etwas anderes ausbremsen. Totalabstürze hatte ich auch nie.
Außerdem hat es auch eine gewisse Eleganz und ist sehr anschaulich. Die Grundideen hinter der Programmierung kann man grob einem Kind erklären.
Auch wenn Flow Programmierung ost sioch sehr ungewohnt anfüllt und manchmal anscheinen an seine Grenze stösst, kann man immer noch ein Function-Knoten nehmen und darin in JavaScript programmieren. Ein gelungenes Kompromiss aus Einfachheit und Mächtigkeit.

Jedes System hat seine Stärken. Warum soll man sie nicht kombinieren? Dank Docker ist das alles recht schnell und übersichtlich zusammengebaut.
Bei mir laufen ca. Dutzend Kontainer mit dem ganzen Kram.

FHEM ist dabei vor allem low-lever-driver (HomeMatic and co.), NodeRed ist business logic Schicht, Frontend stelle ich gerade auf HomeAssistant um.

MQTT2_DEVICE wollte ich gar nicht kritisieren. Ich bin nur nie damit warm geworden. Erscheint mir etwas überladen und schwer verständlich. Vlt. habe ich einfach nie recht die Idee dahinter verstanden.

[hexenmeister]

@hexenmeister: Evtl. sollte man auch MQTT_BRIDGE vor 6.1 noch nach contrib (dort gleich: deprecated?) verschieben? Und entsprechende Hinweise dann auch in CHANGED und UPGRADE einpflegen?

Bin dafür.

[Beta-User]

Bin dafür.

Patch-Vorschlag dafür anbei. Wenn gewünscht, kann ich auch gerne das Gesamtpaket ins svn schieben, aber wie allgemein üblich nicht ohne explizite Anweisung des zuständigen Maintainers.

@Rudi:
Da ist auch ein etwas mehr umfassender Vorschlag für UPGRADE drin. Eigentlich ist das mit den deprecated modules vor allem dann relevant, wenn man neu aufsetzt, und dann nur seine Daten mitnimmt, aber ein besserer Ort ist mir nicht eingefallen.

@hexenmeister:
Danke für die Erhellung bzgl. NodeRed.

MQTT2_DEVICE finde ich nicht unbedingt überladen. Irgendwie müssen halt die Infos in FHEM, und wenn man es mit MQTT_DEVICE vergleicht, sind die lists (bei gleicher Gegenstelle) auch nicht zwangsläufig länger, und auch bei der Kombo MGB+dummy muss die Info "was nach wo und wie" irgendwo hin - das kann halt wildcards, was es an der einen oder anderen Stelle einkürzt. Ähnliches kann man auch mit M2D erreichen, indem man $TOPIC parst, aber das ist eben (in beiden Optionen) nur was für User, die sich (jeweils) etwas tiefer eingearbeitet haben.
Ansonsten ist es erst mal verwirrend, wenn man es mit M2C+autocreate versucht - bei meinen diesbezüglichen Versuchen dachte ich auch erst mal, dass das schwer verdaulich ist (woraus dann das "Sortier-attrTemplate" entsprungen ist). Aus dieser Erfahrung heraus erfolgt auch die Empfehlung, neue Geräte (zumindest erst mal) mit M2S anlegen zu lassen (es sei denn, man weiß, wie das "Sortier-attrTemplate" funktioniert).

M2D ermöglicht es halt, praktisch mit allem irgendwie "fertig zu werden", und wenn das betreffende Gerät seltsame Formate in als Topic-tree und/oder payload verwendet, sieht halt auch das fertige Ergebnis entsprechend aus - aber bisher ging (fast?) alles . Dieser generische Ansatz (den ja auch MGB verfolgt) ist allemal besser, wie für jede Implementierung "da draußen" jeweils eine eigene "Modul-Sonderlocke" aufzuziehen, wie das XiaomiMQTTDevice oder mein damaliger MiLight-Versuch gewesen waren.
Meine bisherige Erfahrung war, dass alle in diese Richtung gecoachten "Gelegenheitsuser" - nach einer kurzen, teils etwas hoppeligen Einarbeitungsphase - den Wechsel auf die 2-er Module als die richtige Entscheidung bestätigt haben. Die haben aber in der Regel nicht so das große Interesse, umfangreiche Systemlandschaften mit verschiedensten Lösungen zu pflegen .

[rudolfkoenig]

@Rudi:
Da ist auch ein etwas mehr umfassender Vorschlag für UPGRADE drin. Eigentlich ist das mit den deprecated modules vor allem dann relevant, wenn man neu aufsetzt, und dann nur seine Daten mitnimmt, aber ein besserer Ort ist mir nicht eingefallen.

Bin Deiner Meinung.
Das heisst, es gehoert eigentlich nicht dahin, weiss aber nicht, wo es besser aufgehoben waere.
Habs eingecheckt.

[Beta-User]

@hexenmeister: Wir scheinen ein Problem zu haben, habe den Verdacht, dass UUID ggf. doch keine gute Idee war (aber noch nicht in den specs nachgesehen, ob das Format wirklich n.i.O. ist): https://forum.fhem.de/index.php/topic,122962.0.html

Habs eingecheckt.

Thx.

[OT-] Hinweis betr. MQTT2_SERVER: Da ist ein next in #495, das ein warning @ startup erzeugt. Vielleicht magst du das bereinigen?