MQTT2_CLIENT Probleme

Begonnen von rudolfkoenig, 07 November 2018, 21:12:15

Vorheriges Thema - Nächstes Thema

hexenmeister

Bei der GenericBrigde bin ich dran. Kann leider noch nicht sagen, wann ich soweit bin. Es dürfte nicht so viel sein, die Module (mqtt und mqtt2) sind jedoch grundverschieden und ich habe gerade leider zu viele Baustellen außerhalb der IT.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Ich habe Bedenken bzgl. MQTT2_CLIENT und Performance in Systemen, wo viele Messages durch die Gegend schwirren. Per default abonniert MQTT2_CLIENT alle topics. Das führt zu unnötigen Last im Netz und in der Software. Das alte mqtt Modul erweitert (und reduziert) die subscription Liste dynamisch bei Bedarf. Es wäre schön, auch für mqtt2 so etwas zu haben. Ich habe gesehen, dass man die Liste selbst vorgegeben kann. Dies ist jedoch eine fehleranfällige und unkomfortable Lösung. Klar, dass autosubscribtion so nicht funktionieren kann. Diese ist jedoch für Systeme mit guter Messagelast eh kein sinnvoll gangbarer Weg.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

rudolfkoenig

ZitatDas alte mqtt Modul erweitert (und reduziert) die subscription Liste dynamisch bei Bedarf. Es wäre schön, auch für mqtt2 so etwas zu haben.
Kannst du mir skizzieren, wie sowas gemacht wird?

hexenmeister

Versuche heute Abend ausführlich zu beschreiben.
Bin gerade noch unterwegs.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Billy

Zitat
ZitatPERL WARNING: Deep recursion on subroutine
Das habe ich evtl. auch gefixt, bin aber unsicher.
Falls es nochmal auftritt, hier ein "attr mqtt2client verbose 5" hier anhaengen.

Ist mit der neuen Version gefixt! Tritt bei mir zumindest nicht mehr auf.

Zitat
ZitatGlobal global UNDEFINED MQTT2_mqtt2client MQTT2_DEVICE mqtt2client
Falls man das autocreate Attribut in MQTT2_CLIENT setzt, dann sollte auch eine autocreate FHEM-Instanz definiert sein, damit die Geraete angelegt werden. Diese Meldung kommt, falls irgendein topic in der Summe der MQTT2_DEVICES nicht behandelt wurde. Alternativ verzichtet man auf autocreate.
Mit autocreate aus erledigt!

Also meine Test als user zeigen, dass man mit mqtt2client arbeiten kann.
Umsteigen werde ich erst wenn die GenericBrigde für mqtt2client läuft. ;)

ZitatOder anders: Mit MQTT2 gibt es noch kein einfaches Verfahren, um ein MQTT2_DEVICE mit einem anderen FHEM-Geraet zu synchronisieren. Fuer MQTT (ohne 2) kann man MQTT_GENERIC_BRIDGE verwenden, hoffentlich demnaechst auch fuer MQTT2.

Ich gebe die Hoffnung nicht auf, dass es in FHEM für MQTT mal eine durchgängige Lösung gibt wobei das Thema Funktionalität Bridge für mich
ein wesentliches Kriterium bleibt!

Gruß Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

rudolfkoenig

Zitatdas Thema Funktionalität Bridge für mich ein wesentliches Kriterium bleibt!
Kannst du mir sagen warum? Ich kann z.Zt. nur Sonderfaelle vorstellen.

HomeAlone

Zitat von: Beta-User am 08 November 2018, 14:02:40
@HomeAlone
Dein ganzes setup wirkt für mich komisch[...]

Wollte gerade meine Antwort losschicken, da gibt es schon sechs neue Beiträge hier... die meine Antwort kürzer machen. :)

was ich final möchte, ist sichere (verschlüsselte) MQTT-Kommunikation.  Das schien mir mit den MQTT2-Modulen möglich, mit den MQTT-Modulen nicht. Daher der Ansatz wie oben von mir gegangen.
Die generic Bridge habe ich bereits getestet - sie ist super bequem und elegant zu konfigurieren - da die Devices "magisch" um MQTT-Fähigkeit erweitert werden, aber (bis zu einem der 6 Zwischenpostings von @hexenmeister ging ich davon aus, dass hier keine sichere Anbindung geplant ist.

Kurz: Der Komfort der Generic Bridge gepaart mit sicherer Kommunikation wäre das, was ich mir wünsche.

Billy

#22
Zitat von: rudolfkoenig am 08 November 2018, 15:08:19
Kannst du mir sagen warum? Ich kann z.Zt. nur Sonderfaelle vorstellen.

Die Bridge (Generic-Bridge) macht es mir einfacher zwischen den Instanzen Informationen auszutauschen. :)

Die ersten 3 Beiträge aus diesem Link
https://forum.fhem.de/index.php/topic,92888.0.html
sagen eigentlich alles. Wenn das Sonderfälle sind auch ok.

Wenn die Funktionalitäten einer Bridge wie von Martin angedacht als "core feature" für FHEM einfliesst wäre mir das auch egal.
Wichtig es ist userfreundlich!



FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

hexenmeister

"core feature" wäre imho dem "separation of concerns" Prinzip zuwider.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

HomeAlone

Zitat von: rudolfkoenig am 08 November 2018, 14:20:01
Das DOIF kann man vmtl auch so vereinfachen:
define di_wz_Fenstergriff_Change notify wz_Fenstergriff_rechts:state.* set wz_Fenstergriff_rechts_MQTT $EVTPART1
attr di_wz_Fenstergriff_Change addStateEvent


Perfekt - funktioniert! Vielen Dank!  :)

hexenmeister

Zitat von: rudolfkoenig am 08 November 2018, 15:08:19
Kannst du mir sagen warum? Ich kann z.Zt. nur Sonderfaelle vorstellen.
Für mich ist das sogar einer der Hauptanwendungsfälle :D
Ich verbinden mehrere FHEM-Instanzen mit der GenericBridge über MQTT miteinander.
Einige FHEM-Instanzes sind eine Art "Hardware-Treiber", die physische Geräte MQTT-fähig machen. Als UI kann dann eine andere FHEM-Instanz oder ein beliebiger MQTT-Client (NodeRed, MQTTDash etc.) dienen.

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

hexenmeister

#26
Zitat von: rudolfkoenig am 08 November 2018, 14:51:53
Kannst du mir skizzieren, wie sowas gemacht wird?

Der Ablauf ist ungefähr so:
- am Anfang ist nichts aboniert.
- MQTT-Modul bekommt mit, wenn Client-Devices angelegt oder gelöscht werden (z.B. MQTT_BRIDGE, MQTT_DEVICE, MQTT_GENERIC_BRIDGE) und wenn darin Topic-Relevante Attribute definiert oder gelöscht werden.
- Es wird nach jeder solchen Änderung eine Schnittmenge der alten und neuen Subscriptions gebildet. Für neue Subscription wird eine Subscribe-Message und für überflüssige (gelöschte) eine Unsubscribe-Message gesendet. Falls grade keine Verbindung besteht, wird lediglich die Liste gepflegt.
- Die jeweils aktuelle Liste wird ggf. bei jedem Connect / Disconnect entsprechend abgearbeitet.

Bei den MQTT_.*-Modulen melden sich die Client-Module selbst bei dem IODev, wenn sich Subscriptions ändern. Es kann natürlich auch über Event-Mechanismus die Anlage/Löschung von Geräten und Attributen überwacht werden. So macht auh die GenericBridge mit den fremden aber von ihr überwachten Geräten.

Ich hoffe, das war halbwegs verständlich. Wenn nicht, versuche ich gern alle weiteren Fragen zu beantworten.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Die Verbindung wird sofort wieder aufgenommen, wenn das Netzwerk wieder steht bzw. MQTT-Server verfügbar wird.
Top!
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

rudolfkoenig

Auto-Subscription ist mAn nur fuer sehr "ausgefallene" Konfigurationen sinnvoll.
Ich kann es implementieren, wird aber nicht die Voreinstellung sein.

Es kann nur mit Einschraenkungen funktionieren, da ich die Regexps der MQTT2_DEVICE readingList nicht immer zu den MQTT-Subscription-Matcher-Syntax konvertieren kann. Und ich haette gerne eine Beschreibung, wie ich aus den MQTT_GENERIC_BRIDGE Attributen die Liste der benoetigten Subscriptions ableiten kann.
Sag Bescheid, wenn MQTT_GENERIC_BRIDGE MQTT2_DEVICE unterstuetzt, vorher waere es sinnlos was zu implementieren.

hexenmeister

Bei den asugefallenen Konfigurationen bin ich mir nicht so sicher. MQTT nimmt immr größeren Raum in IoT. Es werden immer mehr Nachrichten versendet. Derzeit ist das für die allermeisten Nutzer sicher kein Problem, kann aber mal werden.

Welche Fälle bei den Matcher sind problematisch?

Zitathaette gerne eine Beschreibung, wie ich aus den MQTT_GENERIC_BRIDGE Attributen die Liste der benoetigten Subscriptions ableiten kann.
Derzeit meldet sich MQTT_GENERIC_BRIDGE beim MQTT über ein sub call bei jeder Ändeurng. Hat aber auch intern im Hash eine Struktur, wie z.B.:

subscription helper array: $VAR1 = [
          '/ha/dg/wz/rollo/west1/state',
          '/ha/dg/wz/fenster/west2/+',
          '/ha/dg/wz/rollo/ost/position',
          '/ha/dg/wz/rollo/ost1/position',
          '/ha/dg/wz/rollo/west2/position',
          '/ha/dg/wz/fenster/ost1/+',
          '/ha/dg/wz/rollo/all/state',
          '/ha/dg/wz/rollo/west2/state',
          '/ha/dg/wz/rollo/west1/position',
          '/ha/og/bz/rollo/all/position',
          '/ha/dg/wz/rollo/ost2/position',
          '/ha/dg/wz/fenster/west1/+',
          '/ha/og/bz/rollo/all/state',
          '/ha/dg/wz/rollo/all/position',
          '/ha/dg/wz/rollo/west/position',
          '/ha/dg/wz/rollo/ost2/state',
          '/ha/dg/wz/rollo/ost/state',
          '/ha/dg/wz/fenster/ost2/+',
          '/ha/dg/wz/rollo/west/state',
          '/ha/dg/wz/rollo/ost1/state'
        ];


Da ich eh extra was für MQTT2 einbauen muss, kann ich mich gerne danach richten, wie du es an dieser Stelle für besser hälst.

Zitatwenn MQTT_GENERIC_BRIDGE MQTT2_DEVICE unterstuetzt, vorher waere es sinnlos was zu implementieren
Sicher, ich melde mich, wenn ich soweit bin :)

Edit:
MQTT2_DEVICE muss MQTT_GENERIC_BRIDGE eigentlich nicht unterstützen, sondern nur IOs wie MQTT2_SERVER und MQTT2_CLIENT
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy