Autor Thema: MQTT2_CLIENT Probleme  (Gelesen 7519 mal)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21893
MQTT2_CLIENT Probleme
« am: 07 November 2018, 21:12:15 »
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

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4574
    • tech_LogBuch
Antw:MQTT2_CLIENT Probleme
« Antwort #1 am: 07 November 2018, 21:20:53 »
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.
In Verwendung: HM, EnOcean, 1wire, Firmata, MySensors, ESPEasy, MQTT*, NodeRED, Alexa, Telegram,..
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy
Kaffeekasse: https://www.paypal.me/s6z

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4574
    • tech_LogBuch
Antw:MQTT2_CLIENT Probleme
« Antwort #2 am: 07 November 2018, 21:57:00 »
Hat es einen bestimmten Grund, dass QOS 2 nicht implementiert ist? Wäre das aufwendig? Ist es geplant, dies irgendwan nachzuholen?
In Verwendung: HM, EnOcean, 1wire, Firmata, MySensors, ESPEasy, MQTT*, NodeRED, Alexa, Telegram,..
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy
Kaffeekasse: https://www.paypal.me/s6z

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4574
    • tech_LogBuch
Antw:MQTT2_CLIENT Probleme
« Antwort #3 am: 07 November 2018, 22:10:10 »
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.)
In Verwendung: HM, EnOcean, 1wire, Firmata, MySensors, ESPEasy, MQTT*, NodeRED, Alexa, Telegram,..
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy
Kaffeekasse: https://www.paypal.me/s6z

Offline HomeAlone

  • Full Member
  • ***
  • Beiträge: 255
Antw:MQTT2_CLIENT Probleme
« Antwort #4 am: 08 November 2018, 10:00:27 »
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/testnachrichtwas 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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9645
  • eigentlich eher "user" wie "developer"
Antw:MQTT2_CLIENT Probleme
« Antwort #5 am: 08 November 2018, 10:09:57 »
Hast du auch im device mosquitto als io hinterlegt?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline HomeAlone

  • Full Member
  • ***
  • Beiträge: 255
Antw:MQTT2_CLIENT Probleme
« Antwort #6 am: 08 November 2018, 10:16:25 »
Hast du auch im device mosquitto als io hinterlegt?
Ja, habe ich (genauergesagt wude es automatisch angelegt ;) )

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9645
  • eigentlich eher "user" wie "developer"
Antw:MQTT2_CLIENT Probleme
« Antwort #7 am: 08 November 2018, 10:26:01 »
Du setzt den state ;) .

Da könnte $event oder Teile helfen.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Billy

  • Hero Member
  • *****
  • Beiträge: 1124
Antw:MQTT2_CLIENT Probleme
« Antwort #8 am: 08 November 2018, 10:56:04 »
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.
« Letzte Änderung: 08 November 2018, 10:58:31 von Billy »
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink 13x PCA 301;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 1x KFM100, 3x HM-LC-SW1-PL2, ESP8266, Sonoff, Mqtt*

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21893
Antw:MQTT2_CLIENT Probleme
« Antwort #9 am: 08 November 2018, 11:27:16 »
Zitat
Hat 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.
Zitat
Leider wird die Verbindung nicht wieder aufgenommen
Ich arbeite daran.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21893
Antw:MQTT2_CLIENT Probleme
« Antwort #10 am: 08 November 2018, 13:18:09 »
Zitat
Leider wird die Verbindung nicht wieder aufgenommen
Ist jetzt gefixt.

Zitat
PERL 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.

Zitat
Global 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.

Zitat
PERL 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.

Zitat
Im 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.

Offline HomeAlone

  • Full Member
  • ***
  • Beiträge: 255
Antw:MQTT2_CLIENT Probleme
« Antwort #11 am: 08 November 2018, 13:26:57 »
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 :)

Offline HomeAlone

  • Full Member
  • ***
  • Beiträge: 255
Antw:MQTT2_CLIENT Probleme
« Antwort #12 am: 08 November 2018, 13:58:25 »
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>)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9645
  • eigentlich eher "user" wie "developer"
Antw:MQTT2_CLIENT Probleme
« Antwort #13 am: 08 November 2018, 14:02:40 »
@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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21893
Antw:MQTT2_CLIENT Probleme
« Antwort #14 am: 08 November 2018, 14:20:01 »
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

 

decade-submarginal