MQTT2_CLIENT Probleme

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

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Dass es zunehmend mehr Geraete MQTT verwenden, ist mir klar, aber dass die Mehrheit MQTT fuer ein ausgefallenes Routing verwenden will, das glaube ich nicht.

ZitatWelche Fälle bei den Matcher sind problematisch?
Mit einer Definition wie
attr sonoff readingList tele/sonoff/S.* { json2nameValue($EVENT) } haette ich so meine Schwierigkeiten.
readingList in MQTT2_DEVICE ist eine Liste von "regexp mapping" Paare, wobei der Regexp topic:message matchen muss.

ZitatDerzeit meldet sich MQTT_GENERIC_BRIDGE beim MQTT über ein sub call bei jeder Ändeurng.
Das ist unpassend.
Ich wuerde IOWrite($hash, "subscribe", "space separated list of subscriptions") vorziehen, das waere "portabel".

HomeAlone

Zitat von: hexenmeister am 08 November 2018, 18:53:22
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.

Das Bridging ist bei Verwendung von MQTT nicht auf fhem-Instanzen beschränkt. Ich nutzte MQTT zum Bridging zwischen fhem (nativ installiert) und Anbindung von anderen "Hardware-Treibern" die als Containern-Images realisiert sind - z.B. zigbee2mqtt und Node Red. Im Endeffekt kommt es auf dasselbe heraus, wie bei Hexenmeister: Was drunter läuft, ist egal - die Kommunikation geschieht aber standardisiert via MQTT.

Was zum Glück fehlt wäre von der Funktion her die "MQTT2_GENERIC_BRIDGE", mit der Flexibilität der MQTT_GENERIC_BRIDGE und der Möglichkeit, einen externen MQTT-Broker sicher (Authentifizierung und Verschlüsselung) einzubinden.

hexenmeister

Meine Idee ist, das Modul so zu erweitern, dass beides in einem unterstützt wird. Eine zusätzliche MQTT2_GENERIC_BRIDGE würde nur mehr Pflege bedeuten.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

rudolfkoenig

Benutzername/Passwort sollte mit MQTT2_CLIENT funktionieren.
SSL (aka TLS) auch, habe ich aber nie getestet.

hexenmeister

Zitat von: rudolfkoenig am 09 November 2018, 00:00:48
Mit einer Definition wie

attr sonoff readingList tele/sonoff/S.* { json2nameValue($EVENT) }

haette ich so meine Schwierigkeiten.
readingList in MQTT2_DEVICE ist eine Liste von "regexp mapping" Paare, wobei der Regexp topic:message matchen muss.
Das sehe ich ein. Die Definition ist nicht nach MQTT-Regteln abbildbar. Dort gehen Platzhaltern nur für ganze SubTopics, nicht für Teile davon, die mit 'S' anfangen ;D GENERIC_BRIDGE und auch (glaube ich) MQTT erlauben auch nur das, was MQTT-Protokoll auch her gibt. Daher sehe ich kein Problem dabei, dies auch so zu begrenzen.

ZitatIch wuerde IOWrite($hash, "subscribe", "space separated list of subscriptions") vorziehen, das waere "portabel".
Ok, passt. Dann aber wahrscheinlich auch analog für 'unsubscribe'.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

rudolfkoenig

ZitatOk, passt. Dann aber wahrscheinlich auch analog für 'unsubscribe'.
Einfachheithalber wuerde ich nur subscribe haben wollen, und ich wuerde bei jeder Aenderung die Verbindung zu mosquitto neu aufmachen. Spricht was dagegen / hast du vor die subscriptions oft zu aendern?

hexenmeister

Zitat von: rudolfkoenig am 09 November 2018, 13:17:46
Einfachheithalber wuerde ich nur subscribe haben wollen, und ich wuerde bei jeder Aenderung die Verbindung zu mosquitto neu aufmachen. Spricht was dagegen / hast du vor die subscriptions oft zu aendern?
Jain. Streng genommen können in der Zwischenzeit ankommende Nachrichten verloren gehen.
Im normalen Betrieb ändern sich die Subscription eigentlich nicht von alleine. Nur, beim Start (während die Geräte initialisiert werden) und wenn der Benutzer die entsprechenden subscribe-Attribute ändert.
Beim Start wartet GenericBridge eh darauf, dass FHEM 'initialized' meldet, bleibt also nur die Änderung durch de Benutzer. Nicht die reine Lehre, sollte jedoch nicht das Problem sein. Man sollte nur darauf auchten, die Verbindung korrekt zu schliessen, sonst fliegen LWTs. ;D
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Noch ein kleiner Wunsch:
MQTT-Modul erlaubt nicht nur LWT zu definieren, sondern auch beim Connect / Disconnect topics abzusetzen. Damit kann man gut den Status per MQTT nachverfolgen:
- gestartet und verbunden
- disconnected / sauber beendet
- abgestürzt.

So ein OnConnect/OnDisconnect Message sind natürlich auch mit Notify möglich, wären aber in Modul IMHO ganz an der rechten Stelle :)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

rudolfkoenig

ZitatNicht die reine Lehre, sollte jedoch nicht das Problem sein.
Dann werden wir nur mit subscription starten, und wenn es zu Problemen fuehrt, weitersehen.

Zitatbeim Connect / Disconnect topics abzusetzen.
Das Disconnect topic haette ich gerne im Detail erklaert bekommen. Ich dachte das nennt sich LWT.

ZitatSo ein OnConnect/OnDisconnect Message sind natürlich auch mit Notify möglich
Dann wollen wir ja das auch dabei belassen, und das Modul schoen einfach halten :)
Ich bin immer noch der Ansicht, dass sowas nur in Spezialfaellen notwendig ist, und solche Benutzer werden ein notify dazubauen koennen.

hexenmeister

#39
Zitat von: rudolfkoenig am 09 November 2018, 13:43:09
Dann werden wir nur mit subscription starten, und wenn es zu Problemen fuehrt, weitersehen.
OK.

ZitatDas Disconnect topic haette ich gerne im Detail erklaert bekommen. Ich dachte das nennt sich LWT.
LWT wird dann von Server los gelassen, wenn der Client sich ohne abzumelden verabschiedet. Normal Abmelden lösst kein LWT, bin mir da recht sicher.
EDIT: ein schnelles Googeln: http://www.steves-internet-guide.com/mqtt-last-will-example/

ZitatDann wollen wir ja das auch dabei belassen, und das Modul schoen einfach halten :)
Ich bin immer noch der Ansicht, dass sowas nur in Spezialfaellen notwendig ist, und solche Benutzer werden ein notify dazubauen koennen.
Kann damit gut leben, habe nur erwähnt, weil das 'alte' Modull das kann.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Ähm... Vielleicht doch nicht so einfach mit dem notify. Für eine disconnected message muss ich nicht nur den event mitbekommen, sondern auch noch vor dem eigentlichen disconnect die Nachricht versenden können... 😐
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Billy

Bug?
habe einen Sonoff POW mit MQTT2_DEVICE eingebunden.
Das Ergebnis war positiv, insbesondere hat mich die implementierte Json Auflösung mit { json2nameValue($EVENT) }
begeistert.
---------------
Problem!
Ich hatte dann bemerkt, dass inzwischen eine neue  MQTT2_DEVICE und MQTT2_CLIENT Version
verfügbar war --> nach update werden die Readings nicht mehr aktualisiert!
List:
Internals:
   CID        DVES_92312B
   DEF        DVES_92312B
   DEVICETOPIC MQTT2_DVES_92312B
   IODev      mqtt2client
   NAME       MQTT2_DVES_92312B
   NR         144
   STATE      off
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-11-09 16:34:58   ENERGY_Current  0.000
     2018-11-09 16:34:58   ENERGY_Factor   0.00
     2018-11-09 16:34:58   ENERGY_Period   0
     2018-11-09 16:34:58   ENERGY_Power    0
     2018-11-09 16:34:58   ENERGY_Today    0.009
     2018-11-09 16:34:58   ENERGY_Total    0.034
     2018-11-09 16:34:58   ENERGY_Voltage  0
     2018-11-09 16:34:58   ENERGY_Yesterday 0.003
     2018-11-09 16:29:08   POWER           OFF
     2018-11-09 16:34:58   Time            2018-11-09T16:34:58
     2018-11-09 17:04:25   state           off
Attributes:
   IODev      mqtt2client
   devStateIcon devStateIcon on:black_Steckdose.on off:black_Steckdose.off
   readingList DVES_C22239:stat/sonoff_pw2/POWER:.* POWER
DVES_C22239:tele/sonoff_pw2/SENSOR:.* { json2nameValue($EVENT) }
   room       MQTT2
   setList    on cmnd/sonoff_pw2/POWER on
off cmnd/sonoff_pw2/POWER off
   stateFormat state
   webCmd     on:off


Update LOG
Update
   2018.11.09 16:33:00 1: UPD FHEM/00_MQTT2_CLIENT.pm
   2018.11.09 16:34:24 1: update finished,

Man sieht, dass nach dem update die Aktualisierung der Readings stopt.
Schalten on off geht noch.

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*

Billy

#42
Lösung?

Wenn ich aus der Definition readingslist
readingList DVES_C22239:stat/sonoff_pw2/POWER:.* POWER
DVES_C22239:tele/sonoff_pw2/SENSOR:.* { json2nameValue($EVENT) }


DVES_C22239: rausnehme, geht es wieder! ;)

readingList stat/sonoff_pw2/POWER:.* POWER
tele/sonoff_pw2/SENSOR:.* { json2nameValue($EVENT) }


Ist das so gewollt?

List sieht jetzt so aus!

Internals:
   CID        DVES_92312B
   DEF        DVES_92312B
   DEVICETOPIC MQTT2_DVES_92312B
   IODev      mqtt2client
   LASTInputDev mqtt2client
   MSGCNT     20
   NAME       MQTT2_DVES_92312B
   NR         144
   STATE      OFF
   TYPE       MQTT2_DEVICE
   mqtt2client_MSGCNT 20
   mqtt2client_TIME 2018-11-09 17:40:17
   READINGS:
     2018-11-09 17:39:16   ENERGY_Current  0.000
     2018-11-09 17:39:16   ENERGY_Factor   0.00
     2018-11-09 17:35:35   ENERGY_Period   0
     2018-11-09 17:39:16   ENERGY_Power    0
     2018-11-09 17:39:16   ENERGY_Today    0.015
     2018-11-09 17:39:16   ENERGY_Total    0.040
     2018-11-09 17:39:16   ENERGY_Voltage  0
     2018-11-09 17:39:16   ENERGY_Yesterday 0.003
     2018-11-09 17:40:17   POWER           OFF
     2018-11-09 17:39:16   Time            2018-11-09T17:39:15
     2018-11-09 17:40:14   state           on
Attributes:
   IODev      mqtt2client
   devStateIcon devStateIcon ON:black_Steckdose.on OFF:black_Steckdose.off
   readingList stat/sonoff_pw2/POWER:.* POWER
tele/sonoff_pw2/SENSOR:.* { json2nameValue($EVENT) }
   room       MQTT2
   setList    on cmnd/sonoff_pw2/POWER on
off cmnd/sonoff_pw2/POWER off
   stateFormat POWER
   webCmd     on:off


Passt!
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

ZitatWenn ich aus der Definition readingslist...DVES_C22239: rausnehme, geht es wieder!
Danke fuer den Hinweis, das habe ich wohl uebersehen.
Habs gefixt: fuer Geraete, die ueber bridgeRegexp erzeugt werden, wird readingList ab sofort ohne das kuenstliche clientId angelegt.

betateilchen

Zitat von: rudolfkoenig am 09 November 2018, 12:19:52
Benutzername/Passwort sollte mit MQTT2_CLIENT funktionieren.

Ja, funktioniert. Aber ich würde mir wünschen, dass es sinnvolle Meldungen im Logfile gäbe, wenn eine Verbindung wegen fehlender oder falscher user/password Daten nicht aufgebaut werden kann.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!