Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

[TomLee]

Nachdem wir jüngst großes Interesse an kleingeschriebenen state-Readings hatten

Nur weil ich für Kleinschreibung war bin ich aber jetzt nicht für die Meldung verantwortlich.

Geb zu bisher auf meine GU10-Müller-Tint-CCT-Leuchten das aktualisierte Template (auf Kleinschreibung) noch nicht angewendet zu haben, hab ich aber jetzt mal bei einer und bei mir gibts die Meldung nicht.

Weder mit der Alten, noch der Neuen Fassung (mit if defined): 

Code Auswählen Erweitern

defmod MQTT2_zigbee_gu10_1 MQTT2_DEVICE zigbee_0x00158d0003274a6c
attr MQTT2_zigbee_gu10_1 userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 structexclude wzdl wzdl_map
attr MQTT2_zigbee_gu10_1 IODev MQTT2_Server
attr MQTT2_zigbee_gu10_1 alexaName decke1
attr MQTT2_zigbee_gu10_1 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_zigbee_gu10_1 devicetopic zigbee2mqtt/0x00158d0003274a6c
attr MQTT2_zigbee_gu10_1 event-on-change-reading state,pct,ct
attr MQTT2_zigbee_gu10_1 genericDeviceType light
attr MQTT2_zigbee_gu10_1 group Wohnzimmer
attr MQTT2_zigbee_gu10_1 homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true
attr MQTT2_zigbee_gu10_1 icon light_control
attr MQTT2_zigbee_gu10_1 imageLink /fhem/deviceimages/mqtt2/404006-404008-404004.jpg
attr MQTT2_zigbee_gu10_1 jsonMap color_temp:ct color_temp_startup:ct_startup
attr MQTT2_zigbee_gu10_1 model zigbee2mqtt_light_cct
attr MQTT2_zigbee_gu10_1 readingList $DEVICETOPIC:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP);; $ret->{state}=lc($ret->{state});; return $ret }\
$DEVICETOPIC:.* { $EVENT =~ m,brightness..(\d+), ? {"pct"=>sprintf('%.0f',$1/2.55)} : undef }
attr MQTT2_zigbee_gu10_1 room MQTT2_DEVICE,Privat->OG->Wohnzimmer
attr MQTT2_zigbee_gu10_1 setList on:noArg $DEVICETOPIC/set {"state":"ON"}\
  off:noArg $DEVICETOPIC/set {"state":"OFF"}\
  brightness:colorpicker,BRI,0,5,255 $DEVICETOPIC/set {"state":"on","$EVTPART0":"$EVTPART1"}\
  ct:colorpicker,CT,154,2,500 $DEVICETOPIC/set {"color_temp":"$EVTPART1"}\
  ct_startup:coolest,cool,neutral,warmest,previous $DEVICETOPIC/set {"color_temp_startup":"$EVTPART1"}
attr MQTT2_zigbee_gu10_1 setStateList on off
attr MQTT2_zigbee_gu10_1 verbose 2
attr MQTT2_zigbee_gu10_1 webCmd toggle:on:off:brightness:ct
attr MQTT2_zigbee_gu10_1 webCmdLabel Helligkeit\
:

setstate MQTT2_zigbee_gu10_1 on
setstate MQTT2_zigbee_gu10_1 2022-08-28 15:47:15 IODev MQTT2_Server
setstate MQTT2_zigbee_gu10_1 2022-09-11 05:50:15 attrTemplateVersion 20220622
setstate MQTT2_zigbee_gu10_1 2022-09-11 05:56:25 brightness 70
setstate MQTT2_zigbee_gu10_1 2022-09-11 05:56:25 color_mode color_temp
setstate MQTT2_zigbee_gu10_1 2022-09-11 05:56:25 ct 369
setstate MQTT2_zigbee_gu10_1 2022-09-11 05:56:25 ct_startup 370
setstate MQTT2_zigbee_gu10_1 2021-12-08 16:02:01 effect set blink
setstate MQTT2_zigbee_gu10_1 2022-09-11 05:56:25 linkquality 143
setstate MQTT2_zigbee_gu10_1 2022-09-11 05:56:25 pct 27
setstate MQTT2_zigbee_gu10_1 2022-09-11 05:56:25 state on

@SamNitro

zeig doch mal den MQTT-Traffic.

[Beta-User]

Zur Kleinschreibungsfrage hatten noch ein paar andere ein Votum abgegeben...

Das "eval" hat aber den "if defined"-Teil gar nicht drin, das muss also von einem anderen Device kommen. Hatte beim suchen/ersetzen nur die bearbeitet, die dem Muster ohne $JSONMAP entsprechen, muss nochmal nachsehen, welche es mit diesem Feature gibt und das dann nachziehen..

[SamNitro]

Nachdem ich alle Geräte nach dem alten stand abgeändert hatte, kann ich es nicht mehr reproduzieren. Also momentan habe ich selber keine Fehler mehr.. teste mal weiter.

[Umber]

Bin die Tage von Conbee2 und Deconz auf sonoff Zigbee3 und zigbee2mqtt umgezogen.
Den mqtt2server in fhem nutze ich schon länger wegen shellys, tasmota usw.

Die readingList im template vom zigbee2mqtt_bridge bringt mein fhem zu einem 23 sec. freeze, bei ca. 34 Zigbee Geräten.

Code Auswählen Erweitern


attr DEVICE readingList\
  $\DEVICETOPIC/bridge/state:.* state\
  $\DEVICETOPIC/bridge/config/devices:.* {}\
  $\DEVICETOPIC/bridge/config/log_level:.* log_level\
  $\DEVICETOPIC/bridge/config/permit_join:.* permit_join\
  $\DEVICETOPIC/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }\
  $\DEVICETOPIC/bridge/config:.* { json2nameValue($EVENT) }\
  $\DEVICETOPIC/bridge/log:.*\"type\".\"devices\".\"message\".* devices\
  $\DEVICETOPIC/bridge/log:.* log\
  $\DEVICETOPIC/bridge/logging:.* { json2nameValue($EVENT,'log_') }\
  $\DEVICETOPIC/bridge/response/networkmap:.* { my $type = $EVENT =~ m/.*,"type":"(raw|graphviz)",.*/ ? $1 : 'networkmap'; $EVENT =~ m/{"data":\{.*"value":"?(.*[^"])"?\},"status":"ok"\}/ ? { $type=>$1 } : {} }\
  $\DEVICETOPIC/bridge/devices:.* devices\
  $\DEVICETOPIC/bridge/info:.* info\
  $\DEVICETOPIC/bridge/groups:.* groups\
  $\DEVICETOPIC/bridge/event:.* { json2nameValue($EVENT) }\
  $\DEVICETOPIC/bridge/extensions:.* extensions


ich hab das ganze auf

Code Auswählen Erweitern


#zigbee2mqtt/bridge/devices:.* devices
zigbee2mqtt/bridge/event:.* { json2nameValue($EVENT) }
#zigbee2mqtt/bridge/state:.* { json2nameValue($EVENT) }
#zigbee2mqtt/bridge/response/group/remove:.* { json2nameValue($EVENT) }
#zigbee2mqtt/bridge/response/group/add:.* { json2nameValue($EVENT) }
#zigbee2mqtt/bridge/response/group/rename:.* { json2nameValue($EVENT) }
zigbee2mqtt/bridge/info:.* info
#zigbee2mqtt/bridge/response/options:.* { json2nameValue($EVENT) }

reduziert.


Freezes sind nun weg und ich habe, ich frage mich allerdings ob das ein Fehler meinerseits ist und ich bei der Konfiguration was falsch gemacht habe oder hier ein Fehler beim Template passiert ist?

edit:
ich sehe gerade dass die readingList des Templates anders wie meine readingList im device ist?
Hmm vielleicht ist da auch was beim erstellen schiefgelaufen, hatte auch diese 2. zigbee2mqtt bridge drin.

edit2:
Template erneut geladen, richtige readingList sind nun auch im Device und fhem bleibt hängen.

[Beta-User]

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.

[Umber]

Danke für die Rückmeldung.
Du hast Recht, es scheint bei mir zu liegen.

Es werden weiterhin irgendwie 2 zigbee2mqtt_bridge erzeugt.
Das System läuft nun auch mitlerweile ohne Freezes, werde dem Problem der 2. bridge auch erstmal nicht weiter nachgehen.

Ein auskommentieren von beseitigt die freezes:

Code Auswählen Erweitern

\DEVICETOPIC/bridge/devices:.* devices\

Sorry für den Fehlalarm.

[Beta-User]

Wenn da bei dir Backslashes drin sind, ist das seltsam und so nicht gedacht!

[Umber]

Ups,

den Code hab ich aus der Template Beschreibung herauskopiert...

Richtig sollte es so lauten:

Code Auswählen Erweitern

#$DEVICETOPIC/bridge/devices:.* devices

[Beta-User]

Der Code in attrTemplate ist nicht in allen Aspekten dazu gedacht, eine 1:1-Kopie anzufertigen.

Falls du support brauchst, um das zu bereinigen, hatte ich ja geschrieben, was du tun sollst, ansonsten gehe ich davon aus, dass kein allgemeines Problem besteht und du alleine klarkommst.

[drhirn]

Ich bitte (auch im Hinblick auf diesen Thread... https://forum.fhem.de/index.php/topic,126790.msg1213807.html#msg1213807) um weitere Rückmeldungen sowie um Info, ob der erste der drei Pfade aktuell überhaupt noch "beliefert" wird. (wenn nein, kann der raus).

Wie ist es mit den weiteren "bridge/config/"-Topics?

Nach $DEVICETOPIC/bridge/config/devices:.* {} kommt nichts mehr, wie's aussieht.
$DEVICETOPIC/bridge/devices:.* {} und $DEVICETOPIC/bridge/info:.* {} werden immer noch befüllt. Mit unglaublich vielen Informationen.

Ich widme mich erst seit letzter Woche dem Thema zigbee2mqtt, aber da dürfte sich sehr viel getan haben. Das Bridge-Template passt auf jeden Fall nicht mehr ganz.

Die aktuellen Topics sind hier: https://www.zigbee2mqtt.io/guide/usage/mqtt_topics_and_messages.html#mqtt-topics-and-messages

Ich hab da mal schnell eine readingList zusammen gebastelt, weiß aber nicht, in wie fern die sinnvoll ist oder nicht:

Code Auswählen Erweitern


attr Zigbee2Mqtt readingList $DEVICETOPIC/bridge/info:.* {}\
$DEVICETOPIC/bridge/state:.* state\
$DEVICETOPIC/bridge/logging:.* { json2nameValue($EVENT,'logging_') }\
$DEVICETOPIC/bridge/devices:.* {}\
$DEVICETOPIC/bridge/groups:.* {}\
$DEVICETOPIC/bridge/event:.* { json2nameValue($EVENT,'event_') }\
$DEVICETOPIC/bridge/extensions:.* {}\
$DEVICETOPIC/bridge/response/permit_join:.* { json2nameValue($EVENT, 'permit_join_', $JSONMAP) }\
$DEVICETOPIC/bridge/response/health_check:.* { json2nameValue($EVENT,'health_',$JSONMAP) }\
$DEVICETOPIC/bridge/response/restart:.* { json2nameValue($EVENT,'restart_',$JSONMAP) }\
$DEVICETOPIC/bridge/response/networkmap:.* { my $type = $EVENT =~ m/.*,"type":"(raw|graphviz)",.*/ ? $1 : 'networkmap';; $EVENT =~ m/{"data":\{.*"value":"?(.*[^"])"?\},"status":"ok"\}/ ? { $type=>$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_',$JSONMAP) }\
$DEVICETOPIC/bridge/response/device/ota_update/.*:.* device\
$DEVICETOPIC/bridge/response/device/.*:.* device\
$DEVICETOPIC/bridge/response/group/.*:.* group\
$DEVICETOPIC/bridge/response/group/members/.*:.* group_members\
$DEVICETOPIC/bridge/response/options:.* options\
$DEVICETOPIC/bridge/response/touchlink/.*:.* touchlink\
$DEVICETOPIC/bridge/request/permit_join:.* {}\
$DEVICETOPIC/bridge/request/health_check:.* {}\
$DEVICETOPIC/bridge/request/restart:.* {}\
$DEVICETOPIC/bridge/request/networkmap:.* {}\
$DEVICETOPIC/bridge/request/extension/.*:.* {}\
$DEVICETOPIC/bridge/request/backup:.* {}\
$DEVICETOPIC/bridge/request/install_code/add:.* {}\
$DEVICETOPIC/bridge/request/touchlink/.*:.* {}\
$DEVICETOPIC/bridge/request/options:.* {}\
$DEVICETOPIC/bridge/config:.* { json2nameValue($EVENT,'config_',$JSONMAP) }\
$DEVICETOPIC/bridge/config/log_level:.* log_level\
$DEVICETOPIC/bridge/log:.* { json2nameValue($EVENT,'log_',$JSONMAP) }


Die setList muss auch noch überarbeitet werden.

Weiters wird für jede Gruppe ein eigenes MQTT2_DEVICE angelegt. Da müsste man sich etwas überlegen und vielleicht ein eigenes Template bauen.

**edit**
Die Zeile mit Backup geändert.

[Umber]

@drhirn

danke für deine readingList!
Ich kann diese ganz normal nutzen, brauche nichts mehr auszukommentieren, die 2. Brücke wird hiermit auch nicht mehr erstellt.
Meine 23sec. freeze bei der Kartenerstellung und beim hart einschalten eines beliebigen zigbee devices treten hiermit auch nicht mehr auf.
Vielen Dank!

Das hängt vermutlich alles mit der verwendeten zigbee2mqtt Version ab.

Code Auswählen Erweitern


Zigbee2MQTT Version 1.28.0 commit: 03ba647
 

[Beta-User]

Hmm, habe heute morgen mal kurz drübergeschaut, aber da ist mir zu viel unklar (an freezes (nur) wegen dem alten template glaube ich weiter nicht, und das mit der "2. Brücke" kann ich mir zwar zusammenreimen, es dürfte aber andere Ursachen haben).

Wieso wird $JSONMAP als Argument übergeben, wenn es kein jsonMap-Attribut gibt?

Das alles auszuknipsen könnte man zusammenfassen, aber mein Bauchgefühl sagt mir, dass es Leute geben wird, die das sehen wollen (ggf. als unausgepackten Content), evtl. könnte man zwei Varianten anbieten?

Für eine konsolidierte Zusammenfassung bin ich aber gerne zu haben, wenn das mit der setList steht. Es müßte ja genug erfahrene User geben, die ein aktuelles z2m nutzen und was dazu sagen können...

[drhirn]

Ich hab das nur als Diskussionsgrundlage verstanden. Nicht als fertige Lösung.
Bei devices und info kommt z.B. unglaublich viel Text daher. Da scrollt man sich zu Tode, wenn man ans Ende der Seite will . Wer's aber will, kann das einfach ändern. Oder wirklich zwei Versionen.

[drhirn]

Für eine konsolidierte Zusammenfassung bin ich aber gerne zu haben, wenn das mit der setList steht.

Was sollte man denn in die setList alles rein packen? Macht das wirklich Sinn, die ganzen Device-Commandos in der Bridge zu parken? Das selbe für Group? Brauchen wir Touchlink überhaupt?

[Beta-User]

Was sollte man denn in die setList alles rein packen? Macht das wirklich Sinn, die ganzen Device-Commandos in der Bridge zu parken? Das selbe für Group? Brauchen wir Touchlink überhaupt?

Falls sich das an meine Adresse wendet: Ich habe (seit längerem) kein z2m im Einsatz und habe schon von daher vermutlich schon Schwierigkeiten, die Frage zu verstehen, geschweige denn, sie sinnvoll zu beantworten.

Ein paar prinzipielle Antworten vielleicht (das ist aber zum Teil auch eine Geschmacksfrage):
- die setList sollte hinsichtlich der "wirklichen" Administrationsaufgaben alle wichtigen Kommandos ermöglichen. Tocuhlink ist vermutlich ein Grenzfall: Wer es braucht, wird es sehr vermissen, wer keine entsprechenden Geräte hat, wird sich fragen, was der Begriff überhaupt bedeutet. DE hat es in der Phoscon-App so gelöst, dass es in der neuen Version nicht drin ist und man die alte App starten muss, um es zu aktivieren. Von daher wäre ich eher für raus, aber es sollte dann im Wiki stehen, wie mal es dazu basteln kann (oder das attrTemplate solle einem die Wahl lassen). Da es hier um eine relativ zentrale/verbreitete Variante geht, halte ich den Mehraufwand für ok.
- Device-bezogene Kommandos gehören m.E. nicht in die Bridge, aber vermutlich verstehe ich an der Stelle die Frage nicht.
- Dto. für Gruppen-Kommandos, wobei ich darunter alles verstehe, was (in der FHEM-Modul-Welt) in die Richtung "structure" geht. Sowas darf dann auch ein eigenes Device geben. Aber vermutlich war das wieder nicht die Frage...?