Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE

[HomeAlone]

DevSpec, was man im define angeben kann, dient lediglich dazu, die entsprechenden Geräte mit userAttr-Einträgen auszustatten, damit man an den entsprechenen Geräten die mqtt*-Attribute konfigurieren kann. Du verwendest eine globale Publish-Funktion, sie schickt einfach alles weg, was nicht durch exclude ausgeschlossen ist.
Ich schreibe auf die 'Wunschliste' dein Anwendungsfall. Sollte sich durch eine Prüfung gegen devspec realisieren lassen. Bin mir jedoch noch nicht sicher, ob das eine gute Idee ist, kann an der anderen Seite zu Verwirrung führen (nach dem Motto, warum wird etwas NICHT gesendet).

OK, das erklärt das Verhalten, Danke für die Erklärung.

Dennoch möchte ich zur Diskussion stellen, ob das von mir verstandene Verhalten nicht das sinnvollere wäre: Warum sollte die Bridge alle Geräte über MQTT anbinden, wenn ich per devspec spezifisch Gruppen angegeben habe?

Anders ausgedrückt: Ich möchte doch nur für diejenigen Geräte/Gruppen/Räume/... die mqtt-Attribute setzen können, an deren Überwachung ich interessiert bin.

Die Beschreibung in der commandref zur MQTT_GENERIC_BRIDGE liest sich für mich auch so, dass die Überwachung durch die devspec auf eine/mehrere bestimmte Gruppen begrenzt wird:

Der zweite Parameter ('devspec') erlaubt die Menge der zu ueberwachenden Geraeten zu begrenzen (sonst werden einfach alle ueberwacht, was jedoch Performance kosten kann). Beispiel fuer devspec: 'TYPE=dummy' oder 'dummy1,dummy2'. Bei kommaseparierten Liste duerfen keine Leerzeichen verwendet werden! s.a. devspec

und bei den Beispielen

Bridge fuer alle Geraete in einem bestimmten Raum:

Code Auswählen Erweitern

defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=Wohnzimmer
attr mqttGeneric IODev mqtt

Wie gesagt: Ich verstehe jetzt, wie es aktuell funktioniert und kann entsprechend alles Ungewünschte mit der Zeit, wenn die jeweiligen Messages versendet werden filtern, finde dieses Vorgehen aber fehleranfälliger, aufwendiger und weniger intuitiv.

Vielleicht kann ja auch jemand anderes ein Beispiel nennen, wo das aktuelle Verhalten notwendig ist - wie gesagt, sehe gerade keins und es ist immer einfach zu verstehen, wenn man den use case kennt.

[HomeAlone]

Die TLS Unterstützung wird kommen, indem MQTT2_CLIENT als IODev unterstützt wird. Die erste Alpha-Version habe ich bereits, sie ist jedoch noch lange nicht einsatzfähig.

Da freue ich mich schon drauf! *thumbsup*

[hexenmeister]

Klappt soweit auch bestens, allerdings stelle ich gerade fest, dass auch ein HM-Device "mitpublished", obwohl es nicht in den Räumen definiert ist, die ich in der Bridge konfiguriert habe.

Habe jetzt so eine Prüfung hinterlegt (nur Geräte berücksichtigen, die zu dem DevSpec im DEF passen). Habe allerdings nur minimal getestet (eigentlich nur, ob überhaupt noch Nachrichten rausgehen). Werde heute einchecken. Bitte testen, ob das so wie gewünscht funktioniert.

[hexenmeister]

Zu MQTT2 Unterstützung...
Werde heute eine Version einchecken, wo zumindest Empfangn von Nachrichten über MQTT2(CLIENT und SERVER) funktioniert. Muss noch gründlich getestet werden.
Habe zum Thema einen neuen Thread aufgemacht: https://forum.fhem.de/index.php/topic,93255.msg858912.html#msg858912

[Billy]

@Hexenmeister

Bin heute endlich dazu gekommen, JSON-Unterstützung für Subscribe anzusehen.
Wie ich es schon vermutet habe, kann diese leicht mit Hilfe von "expression" in mqttSubscribe realisiert werden.

Code Auswählen Erweitern

json:topic=/TEST/json json:expression={json2nameValue($message)}

In MQTT2_DEVICE  ist in der Klammer { json2nameValue($EVENT) }
Könnte man {json2nameValue($message)} angleichen da beide Welten ja über MQTT_GENERIC_BRIDGE zusammenwachsen?

Gruß Billy

[hexenmeister]

Könnte man natürlich, aber zu welchem Zweck? Ich sehe eigentlich keine Notwendigkeit sowohl die Bridge als auch MQTT2_DEVICE gleichzeitig zu verwenden. Bridge kann ja das andere komplett ersetzen und auch vice-versa. Die Frage ist nur, wie man es haben möchte. Ausserdem erscheint mir message an dieser Stelle treffender als EVENT.
Wenn natürlich eine gute Begründung existiert, lassen ich mich überzeugen.

[Billy]

Wenn natürlich eine gute Begründung existiert, lassen ich mich überzeugen.

Nur "same name for same thing".
Aber nicht wesentlich.

[HomeAlone]

Habe jetzt so eine Prüfung hinterlegt (nur Geräte berücksichtigen, die zu dem DevSpec im DEF passen). Habe allerdings nur minimal getestet (eigentlich nur, ob überhaupt noch Nachrichten rausgehen). Werde heute einchecken. Bitte testen, ob das so wie gewünscht funktioniert.

Habe die Version jetzt getestet: Meine EnOcean, ZWave und HomeMatic Räume jeweils einzeln, zu zweit oder zu dritt in devspec eingebunden: Funktioniert einwandfrei! Die nicht definierten Klassen (Räume) werden nicht gepublished, so wie es sein soll.

Super vielen Dank für die fixe Implementierung!

[hexenmeister]

Danke fürs Testen, das nimmt mir viel Arbeit ab

[HomeAlone]

Zu MQTT2 Unterstützung...
Werde heute eine Version einchecken, wo zumindest Empfangn von Nachrichten über MQTT2(CLIENT und SERVER) funktioniert. Muss noch gründlich getestet werden.
Habe zum Thema einen neuen Thread aufgemacht: https://forum.fhem.de/index.php/topic,93255.msg858912.html#msg858912

Klasse! Komme erst später am Abend oder morgen früh zum Testen, werde das aber definitiv machen! Super Sache!

[hexenmeister]

Klasse! Komme erst später am Abend oder morgen früh zum Testen, werde das aber definitiv machen! Super Sache!

Rudi hat netterweise ein paar Erweiterungen in die MQTT2* Module integriert. Ich vermute jedoch, dass erstmal mein Modul nichts mehr senden kann. Ich muss eine kleine Änderung durchführen, komme heute jedoch aller Voraussicht nach nicht mehr dazu. Kann also sein, dass nach dem Update morgen mein Modul mit mqtt2 ein-zwei Tage nicht richtig läuft.

[Maui]

Bin heute endlich dazu gekommen, JSON-Unterstützung für Subscribe anzusehen.
Wie ich es schon vermutet habe, kann diese leicht mit Hilfe von "expression" in mqttSubscribe realisiert werden.
Eine kleine Modifikation im Code machte das noch etwas einfacher und hier ist ein Beispiel für funktionierende Konfiguration:

Code Auswählen Erweitern

json:topic=/TEST/json json:expression={json2nameValue($message)}

Sendet man jetzt z.B. folgende JSON: {"jtest1":"jval1","jtest2":"jval2"} dann werden zwei Readings (jtest1 und jtest2) entsprechend angelegt/aktualisiert.

Jetzt mache ich mich an die Unterstützung von MQTT2

Moin Alex,
grad gesehen, dass json schon drin ist. Funktioniert super. Danke dir.
Jetzt steht einem Ersetzen aller mqtt's gegen Generic_dummys nix mehr im Weg.

[hexenmeister]

Jo, sollte alles funktionieren. Auch mit mqtt2. Melde dich, wenn etwas nicht funktioniert.

[Billy]

Binjetzt am implementieren der MQTT_GENERIC_BRIDGE auf meine Produktivsysteme.

Das sieht gut aus. sowohl mit IODev  MQTT alsauch IODev MQTT2_CLIENT.

Mal eine Frage, was bringt eine Wechsel von IODev  MQTT  zu IODev MQTT2_CLIENT.
Welchen Vorteil hat das wenn ja alles über die MQTT_GENERIC_BRIDGE angebunden ist?
Gibt es auch Nachteile?

[Beta-User]

Im Moment ist mqtt2-client erst in der Entwicklung, kann also auch Probleme machen.

Umstellen würde ich persönlich im Moment nicht, funktioniert ja soweit. Erst bei einer Neuinstallation oder einem Servertausch hätte mqtt2-client Vorteile, da keine Perl-Komponenten erforderlich sind (cpan).