Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

mark79 · 18 November 2018, 17:45:15

Zitat von: rudolfkoenig am 18 November 2018, 00:27:39
Wie schon angedeutet und gerade hier angekuendigt, habe ich ein Template-Machanismus implementiert.

Könntest du bei dem Template bei den Zigbee2mqtt Bulbs noch ein "eventMap on:ON:off off:OFF:on" mit einbauen?
Weil ohne eventMap lassen sich diese sonst nicht ausschalten:

Code Auswählen

zigbee2mqtt/0x90fd9ffffe0e11b3/set {"state":"ON"}
zigbee2mqtt/0x90fd9ffffe0e11b3 {"state":"ON","brightness":180,"color_temp":381}

zigbee2mqtt/0x90fd9ffffe0e11b3/set {"state":"ON"}
zigbee2mqtt/0x90fd9ffffe0e11b3 {"state":"ON","brightness":180,"color_temp":381}

zigbee2mqtt/0x90fd9ffffe0e11b3/set {"state":"ON"}
zigbee2mqtt/0x90fd9ffffe0e11b3 {"state":"ON","brightness":180,"color_temp":381}

Ansonsten klappt das super und man kann die Lampe jetzt auch gedimmt einschalten lassen, das ging mit dem alten MQTT vorher nicht. Damit kann ich endlich mein Lichtwecker umsetzen.

Ich habe es mit MQTT2_Client umgesetzt und mit einer LED1546G12 von Ikea, brightness und color_temp geht auch.

Viele Grüße
Mark

hexenmeister · 18 November 2018, 17:50:38

ZitatAnsonsten klappt das super und man kann die Lampe jetzt auch gedimmt einschalten lassen, das ging mit dem alten MQTT vorher nicht.

MQTT ist nur der Vermittler. Alles was mit neuer Version geht, ging auch mit der alten.

mark79 · 18 November 2018, 20:06:13

Zitat von: hexenmeister am 18 November 2018, 17:50:38
MQTT ist nur der Vermittler. Alles was mit neuer Version geht, ging auch mit der alten.

Ja das ist schon klar, nur das durch die neuen MQTT2 Module das Device fast fertig einrichtet wird.

Mit zigbee2mqtt und MQTT Modul habe ich das damals nicht hinbekommen die Ikea Birne gedimmt einzuschalten, weil er mir immer zuviele "" in den MQTT Befehl reingesetzt hat. Du hattest das Modul übernommen und seit dem hatte ich es nicht noch mal neu getestet...
Ich weiß also nicht woran das lag, an zigbee2mqtt Modul, MQTT Modul oder ob das Problem vor dem Bildschirm saß, aber ist jetzt auch wurscht.

hexenmeister · 18 November 2018, 20:10:00

Das ist schon richtig. Hauptsache es läuft.

rudolfkoenig · 18 November 2018, 21:06:59

ZitatKönntest du bei dem Template bei den Zigbee2mqtt Bulbs noch ein "eventMap on:ON:off off:OFF:on" mit einbauen?

Das muss irgendwie anders zu loesen sein, wenn ich das Setze, dann kriege ich das angehaengte Bild: "set XX OFF on" ist fuer mich unverstaendlich, ich habe eventMap auch deswegen zunaechst entfernt. Ohne kann ich ein und ausschalten:

Code Auswählen

2018.11.18 19:05:25 5: mq: PUBLISH zigbee2mqtt/kueche/set {"state":"OFF"}
2018.11.18 19:05:36 5: mq: PUBLISH zigbee2mqtt/kueche/set {"state":"ON"}

ZitatMQTT ist nur der Vermittler. Alles was mit neuer Version geht, ging auch mit der alten.

Das wuerde ich auch nicht bezweifeln, die Frage ist, was man mit einem bestimmten Wissenstand eher konfiguriert kriegt.

hexenmeister · 18 November 2018, 21:20:43

Zitat von: rudolfkoenig am 18 November 2018, 21:06:59
Das wuerde ich auch nicht bezweifeln, die Frage ist, was man mit einem bestimmten Wissenstand eher konfiguriert kriegt.

Sehe ich ein. Und weil die alten Module schon etwas kryptisch waren, habe ich das Modul MQTT_GENERIC_BRIDGE implementiert. Jetzt auch mit MQTT2.* einsetzbar

akr1983 · 20 November 2018, 00:40:37

Hiho,

gab es seit gestern eine wichtige Änderung bei MQTT2_client? Hab heute sehr viel an meinem System gedreht und jetzt horcht mein MQTT2_Client device nicht mehr. Auch ein löschen des Client Devices gab keinen Erfolg... per Autocreate gibt es auch kein neues device mehr.

Code Auswählen


defmod mqtt2_client MQTT2_CLIENT 192.168.2.4:1883
attr mqtt2_client autocreate 1
attr mqtt2_client room MQTT2_DEVICE
attr mqtt2_client subscriptions #

setstate mqtt2_client opened
setstate mqtt2_client 2018-11-20 00:37:07 state opened

Zusätzlich bekomm ich im MQTT Log jetzt immer die folgende Meldung:

Code Auswählen


2018-11-19T23:37:37.474026342Z 1542670657: Socket error on client <unknown>, disconnecting.
2018-11-19T23:37:37.530962719Z 1542670657: New connection from 172.18.0.1 on port 1883.

Ein setzen der ClientID macht leider auch keinen Unterschied... Ich hoffe, da ist nur ein Fehler beim Update passiert. Aktuell tut das MQTT2_Client device nämlich gar nix mehr...
Und Weibchen wird ungeduldig, weil das Licht nicht mehr automatisch angeht

Kurz was anderes, ich hab mal ein paar weitere Definitionen in die mqtt2.template eingebaut:

Code Auswählen

name:zigbee2mqtt_bulb
filter:TYPE=MQTT2_DEVICE
par:NAMEINTHEBRIDGE;name of this device in the bridge;{ AttrVal("DEVICE","readingList","") =~ m,zigbee2mqtt/(.*):, ? $1 : undef }
attr DEVICE icon hue_filled_living_whites
attr DEVICE stateFormat {sprintf(lc ReadingsVal("$name","state",0))}
attr DEVICE devStateIcon {devStateIcon255($name)}
attr DEVICE setList \
  on:noArg zigbee2mqtt/NAMEINTHEBRIDGE/set {"state":"ON"}\
  off:noArg zigbee2mqtt/NAMEINTHEBRIDGE/set {"state":"OFF"}\
  brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/NAMEINTHEBRIDGE/set {"state":"on","$EVTPART0":"$EVTPART1"}

name:zigbee2mqtt_colorbulb
filter:TYPE=MQTT2_DEVICE
par:NAMEINTHEBRIDGE;name of this device in the bridge;{ AttrVal("DEVICE","readingList","") =~ m,zigbee2mqtt/(.*):, ? $1 : undef }
attr DEVICE icon hue_filled_white_and_color_e27_b22
attr DEVICE stateFormat {sprintf(lc ReadingsVal("$name","state",0))}
attr DEVICE devStateIcon {devStateIcon255($name)}
attr DEVICE webCmd toggle:on:off:brightness:color:color_temp
attr DEVICE setList \
  on:noArg zigbee2mqtt/NAMEINTHEBRIDGE/set {"state":"ON"}\
  off:noArg zigbee2mqtt/NAMEINTHEBRIDGE/set {"state":"OFF"}\
  brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/NAMEINTHEBRIDGE/set {"state":"on","$EVTPART0":"$EVTPART1"}\
  color_temp:colorpicker,CT,250,1,454 zigbee2mqtt/NAMEINTHEBRIDGE/set {"$EVTPART0":"$EVTPART1"}\
  color:colorpicker,RGB {"zigbee2mqtt/NAMEINTHEBRIDGE/set " . encode_json(convertRGBtoR_G_B($EVTPART1))}

name:zigbee2mqtt_colorbulb_withoutColorTemp
filter:TYPE=MQTT2_DEVICE
par:NAMEINTHEBRIDGE;name of this device in the bridge;{ AttrVal("DEVICE","readingList","") =~ m,zigbee2mqtt/(.*):, ? $1 : undef }
attr DEVICE icon hue_filled_white_and_color_e27_b22
attr DEVICE stateFormat {sprintf(lc ReadingsVal("$name","state",0))}
attr DEVICE devStateIcon {devStateIcon255($name)}
attr DEVICE webCmd toggle:on:off:brightness:color
attr DEVICE setList \
  on:noArg zigbee2mqtt/NAMEINTHEBRIDGE/set {"state":"ON"}\
  off:noArg zigbee2mqtt/NAMEINTHEBRIDGE/set {"state":"OFF"}\
  brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/NAMEINTHEBRIDGE/set {"state":"on","$EVTPART0":"$EVTPART1"}\
  color:colorpicker,RGB {"zigbee2mqtt/NAMEINTHEBRIDGE/set " . encode_json(convertRGBtoR_G_B($EVTPART1))}

name:zigbee2mqtt_smoke_detector
filter:TYPE=MQTT2_DEVICE
par:NAMEINTHEBRIDGE;name of this device in the bridge;{ AttrVal("DEVICE","readingList","") =~ m,zigbee2mqtt/(.*):, ? $1 : undef }
attr DEVICE icon secur_smoke_detector
attr DEVICE stateFormat smoke

Wenn mein Modul wieder läuft, würde ich auch templates für den Water_leakage Sensor machen sowie für die Temperatur und humidity Sensoren...

Lg
Arne

rudolfkoenig · 20 November 2018, 07:42:34

Zitatgab es seit gestern eine wichtige Änderung bei MQTT2_client?

Die letzten Aenderungen waren am 15 und 16.11, und dabei wurde die interne Schnittstelle zwischen MQTT2_DEVICE und MQTT2_CLIENT/SERVER umgebaut, damit MQTT_GENERIC_BRIDGE mehr Optionen hat. Weiterhin wird beim FHEM shutdown/etc ein DISCONNECT gesendet, und man kann mit msgBeforeDisconnect/msgAfterConnect zusaetzliche Meldungen versenden.

Die erwaehnten Fehler sollten nicht aus den Aenderungen stammen.
Kannst du bitte Folgendes testen:
- was steht im FHEM Log bei einem "attr mqtt2_client verbose 5"
- funktioniert es mit der letzten MQTT2_CLIENT Version (Achtung, du musst auch MQTT2_DEVICE zurueckrollen)
- was war die letzte MQTT2_CLIENT Version?

Prinzipiell sollte MQTT2_CLIENT funktionieren, ich habe seitdem viele Tests damit durchgefuehrt

akr1983 · 20 November 2018, 08:00:42

Guten morgen,

verbose 5 ist gesetzt, allerdings werd ich aus dem Log nicht schlau. Steht genau "nix" drin.

Code Auswählen


"2018-11-20 07:57:30"	"mqtt2_client"	"MQTT2_CLIENT"	"DISCONNECTED"	"state"	"DISCONNECTED"	""
"2018-11-20 07:57:30"	"mqtt2_client"	"MQTT2_CLIENT"	"CONNECTED"	"state"	"CONNECTED"	""
"2018-11-20 07:57:08"	"mqtt2_client"	"MQTT2_CLIENT"	"DISCONNECTED"	"state"	"DISCONNECTED"	""
"2018-11-20 07:57:08"	"mqtt2_client"	"MQTT2_CLIENT"	"CONNECTED"	"state"	"CONNECTED"	""

Ich benutz übrigens DBLog, also nicht über die Formatierung wundern.

Ich hab zusätzlich noch das Modul MQTT_Broker im Einsatz. Das tut weiterhin seinen Dienst. :-/

Hier noch ein Auszug beim Senden im Log:

Code Auswählen


2018.11.20 08:14:16 5: mqtt2_client: sending PUBLISH zigbee2mqtt/Kueche_Licht_Arbeitsplatte/set {"state":"OFF"}
2018.11.20 08:14:16 1: 192.168.2.4:1883 disconnected, waiting to reappear (mqtt2_client)
2018.11.20 08:14:16 5: HttpUtils url=http://192.168.2.4:1883/
2018.11.20 08:14:16 1: 192.168.2.4:1883 reappeared (mqtt2_client)

Lg
Arne

rudolfkoenig · 20 November 2018, 10:38:14

Gehen beide Verbindungen zum gleichen Server?

Evtl. hat mosquitto eine spezielle Logik, ich musste in MQTT2_SERVER auch Sonderlogik einbauen, wenn vom gleichen IP mit gleichen clientId zwei Verbindungen hergestellt sind, da manche MQTT-Clients da (mAn) sich komisch verhalten.

mark79 · 20 November 2018, 18:00:06

Zitat von: rudolfkoenig am 18 November 2018, 21:06:59
Das muss irgendwie anders zu loesen sein, wenn ich das Setze, dann kriege ich das angehaengte Bild: "set XX OFF on" ist fuer mich unverstaendlich, ich habe eventMap auch deswegen zunaechst entfernt. Ohne kann ich ein und ausschalten:
Code Auswählen Erweitern
2018.11.18 19:05:25 5: mq: PUBLISH zigbee2mqtt/kueche/set {"state":"OFF"} 2018.11.18 19:05:36 5: mq: PUBLISH zigbee2mqtt/kueche/set {"state":"ON"}

Das wuerde ich auch nicht bezweifeln, die Frage ist, was man mit einem bestimmten Wissenstand eher konfiguriert kriegt.

Das ist komisch, bei mir ist das genau anders herum.

Ich habe das eventMap noch mal gelöscht, aber dann lässt sie sich wie oben nicht mehr ausschalten und das DevStateIcon ist auch verschwunden.
Das muss wohl an der Groß/Kleinschrift vom STATE von ON/on:OFF/on liegen:

Setzte ich ein... kommt untere Fehlermeldung:

Code Auswählen

set MQTT2_zigbee_90fd9ffffe0e11b3 OFF

Unknown argument OFF, choose one of on off brightness color_temp blink on-till off-till toggle on-till-overnight off-till-overnight intervals on-for-timer off-for-timer attrTemplate

Code Auswählen

set MQTT2_zigbee_90fd9ffffe0e11b3 off
Damit gehts...

Hier noch ein List:

Code Auswählen

Internals:
   CFGFN      
   CID        zigbee_90fd9ffffe0e11b3
   DEF        zigbee_90fd9ffffe0e11b3
   DEVICETOPIC MQTT2_zigbee_90fd9ffffe0e11b3
   IODev      mqtt2_client
   LASTInputDev mqtt2_client
   MSGCNT     43
   NAME       MQTT2_zigbee_90fd9ffffe0e11b3
   NR         711
   STATE      ON
   TYPE       MQTT2_DEVICE
   mqtt2_client_MSGCNT 43
   mqtt2_client_TIME 2018-11-20 17:54:47
   READINGS:
     2018-11-20 17:54:47   brightness      195
     2018-11-20 17:54:47   color_temp      381
     2018-11-20 17:54:47   state           ON
Attributes:
   DbLogExclude .*
   IODev      mqtt2_client
   eventMap   on:ON:off off:OFF:on
   icon       light_control
   readingList zigbee2mqtt/0x90fd9ffffe0e11b3:.* { json2nameValue($EVENT) }
   room       habridge,MQTT2_DEVICE
   setList    on:noArg zigbee2mqtt/0x90fd9ffffe0e11b3/set {"state":"ON"}
  off:noArg zigbee2mqtt/0x90fd9ffffe0e11b3/set {"state":"OFF"}
  brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/0x90fd9ffffe0e11b3/set {"state":"on","$EVTPART0":"$EVTPART1"}
  color_temp:colorpicker,CT,250,1,454 zigbee2mqtt/0x90fd9ffffe0e11b3/set {"$EVTPART0":"$EVTPART1"}
   webCmd     brightness:color_temp

akr1983 · 20 November 2018, 18:56:37

Zitat von: rudolfkoenig am 20 November 2018, 10:38:14
Gehen beide Verbindungen zum gleichen Server?

Evtl. hat mosquitto eine spezielle Logik, ich musste in MQTT2_SERVER auch Sonderlogik einbauen, wenn vom gleichen IP mit gleichen clientId zwei Verbindungen hergestellt sind, da manche MQTT-Clients da (mAn) sich komisch verhalten.

Jupp, beide Verbindungen gehen zum gleichen Server. Ich werde jetzt zum letzten Backup zurückgehen und gucken, ob der Fehler nochmal auftritt. Du hast jetzt ja die Templates implementiert, wofür ich dich küssen könnte! Da geht das alles viel einfacher

Und trotzdem danke!

akr1983 · 21 November 2018, 00:37:36

Zitat von: rudolfkoenig am 20 November 2018, 10:38:14
Gehen beide Verbindungen zum gleichen Server?

Evtl. hat mosquitto eine spezielle Logik, ich musste in MQTT2_SERVER auch Sonderlogik einbauen, wenn vom gleichen IP mit gleichen clientId zwei Verbindungen hergestellt sind, da manche MQTT-Clients da (mAn) sich komisch verhalten.

Ich hab den Fehler gefunden... Ich hab meine Devices umbenannt. Also z.B.

Code Auswählen

rename MQTT2_zigbee_WZ_Licht_Blumenbank WZ_Licht_Blumenbank

Das hab ich gemacht, damit die Devices auf die "alten" notify reagieren, da ich ja vom Xiaomi Modul gewechselt hab. Es funktioniert auch einwandfrei, bis ich FHEM neustarte. Danach sind die Devices ohne Funktion und absurderweise gibt es dann die MQTT Disconnect Meldung... Kann ich wunderbar reproduzieren.

Lg
Arne

rudolfkoenig · 22 November 2018, 10:36:28

ZitatKurz was anderes, ich hab mal ein paar weitere Definitionen in die mqtt2.template eingebaut:

Habe die beiden Eintraege ohne Pruefung uebernommen.

rudolfkoenig · 22 November 2018, 11:14:23

@mark79: bitte die Listings demnaechst mit "list -r" oder "Raw definition" Link unten in der Detailansicht erstellen, sonst muss ich fuers Nachstellen anfangen zu editieren und ich will Arbeit sparen und Vertipper vermeiden.

Sonst: ich bleibe bei meiner Aussage: mit dem eventMap ist nicht nur die Anzeige kaputt, es wird auch was kaputtes per publish zum MQTT Server weitergegeben. Auch von der "Theorie" her macht dieses Eventmap keinen Sinn. Wuerde mich freuen, wenn jemand mir zeigt, wo das Problem ist. Bzgl. ON/on: Das ist so gewollt, und sollte funktionieren. Ich habe fuer ON/OFF Icon-Alias angelegt, damit man fuer die Icons das lowercase sparen kann.

@akr1983: ich habe jetzt eine Weile mit mosquitto und ein FHEM mit MQTT2_CLIENT und MQTT gespielt, kann aber kein Problem feststellen. Ein rename setzt zwar interne Datenstrukturen um, sollte aber nichts bewirken. Bei einem gerade durchgefuehrten Test mit MQTT_CLIENT/mosquitto, habe ich kein Unterschied gesehen, d.h. ich vermute, die Ursache ist was Anderes, was mir noch unbekannt ist.