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?
Was genau ist unter "MQTT Broker in FHEM" zu verstehen?
Das betrifft das MQTT-Modul, nicht MQTT2.
Ich habe das gleiche Problem.
Zitat von: rudolfkoenig am 06 September 2021, 22:22:37
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.
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 (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 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/Net/MQTT?order=name) 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?
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.
Zitat von: Master_Nick am 07 September 2021, 11:30:11
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).
Zitat
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.
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:
services:
mosquitto:
#image: eclipse-mosquitto
image: eclipse-mosquitto:1.6
Jetzt kann ich erst mal ganz in Ruhe auf MQTT2 umstellen :-)
Gruß, Uli
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 (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):
Zitat1.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.
Zitat von: Beta-User am 07 September 2021, 11:42:48
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 ;-)
Zitat von: Master_Nick am 07 September 2021, 14:34:55
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...
Zitat
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...
Zitat
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?)
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.
"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...
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.
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
Zitat von: Master_Nick am 07 September 2021, 20:28:50
Stoße mit Net::MQTT genau auf das hier beschriebene: https://forum.fhem.de/index.php?topic=35201.0 (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...
Zitat von: Beta-User am 07 September 2021, 17:02:47
"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:
"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?
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.
Zitat von: Master_Nick am 08 September 2021, 09:46:10
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...?
"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"
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 :).
---------------------------------------------------------------------------
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
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?
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
(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?
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.
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 8).
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.
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:
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...
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:
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?
Zitat von: rudolfkoenig am 08 September 2021, 21:39:37
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?
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.
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.
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
Zitat von: rudolfkoenig am 08 September 2021, 22:41:13
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).
Zitat
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...)
Hallo,
Zitat(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 ;D
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.
...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:
"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...
Hallo Beta-User,
vielen Dank für deine Hilfe, leider löst das nicht das Problem.
Ich habe heute abend herausgefunden wo diese 0x8a Nachrichten generiert werden. Da ich Perl nicht verstehe habe ich einfach mal ein paar Logs in den Code hinzugefügt, um das rauzufinden. Diese Nachtichten werden in 00_MQTT.pm in der sub Read generiert. Und zwar wenn eine Mesage MQTT_CONNACK empfangen wird. Ich habe zu Testzwecken einfach mal das DevIo_SimpleWrite auskommentiert. Dann gibt es keine Connection Abbrüche aufgrund "malformed packet" von Mosquitto mehr und ich kann Nachrichten in Fhem empfangen. Was nun nicht mehr funktioniert habe ich noch nicht herausgefunden. Warum die "falschen" Nachrichten generiert werden ist mir nciht klar.
MESSAGE_TYPE: {
$message_type == MQTT_CONNACK and do {
readingsSingleUpdate($hash,"connection","connected",1);
onConnect($hash);
GP_ForallClients($hash,\&client_start);
GP_ForallClients($hash,\¬ify_client_connected);
foreach my $message_id (keys %{$hash->{messages}}) {
my $msg = $hash->{messages}->{$message_id}->{message};
$msg->{dup} = 1;
# Commented out from Lothar64: DevIo_SimpleWrite($hash,$msg->bytes,undef);
}
last;
};
CONNACK klingt irgendwie nach einer Bestätigung, dass die Verbindung da ist. Danach scheint das Modul alle zwischengespeicherten Messages (?) am Stück rauszuschicken, was ggf. der Gegenseite schlicht zu schnell ist...?
Eventuell würde es helfen, das ganze in eine rekursive Timer-Schleife zu packen, dann würde FHEM wenigstens nach jeder Nachricht kurz schauen, ob es noch was anderes zu tun gibt?
In dem tcpdump war aber keine ConnAck Message zu sehen, als Fhem angefangen hat diese 0x8a Messages zu senden. Das letzte ConnAck wurde etwa 500 ms vorher empfangen. Das war nach dem letzen Verbindungsabbruch und dem Neuconnecten. Dort wurde dann ein PINGREQ und PINGRESP ausgetauscht. Dann wurde angefangen die ganzen subscribe messages (0x82) auszutauschen. Also alles IO. Nur das nicht alle Subscribe Nachrichten raus gehen, sondern mitten drin dieses ConnAck" scheinbar empfangen" wird.
Woher bekommt das MQTT Modul nun diese ConAck Message, wenn es im TCP Dump nicht vorhanden ist und sendet korupte Nachrichten?
edit: falls jemand den kompletten TCP dump benötigt um das nachzuvollziehen, bitte Bescheid sagen. Ich glaube das ist zuviel um es hier zu posten oder?
Nun ja, was mich angeht: TCP-Dumps lesen ist nicht so mein Spezialgebiet; notfalls könnte man größere Datenmengen einfach anhängen.
Habe hexenmeister mal angeschrieben wegen dieses Threads hier und gehe mal davon aus, dass er sich bei Gelegenheit meldet.
Bezüglich der "Schein-Messages": Könnte es sein, dass das wegen des {dup}-flags von FHEM aus so erzeugt wird. In https://metacpan.org/release/BEANZ/Net-MQTT-1.163170/source/lib/Net/MQTT/Message.pm#L40 (https://metacpan.org/release/BEANZ/Net-MQTT-1.163170/source/lib/Net/MQTT/Message.pm#L40) scheint irgendwas an Bits geschubst zu werden...? (ist auch in der 2014-er Version so drin).
my $b = decode_byte($bytes, \$offset);
$p{message_type} = ($b&0xf0) >> 4;
$p{dup} = ($b&0x8)>>3;
$p{qos} = ($b&0x6)>>1;
$p{retain} = ($b&0x1);
Im Zweifel würde ich lieber erst mal die Zeile mit dem "dup"-Flag deaktivieren und die Messages als normale Messages raussenden; wenn ich hexenmeister in anderen Zusammenhängen richtig verstanden habe, sieht er den Vorteil des 00_MQTT-Moduls grade darin, dass es "sauber" Nachrichten puffert usw., so dass es mAn. kontraproduktiv ist, die Funktionalität komplett auszuschalten...
Kannst du in etwa sagen, wie viele gepufferte Messages da nach einem Connect in etwa gesendet werden, bis der Abbruch kommt?
Ansonsten ist der Code die "helle Freude", ich bin echt ratlos, was sich z.B. an Weisheit (oder Perl-Magie?!?) hinter dieser Konstruktion verbirgt (steht seit "Ewigkeiten" so drin):
sub send_message($$$@) {
my ($hash,%msg) = @_;
Sowas macht es extrem schwer nachzuvollziehen, was eigentlich passieren soll.
(OK, zugegeben, die Aufrufe der Funktion im Code sind nachvollziehbar, aber das grade zu ziehen etwas aufwändiger).
Hallo Beta-User,
vielen Dank für deine Arbeit. Da das ganze scheinbar nicht einfach zu lösen ist, glaube ich das sinnvollste ist erstmal die Antwort von Hexenmeister abzuwarten. Ich hoffe er hat Zeit und Lust uns da weiter zu helfen. Ich könnte ihm alles was er benötigt zusenden.
Nach dem Verbindungsaufbau werden folgende Nachrichten ausgetauscht:
CONNECT von Fhem
CONNACK von Mosq.
PINGREQ von Fhem
PINGRESP von Mosq.
22 mal
SUBSCRIBE von Fhem
SUBACK von Mosq.
Dann kommt die kaputte Message
Ich bin hier zur Zeit auch erst mal am Ende meines Lateins. Da ich von Perl nichts verstehe, habe ich versucht logische Gemeinsamkeiten zu "C" zu finden und mittels Logs das ganze einzugrenzen. Ich weiß ja noch nicht einmal was da im Fehlerfall wirklich für Messages gesendet werden sollen, sind das 0x82 Nachrichten oder sind die 0x83 Nachrichten alter Datensalat in einem Buffer ...
Mit dem Auskommentieren von "DevIo_SimpleWrite($hash,$msg->bytes,undef);" in dem MQTT_CONNACK Zweig scheint (!) aber alles wieder zu funktionieren, soweit ich das bisher sehe. Das wäre also ein lokaler tempörarer Workaround für alle Betroffenen, bis es hoffentlich gefixt ist. Keine schöne Lösung, ich mag keine Workarounds, aber besser als gar keinen Fhem Server am Laufen zu haben.
Also...
Das läuft mAn. ab:
Das Modul verwaltet einen Puffer für Nachrichten, von denen es gerne eine Rückmeldung vom Server hätte. Nach einem reconnect werden diese Nachrichten "am Stück" rausgeschoben, allerdings mit einem "das ist eine Wiederholung"-flag ({dup}).
Du hast jetzt das Senden unterdrückt, was dazu führen kann, dass ggf. auch wichtige Nachrichten verloren gehen, (und die Queue uU. immer weiter vollläuft) statt das Risiko einzugehen, dass es eben doppelt/mehrfach gesendet wird.
Kannst du einfach mal testen, ob das Reconnect-Problem auch weg ist, wenn du zu Zeile vorher (_statt_ DevIo_SimpleWrite()) auskommentierst?
Die Schleife wäre dann:
for my $message_id (keys %{$hash->{messages}}) {
my $msg = $hash->{messages}->{$message_id}->{message};
#$msg->{dup} = 1;
DevIo_SimpleWrite($hash,$msg->bytes,undef);
}
Falls das mit dem code-Auszug aus Message.pm sieht mir so aus, als würde da der originäre Message-Type einfach um drei (bit-) Stellen nach links verschoben, was beim unteren Nibble +8 bedeutet, aus 2 würde a (?)...
Danke auch hiermit gibt es keine reconnects :).
Alle Subscribe Nachrichen werden nun zwei mal gesendet, was Mosquitto akzeptiert. Das DUP Bit gibt es im MQTT ab 3.1.1 aber nur bei der Publish Nachricht. Ich habe jetzt mal in der alten MQTT 3.1 Spec nachgesehen, dort gibt es das DUP Bit noch (Scheinbar bei allen Nachrichten). Da haben wir nun den Grund für unser Problem mit dem MQTT Modul, es verwendet noch das MQTT 3.1 Protokoll.
p.s. sorry heute ich ich keine Zeit mehr, muß gleich weg
:) kein Problem...
Falls jemand anderes testen will, anbei der Versuch, das 3.1.1-kompatibel zu machen, indem das DUP-Flag (hoffentlich) nur gesetzt wird, wenn es eine normale Publish-Message ist.
Hallo allerseits,
nach dem Problemlösung habe ich seit zwei Tagen gesucht. Danke an Beta-User für den Link zu diesem Thread.
Ihr alle habt tolle Arbeit geleistet hier. Absolut Spitze!
Ich bin übrigens gestern sabend zu dem gleichen Ergebnis gekommen: der DUP Flag!
Darauf bin ich bei Lesen der Doku geklommen: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718033
Zitat
If the DUP flag is set to 0, it indicates that this is the first occasion that the Client or Server has attempted to send this MQTT PUBLISH Packet. If the DUP flag is set to 1, it indicates that this might be re-delivery of an earlier attempt to send the Packet.
The DUP flag MUST be set to 1 by the Client or Server when it attempts to re-deliver a PUBLISH Packet [MQTT-3.3.1.-1]. The DUP flag MUST be set to 0 for all QoS 0 messages [MQTT-3.3.1-2].
The value of the DUP flag from an incoming PUBLISH packet is not propagated when the PUBLISH Packet is sent to subscribers by the Server. The DUP flag in the outgoing PUBLISH packet is set independently to the incoming PUBLISH packet, its value MUST be determined solely by whether the outgoing PUBLISH packet is a retransmission [MQTT-3.3.1-3].
Bin leider kein MQTT-Protokoll-Profi, jetzt müssen wir rausfinden, wann genau der Flag NICHT gesetzt werden muss. Also ob nur die QOS0 Messages betroffen sind oder alles, was nicht PUBLISH ist (
ich meine aktuell wird auch nur für PUBLISH gesetzt, muss aber noch überprüfen => Quatsch, was ich da geschriben habe, in dem Puffer sind natürlich alle nicht bestätigte Nachrichten)
Die Änderung von Beta-User ist die Lösung. Ich habe diese lediglich leicht ergänzt entsprechend dem, was in in DOku gefunden habe. Hoffe, ich habe das auch richtig interpretiert.
foreach my $message_id (keys %{$hash->{messages}}) {
my $msg = $hash->{messages}->{$message_id}->{message};
$msg->{dup} = $msg->{ispub} & $msg->{qos} == MQTT_QOS_AT_MOST_ONCE;
DevIo_SimpleWrite($hash,$msg->bytes,undef);
}
Ich teste noch ein wenig und checke dann ein.
Erst mal willkommen hier und Danke für das feedback.
Ich glaube, die Ergänzung ist an dieser Stelle an sich richtig so. ABER: die Logik in send_publish() kommt mir in der Hinsicht "kaputt" vor - da wird nämlich so eine Nachricht gar nicht mit einer Nummer versehen und dann auch nicht gequeued, so dass diese doppelte Bedingung gar nicht eintreffen kann? Oder bin ich auf dem Holzweg?
Nachbrenner-Frage: $msg->{qos} wird dann auch in den Queue-Hash übergeben, oder?
Zitat von: Beta-User am 11 September 2021, 13:12:33
Erst mal willkommen hier und Danke für das feedback.
Ich glaube, die Ergänzung ist an dieser Stelle an sich richtig so. ABER: die Logik in send_publish() kommt mir in der Hinsicht "kaputt" vor - da wird nämlich so eine Nachricht gar nicht mit einer Nummer versehen und dann auch nicht gequeued, so dass diese doppelte Bedingung gar nicht eintreffen kann? Oder bin ich auf dem Holzweg?
Da sagst Du was... Stimmt vollkommend, hier rächt sich, dass ich mich schon ewig nicht mit dem Modul beschäftigt habe (und die Ursprungsversion mit der Basis-Logik auch nicht von mir ist). Eigentlich dachte ich, das Modul ist reif zum Einmotten, jedoch sehe ich, dass es noch Nutzer gibt, denen es wichtig ist.
Die Abfrage nach QOS wäre hier tatsächlich Quatsch, da die Nachrichten mit QOS0 eh nicht bestätigt werden und der Pufferung entsprechend sinnlos ist.
Zitat von: Beta-User am 11 September 2021, 13:22:29
Nachbrenner-Frage: $msg->{qos} wird dann auch in den Queue-Hash übergeben, oder?
Meinst Du mit Queue "$hash->{messages}"? Ja, {qos} wird ja an die "send_xxx" subs mitgegeben und in Message.pm mit in die Nachricht (hash) mitgenommen. Nachricht-Hash landet dann in "$hash->{messages}->{msgiid}".
Zitat von: hexenmeister am 11 September 2021, 13:29:51
Meinst Du mit Queue "$hash->{messages}"? Ja, {qos} wird ja an die "send_xxx" subs mitgegeben und in Message.pm mit in die Nachricht (hash) mitgenommen. Nachricht-Hash landet dann in "$hash->{messages}->{msgiid}".
Das deckt sich nicht mit meinem Verständnis: Wenn, dann müßte es irgendein Unterhash von dem sein, was sich aus
my $message = Net::MQTT::Message->new(%msg); ergibt. Vermutlich könnte man da auch auf die "inneren Werte" zugreifen, aber das hatte ich bei meinem Vorschlag übersehen...
Was sub send_publish() angeht - müßte das nicht so starten:
sub send_publish($@) {
my ($hash,%msg) = @_;
if (!$msg{qos}) {
Zitat von: hexenmeister am 11 September 2021, 13:25:40
Eigentlich dachte ich, das Modul ist reif zum Einmotten, jedoch sehe ich, dass es noch Nutzer gibt, denen es wichtig ist.
Na ja, vielleicht sollte man es wirklich mittelfristig einmotten, aber wir bräuchten dann einen Plan, wie das gehen soll, damit niemand aus allen Wolken fällt. Da die meisten User vermutlich die kommenden Monate vor dem Problem stehen werden, dass sie updaten müssen, wäre vermutlich jetzt ein guter Zeitpunkt, um zumindest diese Kommunikation in die Richtung zu machen...
Stichworte:
- MQTT_BRIDGE direkt nach contrib, (v.a. auch UPDATE nicht vergessen)
- commandrefs von
-- MQTT_DEVICE Vorbemerkung in Richtung "use MQTT2_DEVICE instead" (für neue User!)
-- MQTT: (analog)
-- MQTT_GENERIC_BRIDGE (low prio): Beispiel (falls vorhanden weg von MQTT nach MQTT_CLIENT)
- Einen Satz Module (samt den 2016-er libs, falls getestet ist, dass die "ok" sind) mal aktuell ausliefern, damit "updater" ohne cpan auskommen, in ca. 6 Monaten die libs löschen, Installation dann nur noch via cpan?
- in ca. 12-18 Monaten dann "BRIDGE" nach "deprecated", MQTT+MQTT_DEVICE nach contrib (oder in dem Zug der Entfernung der libs alles "mittelfristige" direkt nach contrib?
@Rudi:
Gibt es eigentlich einen Plan für 6.1? (Spätestens,) wenn "MQTT-classic" raus ist, wäre es eventuell Zeit für einen Versionswechsel (kann auch 6.2 sein)? (Aber bitte nicht grade jetzt, solange das mit CUL_HM noch nicht wieder rund ist).
...und noch zwei Nachbrenner-Gedanken zum Modul:
my $clientId = AttrVal($name,"client-id",undef);
Kommt mir komisch vor. Neulich hatten "wir" es irgendwo anders davon, dass das Protokoll zwingend eine ID fordert. Am Ende scheint die immer da zu sein, allerdings ist mir vor obigem Hintergrund nicht klar, wo die herkommt.
Was MQTT_QOS_AT_MOST_ONCE angeht, war ich erst unsicher, aber anscheinend wird das mehr oder weniger überall (set publish und set-Anweisungen an MQTT_DEVICE) per default gesetzt. Soweit ok. Wenn aber die "Speicherlogik" geändert wird, müßte/sollte/könnte es eine Obergrenze geben? (Ich habe nicht geprüft, ob DEVICE das auch noch puffert und ggf. gegen aktuelle Werte tauscht, wenn erkannt wird, das das IO weg ist).
Zitat von: Beta-User am 11 September 2021, 14:03:35
Das deckt sich nicht mit meinem Verständnis: Wenn, dann müßte es irgendein Unterhash von dem sein, was sich aus my $message = Net::MQTT::Message->new(%msg);
ergibt. Vermutlich könnte man da auch auf die "inneren Werte" zugreifen, aber das hatte ich bei meinem Vorschlag übersehen...
Ich verstehe nicht, was Du meinst. new erstellt mit bless doch nur eine Art (Perl) Object, was auch nur ein Hash ist. Hat in diesem Fall keine interne Strukturen. In diesem Hash ist einfach alles, was man da rein gibt. U.a. auch qos. Und msg selbst liegt in dem (device)hash->{messages}.
Zitat von: Beta-User am 11 September 2021, 14:03:35
Was sub send_publish() angeht - müßte das nicht so starten:
sub send_publish($@) {
my ($hash,%msg) = @_;
if (!$msg{qos}) {
Würde in diesem Fall ja auch funktionieren, da MQTT_QOS_AT_MOST_ONCE gleich Nulöl ist, aber ein direkter Vergleich ist verständlicher.
Zitat von: Beta-User am 11 September 2021, 14:03:35
Na ja, vielleicht sollte man es wirklich mittelfristig einmotten, aber wir bräuchten dann einen Plan, wie das gehen soll, damit niemand aus allen Wolken fällt.
Ja, stimmt. Könnte man so, wie Du schreibts auch machen.
Zitat von: Beta-User am 11 September 2021, 15:53:39
my $clientId = AttrVal($name,"client-id",undef);
Kommt mir komisch vor. Neulich hatten "wir" es irgendwo anders davon, dass das Protokoll zwingend eine ID fordert. Am Ende scheint die immer da zu sein, allerdings ist mir vor obigem Hintergrund nicht klar, wo die herkommt.
Dokuj meint dazu:
ZitatA Server MAY allow a Client to supply a ClientId that has a length of zero bytes, however if it does so the Server MUST treat this as a special case and assign a unique ClientId to that Client. It MUST then process the CONNECT packet as if the Client had provided that unique ClientId [MQTT-3.1.3-6].
If the Client supplies a zero-byte ClientId, the Client MUST also set CleanSession to 1 [MQTT-3.1.3-7].
If the Client supplies a zero-byte ClientId with CleanSession set to 0, the Server MUST respond to the CONNECT Packet with a CONNACK return code 0x02 (Identifier rejected) and then close the Network Connection [MQTT-3.1.3-8].
If the Server rejects the ClientId it MUST respond to the CONNECT Packet with a CONNACK return code 0x02 (Identifier rejected) and then close the Network Connection [MQTT-3.1.3-9].
Allerdiongs nur, wenn CleanSession gesetzt ist, was wir anscheinend nie tun. Somit hast Du recht, sollte eiug. nicht funktionieren.
Zitat von: Beta-User am 11 September 2021, 15:53:39
Was MQTT_QOS_AT_MOST_ONCE angeht, war ich erst unsicher, aber anscheinend wird das mehr oder weniger überall (set publish und set-Anweisungen an MQTT_DEVICE) per default gesetzt. Soweit ok. Wenn aber die "Speicherlogik" geändert wird, müßte/sollte/könnte es eine Obergrenze geben? (Ich habe nicht geprüft, ob DEVICE das auch noch puffert und ggf. gegen aktuelle Werte tauscht, wenn erkannt wird, das das IO weg ist).
Ja, QOS0 ist Standard. Was würdest Du mit der Speicherlogik anders tun? DEVICE macht damit, meine ich, gar nichts und schon gar kein Austausch.
Zitat von: hexenmeister am 11 September 2021, 17:55:49
Ich verstehe nicht, was Du meinst. new erstellt mit bless doch nur eine Art (Perl) Object, was auch nur ein Hash ist. Hat in diesem Fall keine interne Strukturen. In diesem Hash ist einfach alles, was man da rein gibt. U.a. auch qos. Und msg selbst liegt in dem (device)hash->{messages}.
Danke für die Erläuterung. Das mit den Objekten muss ich dann wohl nochmal (bei Bedarf) vertiefen, ich hätte das jetzt als den Rückgabewert einer Umwandlung aufgefasst.
Aber dann kann man auch direkt auf "ispub" zurückgreifen, weil das als "message_type" dann ja auch mit da drin steckt, und man das nur rausholen muss, wenn die Gegenstelle noch nicht quittiert hat.
Zitat
Würde in diesem Fall ja auch funktionieren, da MQTT_QOS_AT_MOST_ONCE gleich Null ist, [...]
:o ...Denkfehler meinerseits, sorry.!
Streich es von der Liste ::) .
Zitat von: hexenmeister am 11 September 2021, 18:10:02
Allerdiongs nur, wenn CleanSession gesetzt ist, was wir anscheinend nie tun.
Dann einfach "$name" als Rückgabe aus der AttrVal-Abfrage? (Just to be sure...) MQTT2_SERVER macht zwar von "may" Gebrauch und läßt das auch zu, führt dann aber ohne ClientID z.B. kein "autocreate" aus (wie auch immer man dazu steht, deine Skepsis hat durchaus auch eine gewisse Berchtigung :D ). Andere Server-Typen (oder future mosquitto) sind da evtl. nicht so tolerant...
Zitat
Ja, stimmt. Könnte man so, wie Du schreibts auch machen.
Eilt ja nicht, erst kommt die Reparatur :) .
Zitat von: Beta-User am 11 September 2021, 18:22:41
Danke für die Erläuterung. Das mit den Objekten muss ich dann wohl nochmal (bei Bedarf) vertiefen, ich hätte das jetzt als den Rückgabewert einer Umwandlung aufgefasst.
Aber dann kann man auch direkt auf "ispub" zurückgreifen, weil das als "message_type" dann ja auch mit da drin steckt, und man das nur rausholen muss, wenn die Gegenstelle noch nicht quittiert hat.
Die Objekte in Perl sind mir (als Java-Entwickler) auch recht suspekt. Bin mir da auch oft unsicher, was alles da geht und was nicht ;D
Auf ispub kann man da, wie du ja auch gemacht hast, einfach zugreifen mit $msg->{ispub};
Zitat von: Beta-User am 11 September 2021, 18:22:41
Dann einfach "$name" als Rückgabe aus der AttrVal-Abfrage? (Just to be sure...) MQTT2_SERVER macht zwar von "may" Gebrauch und läßt das auch zu, führt dann aber ohne ClientID z.B. kein "autocreate" aus (wie auch immer man dazu steht, deine Skepsis hat durchaus auch eine gewisse Berchtigung :D ). Andere Server-Typen (oder future mosquitto) sind da evtl. nicht so tolerant...
Da habe ich auch schon überlegt, was ich in diesem Fall nehmen soll... Evtl. wirklich etwas wie "fhem_client_$name", oder FUUID... Vlt. sogar FUUID besser.
Zitat von: hexenmeister am 11 September 2021, 19:08:47
Auf ispub kann man da, wie du ja auch gemacht hast, einfach zugreifen mit $msg->{ispub};
Achtung: Das habe ich vorher erst in send.* reingeknödelt, im originalen Hash heißt das anders und könnte dann ggf. auch anders (im Connect-Fall) ausgewertet werden. Deswegen der Hinweis vorhin, dass ich meine, der letztgenannte Weg wäre effizienter (wenn es denn geht...)
Zitat
Da habe ich auch schon überlegt, was ich in diesem Fall nehmen soll... Evtl. wirklich etwas wie "fhem_client_$name", oder FUUID... Vlt. sogar FUUID besser.
Evtl. wäre ja grade wegen der "autocreate"-Geschichte auch "" die beste Lösung. FUUID hatte ich auch schon überlegt, aber wieder verworfen. Müßte man auch holen und wäre nicht "unique", falls jemand auf den Gedanken kommt, mehrere Verbindungen aufzumachen (aus welchen Gründen auch immer...). Die ID ist meinem Gefühl nach auch nicht zur größeren Verbreitung gedacht.
Zitat von: Beta-User am 11 September 2021, 19:19:34
Achtung: Das habe ich vorher erst in send.* reingeknödelt, im originalen Hash heißt das anders und könnte dann ggf. auch anders (im Connect-Fall) ausgewertet werden. Deswegen der Hinweis vorhin, dass ich meine, der letztgenannte Weg wäre effizienter (wenn es denn geht...)
Jeeeetzt (erst) ist der Groschen gefallen. :/ Habe Deine Lösung genommen, da es funktioniert hat (klar, ist ja immer false) und dachte, in der Message existiert dieser Flag schon... Dann muss das natürlich so sein:
$msg->{dup} = $msg->message_type == MQTT_PUBLISH;In diesem Fall ist das ein Methodenaufruf, Message.pm Definiert das so:
sub message_type { shift->{message_type} }Jedoch scheinen die einzelnen Subklassen das einfach stumpf zu überschreiben:
sub message_type {
3
}Somit bin ich nicht sicher, dass $msg->{message_type} immer korrekt befüllt wird.
Zitat von: Beta-User am 11 September 2021, 19:19:34
Evtl. wäre ja grade wegen der "autocreate"-Geschichte auch "" die beste Lösung. FUUID hatte ich auch schon überlegt, aber wieder verworfen. Müßte man auch holen und wäre nicht "unique", falls jemand auf den Gedanken kommt, mehrere Verbindungen aufzumachen (aus welchen Gründen auch immer...). Die ID ist meinem Gefühl nach auch nicht zur größeren Verbreitung gedacht.
Wenn man UID des IODevices niummt, sollte doch eindeutig sein?
hehehe, jetzt ist dann auch bei mir der Groschen gefallen, auf was sich UUID bezieht - gute Lösung mit dem Internal :) .
Könnte man dann so machen:
my $clientId = AttrVal($name,"client-id", $hash->{'FUUID'}});
Hehe, ... ja, wenn man doppelte Quotes mag und "normale" Hash-Labels in einfachen...
*duckundweg*
Hallo,
kaum ist man ein paar Stunden weg, schon geht es hier richtig ab.
Vielen vielen Dank für eure Mühe, die ihr in dieses alte Modul steckt, wobei alt ja nicht schlecht heißt. Kann auch ausgereift bedeuten :D .
Ich habe die Version von Beta-User aus Antwort 37 mal geladen. Sie funktioniert auch.
Aus den Perl Diskussionen halte ich mich schön raus, da ist zu hoch für mich als C Entwickler.
Ich werde mich noch mal etwas tiefer in das MQTT Protokoll einlesen. Aber eine Frage vorab. Warum sendet man Nachrichten zwei mal, die werden doch schon über TCP/IP abgesichert. Ein weiteres Update von Mosquitto könnte das ebenfalls nicht gefallen.
Zitat von: Beta-User am 11 September 2021, 22:33:16
Hehe, ... ja, wenn man doppelte Quotes mag und "normale" Hash-Labels in einfachen...
*duckundweg*
>:( Als "Java-Mensch" vergesse ich so was ständig.
Besser?
my $clientId = AttrVal($name,'client-id', $hash->{FUUID}); :P
Zitat von: Lothar64 am 11 September 2021, 22:34:28
Ich habe die Version von Beta-User aus Antwort 37 mal geladen. Sie funktioniert auch.
Ab morgen per Update wird eine funktionierende Version verteilt.
Zitat von: Lothar64 am 11 September 2021, 22:34:28
Ich werde mich noch mal etwas tiefer in das MQTT Protokoll einlesen. Aber eine Frage vorab. Warum sendet man Nachrichten zwei mal, die werden doch schon über TCP/IP abgesichert. Ein weiteres Update von Mosquitto könnte das ebenfalls nicht gefallen.
Naja, ich hoffe im Normalfall werden Nachrichten nicht zwei Mal gesendet.
Die fragliche Stelle ist für den Fall gedacht, wenn die Quittungen fehlen. So sieht das auch das Protokoll vor.
Alle gesendete Nachtrichten mit QOS>0 werden in einer Liste gehalten, beim Eingehen von Quittungen vom Server werden gespeichrte Nachrichten aus der Liste entfernt.
Bei Verlust der Verbindung, nach dem Reconnect, werden alle noch nicht bestätigte Nachrichten nochmal geschickt, diesmal mit dem DUP-Flag. Sollte (hoffentlich) in Übereinstimmung mit dem Protokoll sein.
ZitatNaja, ich hoffe im Normalfall werden Nachrichten nicht zwei Mal gesendet.
In meinem Mosquitto log werden alle Subscribe Nachrichten nach einem connect zwei mal gesendet. Alle werden auch mittels Suback korrekt bestätigt.
Zitat von: hexenmeister am 11 September 2021, 22:38:58Besser?
;D ...die Sonne geht über Java auf ;D ...
Zitat von: Lothar64 am 11 September 2021, 22:34:28
wobei alt ja nicht schlecht heißt. Kann auch ausgereift bedeuten :D .
Ja, weiß nicht recht...
MQTT-classic (und MYSENSORS) sind an ein paar Stellen "an FHEM vorbei", was einer der Gründe war, warum Rudi MQTT2 entwickelt hat. Und der Code ist auch - na ja - irgendwie eigentlich "seit immer" kaum verändert - läuft ja.
Zitat
Warum sendet man Nachrichten zwei mal, die werden doch schon über TCP/IP abgesichert.
Wenn ich es richtig verstanden habe, ist der Grund schlicht und ergreifend der, dass es keinen Check gibt, ob der Broker verfügbar ist, bevor gesendet wird. Ansonsten müßte man eine 2. Queue haben... (@hexenmeister: Bin nicht sicher, ob das nicht auch z.B. die subscriptions betrifft; sonst müßte man uU. noch mehr Statusinfos abfragen und sich den Start-Prozess ansehen...)
Das war jedenfalls das Zwischenergebnis, zu dem ich bis dato gekommen bin. Soviel dann zum "ausgereift"...
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 (warum auch, lief ja soweit) ;D .
Da der Code aber "eigen" ist, ist es auch relativ schwer, da tiefer einzugreifen...
Will sagen: Danke, hexenmeister, dass du den Job machst! ;D
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 :)
@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.
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).
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
Änderungen eingecheckt.
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!
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.
:(
Effizient fehlt noch, oder?
(Wenn man die Stolperfallen vermeidet).....
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.
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 :)
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.
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) :-)
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.
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
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
Hab ich mal eingesetzt in die Config bei Mosquitto - geändert an der Ausgabe hat es für mich nicht wirklich was.
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.
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?
Da fehlt einiges. Bei mir sieht so ein log so aus.
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 :)
Zitat von: Beta-User am 12 September 2021, 22:28:04
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 ;-)
ZitatLibs 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...
Ich meinte mittels deiner Anweisungen in den Seiten zuvor.
Zitat"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 ;-)
Zitat von: Master_Nick am 12 September 2021, 21:45:38
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:
$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. :/
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 :
}
;-)
Zitat"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:
sub client_id { shift->{client_id} || 'Net::MQTT::Message['.$$.']' }neu:
sub client_id { shift->{client_id} || 'NetMQTTpm'.$$ }
Zitat von: Master_Nick am 12 September 2021, 22:51:57
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 :
}
;-)
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.
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.
Lag an der Datei, libs sollten auch alte funktionieren.
Bei Dir stimmt irgendwas mit Update nicht.
Aber immerhin läuft es erstmal wieder :)
Zitat von: hexenmeister am 12 September 2021, 23:00:39
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.
ZitatNein! 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 ;D
Zitat von: Master_Nick am 12 September 2021, 23:07:51
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 ;D
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.
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. :o
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.
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
Moin @pjakobs - ja das klingt sehr nach dem was hier gefixt wurde ;D
Zitat von: hexenmeister am 13 September 2021, 00:07:53
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. :o
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:
ZitatTendenziell 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?
Zitat von: Master_Nick am 14 September 2021, 10:45:10
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...
ZitatKurzformel:
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! :-)
Zitat von: Master_Nick am 14 September 2021, 11:11:54
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.
Zitat@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.
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?
Zitat von: Master_Nick am 14 September 2021, 10:45:10
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.
Zitat von: Beta-User am 14 September 2021, 11:03:08
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.
Zitat von: Beta-User am 14 September 2021, 12:48:46
@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.
Zitat von: hexenmeister am 15 September 2021, 01:16:02
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 8) . 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 ;D .
Zitat@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.
@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
Zitat von: rudolfkoenig am 15 September 2021, 17:25:49
Habs eingecheckt.
Thx.
[OT-] Hinweis betr. MQTT2_SERVER: Da ist ein next in #495, das ein warning @ startup erzeugt. Vielleicht magst du das bereinigen?
Mein Perl (5.34) meldet kein Warning beim Startup, und auch bei "set m2s publish bla bla" nur dann, wenn ignoreRegexp definiert ist.
Danke fuer den Hinweis, habs gefixt.
Thx, mein Hauptsystem läuft "noch" auf 5.28...
@hexenmeister: Danke auch für's fixen des bugs in MQTT, sorry for inconvenience ::)
Ich find es mega, wie ihr ein Thema was eventuell gar nicht mehr so "notwendig" oder "zwingend zu pflegen" wäre so mit Eifer verfolgt.
Ich beneide euch um die Motivation und halte sie hoch.
Tolle Teamarbeit - Danke allen beteiligten!
Sowas hätte ich gerne mehr in meiner Arbeitskette!
Hallo zusammen,
nachdem die patches betr. das "deprecated" für MQTT_BRIDGE bei mir im svn-Verzeichnis auf der Platte etwas "quer" lagen, habe ich das vorhin eingecheckt.
Bitte melden, wenn das komplett daneben gewesen sein sollte...
Zitat von: Master_Nick am 17 September 2021, 10:57:16
Ich find es mega, wie ihr ein Thema was eventuell gar nicht mehr so "notwendig" oder "zwingend zu pflegen" wäre so mit Eifer verfolgt.
Danke für die Rückmeldung. Ich habe zwischenzeitlich so viele Leute "verarztet", die es - warum auch immer - in den letzten 2-3 Jahren versucht haben, mit MQTT_BRIDGE weiterzukommen, dass (vermutlich nicht nur) ich ehrlich gesagt einigermaßen froh bin, wenn das den Blick nicht mehr auf bessere Lösungen verstellt... (erst neulich habe ich eine (ältere) Anleitung im FHEM-Wiki (!) gefunden, die doch tatsächlich dummy+MQTT_BRIDGE vorschlägt; ohne Worte...).
Ansonsten ist es m.E. auch eine Stärke von FHEM, dass "breaking changes" eher selten vorkommen und die User nicht mit Absicht "ständig" damit genervt werden, dass irgendwas substantielles umgestellt werden muss (ich meine, dass andere Lösungen da in der Vergangenheit recht rabiat waren und schätze persönlich auch den eher konservativen Zugang, den wir hier pflegen :) ).
@hexenmeister:
(leicht OT)
MQTT_GENERIC_BRIDGE scheint noch nicht darauf vorbereitet zu sein, dass IODev nicht mehr zwingend als Attribut zu hinterlegen ist. (Ich finde das zwar weiter empfehlenswert, aber da heute jemand in diese Falle getappt ist):
https://forum.fhem.de/index.php/topic,123092.msg1176294.html#msg1176294 (https://forum.fhem.de/index.php/topic,123092.msg1176294.html#msg1176294)
(Ist nur kurz angetestet, bitte daher um sehr kritische Durchsicht!)
Damit es nicht untergeht, hängt hier auch der Docu-Patch von neulich nochmal dran, in der das mit Net::MQTT nochmal klarer formuliert wird, damit nicht noch jemand "alles" nachinstalliert...