Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

[drhirn]

War an alle z2m User gerichtet.

Hast aber alle Fragen richtig verstanden. Es ist aber bei Device und Group irgendwie ein Spezialfall. Gibt schon Kommandos, die in der Bridge sein sollten. "group add" z.B. Sonst aber keines fällt mir gerade auf. Alles andere würde ich auch eher beim Device bzw. der Gruppe unterbringen. Wobei's für Gruppen noch ein Template brauchen könnte.
Mal schauen, ob sich noch jemand mit einer Meinung meldet.

OT: Warum hast du von z2m auf Deconz/Phoscon gewechselt? Ich plane gerade den umgekehrten Weg

[Beta-User]

"group add"

remove sollte es noch geben, und ich fand es damals nicht logisch, beides an getrennten Orten unterzubringen. Beides sind nach meinem Verständnis Aministrationsaufgaben, kann man aber wie gesagt auch anders sehen.

OT: Warum hast du von z2m auf Deconz/Phoscon gewechselt? Ich plane gerade den umgekehrten Weg

Damals gab es nur die CC253x als Hardware-Interface, mir war aber nach den ersten Tests soweit klar, dass mir die Technik zusagt. Also habe ich einen ConBee II besorgt, den man damals aber noch nicht für z2m nutzen konnte...

Habe dann immer mal wieder überlegt, ob ich nicht auch wieder zu z2m wechseln will, aber der "Schmerz" ist nicht groß genug (eigentlich finde ich nur die Auftrennung der Hardware in mehrere FHEM-Devices manchmal immer noch seltsam, z.B. bei Temp/Hum-Sensoren oder Strommessdosen), und andererseits ist Java ganz allgemein auch nicht so meins (docker mag ich immer noch nicht wirklich, und damals war bei der Installation auf dem Test-Pi gleich "2 vulnerabilities" zu lesen). Und so ist es jetzt halt wie es ist...

[drhirn]

Das Leid der Early-Adopter. Kenn ich

[Beta-User]

Das Leid der Early-Adopter. Kenn ich

Vermutlich...

Jetzt kenne ich andererseits beide Welten und kann daher guten Gewissens "Werbung" für den ConBee II machen, wenn jemand noch unentschlossen ist. Im Ergebnis sehe ich keinen wirklichen Vorteil für eine dieser beiden Varianten. Wer eher was textbasiertes sucht, dem wird z2m vermutlich eher zusagen (weswegen ich jemand mit screenreader explizit diese Variante auch schon empfohlen habe), wer Bewegungsmelder-Szenarien zusammenklicken will, ist evtl. bei deconz besser aufgehoben...

Anekdote am Rande: vom Aufbau her ist z2m "nur" ein Klon der MiLight-Lösung. Die für MiLight von Rudi dann noch relativ früh in der Geschichte der M2-Module ergänzten Methoden (v.a. bridgeRegexp und diese $EVTPART1-Sachen in der setList usw.) sind hier erst richtig zur Blüte gekommen.

[drhirn]

Also, mein komplettes Zigbee2Mqtt-Bridge-Device täte jetzt so aussehen.

Code Auswählen Erweitern


defmod MQTT2_zigbee_bridge MQTT2_DEVICE zigbee_bridge
attr MQTT2_zigbee_bridge bridgeRegexp zigbee2mqtt/([A-Za-z0-9._]+)[/]?.*:.* "zigbee_$1"
attr MQTT2_zigbee_bridge comment To check for new updates of the deamon software, you might want to use a separate HTTPMOD device. See HTTPMOD template zigbee2mqtt_daemon_updates for further details.
attr MQTT2_zigbee_bridge devicetopic zigbee2mqtt
attr MQTT2_zigbee_bridge getList networkmap_raw:noArg raw $DEVICETOPIC/bridge/request/networkmap raw\
networkmap_graphviz:noArg graphviz $DEVICETOPIC/bridge/request/networkmap graphviz\
networkmap_plantuml:noArg plantuml $DEVICETOPIC/bridge/request/networkmap plantuml
attr MQTT2_zigbee_bridge icon mqtt
attr MQTT2_zigbee_bridge model zigbee2mqtt_bridge
attr MQTT2_zigbee_bridge readingList $DEVICETOPIC/bridge/info:.* {}\
$DEVICETOPIC/bridge/state:.* bridgeState\
$DEVICETOPIC/bridge/logging:.* { json2nameValue($EVENT,'logging_') }\
$DEVICETOPIC/bridge/devices:.* {}\
$DEVICETOPIC/bridge/groups:.* {}\
$DEVICETOPIC/bridge/event:.* event\
$DEVICETOPIC/bridge/extensions:.* {}\
$DEVICETOPIC/bridge/response/permit_join:.* { json2nameValue($EVENT, 'permit_join_') }\
$DEVICETOPIC/bridge/response/health_check:.* { json2nameValue($EVENT,'health_') }\
$DEVICETOPIC/bridge/response/restart:.* { json2nameValue($EVENT,'restart_') }\
$DEVICETOPIC/bridge/response/networkmap:.* { my $type = $EVENT =~ m/.*,"type":"(raw|graphviz|plantuml)",.*/ ? $1 : 'networkmap';; $EVENT =~ m/{"data":\{.*"value":"?(.*[^"])"?\},"status":"ok"\}/ ? { "networkmap"=>$1 } : {} }\
$DEVICETOPIC/bridge/response/extension/.*:.* {}\
$DEVICETOPIC/bridge/response/backup:.* { my $string = $EVENT =~ m/\"\:\"(.*)\".,/;; {'backup' => "<html><a href='data:application/zip;;base64,$1'>download</a></html>" } }\
$DEVICETOPIC/bridge/response/install_code/add:.* { json2nameValue($EVENT,'install_code_add_') }\
$DEVICETOPIC/bridge/response/device/ota_update/.*:.* device\
$DEVICETOPIC/bridge/response/device/.*:.* device\
$DEVICETOPIC/bridge/response/group/.*:.* group\
$DEVICETOPIC/bridge/response/group/members/.*:.* group\
$DEVICETOPIC/bridge/response/options:.* options\
$DEVICETOPIC/bridge/response/touchlink/.*:.* touchlink\
$DEVICETOPIC/bridge/response/config/.*:.* config\
$DEVICETOPIC/bridge/request/.*:.* {}\
$DEVICETOPIC/bridge/config:.* { json2nameValue($EVENT,'config_') }\
$DEVICETOPIC/bridge/config/log_level:.* log_level\
$DEVICETOPIC/bridge/log:.* { json2nameValue($EVENT,'log_') }\

attr MQTT2_zigbee_bridge room MQTT2_DEVICE

attr MQTT2_zigbee_bridge setList b_permit_join:true,false $DEVICETOPIC/bridge/request/permit_join $EVTPART1\
b_health_check:noArg $DEVICETOPIC/bridge/request/health_check\
b_restart:noArg $DEVICETOPIC/bridge/request/restart\
b_backup:noArg $DEVICETOPIC/bridge/request/backup\
b_options:textField,JSON $DEVICETOPIC/bridge/request/options $EVTPART1\
dev_remove:textField,Device-ID $DEVICETOPIC/bridge/request/device/remove {"id": "$EVTPART1"}\
dev_ota_check:textField,Device-ID $DEVICETOPIC/bridge/request/device/ota_update/check {"id": "$EVTPART1"}\
dev_ota_update:textField,Device-ID $DEVICETOPIC/bridge/request/device/ota_update/update {"id": "$EVTPART1"}\
dev_reconfigure:textField,Device-ID $DEVCETOPIC/bridge/request/device/configure {"id": "$EVTPART1"}\
dev_options:textField,Device-ID+options $DEVICETOPIC/bridge/request/device/options {"id":"$EVTPART1","options":{"$EVTPART2":"$EVTPART3"}}\
dev_rename:textField $DEVICETOPIC/bridge/request/device/rename {"from":"$EVTPART1","to":"$EVTPART2"}\
dev_bind:textField $DEVICETOPIC/bridge/request/device/bind {"from":"$EVTPART1","to":"$EVTPART2"}\
dev_unbind:textField $DEVICETOPIC/bridge/request/device/unbind {"from":"$EVTPART1","to":"$EVTPART2"}\
dev_set:textField $DEVICETOPIC/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}\
dev_reporting:textField,JSON $DEVICETOPIC/bridge/request/device/configure_reporting {$EVTPART1}\
grp_add:textField,friendlyName $DEVICETOPIC/bridge/request/group/add {"friendly_name":"$EVTPART1"}\
grp_remove:textField,friendlyName $DEVICETOPIC/bridge/request/group/remove {"id":"$EVTPART1"}\
grp_rename:textField $DEVICETOPIC/bridge/request/group/rename {"from":"$EVTPART1","to":"$EVTPART2"}\
grp_options:textField $DEVICETOPIC/bridge/request/group/options {"id":"$EVTPART1","options":{"$EVTPART2":"$EVTPART3"}}\
grp_mbr_add:textField $DEVICETOPIC/bridge/request/group/members/add {"group":"$EVTPART1","device":"$EVTPART2"}\
grp_mbr_rm:textField $DEVICETOPIC/bridge/request/group/members/remove {"group":"$EVTPART1","device":"$EVTPART2"}\
grp_mbr_rmall:textField $DEVICETOPIC/bridge/request/group/members/remove_all {"device":"$EVTPART1"}

attr MQTT2_zigbee_bridge stateFormat bridgeState


[Umber]

Habe vor ca. 2h dein Bridge Device übernommen.
Hab nix negatives festgestellt...

Danke!

[Mathea]

Da das ein isoliertes Problem zu sein scheint, kann ich im Moment auch nicht wirklich weiterhelfen. Oder hat sonst noch jemand Freezes im Zusammenhang mit z2m?

@Umber:
Ist/war das ein einmaliges Problem, oder tritt das ständig auf?

Irgendwie habe ich den Verdacht, dass da bei dir nicht nur an einer Stelle was verbogen ist, vermutlich wäre es im Fall der Fälle besser, das gesondert zu diskutieren.

Hallo zusammen,

bei mir treten leider auch signifikante Freezes von über 20 Sekunden auf, sobald ich in z2m ein Gerät einbinde, ein OTA Firmware Update mache oder die Topographie-Karte lade. Manchmal muss ich fhem sogar manuell neustarten, weil es sich nicht mehr fängt.

Ich habe verschiedene Einstellungen in z2m probiert und auch im fhem Device readingList rumprobiert, aber erreiche leider keine Verbesserungen.

Zur Info: z2m läuft bei mir auf dem selben Rechner wie fhem (leistungsstarkes APU Board, also sollte es eigentlich keine Hardware-Einschränkungen geben).
MQTT server Einstellung im z2m: mqtt://localhost:1883
In FHEM habe ich ein z2m Bridge MQTT-Device (attrTemplate zigbee2mqtt_bridge) und natürlich pro physikalischem Zigbee-Gerät ein fhem Device.

Habt ihr einen Tipp, woran das Problem liegen könnte, bzw. wie ich es beheben kann?


Edit: OK ich habe es gelöst. Ich glaube, am Ende hat folgendes ignoreRegexp im MQTT2 Server geholfen:

Code Auswählen Erweitern

attr MQTT2_FHEM_Server ignoreRegexp zigbee2mqtt/bridge.*

Die zigbee2mqtt bridge Nachrichten waren so immens, dass sie jedes mal meinen FHEM Server lahm gelegt haben. Mit dem ignoreRegexp ignoriere ich sie eiskalt und benötige sie auch nicht weiter. Mich ärgert es, dass man dieses exzessive Daten-Spam nicht im zigbee2mqtt abschalten kann, bzw. verstehe auch nicht, warum man es überhaupt braucht.

[Motivierte linke Hände]

Tach, ich habe hier ein paar Bosch Devices an z2m und für den Zwischenstecker gerade mein erstes angepasstes Template erstellt.

Code Auswählen Erweitern

# Bosch Zwischenstecker BSP-FZ2
name:zigbee2mqtt_bosch_bsp-fz2
filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
desc: Bosch plug BSP-FZ2, zigbee 3.0, with energy measurement
order:L_05b
set DEVICE attrTemplate zigbee2mqtt_plug
attr DEVICE devStateIcon {my $light = FW_makeImage(ReadingsVal($name,'state','off')); my $pwr = ReadingsVal($name,'power',0); my $energy = ReadingsVal($name,'energy',0); qq(<div> <a href="/fhem?cmd.dummy=set $name toggle&XHR=1">$light</a>akt. $pwr W, ges. $energy kWh<b></b>)}
attr DEVICE setList \
  on:noArg $\DEVICETOPIC/set {"state":"ON"}\
  off:noArg $\DEVICETOPIC/set {"state":"OFF"}\
  toggle:noArg $\DEVICETOPIC/set {"state":"TOGGLE"}\
  power_on_behavior:off,previous,on $\DEVICETOPIC/set {"power_on_behavior":"$EVTPART1"}
attr DEVICE model zigbee2mqtt_bosch_bsp-fz2
setreading DEVICE attrTemplateVersion 20230207

Passt das so? (Vom Format her - Funktionalität bei mir ist gegeben.) Oder muss/kann/soll ich das irgendwo hochladen?

[Motivierte linke Hände]

Noch was, was bei mir läuft und ggf. auch anderen helfen könnte:

Code Auswählen Erweitern

name:zigbee2mqtt_bosch_radiator_thermostat_ii
desc: Developed for <a href="https://www.zigbee2mqtt.io/devices/BTH-RA.html">Bosch Radiator Thermostat II</a> via zigbee2mqtt
filter:TYPE=MQTT2_DEVICE:FILTER=CID~zigbee.*
order:L_17c
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[\b]?([^/:]+)[/].+, ? $1 : undef }
par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","devicetopic",AttrVal("DEVICE","readingList","")) =~ m,[^/]+[/]([^/:]+).*, ? $1 : undef }
par:ICON;ICON as set, defaults to temp_control;{ AttrVal("DEVICE","icon","temp_control") }
attr DEVICE icon ICON
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE setList \
  desired-temp:slider,5.0,0.5,30.0,1 $\DEVICETOPIC/set {"occupied_heating_setpoint": "$EVTPART1"}\
  temp-calibration:slider,-5.0,0.5,5.0,1 $\DEVICETOPIC/set {"local_temperature_calibration": "$EVTPART1"}\
  btnLock:LOCK,UNLOCK $\DEVICETOPIC/set {"child_lock": "$EVTPART1"}\
  boost:ON,OFF $\DEVICETOPIC/set {"boost": "$EVTPART1"}\
  mode:heat,auto,off $\DEVICETOPIC/set {"system_mode": "$EVTPART1"}\
  display_orientation:normal,flipped $\DEVICETOPIC/set {"display_orientation": "$EVTPART1"}\
  display_ontime:slider,5,1,30,1 $\DEVICETOPIC/set {"display_ontime": "$EVTPART1"}\
  display_brightness:slider,0,1,10,1 $\DEVICETOPIC/set {"display_brightness": "$EVTPART1"}\
  window_open:ON,OFF $\DEVICETOPIC/set {"window_open": "$EVTPART1"}
attr DEVICE devStateIcon LOCKED:secur_lock:btnLock+UNLOCK UNLOCKED:secur_open:btnLock+LOCK
attr DEVICE webCmd desired-temp
attr DEVICE jsonMap occupied_heating_setpoint:desired-temp local_temperature:temperature local_temperature_calibration:temp-calibration system_mode:mode pi_heating_demand:valvePos child_mode:btnLock
attr DEVICE stateFormat T: temperature desired: desired-temp valve: valvePos
attr DEVICE model zigbee2mqtt_bosch_radiator_thermostat_ii
set DEVICE attrTemplate speechcontrol_type_thermostat
deletereading -q DEVICE (?!associatedWith|IODev).*
setreading DEVICE attrTemplateVersion 20230207

[Beta-User]

Sieht soweit ganz ok aus - abgesehen davon, dass wir üblicherweise keine Typen- oder Herstellerbezeichnungen in den template-Namen drin haben, sondern das eher generisch nach Funktion benannt ist. (Ich versuche mir was zu überlegen, falls keine diesbezüglichen Vorschläge kommen...).

[Motivierte linke Hände]

Das Problem, das ich für mich gelöst habe, ist, dass deren Geräte sich ein wenig anders verhalten als die anderen ihrer Art. Und es ist, je länger die Liste wird, für den FHEM-Nutzer sicher einfacher, das Passende zu finden, wenn man die genaue Modellbezeichnung hat.

Ich bin mit nichts und niemandem im Zusammenhang mit der Robert Bosch Stiftung oder der von ihr gehaltenen Gesellschaften verbunden.  (So wie auch vmtl. niemand mit Alterco verbunden ist, der "Shelly" in die Namen aufgenommen hat, oder mit IKEA, der symfonisk aufgenommen hat, etc.  )

Wenn Dir was anderes einfällt, ändere das gerne so, wie Du meinst, dass es passt. Oder lass es raus, wenn Du meinst, dass solche Nischendinge gar nicht aufgenommen werden sollten. Man kann es ja auch über die Suche im Forum finden.

[Beta-User]

...die reine Lehre ist immer schwierig einzuhalten, v.a., wenn man halt irgendwo anfängt und noch gar nicht weiß, wie es irgendwann im Detail weitergeht (ad Shelly...)

Das mit dem Wiederfinden bzw. Zuordnen können ist in der Tat ein Problem; bisher gab es nicht allzuvielle Beschwerden, weil z.B. halt die (bisher: wenigen) z2m-Thermostat-Varianten an sich untereinander auftauchen sollten, mit zunehmender Komplexität. Das sollte eigentlich ok sein, v.a., wenn man es mit der Modellbezeichnung ergänzt, mit der es getestet wurde.
Sonst haben wir irgendwann wirklich eine "endlose" Liste, die niemand mehr überblickt (oder pflegen könnte ).

Kurz: ich überlege mir was, ich wollte nur erläutern, warum ich das _hier_ nicht passend finde, die Herstellerinfo im Namen zu haben...

[Motivierte linke Hände]

In dem Zusammenhang: Was empfiehlst Du denn für eine Angabe bei "order" für selbsterstellte Templates, die nicht zentral aufgenommen werden? Die oben einkopierten halten sich an die generelle Reihenfolge - was funktioniert, solange diese Plätze nicht von anderen Geräten "besetzt" werden.

Lt. Erklärung:

Code Auswählen Erweitern

(EDIT: Die Sortierung erfolgt neurdings über "order:", nicht mehr über den template-Namen)
Der erste Buchstabe steht für eine Hauptgruppe.
- A ist reserviert für ESP-Derivate (aktuell Shelly und Tasmota),
- B-M für Kaufgeräte, die nativ MQTT sprechen
- L-Z für eher seltene Geräte oder auch ESP-firmwares, z.B. X90_esp_milight_hub_bridge

Einfach mit Zahlen arbeiten? Will nur irgendwas suchen, was nicht zu Konflikten führt.

[Beta-User]

Dieselbe order-Bezeichnung bedeutet nur, dass dann die betreffenden Geräte unter sich nach dem Namen sortiert werden, der Platz ist nicht "belegt".

[Motivierte linke Hände]

Moin, ich habe nun gerade meine HUE E27 Leuchten von der HUE Bridge auf zigbee2mqtt umgestellt. Auf der Suche nach dem passenden Template bin ich bei zigbee2mqtt_light_rgbcct_rgb gelandet. Die grundlegende Steuerung funktioniert, aber einige Elemente wie z.B. "transition" und "power-on-behavior" scheinen nicht vorhanden zu sein.

Bevor ich jetzt das nächste hersteller- und modellspezifische Template erstelle: Gibt es was Besseres, was ich übersehen habe?