MQTT2_CLIENT Probleme

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

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Auf Wunsch und auf Vorrat.

#1: Es steht ab morgen ab 8 per update zur Verfuegung
#2: Modul aus SVN holen reicht nicht, da fhem.pl, DevIo.pm und MQTT2*.pm auch leicht angepasst wurden

hexenmeister

Grundsätzlich funktioniert und spricht auch mit meinem Mosquitto.
Habe leider in den nächsten tagen sehr wenig Zeit, werde aber nach und nach testen und  die GenericBridge kompatibel machen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Hat es einen bestimmten Grund, dass QOS 2 nicht implementiert ist? Wäre das aufwendig? Ist es geplant, dies irgendwan nachzuholen?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Hab gleich eine kleine Wunschliste:
  set connect
  set disconnect

autoreconnect bei Verbindungsabbruch / MQTTServer-Restart
(Leider wird die Verbindung nicht wieder aufgenommen und eine manuelle Möglichkeit gibt es auch nicht.)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

HomeAlone

Hallo zusammen. Ich möchte das Modul auch gerne testen, habe aber ein Problem bei der Implementierung:

Zunächst habe ich das Client-Device definieren (Verweis auf den lokal laufenden Mosquitto, zu Testzwecken aktuell noch ohne user/pw/tls):
define mosquitto MQTT2_CLIENT localhost:1883

Das klappt, getestet mit 
set mosquitto publish fhem/testnachricht
was auch verschickt wird.

Jetzt habe ich für meinen EnOcean Fenstergriff ein MQTT2_DEVICE erstellt und die setList definiert:

define wz_Fenstergriff_rechts_MQTT MQTT2_DEVICE
attr wz_Fenstergriff_rechts_MQTT
setList
  closed fhem/Wohnzimmer/Fenster_rechts/state closed\
  open fhem/Wohnzimmer/Fenster_rechts/state open\
  tilted fhem/Wohnzimmer/Fenster_rechts/state tilted\
  open_from_tilted fhem/Wohnzimmer/Fenster_rechts/state open_from_tilted


Hier scheine ich aber noch einen Fehler zu machen, denn bei den entsprechenden Aktionen wird keine Nachricht via MQTT versendet.
Da scheint der Wurm drin zu sein - zumindest wird keine Nachricht versendet, wenn ich den Fenstergriff betätige.

Im Log erscheint nichts zum MQTT2_CLIENT oder MQTT2_DEVICE, was mir bei der Behebung helfen würde. Eine Perl-warning, die aber eher für Rudi interessant sein dürfte:
2018.11.08 09:20:01 1: PERL WARNING: Use of uninitialized value $a[0] in string eq at ./FHEM/00_MQTT2_CLIENT.pm line 208.

Im Eventlog erscheinen die Events zum Fenstergriff:
2018-11-08 09:48:35 EnOcean wz_Fenstergriff_rechts open
2018-11-08 09:48:41 EnOcean wz_Fenstergriff_rechts closed

Jedoch keine zum MQTT2_DEVICE. Auch bei verbose level 5 kommt nichts.

Da der Zustand des Fenstergriffs im Reading state definiert wird, habe ich auch
setList
  state:closed fhem/Wohnzimmer/Fenster_rechts/state closed\
  state:open fhem/Wohnzimmer/Fenster_rechts/state open\
  state:tilted fhem/Wohnzimmer/Fenster_rechts/state tilted\
  state:open_from_tilted fhem/Wohnzimmer/Fenster_rechts/state open_from_tilted

probiert, mit demselben - gar keinem ;) - Ergebniss.

Jemand eine Idee, was ich falsch mache?

Viele Grüße
Sascha

Beta-User

Hast du auch im device mosquitto als io hinterlegt?
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

HomeAlone

Zitat von: Beta-User am 08 November 2018, 10:09:57
Hast du auch im device mosquitto als io hinterlegt?
Ja, habe ich (genauergesagt wude es automatisch angelegt ;) )

Beta-User

Du setzt den state ;) .

Da könnte $event oder Teile helfen.
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

Billy

#8
Habe mal mit dem Test auf meinem Testsystem begonnen.
1. Anlegen mit
define mqtt2client MQTT2_CLIENT 192.168.148.17:1883
attr mqtt2client autocreate 1
attr mqtt2client disable 0
attr mqtt2client room MQTT2

hat geklappt!
Einen SonoffBasic anlegen mit
define mqtt2_Sonoff8 MQTT2_DEVICE
attr mqtt2_Sonoff8 IODev mqtt2client
attr mqtt2_Sonoff8 devicetopic Sonoff/cmnd/sonoff_8
attr mqtt2_Sonoff8 disable 0
attr mqtt2_Sonoff8 room MQTT2
attr mqtt2_Sonoff8 setList on Sonoff/cmnd/sonoff_8/POWER1 ON\
off Sonoff/cmnd/sonoff_8/POWER1 OFF

hat geklappt! und lässt sich schalten! :)

Bug?
Im Event monitor kommt ständig Meldung
Global global UNDEFINED MQTT2_mqtt2client MQTT2_DEVICE mqtt2client

Und im Log
PERL WARNING: Deep recursion on subroutine "main::MQTT2_CLIENT_Read" at /data/fhem//FHEM/00_MQTT2_CLIENT.pm line 312.
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

ZitatHat es einen bestimmten Grund, dass QOS 2 nicht implementiert ist? Wäre das aufwendig? Ist es geplant, dies irgendwan nachzuholen?
Ja, Ja, haengt vom Bedarf ab.
ZitatLeider wird die Verbindung nicht wieder aufgenommen
Ich arbeite daran.

rudolfkoenig

ZitatLeider wird die Verbindung nicht wieder aufgenommen
Ist jetzt gefixt.

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.

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.

ZitatPERL WARNING: Use of uninitialized value $a[0]
Das muss ein set gewesen sein, aber eigentlich wird ein paar Zeilen vorher genau das geprueft.
Wuerde mich freuen, wenn du es mit der aktuellen Version (SVN oder morgen ab 8 per update) verifizieren koenntest, und falls es auftritt, mir genau beschreibst, wie ich es reproduzieren kann.

ZitatIm Log erscheint nichts zum MQTT2_CLIENT oder MQTT2_DEVICE, was mir bei der Behebung helfen würde.
Ich habe eine Log-Meldung auf verbose 5 beim verschicken (aka PUBLISH) hinzugefuegt, und auch die anderen Meldungen etwas umformuliert.

HomeAlone

Zitat von: Beta-User am 08 November 2018, 10:26:01
Du setzt den state ;) .

Da könnte $event oder Teile helfen.
Oh Mann, ich Depp. Ich muss dem MQTT2_DEVICE ja noch mitteilen, wenn sich etwas am Fenstergriff geändert hat.  :-[

D.h. ein DoIF für das eigentliche Device (wz_Fenstergriff_rechts) definieren, innerhalb dieses DoIFs den State des Device wz_Fenstergriff_rechts_MQTT füttern und dann noch mal schauen, ob es nicht doch klappt, korrekt?

Teste ich doch mal :)

HomeAlone

Zitat von: HomeAlone am 08 November 2018, 13:26:57
Oh Mann, ich Depp. Ich muss dem MQTT2_DEVICE ja noch mitteilen, wenn sich etwas am Fenstergriff geändert hat.  :-[

D.h. ein DoIF für das eigentliche Device (wz_Fenstergriff_rechts) definieren, innerhalb dieses DoIFs den State des Device wz_Fenstergriff_rechts_MQTT füttern und dann noch mal schauen, ob es nicht doch klappt, korrekt?

Teste ich doch mal :)

Und siehe da, kaum macht man alles richtig, schon klappts! ;)

Folgendes DOIF wirkt Wunder:

define di_wz_Fenstergriff_Change DOIF \
([wz_Fenstergriff_rechts:state] eq "open") (set wz_Fenstergriff_rechts_MQTT open) DOELSEIF \
([wz_Fenstergriff_rechts:state] eq "closed") (set wz_Fenstergriff_rechts_MQTT closed) DOELSEIF \
([wz_Fenstergriff_rechts:state] eq "tilted") (set wz_Fenstergriff_rechts_MQTT tilted) DOELSEIF \
([wz_Fenstergriff_rechts:state] eq "open_from_tilted") (set wz_Fenstergriff_rechts_MQTT open_from_tilted) DOELSE \
(set wz_Fenstergriff_rechts_MQTT notdefined)


Dann klappt es mit der normalen Definition für das Attribut setList:
attr wz_Fenstergriff_rechts_MQTT set List\
  closed fhem/Wohnzimmer/Fenster_rechts/state closed\
  open fhem/Wohnzimmer/Fenster_rechts/state open\
  tilted fhem/Wohnzimmer/Fenster_rechts/state tilted\
  open_from_tilted fhem/Wohnzimmer/Fenster_rechts/state open_from_tilted\
  notdefined fhem/Wohnzimmer/Fenster_rechts/state notdefined\


Was ich leider nicht gefunden habe: Kann man das DoIf auch vereinfachen? Im Endeffekt möchte ich ja den state 1:1 wieder übergeben. Also irgendwas in der Art:
define di_wz_Fenstergriff_Change DOIF \
([wz_Fenstergriff_rechts:state] <has_changed>) (set wz_Fenstergriff_rechts_MQTT <value of wz_Fenstergriff_rechts:state>)

Beta-User

@HomeAlone
Dein ganzes setup wirkt für mich komisch. Du hast einen Sensor. Der erzeugt per autocreate ein mqtt2_device. Damit verbinde ich gedanklich einen entfernten Sensor, der auf einer anderen fhem-installation lebt und dann per (generic) bridge übermittelt wird.
Jetzt liest es sich so, als solle ein Sensorwert versendet werden. Dafür sind die mqtt2-Module noch nicht optimiert. Heute löst man sowas noch besser mit der generic_bridge; will man nicht mosquitto nutzen sondern mqtt2_Server, muss man diesen mit 00_MQTT.pm anbinden (noch...).
Ich würde daher diesen Weg empfehlen, dürfte für die Zukunft leichter zu warten sein...
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

rudolfkoenig

Oder 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.

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