Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

[Beta-User]

[...]sagen wie es dir gefällt bzw. ob alles funktioniert, dann würde ich vielleicht nochmal alle templates ein wenig danach anpassen:

Code Auswählen Erweitern

...
   userReadings state {if(ReadingsVal($name,"state","") eq "OFF") {return "off"} else {return "on"}},brightness {(split ' ',ReadingsVal($name,"brightness",0))[1]},
color:color_y.* {Color::xyY2hex(ReadingsVal($name,"color_x",0),ReadingsVal($name,"color_y",0),ReadingsVal($name,"brightness",255))}
   webCmd     toggle:on:off:brightness:color

So, nachdem ich zum einen die tint kurz nochmal rausgeholt hatte und etwas mehr "Erfahrung" mit stateFormat, eventMap & Co gesammelt habe, habe ich meine grundsätzliche Skepsis gegenüber userreadings etwas reduziert. ABER: bitte IMMER den trigger besser eingrenzen. Hier ist m.E. nur der color-trigger insoweit "sauber".

Was die zwei Vorschläge zu state und brightness angeht, kommt es mir aber so vor, dass das hier "gelöste" Problem eigentlich darin begründet ist, dass Befehle nicht bei der Lampe ankommen.
Wenn das stimmt, es aber nur ein temporäres Problem ist, ist es m.E. sinnvoll, das bei Eintreten weiterhin sichtbar zu machen.

Ist es was dauerhaftes (z.B. weil die bulb gar nicht am Stromnetz hängt - wie meine übrigens auch, wenn der Schalter aus ist...), sollte man m.E. einen _anderen_ Mechanismus nutzen:

Code Auswählen Erweitern

defmod n_Zigbeedevice_availability notify MQTT2_zigbee.*:availability:.* {\
if (Value($NAME) =~ /ON|on/ and $EVENT =~ /offline/) {fhem "setreading $NAME state off";;}\
elsif (Value($NAME) =~ /OFF|off/ and $EVENT =~ /online/){fhem "setreading $NAME state on"}\
}
attr n_Zigbeedevice_availability room Steuerung->Logik
Damit das funktioniert, muß man aber ein recht aktuelles zigbee2mqtt nutzen und irgendeine Option in der yaml setzen (bitte Doku wälzen).

Liege ich da richtig, oder habe ich nur etwas falsch verstanden?

[R1k4rd]

Hey, sorry erstmal für die späte Rückmeldung.. Semesterferien sind leider vorbei

Was die zwei Vorschläge zu state und brightness angeht, kommt es mir aber so vor, dass das hier "gelöste" Problem eigentlich darin begründet ist, dass Befehle nicht bei der Lampe ankommen.
Wenn das stimmt, es aber nur ein temporäres Problem ist, ist es m.E. sinnvoll, das bei Eintreten weiterhin sichtbar zu machen.

Vollkommen richtig, das Ganze war nur temporär, als ich dann mal auf die dev Branch umgestellt hatte, fiel mir auf, dass das Problem nicht an Fhem lag wie ich die ganze Zeit aus Unwissenheit der genaueren Zusammenhänge dachte, sondern an Zigbee2MQTT selbst. Nach dem Umstellen bzw. später dann auch Updaten des master branch bekam ich für meine Geräte brightness sowie color_temp zurückgeliefert, damit entfallen natürlich jetzt userReadings die ich damals angestrebt hatte. Wäre auch mal nett gewesen wenn jemand anderes hier einfach mal geschrieben hätte das er normale Werte für color_temp und brightness zurück bekommt 

Ist es was dauerhaftes (z.B. weil die bulb gar nicht am Stromnetz hängt - wie meine übrigens auch, wenn der Schalter aus ist...), sollte man m.E. einen _anderen_ Mechanismus nutzen:
Code: [Auswählen]
defmod n_Zigbeedevice_availability notify MQTT2_zigbee.*:availability:.* {\
if (Value($NAME) =~ /ON|on/ and $EVENT =~ /offline/) {fhem "setreading $NAME state off";;}\
elsif (Value($NAME) =~ /OFF|off/ and $EVENT =~ /online/){fhem "setreading $NAME state on"}\
}
attr n_Zigbeedevice_availability room Steuerung->Logik
Damit das funktioniert, muß man aber ein recht aktuelles zigbee2mqtt nutzen und irgendeine Option in der yaml setzen (bitte Doku wälzen).

Öhm ja, ich muss mir das selbst erstmal alles wieder genau anschauen, danach würde ich dann wahrscheinlich nochmal die templates ein wenig an den aktuellen Stand anpassen und nochmal ein wenig vereinheitlichen soweit das möglich ist.

Das ganze mit den Gruppen funktioniert jetzt auch super und wie ihr schon gesagt habt mit

Code Auswählen Erweitern

zigbee2mqtt/Gruppenname:.* { json2nameValue($EVENT) }
lässt sich der Status auch einfach in den einzelnen Geräten aktualisieren.
Was mir außerdem nun aufgefallen ist: Ich hatte die Templates auf die unterschiedlichen Farbsysteme angespasst und unterschieden, allerdings lassen sich meine Controller mit dem Update von Zigbee2MQTT nun auch mit dem Hex Eintrag steuern. Aus dem Grund würde ich die Templates eventuell erneut auch dahingehend anpassen und die Unterteilung in "rgb" und "hex" wieder entfernen da dies scheinbar auch nur bei mir der Fall war. Außerdem denke ich, dass mit voranschreitender Entwicklung jedes Geräte mit allen Farbsystemen steuerbar gemacht wird. Zusätzlich würde ich bei den Templates mit Farbsteuerung auch überall das userReading für die Umrechnung von color_x u y zu hex einfügen und damit das zuvor gesetzte color überschreiben damit der Wert immer aktuell ist.
Das userReading mit on/off würde ich fasst auch so mit reinnehmen wollen, dadurch unterscheidet es sich dann nicht mehr zwischen state ON/OFF und dem setzen von on/off, das macht es z.B. bei der Verwendung mit TabletUi einfacher. Ich denke ich würde dann auch ein Template für Gruppen definiert in das ich alle bis jetzt möglichen Befehle reinpacke damit jeder den passenden Code für sich dort finden könnte, sind aber nur alles Ideen ich würde mal auf deine Antwort warten und je nachdem mich dann an die Umsetzung machen.

LG Richard

[Beta-User]

Zunächst mal Danke für die Rückmeldung, dass du noch bzw. wieder da bist!

Ich habe leider nicht den Überblick, was jetzt welches Gerät an Anweisungen braucht. Meine Tendenz wäre die, es möglichst übersichtlich zu halten, also wieder rauszustreichen, was nicht (mehr) benötigt wird.

Den Farbstatus rückwärts wieder sauber zusammenzubasteln finde ich gut, aber das mit userreadings zu ON/OFF würde ich für meine Devices bitte nicht haben wollen, Gründe hatte ich erläutert, oder? Allerdings fände ich direkte Infos in Kleinschreibung auch klasse, vielleicht kann man den zigbee2mqtt-Dienst entsprechend konfigurieren oder kkoenk bitten, sowas einzubauen? (Ich habe noch nicht danach gesucht, vielleicht gibt' das schon).

[R1k4rd]

Zunächst mal Danke für die Rückmeldung, dass du noch bzw. wieder da bist!

Ich bleibe auch da, nur ab und zu fehlt mir leider die Zeit

So wirklich klar steht es ja auch nirgends welche Anweisungen genau von welchem Gerät unterstützt werden, aus dem Grund würde ich schon gerne ein Template anlegen welches halt irgendwie alle bis jetzt dokumentierten bzw. erstellten Befehle für Leuchtmittel vereint, damit jeder die Möglichkeit hat sich das passende raus zu suchen ohne an unterschiedlichen Stellen im Forum zu schauen. Dementsprechend würde ich dann wahrscheinlich auch nochmal die Texte etwas anpassen und Beschreibungen ändern die jetzt so im MQTT2 Praxisbeispiele Teil stehen.

Den Farbstatus rückwärts wieder sauber zusammenzubasteln finde ich gut

Was sagst du dazu, auch zum Beispiel, aus dem Reading "hex" einfach "color" zu machen, es ist nunmal der Parameter der auch von Zigbee2MQTT geliefert wird aus dem Grund würde ich es so auch vereinheitlichen wollen? Zu ON/OFF: ja das hatten wir schonmal kurz und ich kann es auch verstehen, darum Frage ich ja lieber, ich will und kann es nicht alleine entscheiden
Da müsste ich mich auch drüber informieren, soweit ich das mal getestet hatte ging aber z.B. set {"state":"ON"} als auch set {"state":"on"}, nur zurück bekommt man halt immer ON/OFF, was ist den der Standard für Fhem, on/off oder ON/OFF?

LG Richard

[Beta-User]

Ich bleibe auch da, nur ab und zu fehlt mir leider die Zeit

Ist schon ok, war halt etwas sehr still... Ansonsten: wie du dazu kommst, mache ich bei manchen Dingen ja auch nicht anders...

So wirklich klar steht es ja auch nirgends welche Anweisungen genau von welchem Gerät unterstützt werden, aus dem Grund würde ich schon gerne ein Template anlegen welches halt irgendwie alle bis jetzt dokumentierten bzw. erstellten Befehle für Leuchtmittel vereint, damit jeder die Möglichkeit hat sich das passende raus zu suchen ohne an unterschiedlichen Stellen im Forum zu schauen. Dementsprechend würde ich dann wahrscheinlich auch nochmal die Texte etwas anpassen und Beschreibungen ändern die jetzt so im MQTT2 Praxisbeispiele Teil stehen.

Ich würde vorschlagen, das ggf. nicht gleich komplett auszubauen, aber ggf. "nach hinten" zu schieben, in der angezeigten template-Liste und dann ggf. erst später tatsächlich zu löschen.

Was sagst du dazu, auch zum Beispiel, aus dem Reading "hex" einfach "color" zu machen, es ist nunmal der Parameter der auch von Zigbee2MQTT geliefert wird aus dem Grund würde ich es so auch vereinheitlichen wollen?

Sehr gut. hex ist für die meisten "seltsam", unter color kann man sich was vorstellen.

Zu ON/OFF: ja das hatten wir schonmal kurz und ich kann es auch verstehen, darum Frage ich ja lieber, ich will und kann es nicht alleine entscheiden Da müsste ich mich auch drüber informieren, soweit ich das mal getestet hatte ging aber z.B. set {"state":"ON"} als auch set {"state":"on"}, nur zurück bekommt man halt immer ON/OFF, was ist den der Standard für Fhem, on/off oder ON/OFF?

Aus einem kleinen "on" sendeseitig ein großes zu machen, ist kein Problem, da benötigen wir in der Regel sowieso separate Befehle und können nicht mit "EVTPARTx" arbeiten.

In FHEM ist Kleinschreibung viel einfacher zu handhaben, von daher sollte man dafür sorgen, dass (optional) eben von zigbee2mqtt auch Kleinschriebung zurückkommt. (Hast du einen ESP8266 ungenutzt rumliegen? Mach mal tasmota drauf und analysiere das basis-template dazu bzw. die direkten IO-publishes darin. Dann wird das ggf. klarer).

[R1k4rd]

Ich würde vorschlagen, das ggf. nicht gleich komplett auszubauen, aber ggf. "nach hinten" zu schieben, in der angezeigten template-Liste und dann ggf. erst später tatsächlich zu löschen.

Werde ich versuchen so umzusetzen.

Sehr gut. hex ist für die meisten "seltsam", unter color kann man sich was vorstellen.

Sehr gut, dann hätte ich zusätzlich noch folgenden Vorschlag:

Code Auswählen Erweitern

color:colorpicker,HEX,0,5,255 zigbee2mqtt/rgbcct01/set {"color":{"hex":"#$EVTPART1"},"transition": 1}
Neu wäre dabei nur "transition":1, bewirkt einfach das der Übergang von einer in die andere Farbe etwas sanfter vonstatten geht, bei meinem Controller ist dies von Haus aus nämlich nicht firmwareseitig umgesetzt worden. Wie es sich allerdings bei Leuchtmitteln auswirkt, bei denen schon in der Firmware des Gerätes ein sanfter Übergang implementiert ist, weiß ich nicht so recht (eventuell stört es dann auch garnicht). Falls noch jemand außer Beta-User hier mitliest würde ich mich um ein kurzes Testen freuen und natürlich Feedback

In FHEM ist Kleinschreibung viel einfacher zu handhaben, von daher sollte man dafür sorgen, dass (optional) eben von zigbee2mqtt auch Kleinschriebung zurückkommt. (Hast du einen ESP8266 ungenutzt rumliegen? Mach mal tasmota drauf und analysiere das basis-template dazu bzw. die direkten IO-publishes darin. Dann wird das ggf. klarer).

Gut da war ich zumindest mit dem on/off alles klein zu machen schonmal auf dem richtigen Weg Einen ESP8266 habe ich leider nicht rumliegen, muss mich demnächst eh mal mehr mit aller möglicher Hardware beschäftigen, da werde ich mir den defintiv auch mal anschaffen.

Ich hätte jetzt beim stöbern auf der Zigbee2MQTT Seite noch folgendes gefunden bzw mal eingebaut:

Code Auswählen Erweitern

statusRequest:noArg zigbee2mqtt/rgbcct01/get
Bewirkt einfach, dass das Gerät nach allen Werte abgefragt wird, bei mir funktioniert es, auch hier bitte mal alle die vielleicht noch mitlesen ausprobieren und Bescheid sagen, wäre super! Ansonsten wie ist deine Meinung dazu, als "statusRequest" könnte dies in jedes Template übernommen werden oder?

Und zu guter letzt bräuchte ich vielleicht einen Tipp/Hinweis/Link/Gedankenanstoß:
Und zwar schickt Zigbee2MQTT ja immer alles zurück, also gehen wir davon aus ich verändere die RGB Farbe eines Leuchtmittels, dann erhalte ich z.B.

Code Auswählen Erweitern

{"state":"ON","color":{"x":0.17,"y":0.162},"brightness":185,"linkquality":34,"color_temp":272}
Daraus kann ich nicht entnehmen was ich zuletzt geändert habe, also ob nun zum Beispiel gerade eine Farbe aktiv ist oder aber eine Lichtfarbe (Warmweiß/Kaltweiß). Stellt sich sicher die Frage warum ich das gerne wissen möchte oder was der Plan ist. Zum Beispiel wäre sowas nötig beim Google Assistent Modul um zu wissen ob gerade eine Farbe aktiv ist oder halt einer der Weißtöne (Beispiel: "damit eine Frage nach, wie leuchtet meine Lampe gerade entweder mit z.B. warmweiß oder rot beantwortet werden kann.") Aus dem Grund war jetzt die Entstehung eines neuen userReadings mit den Namen "colormode" geplant, der dann halt die Werte "color" oder "color_temp" annehmen kann. Je nachdem was zuletzt gesetzt wurde soll dann halt in dem Reading stehen, fällt dazu jemanden spontan eine einfache Umsetzungsmöglichkeit oder Idee ein?

LG Richard

[dk3572]

Hallo,

ich habe nach dieser Anleitung https://www.zigbee2mqtt.io/getting_started/running_zigbee2mqtt.html zigbee2mqtt auf einem Intel Nuc unter Ubuntu Server installiert.

Darf ich an dieser Stelle mal nachfragen wie ich das ganze wieder restlos deinstallieren kann?

Wäre für Hilfe dankbar.

VG Dieter

[Beta-User]

Nachdem es ja bei zigbee2mqtt wieder einige Neuerungen gegeben zu haben scheint, anbei mal ein fortgeschriebenes bridge-template mdB. um feedback. (Ich bin selbst leider noch nicht auf dem letzten Stand und kann vermutlich auch erst mal nicht so viel testen).

Code Auswählen Erweitern

name:L_01_zigbee2mqtt_bridge
desc:The zigbee2mqtt bridge device
filter:TYPE=MQTT2_DEVICE
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^:]+:([^/]+)[/].*:, ? $1 : undef }
attr DEVICE bridgeRegexp\
BASE_TOPIC/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"
attr DEVICE getList\
  devicelist:noArg log BASE_TOPIC/bridge/config/devices\
  networkmap_raw:noArg raw BASE_TOPIC/bridge/networkmap raw\
  networkmap_graphviz:noArg graphviz BASE_TOPIC/bridge/networkmap graphviz
attr DEVICE readingList\
  BASE_TOPIC/bridge/state:.* state\
  BASE_TOPIC/bridge/config/devices:.* {}\
  BASE_TOPIC/bridge/config/log_level:.* log_level\
  BASE_TOPIC/bridge/config/permit_join:.* permit_join\
  BASE_TOPIC/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }\
  BASE_TOPIC/bridge/log:.*\"type\".\"devices\".\"message\".* devices\
  BASE_TOPIC/bridge/log:.* log\
  BASE_TOPIC/bridge/networkmap:.* {}\
  BASE_TOPIC/bridge/networkmap/graphviz:.* graphviz\
  BASE_TOPIC/bridge/networkmap/raw:.* raw\
  BASE_TOPIC/bridge/config:.* { json2nameValue($EVENT) }
attr DEVICE setList\
  log_level:debug,info,warn,error BASE_TOPIC/bridge/config/log_level $EVTPART1\
  permit_join:true,false BASE_TOPIC/bridge/config/permit_join $EVTPART1\
  remove:textField BASE_TOPIC/bridge/config/remove $EVTPART1\
  y_device_setting:textField zigbee2mqtt/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}}
  x_bind:textField BASE_TOPIC/bridge/bind/$EVTPART1 $EVTPART2\
  x_bind_unbind:textField BASE_TOPIC/bridge/unbind/$EVTPART1 $EVTPART2\
  x_device_options:textField BASE_TOPIC/bridge/config/device_options {"friendly_name":"$EVTPART1",""options": {"$EVTPART2": "$EVTPART3"}}\
  x_group_add_to:textField BASE_TOPIC/bridge/group/$EVTPART1/add $EVTPART2\
  x_group_rm_from:textField BASE_TOPIC/bridge/group/$EVTPART1/remove $EVTPART2\
  x_group_rm_from_all:textField BASE_TOPIC/bridge/group/$EVTPART1/remove_all $EVTPART2\
  x_group_add_group:textField BASE_TOPIC/bridge/config/add_group $EVTPART1\
  x_group_rm_group:textField BASE_TOPIC/bridge/config/remove_group $EVTPART1\
  z_elapsed:textField BASE_TOPIC/bridge/config/elapsed $EVTPART1\
  z_last_seen:textField BASE_TOPIC/bridge/config/last_seen $EVTPART1\
  z_ban:textField BASE_TOPIC/bridge/config/ban $EVTPART1\
  z_rename:textField BASE_TOPIC/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
  z_reset_CC:noArg BASE_TOPIC/bridge/config/reset
attr DEVICE setStateList on off
attr DEVICE model L_01_zigbee2mqtt_bridge

Neu wäre dabei nur "transition":1, [...]

Können wir gerne aufnehmen, scheint ja bisher niemand dagegen gewesen zu sein...

Ich hätte jetzt beim stöbern auf der Zigbee2MQTT Seite noch folgendes gefunden bzw mal eingebaut:

Code Auswählen Erweitern

statusRequest:noArg zigbee2mqtt/rgbcct01/get
[...] als "statusRequest" könnte dies in jedes Template übernommen werden oder?

Von mir aus gerne!

Und zu guter letzt bräuchte ich vielleicht einen Tipp/Hinweis/Link/Gedankenanstoß:
Und zwar schickt Zigbee2MQTT ja immer alles zurück, also gehen wir davon aus ich verändere die RGB Farbe eines Leuchtmittels, dann erhalte ich z.B.[...] Je nachdem was zuletzt gesetzt wurde soll dann halt in dem Reading stehen, fällt dazu jemanden spontan eine einfache Umsetzungsmöglichkeit oder Idee ein?

Hmm, kann das nicht abschließend beurteilen. Wäre vermutlich einfacher, wenn man z.B. regulär immer nur einen "changed"-Datensatz bekommen würde, und nur bei einem "get" (statusRequest) die vollständige Liste. Das müßte dann aber von der zigbee2mqtt-Seite her so implementiert sein (was es nicht ist, oder)?

[ulli]

Was nehm ich denn für ein MQTT Template für einen CC2530 Router im Zigbee Netzwerk?

[Beta-User]

Gibt im Moment (noch) keines. Was sollte das den "können"?

[supernova1963]

Hallo Dieter,

definiere bitte restlos, mit nodejs + npm, und mit fhem - devices?


Wenn es "nur" um zigbee2mqtt geht:

Code Auswählen Erweitern


sudo systemctl stop zigbee2mqtt
sudo systemctl disable zigbee2mqtt.service
sudo rm /etc/systemd/system/zigbee2mqtt.service
sudo rm -r /opt/zigbee2mqtt
# optional:
# sudo reboot


Gernot

P.S.: Ich habe es aufgegeben. 2,4 GHz und Betondecken und Fussbodenheizung passen bei mir nicht zusammen.
Bei meinen Schwierigkeiten mit WLAN (nur mit diversen neuen Kabel, DLAN und mehreren Router flächendeckend) hätte ich mir das denken können. Doch die Verlockung dieser echt günstigen SmartHome Geräte war zu groß. 

[maclovlin]

P.S.: Ich habe es aufgegeben. 2,4 GHz und Betondecken und Fussbodenheizung passen bei mir nicht zusammen.
Bei meinen Schwierigkeiten mit WLAN (nur mit diversen neuen Kabel, DLAN und mehreren Router flächendeckend) hätte ich mir das denken können. Doch die Verlockung dieser echt günstigen SmartHome Geräte war zu groß.

Wäre dieses denn keine Option?
https://www.ikea.com/de/de/p/tradfri-signalverstaerker-10400408/

Diesen Artikel fand ich auch sehr interessant, habs bei mir umgesetzt.
https://www.metageek.com/training/resources/zigbee-wifi-coexistence.html

[ulli]

Gibt im Moment (noch) keines. Was sollte das den "können"?

Ein status online/offline wäre gut

[ulli]

Wäre dieses denn keine Option?
https://www.ikea.com/de/de/p/tradfri-signalverstaerker-10400408/

Diesen Artikel fand ich auch sehr interessant, habs bei mir umgesetzt.
https://www.metageek.com/training/resources/zigbee-wifi-coexistence.html

Funktioniert der Verstärker auch mit xiaomi geräten?

Zu 2. Zeigt es eine Verbesserung?

[maclovlin]

Funktioniert der Verstärker auch mit xiaomi geräten?

Keine Ahnung ob es mit Xiaomi funktioniert, aber für 10 Euro könnte man es doch ausprobieren.
Vielleich kann es auch ein anderer Beantworten.

Zu 2. Zeigt es eine Verbesserung?

Ich finde es klingt logisch, also habe ich es für meine Umgebung angepasst.
Ich finde seit dem läuft es besser.

Kann aber auch sein, dass Zigbee2MQTT "erwachsener" wird...