Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

[Invers]

Vielen Dank für die WIKI-Seite.
Könnte der Autor bitte diese Formuliefung noch einmal überdenken?

Zur Einbindung von Geräten, welche mit einem MQTT-Server (früher: Broker) kommunizieren können, stehen unter FHEM zwei Optionen zur Verfügung. Details sind der zu entnehmen.

Danke

[Omega]

Ich hatte kein List oder Log beigefügt, weil ich zu wenig wusste, wo ansetzen.

Mein Bridge-Device sieht - bisher - so aus:

Code Auswählen Erweitern

define MQTT2_zigbee_pi MQTT2_DEVICE zigbee_pi
attr MQTT2_zigbee_pi DbLogExclude .*
attr MQTT2_zigbee_pi IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_pi bridgeRegexp zigbee2mqtt/([^:]*):.* "zigbee_$1"
attr MQTT2_zigbee_pi room MQTT
attr MQTT2_zigbee_pi setList permit_join:true,false zigbee2mqtt/bridge/config/permit_join $EVTPART1\
remove:textField zigbee2mqtt/bridge/config/remove $EVTPART1\
log_level:debug,info,warn,error zigbee2mqtt/bridge/config/log_level $EVTPART1\
rename:textField zigbee2mqtt/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
network_map:raw,graphviz zigbee2mqtt/bridge/networkmap  $EVTPART1\
devicelist:noArg zigbee2mqtt/bridge/config/devices

setstate MQTT2_zigbee_pi permit_join
setstate MQTT2_zigbee_pi 2018-11-24 15:35:33 state permit_join

Nachdem ich das auf <mqtt2-device> bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1" geändert hatte, waren auch die Fehler weg  .

Danke für die Unterstützung!

[Beta-User]

Vielen Dank für die WIKI-Seite.
Könnte der Autor bitte diese Formuliefung noch einmal überdenken?

Danke für den Hinweis; da ist ein Link durch Änderungen ins Leere gegangen...
Wenn jemand Muse hat, darf gerne an beiden Artikelchen weitergebastelt werden.

Was die fehlenden Readings (und evtl. das immer noch vorhandene log-Erstellungsthema) für das "Bridge-Device" angeht, glaube ich zwischenzeitlich, die Ursache gefunden zu haben: Das internal CID verweist möglicherweise auf den falschen Punkt, nämlich die eine Bulb; die hat dieselbe...   

Wie ich vorgegangen war, um überhaupt was zu erhalten, hatte ich ja geschildert. Vermutlich sollte ich alles nochmal löschen und dann mit einer Devicelistanfrage über den MQTT2-Server starten (statt eines Schaltbefehls; aber ich sehe grade, dass ich genau so (devicelist-Anfrage) gestartet war und auch das "online" nicht ausgewertet worden war). Vielleicht fehlte "nur" ein simpler FHEM-Neustart nach dem Löschen, um das alte bridgeREgexp aus dem Speicher rauszuwerfen .

Werde mir mal die jüngsten Beiträge nochmal zu Gemüte führen.

Danke jedenfalls für die Rückmeldungen!

[Ralf W.]

@Omega
Deine Variante erzeugt bei mir auch zwei Events, einmal klein und einmal groß geschrieben.

@Rudi
verbose 5 IO

Code Auswählen Erweitern

2018.12.04 11:34:51 5: SE_MQTT2_SERVER: PUBLISH zigbee2mqtt/0x84182600000ec127/set ON                                                                                                                                                                                           
2018.12.04 11:34:51 5: SE_MQTT2_SERVER_127.0.0.1_33214 z2m => zigbee2mqtt/0x84182600000ec127/set:ON                                                                                                                                                                             
2018.12.04 11:34:51 5: SE_MQTT2_SERVER_127.0.0.1_59632 mosqsub/7742-fhem => zigbee2mqtt/0x84182600000ec127/set:ON                                                                                                                                                               
2018.12.04 11:34:52 5: PUBLISH: (0)(30)zigbee2mqtt/0x84182600000ec127{"state":"ON","linkquality":81}                                                                                                                                                                           
2018.12.04 11:34:52 4: SE_MQTT2_SERVER_127.0.0.1_33214 z2m PUBLISH zigbee2mqtt/0x84182600000ec127:{"state":"ON","linkquality":81}                                                                                                                                               
2018.12.04 11:34:52 5: SE_MQTT2_SERVER_127.0.0.1_59632 mosqsub/7742-fhem => zigbee2mqtt/0x84182600000ec127:{"state":"ON","linkquality":81}                                                                                                                                     
2018.12.04 11:34:52 5: SE_MQTT2_SERVER: dispatch autocreate:z2m:zigbee2mqtt/0x84182600000ec127:{"state":"ON","linkquality":81}                                                                                                                                                 
2018.12.04 11:34:52 5: PUBLISH: (0)(30)zigbee2mqtt/0x84182600000ec127{"state":"ON","linkquality":97}                                                                                                                                                                           
2018.12.04 11:34:52 4: SE_MQTT2_SERVER_127.0.0.1_33214 z2m PUBLISH zigbee2mqtt/0x84182600000ec127:{"state":"ON","linkquality":97}                                                                                                                                               
2018.12.04 11:34:52 5: SE_MQTT2_SERVER_127.0.0.1_59632 mosqsub/7742-fhem => zigbee2mqtt/0x84182600000ec127:{"state":"ON","linkquality":97}                                                                                                                                     
2018.12.04 11:34:52 5: SE_MQTT2_SERVER: dispatch autocreate:z2m:zigbee2mqtt/0x84182600000ec127:{"state":"ON","linkquality":97}                                                                                                                                                 
2018.12.04 11:34:53 5: SE_MQTT2_SERVER: PUBLISH zigbee2mqtt/0x84182600000ec127/set OFF                                                                                                                                                                                         
2018.12.04 11:34:53 5: SE_MQTT2_SERVER_127.0.0.1_33214 z2m => zigbee2mqtt/0x84182600000ec127/set:OFF                                                                                                                                                                           
2018.12.04 11:34:53 5: SE_MQTT2_SERVER_127.0.0.1_59632 mosqsub/7742-fhem => zigbee2mqtt/0x84182600000ec127/set:OFF                                                                                                                                                             
2018.12.04 11:34:53 5: PUBLISH: (0)(30)zigbee2mqtt/0x84182600000ec127{"state":"OFF","linkquality":97}                                                                                                                                                                           
2018.12.04 11:34:53 4: SE_MQTT2_SERVER_127.0.0.1_33214 z2m PUBLISH zigbee2mqtt/0x84182600000ec127:{"state":"OFF","linkquality":97}                                                                                                                                             
2018.12.04 11:34:53 5: SE_MQTT2_SERVER_127.0.0.1_59632 mosqsub/7742-fhem => zigbee2mqtt/0x84182600000ec127:{"state":"OFF","linkquality":97}                                                                                                                                     
2018.12.04 11:34:53 5: SE_MQTT2_SERVER: dispatch autocreate:z2m:zigbee2mqtt/0x84182600000ec127:{"state":"OFF","linkquality":97}                                                                                                                                                 
2018.12.04 11:34:53 5: PUBLISH: (0)(30)zigbee2mqtt/0x84182600000ec127{"state":"OFF","linkquality":84}                                                                                                                                                                           
2018.12.04 11:34:53 4: SE_MQTT2_SERVER_127.0.0.1_33214 z2m PUBLISH zigbee2mqtt/0x84182600000ec127:{"state":"OFF","linkquality":84}                                                                                                                                             
2018.12.04 11:34:53 5: SE_MQTT2_SERVER_127.0.0.1_59632 mosqsub/7742-fhem => zigbee2mqtt/0x84182600000ec127:{"state":"OFF","linkquality":84}                                                                                                                                     
2018.12.04 11:34:53 5: SE_MQTT2_SERVER: dispatch autocreate:z2m:zigbee2mqtt/0x84182600000ec127:{"state":"OFF","linkquality":84}                                                                

Eventmonitor:

Code Auswählen Erweitern

2018-12-04 11:34:45 Global global ATTR SE_MQTT2_SERVER verbose 5
2018-12-04 11:34:51 MQTT2_DEVICE Osram_Plug on
2018-12-04 11:34:52 MQTT2_DEVICE Osram_Plug on
2018-12-04 11:34:52 MQTT2_DEVICE Osram_Plug linkquality: 97
2018-12-04 11:34:53 MQTT2_DEVICE Osram_Plug off
2018-12-04 11:34:53 MQTT2_DEVICE Osram_Plug off
2018-12-04 11:34:53 MQTT2_DEVICE Osram_Plug linkquality: 84           

MfG
Ralf                                                               

[Omega]

Ja, macht er mittlerweile bei mir auch.
Momentan mache ich fast täglich ein Update in FHEM aufgrund der vielen Änderungen in MQTT2 - wahrscheinlich hatte ich daher vor ein paar Tagen eine Konstellation bei der nur 1 Event erzeugt wurde.

[Beta-User]

So, kurzer update mit den aktuellen Modulen.

Habe jetzt mal die Bridge gelöscht+save+Neustart.

Dann auf das automatisch angelegte Device die BridgeRegex aus der cref angewendet.
Jetzt landen die "bridge" und "log"-Infos in einem weiteren automatisch angelegten Device => unnötig.
Kann man beheben, wenn man stattdessen "zigbee2mqtt/0x([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"" verwendet. Dann landen die "eigentlichen" Bridge-Readings auch im richtigen Device, sauber aufgeschlüsselt .

Was mir jetzt noch nicht gefällt: fordere ich die devicelist an ("set <bridge> devicelist"), kommt das in den state.
Habe dann mal die setList ergänzt um ein "true" (FHEM neu gestartet) und dann den Befehl nochmal abgesetzt => die Angabe "devicelist" landet trotzdem im state. An sich würde ich aber erwarten, dass das, was als setList da steht auch zu entsprechend benannten Readings führt.
Unschön, aber auch kein Beinbruch.

Danke daher für die updates, ist wieder ein merklicher Fortschritt.

Würde noch dafür plädieren, die cref um das "0x" in der bridgeRegexp zu ergänzen, vielleicht gibt es dazu noch weitere Meinungen?

[rudolfkoenig]

Jetzt landen die "bridge" und "log"-Infos in einem weiteren automatisch angelegten Device => unnötig.

Das habe ich vorher auch geschrieben, mein Vorschlag erzeugte fuer MQTT2_SERVER auch deutlic "nettere" Geraete. Ich habe mich aber fuer den Vorschlag von OdfFhem entschlossen, weil im Fall von MQTT2_CLIENT seine Loesung besser ist. Man koennte auch zwei Varianten erwaehnen, das optimale bridgeRegexp ist aber von der Quelle (MQTT2_SERVER oder MQTT2_CLIENT) und vom Lieferanten (zigbee2mqtt oder was anderes) abhaengig.
Meiner Meinung nach gehoert sowas ins Wiki.

[Beta-User]

Die Diskussion hatte ich wahrgenommen, auch den Vorschlag mit "0x".

Allerdings muß ich zugeben, dass mir das Argument mit MQTT2_CLIENT nicht so recht einleuchtet:
Der wesentliche Unterschied besteht doch darin, dass ...Client die eigentliche Herkunft der Info nicht kennt, aber weder Topic noch Payload sind unterschiedlich, egal, ob die Quelle (hier: zigbee2mqtt) das direkt an MQTT2_SERVER schickt oder an irgend einen anderen Broker, der das dann (nur mit anderer CID?) an ...Client weitergibt. Ist diese Annahme falsch?

Das eigentliche "Problem" besteht m.E. darin, dass jemand ggf. mehrere dieser Dienste nebeneinander betreiben könnte, was dann ggf. zu Verwirrung sorgen würde (insbes. mit MQTT2_Client, das ist korrekt). In diesem Fall sollte derjenige aber wissen, was er tut und dann die Topic-Angaben in der yaml (bzw. Weboberfläche des betr. Devices usw.) entsprechend anpassen. Was templates und cref angeht, sollten wir eher dafür sorgen, dass der Standard so abgebildet ist, dass ein "normaler FHEM-User" möglichst wenig Aufwand hat, wenn er die defaults nutzt.

Kann natürlich falsch liegen, aber ansonsten wäre ich dafür,
a) das mit "0x" doch in die cref aufzunehmenb) in mqtt2.template
aa) wieder "BRIDGENAME" durch "bridge" zu ersetzen (ich würde z.B. in der Konfiguration eines zweiten zigbee2mqtt-Dienstes die erste Angabe ändern (permit_join:true,false zigbee2mqtt_2/bridge/config/permit_join $EVTPART1\))
bb) gleich die bridgeRegexp in der passenden Form mit aufzunehmen (bei name:zigbee2mqtt_bridge)

Dass das so oder so in die "Praxisbeispiele" Eingang finden wird, versteht sich von selbst (deswegen mache ich die Übung hier ja...).

[rudolfkoenig]

Ist diese Annahme falsch?

Nein, aber du beruecksichtigst nicht, dass man neben zigbee2mqtt auch weitere MQTT Geraete anschliessen kann.
Und diese waeren dann beim MQTT_CLIENT zusammen mit dem Bridge in einem MQTT2_DEVICE untergebracht.

a) das mit "0x" doch in die cref aufzunehmen

Habs gemacht.
Da ich das bridge-Template ohne bridge nicht testen kann, waere es nett, von Dir/sonstwem eine getestete Version zu bekommen.

[Papaloewe]

@Rudolf

Wäre dir mit so einem fertig geflasheten ZigBee-Stick (CC2531) zum Betrieb von "zigbee2mqtt" geholfen?
Ich kann dir gerne einen für Tests und zum Verbleib zukommen lassen.

Gruß
Thomas

[Beta-User]

Anbei die für die zigbee2mqtt-Geschichte aktualisierte mqtt2.template.

Getestet habe ich die Bridge und die 1. Bulb-Variante.
Was nicht so toll ist: Nach dem Anwenden des bridge-Templates auf das automatisch angelegte device mußte ich FHEM neu starten, damit die 1. Lampe automatisch angelegt wurde. Die 2. ging dann wieder nicht automatisch. Dann habe ich es mit einem Reload von MQTT2_DEVICE versucht, mit der Folge, dass ich zwei Meldungen bzgl. des Anlegens des FileLog-Devices hatte (passend zum schon vorhandenen Bridge-Device-Namen).

Also FHEM neu gestartet, aber leider legt mir FHEM das 2. Device nicht automatisch an, wenn ich einen ON oder OFF-Command darauf absetze (der Dienst selbst meldet das aber zurück und die Lampe reagiert auch).

Irgend eine Idee dazu?

RAW-Definitionen der automatisch angelegten Geräte:

Code Auswählen Erweitern

defmod MQTT2_zigbee_pi MQTT2_DEVICE zigbee_pi
attr MQTT2_zigbee_pi IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_pi bridgeRegexp zigbee2mqtt/0x([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"
attr MQTT2_zigbee_pi readingList zigbee_pi:zigbee2mqtt/bridge/log:.* { json2nameValue($EVENT, 'log_') }\
zigbee_pi:zigbee2mqtt/bridge/state:.* state
attr MQTT2_zigbee_pi room MQTT2_DEVICE
attr MQTT2_zigbee_pi setList permit_join:true,false zigbee2mqtt/bridge/config/permit_join $EVTPART1\
  remove:textField zigbee2mqtt/bridge/config/remove $EVTPART1\
  log_level:debug,info,warn,error zigbee2mqtt/bridge/config/log_level $EVTPART1\
  rename:textField zigbee2mqtt/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
  network_map:raw,graphviz zigbee2mqtt/bridge/networkmap  $EVTPART1\
  devicelist:true zigbee2mqtt/bridge/config/devices

setstate MQTT2_zigbee_pi online
setstate MQTT2_zigbee_pi 2018-12-07 08:34:35 log_message device incoming
setstate MQTT2_zigbee_pi 2018-12-07 08:12:28 log_message_1_friendly_name 0x90fd9ffffe65db16
setstate MQTT2_zigbee_pi 2018-12-07 08:12:28 log_message_1_ieeeAddr 0x90fd9ffffe65db16
setstate MQTT2_zigbee_pi 2018-12-07 08:12:28 log_message_1_model LED1650R5
setstate MQTT2_zigbee_pi 2018-12-07 08:12:28 log_message_1_type Router
setstate MQTT2_zigbee_pi 2018-12-07 08:12:28 log_message_2_friendly_name 0x90fd9ffffe0bcd51
setstate MQTT2_zigbee_pi 2018-12-07 08:12:28 log_message_2_ieeeAddr 0x90fd9ffffe0bcd51
setstate MQTT2_zigbee_pi 2018-12-07 08:12:28 log_message_2_model LED1650R5
setstate MQTT2_zigbee_pi 2018-12-07 08:12:28 log_message_2_type Router
setstate MQTT2_zigbee_pi 2018-12-07 08:34:35 log_type pairing
setstate MQTT2_zigbee_pi 2018-12-07 08:34:26 state online


defmod MQTT2_zigbee_90fd9ffffe0bcd51 MQTT2_DEVICE zigbee_90fd9ffffe0bcd51
attr MQTT2_zigbee_90fd9ffffe0bcd51 IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_90fd9ffffe0bcd51 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_zigbee_90fd9ffffe0bcd51 icon light_control
attr MQTT2_zigbee_90fd9ffffe0bcd51 readingList zigbee2mqtt/0x90fd9ffffe0bcd51:.* { json2nameValue($EVENT, '') }
attr MQTT2_zigbee_90fd9ffffe0bcd51 room MQTT2_DEVICE
attr MQTT2_zigbee_90fd9ffffe0bcd51 setList on:noArg zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"ON"}\
  off:noArg zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"OFF"}\
  brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"on","$EVTPART0":"$EVTPART1"}
attr MQTT2_zigbee_90fd9ffffe0bcd51 webCmd brightness

setstate MQTT2_zigbee_90fd9ffffe0bcd51 ON
setstate MQTT2_zigbee_90fd9ffffe0bcd51 2018-12-07 08:34:26 brightness 60
setstate MQTT2_zigbee_90fd9ffffe0bcd51 2018-12-07 08:34:26 state ON


Was die Bridge-Diskussion angeht: Das ist klar, dass andere Bridges andere Vorgaben benötigen. Werde das für die sidoh-Milight-Bridge gerne bei Gelegenheit mal versuchen, auch in template-Form abzuliefern und das Wiki upzudaten. Das sind aber leider nicht nur 2 unwichtige Bulbs, die darüber laufen...

Wäre dir mit so einem fertig geflasheten ZigBee-Stick (CC2531) zum Betrieb von "zigbee2mqtt" geholfen?

Du müßtest Rudi mindestens noch eine Bulb und irgendeinen Sensor mitliefern. Der Dienst liefert nur eine Rückmeldung, wenn das Gerät den Befehl erhalten hat (bzw. ein Sensor was liefert).

[rudolfkoenig]

Wäre dir mit so einem fertig geflasheten ZigBee-Stick (CC2531) zum Betrieb von "zigbee2mqtt" geholfen?

Vielen Dank fuers Angebot, aber eigentlich haette ich gerne, dass auch Andere Templates bauen (vulgo Aufgaben delegieren), und nicht noch mehr eigene Baustellen (wie z.Bsp. zigbee2mqtt Firmware debuggen).

@Beta-User: kannst du mir bitte jeweils ein Event vom bridge, 1. Device, 2. Device hier anhaengen?

[Beta-User]

@Beta-User: kannst du mir bitte jeweils ein Event vom bridge, 1. Device, 2. Device hier anhaengen?

Kommt dann aber erst später (vermutlich morgen), und bisher gibt es auch nur 2 MQTT2_DEVICE-Geräte (die RAW angehängten), das 2. will ich ja unbedingt auch automatisiert anlegen lassen (war doch unser Ziel, das noob-freundlich zu gestalten, oder?).

Kann ich was loggen und den log-Level erhöhen? (evtl. auch am MQTT2__SERVER)? Wieviele Events wären denn sinnvoll (die letzten stehen ja in den RAW-lists)?

Vielen Dank fuers Angebot, aber eigentlich haette ich gerne, dass auch Andere Templates bauen (vulgo Aufgaben delegieren), und nicht noch mehr eigene Baustellen (wie z.Bsp. zigbee2mqtt Firmware debuggen).

Soweit erkennbar hatte ich mit der firmware an sich bisher keine Probleme und auch der Java-Code scheint stabil zu sein. Ergo: Eigentlich keine Baustelle, aber auch nicht die Superduper-Lösung, weil:
- Java (nach der Installation 3 vulnerabilities...)
- die Beschränkung in der firmware auf nicht so viele Devices besteht (je nach CC235x-Typ)  und man dann Router einsetzen muß/kann/darf
- zigbee an sich ein Problem zu haben scheint, wenn die mesh-Optionen genutzt werden, aber dazwischen irgend ein Router wegfällt (danach klingen jedenfalls diverse Anmerkungen, von anderen, die mir im Ohr geblieben sind).

Wenn Bedarf bestehen würde, "eigene" Hardware zu haben, wäre ein simpler, nackiger ESP8266 mit der Sidoh-Milight-Bridge-firmware einfacher - die tut schlicht so, als wäre ein Transceiver dran und schickt einen Status zurück, ohne (prinzipbedingt) wissen zu können, ob tatsächlich was passiert ist; das ganze läßt sich bequem auf dem Web-Interface ansteuern.... Aber die Technik an sich ist Mist, und von daher bin ich voll bei Rudi: Soll ausbaden (templates liefern), wer sich so einen Sch.. ins Haus holt . Und zum debuggen reicht es eigentlich, die Messages manuell zu erzeugen (geht mit den vorhandenen mosquitto_sub-Infos).

[rudolfkoenig]

Wieviele Events wären denn sinnvoll

Jeweils eins (das was eigentlich ein Device erzeugen sollte) reicht mir.

(die letzten stehen ja in den RAW-lists)?

Bin wohl blind, finde sie nicht...

Und zum debuggen reicht es eigentlich, die Messages manuell zu erzeugen (geht mit den vorhandenen mosquitto_sub-Infos).

Ich habe es noch nicht verstanden, warum mosquitto_sub den "eingebauten" Trace-Moeglichkeiten Vorzug gegeben wird:
- fuer eine vergleichbare Ausgabe kann man im MQTT2 IODev rawEvents setzen, und Event-Monitor verwenden
- fuer mehr Details kann man "verbose 5" setzen, und das FHEM-Log anschauen (evtl. auch uebers Event-Monitor).
Vielleicht uebersehe ich was.

[Beta-User]

Jeweils eins (das was eigentlich ein Device erzeugen sollte) reicht mir.
Bin wohl blind, finde sie nicht...

Ah ok, das war nicht enthalten und an die Mitschnitte von mosquitto_sub komme ich grade nicht dran. War aber ziemlich sicher sowas:

Code Auswählen Erweitern

zigbee2mqtt/0x90fd9ffffe0bcd51 {"state":"ON"}

Ich habe es noch nicht verstanden, warum mosquitto_sub den "eingebauten" Trace-Moeglichkeiten Vorzug gegeben wird:- fuer eine vergleichbare Ausgabe kann man im MQTT2 IODev rawEvents setzen, und Event-Monitor verwenden
- fuer mehr Details kann man "verbose 5" setzen, und das FHEM-Log anschauen (evtl. auch uebers Event-Monitor).
Vielleicht uebersehe ich was.

Danke für den weiteren Schubs - ich habe aus "alter Gewohnheit" schlicht mosquitto_sub verwendet, werde das aber dann zukünftig mit den rawEvents machen; ist dann für die Darstellung im Wiki für MQTT-Einsteiger natürlich auch viel einfacher (hatte nicht danach gesucht und deswegen die doofe Frage gestellt - ich bin also mal wieder derjenige, der was übersehen hat ).

Danke!