Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE

Begonnen von Master_Nick, 11 Oktober 2018, 17:23:24

Vorheriges Thema - Nächstes Thema

hexenmeister

Zitat von: Billy am 20 November 2018, 11:25:16
Welchen Vorteil hat das wenn ja alles über die MQTT_GENERIC_BRIDGE angebunden ist?
Gibt es auch Nachteile?
Vorteile? Ein wenig Geschmachssache. Die Bridge erlaubt einfachere Konfiguration der MQTT-Bindings direkt in den jeweiligen Devices.
Nachteile sollte es nicht geben. Da die Bridge noch relativ neu ist, könnte es noch Bugs in bestimmten Situationen geben. Läuft jedoch bei mir schon länger in der produktiven Umgebung ohne Probleme.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Billy

Sorry, vielleicht habe ich mich missverständlich ausgedrückt. MQTT_GENERIC_BRIDGE ist für mich gesetzt!

Ich meinte welchen Vorteil bringt es die MQTT_GENERIC_BRIDGE an MQTT2_CLIENT anzubinden?
Oder ist es besser als IODev MQTT-Brooker zu belassen?

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

Solange es läuft, würde ich es so lassen.
Ist derzeit auch vermutlich die stabilste und performanteste Lösung. Der große Vorteil von mqtt2_client ist SSL-Unterstützung.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Billy

Zitat von: hexenmeister am 20 November 2018, 17:06:39
Solange es läuft, würde ich es so lassen.
Ist derzeit auch vermutlich die stabilste und performanteste Lösung. Der große Vorteil von mqtt2_client ist SSL-Unterstützung.
Danke, SSL-Unterstützung brauche ich z.Zt. nicht, also lasse ich es so. ;)
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*

HomeAlone

Zitat von: Beta-User am 20 November 2018, 11:36:58
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).

MQTT2_CLIENT hat den entscheidenden Vorteil, dass die Kommunikation mit dem MQTT-Server TLS-verschlüsselt ablaufen kann. Wenn Du also den mosquitto nicht lokal auf dem fhem Server aufgesetzt und die Kommunikation in Mosquitto auf localhost beschränkt hast, ist die Verwendung von MQTT aus Sicherheitsgründen meiner Meinung nach in Produktivsystemen nicht empfehlenswert.

Allerdings kommt es bei mir (und anderen auch) aktuell zu Verbindungsproblemen mit dem MQTT2_CLIENT.

der-pw

#95
Hallo hexenmeister,

ich bin deinem Aufruf gefolgt und beschäftige mich eben mit. MQTT_GENERIC_BRIDGE
Weniger ist mehr ;-)

Deinem Beispiel folgend habe ich einen  Dummy angelegt.
Internals:
   CFGFN     
   LASTInputDev mqtt2_server
   MSGCNT     49
   NAME       s2xdummy
   NR         5945
   STATE      on
   TYPE       dummy
   mqtt2_server_MSGCNT 49
   mqtt2_server_TIME 2018-11-27 19:31:26
   OLDREADINGS:
   READINGS:
     2018-11-27 19:31:26   select          ON
     2018-11-27 19:31:26   state           ON
Attributes:
   DbLogExclude .*
   eventMap   ON:on OFF:off
   mqttPublish state|select:topic=cmnd/teststecki1/POWER
   mqttSubscribe state|select:topic=stat/teststecki1/POWER
   readingList select
   room       MQTT
   webCmd     on:off


"state"reagiert schön, auf das externe Schalten am Sonoff-Gerät.
Aber eine Frage habe ich, angenommen das zu schaltende Gerät ist aus, aber nicht erreichbar oder reagiert nicht.
Kann man "state" dann irgendwie abfangen und der Dummy bleibt dann weiterhin auf "off", wenn eben kein Feedback vom Sonoff zurückkommt?
Ich hoffe, ich konnte mich halbwegs verständlich ausdrücken?

Ich reagiere zwar per Notify auf den LWT eines jeden MQTT-Gerätes, aber meine Frau bekommt die Nachricht nicht, wenn dann der Schalter in Homekit einfach aus bleibt, wüsste sie, dass da was nicht stimmt.

btw:
Wenn schon ein MQTT2_DEVICE auf dem Topic lauscht, kommt am Dummy nichts mehr an, richtig?

Schöne Grüße,
Patrick

HomeAlone

Zitat von: hexenmeister am 11 November 2018, 23:18:54
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. 8)
Eine kleine Modifikation im Code machte das noch etwas einfacher und hier ist ein Beispiel für funktionierende Konfiguration:
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 :)
Gibt es hier auch Unterstützung in der anderen Richtung? Also Versenden eines JSON-Objektes (oder JSON-Strings) bei einem Publish?

Hintergrund ist, dass andere Services, wie z.B. Zigbee2MQTT einen JSON-String oder ein komplettes JSON-Objekt publishen. JSON-Strings oder JSON-Objekte lassen sich in fast allen Systemen einfach abfragen / erweitern (in meinem konkreten Fall: Node-Red). Aktuell bekomme ich von Node-Red, wenn ich die von fhem gepublishten Messages verarbeiten will, einen Syntaxfehler gemeldet.

Ich habe jetzt einmal zu Fuß probiert, beim publishen einen JSON-String zu erzeugen, scheitere aber daran, etwas JSON-mäßiges zu bekommen, da ich laut commandref lediglich auf readings zurückgreifen darf:
(Format: <reading>:topic=<topic>)
Was ich gerne würde, wäre etwas in der Art wie folgt:
*:topic={"fhempub/$device"} payload":"{\"$name\":\"expression={"message: $value"}"}

(wobei ich auch hier nicht sicher bin, ob ich die Syntax von expression richtig verstanden habe, aber ich hoffe, es wird klar, was die Idee dahinter ist.

Im Endeffekt möchte ich einen JSON-String als Rückgabe bekommen, so in der Art:
{"topic":"fhempub/az_Fensterkontakt","payload":"{\"contact\":true}

Das hätte den charmanten Vorteil, dass man den Payload geschickt noch um weitere Komponenten erweitern kann: Z.B. um eine Ergänzung des Raums, für den die Meldung gilt, oder die Art der Meldung (Bewegung/Licht/...)

Eventuell lässt sich das auch jetzt schon realisieren, ich verstehe aber aktuell nicht wie.


hexenmeister

Zitat von: der-pw am 27 November 2018, 19:44:24
Deinem Beispiel folgend habe ich einen  Dummy angelegt.
Internals:
   CFGFN     
   LASTInputDev mqtt2_server
   MSGCNT     49
   NAME       s2xdummy
   NR         5945
   STATE      on
   TYPE       dummy
   mqtt2_server_MSGCNT 49
   mqtt2_server_TIME 2018-11-27 19:31:26
   OLDREADINGS:
   READINGS:
     2018-11-27 19:31:26   select          ON
     2018-11-27 19:31:26   state           ON
Attributes:
   DbLogExclude .*
   eventMap   ON:on OFF:off
   mqttPublish state|select:topic=cmnd/teststecki1/POWER
   mqttSubscribe state|select:topic=stat/teststecki1/POWER
   readingList select
   room       MQTT
   webCmd     on:off


"state"reagiert schön, auf das externe Schalten am Sonoff-Gerät.
Aber eine Frage habe ich, angenommen das zu schaltende Gerät ist aus, aber nicht erreichbar oder reagiert nicht.
Kann man "state" dann irgendwie abfangen und der Dummy bleibt dann weiterhin auf "off", wenn eben kein Feedback vom Sonoff zurückkommt?
Ich hoffe, ich konnte mich halbwegs verständlich ausdrücken?

Ich reagiere zwar per Notify auf den LWT eines jeden MQTT-Gerätes, aber meine Frau bekommt die Nachricht nicht, wenn dann der Schalter in Homekit einfach aus bleibt, wüsste sie, dass da was nicht stimmt.
Hm. Verstehe. Naja, die Bridge lauscht auf Änderung eines Readings und gibt diese weiter (und natürlich leitet auch eine MQTT Nachricht hinein). Die Änderung ist im Gerät also schon stattgefunden und kann durch die Bridge nicht unterbunden werden. Was man natürlich machen kann, ist die Readings zu trennen. Wenn man nicht mit 'set on', sondern mit 'set select on' arbeitet, dannwird 'state' auch nicht geändert, nur 'select'. Bei einer ankommender MQTT-Nachricht zieht dann auch state mit. Ansonsten könnte man mit 'expression' Arbeiten, sollte möglich sein. Muss ich ausprobieren. Die Idee ist dabei folgende: man setzt in expression den state auf 'set_on' oder so, sendet aber 'on' weiter. Irgendwie so. Commandref wird helfen ;)



Zitat von: der-pw am 27 November 2018, 19:44:24
btw:
Wenn schon ein MQTT2_DEVICE auf dem Topic lauscht, kommt am Dummy nichts mehr an, richtig?
Nein, sind völlig unabhängig voneinander. Mehrere Geräte (oder Readings in selben Gerät) können unabhängig auf die gleiche TOpics lauschen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

der-pw

Auf "set select" zu schalten und auf "state" den Zustand zu validieren ist eine gute Idee!

ZitatNein, sind völlig unabhängig voneinander.
Dann muss ich nochmal gucken. Aktuell ist es so, sobald über autocreate ein MQTT2_DEVICE angeleget wird, dass auf den Topics lautsch, die ich auch im Dummy anlege, kommt das "subscribe" am Dummy nicht mehr an.

hexenmeister

Wenn du mqtt2_client verwendest, dann könnte es sein, dass es da Wechselwirkungen gibt. Die mqtt2 Unterstützung ist noch recht neu. Müsste ich mal ansehen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Wegen json Versand habe ich paar Ideen, wie man das bequem machen kann. Kommt noch, muss Zeit finden
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

der-pw

Zitat von: hexenmeister am 28 November 2018, 17:16:55
Wenn du mqtt2_client verwendest, dann könnte es sein, dass es da Wechselwirkungen gibt. Die mqtt2 Unterstützung ist noch recht neu. Müsste ich mal ansehen.

Ich verwende MQTT2_DEVICE in Verbindung mit MQTT2_SERVER.
Wenn es das Zusammenspiel ebenfalls betrifft, sag bescheid, wenn ich irgendwie was testen soll. ;-)

hexenmeister

Testen ist immer gut, ich stelle immer wieder fest, dass jeder seine eigene Anwendungsszenarien hat, die mir teilweise gar nicht einfallen würden :D
Wird evtl. etwas dauern - stecke leider beruflich wie privat voll im 'Jahresendstress'. >:(
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

HomeAlone

Zitat von: hexenmeister am 28 November 2018, 17:18:03
Wegen json Versand habe ich paar Ideen, wie man das bequem machen kann. Kommt noch, muss Zeit finden

Passt, Dankeschön.

Heisst im Umkehrschluss dann leider auch, dass ich das von mir gewünschte Konstrukt (gültiges JSON-String / oder JSON-Objekt) aktuell auch nicht von Hand erzeugen kann, oder?

Beta-User

Zitat von: HomeAlone am 29 November 2018, 12:38:49
Heisst im Umkehrschluss dann leider auch, dass ich das von mir gewünschte Konstrukt (gültiges JSON-String / oder JSON-Objekt) aktuell auch nicht von Hand erzeugen kann, oder?
Das sollte gehen; früher hatte ich auch mal "normales" MQTT im Einsatz und manches an Sendestring dann mit "toJSON()" zusammengestrickt; das ging auch über 00_MQTT raus.
Startpunkte für Beispiele, die evtl. weiterhelfen: https://forum.fhem.de/index.php/topic,91394.msg839718.html#msg839718
Leider finde ich den Rest an funktionierenden Beispielen nicht mehr....

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