zigbee2mqtt_bridge nach Anwendung attrTemplate und reboot wieder viele readings

[cb2sela]

Hallo zusammen,

DeConz hatte mir gar nicht gefallen und meine Zigbee-Devices sind für ein Jahr mit IOBroker fremdgegangen und liefen dort ganz gut mit dem nativen Zigbee-Adapter.
Ich würde meine Zigbee-Devices jetzt aber doch gerne zurück nach FHEM holen und habe mir ein Testsystem mit Zigbee2MQTT aufgebaut. Das läuft auch schon ganz passabel, aber hat noch ein paar kleine Wehwehchen.

Ich betreibe Zigbee2MQTT als Docker-Image (non-root) und meine configuration.yaml sieht so aus:

Code Auswählen Erweitern

homeassistant: false
permit_join: false

mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://172.17.0.1
  user: mqttuser
  password: xxxxxxxxx
  client_id: 'zigbee_pi'

serial:
  port: /dev/ttyACM0

advanced:
  network_key: GENERATE
  log_level: warn

frontend:
  port: 8080
  host: 0.0.0.0
  auth_token: xxxxxxxxx

ota:
  disable_automatic_update_check: true


(btw.: das setting report: true gilt gem. Zigbee2MQTT-Doku mittlerweile als deprecated. Falls jemand mit Berechtigung das im Wiki-Artikel korrigieren möchte).

Starten / Laufen tut es so:

Code Auswählen Erweitern

docker run -d --name="Zigbee2MQTT" \
   --device=/dev/ttyACM0 \
   -p 8080:8080 \
   -v /opt/Zigbee2MQTT/data:/app/data \
   -v /run/udev:/run/udev:ro \
   --user 1000:1000 \
   --group-add dialout \
   -e TZ=Europe/Berlin \
   --restart unless-stopped \
   koenkk/zigbee2mqtt


Wenn ich in FHEM das attrTemplate auf mein bridgedevice anwende:

Code Auswählen Erweitern

set MQTT2_zigbee_pi attrTemplate zigbee2mqtt_bridge
dann sind die je ca. 30kb großen readings für devices und info weg.
Sie erscheinen nicht mehr im Event-Monitor und werden auch nicht geloggt, wenn ich z.B. einen Dimmer betätige.

Nach einem reboot meines raspberrys sind die readings wieder da und tauchen auch immer wieder im logfile MQTT2_zigbee_pi auf.
Das hat beim setup jetzt mal eben zu 11MB logdaten geführt.

Mache ich was falsch, weil die readings nach einem reboot immer wieder da sind oder ist das normal?
Wie ist das bei Euch? Sollte ich die readings einfach nur mit einer entsprechenden regex aus dem logfile verbannen und damit leben, dass sie mir halt auch immer wieder den Event-Monitor zuspammen?

Vielen Dank + Gruß

[Beta-User]

Wiki habe ich (geringfügig) angepaßt, kann gerne noch wer weiter verbessern, der das nutzt.

Was die eigentliche Frage angeht, tappe ich im Dunkeln, wie das was gemeint ist...
Mir fehlen z.B. Infos, welcher MQTT-Server im Einsatz ist: https://forum.fhem.de/index.php/topic,112327.0.html

Und es kann schon sein, dass bestimmte Infos dann wieder gesendet werden, wenn ein reconnect zum Server stattfindet. Es ist aber niemand gezwungen, irgendwas zu loggen.

Vielleicht zeigst du das aktuelle "bridge"-Device (als RAW), wie es nach einem FHEM-restart aussieht?

[cb2sela]

Danke für das Anpassen des WIKI-Eintrags.

Ich verwende den FHEM MQTT2-Server ohne irgendwelche Besonderheiten.

Code Auswählen Erweitern

define MQTT2_FHEM_Server MQTT2_SERVER 1883 global;
attr MQTT2_FHEM_Server autocreate 1;


Die RAW-Definition meiner Bridge sieht so aus (Das lange JSON aus den readings devices, info und groups habe ich gekürzt (z.B. XXX HIER KOMMEN CA. 30KB JSON XXX)  und ein paar Hardware-Adressen ge-x-t.

Mich interessiert primär, ob Ihr nach einem reboot des raspis auch die langen readings aus devices und info habt und wie Ihr damit umgeht.

Code Auswählen Erweitern


defmod MQTT2_zigbee_pi MQTT2_DEVICE zigbee_pi
attr MQTT2_zigbee_pi bridgeRegexp zigbee2mqtt/([A-Za-z0-9._]+)[/]?.*:.* "zigbee_$1"
attr MQTT2_zigbee_pi 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_pi devicetopic zigbee2mqtt
attr MQTT2_zigbee_pi getList networkmap_raw:noArg raw $DEVICETOPIC/bridge/request/networkmap raw\
  networkmap_graphviz:noArg graphviz $DEVICETOPIC/bridge/request/networkmap graphviz
attr MQTT2_zigbee_pi icon mqtt
attr MQTT2_zigbee_pi model zigbee2mqtt_bridge
attr MQTT2_zigbee_pi 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
attr MQTT2_zigbee_pi room MQTT2_DEVICE
attr MQTT2_zigbee_pi setList log_level:debug,info,warn,error $DEVICETOPIC/bridge/config/log_level $EVTPART1\
  permit_join:true,false $DEVICETOPIC/bridge/config/permit_join $EVTPART1\
  remove:textField $DEVICETOPIC/bridge/config/remove $EVTPART1\
  ota_update:textField $DEVICETOPIC/bridge/ota_update/update $EVTPART1\
  ota_update_check:textField $DEVICETOPIC/bridge/ota_update/check $EVTPART1\
  y_device_setting:textField $DEVICETOPIC/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}\
  x_bind:textField $DEVICETOPIC/bridge/bind/$EVTPART1 $EVTPART2\
  x_bind_unbind:textField $DEVICETOPIC/bridge/unbind/$EVTPART1 $EVTPART2\
  x_device_options:textField $DEVICETOPIC/bridge/config/device_options {"friendly_name":"$EVTPART1","options": {"$EVTPART2": "$EVTPART3"}}\
  x_group_add_to:textField $DEVICETOPIC/bridge/group/$EVTPART1/add $EVTPART2\
  x_group_rm_from:textField $DEVICETOPIC/bridge/group/$EVTPART1/remove $EVTPART2\
  x_group_rm_from_all:textField $DEVICETOPIC/bridge/group/$EVTPART1/remove_all $EVTPART2\
  x_group_add_group:textField $DEVICETOPIC/bridge/config/add_group $EVTPART1\
  x_group_rm_group:textField $DEVICETOPIC/bridge/config/remove_group $EVTPART1\
  z_elapsed:textField $DEVICETOPIC/bridge/config/elapsed $EVTPART1\
  z_last_seen:disable,ISO_8601,epoch,ISO_8601_local $DEVICETOPIC/bridge/config/last_seen $EVTPART1\
  z_ban:textField $DEVICETOPIC/bridge/config/ban $EVTPART1\
  z_rename:textField $DEVICETOPIC/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
  z_reset_CC:noArg $DEVICETOPIC/bridge/config/reset
attr MQTT2_zigbee_pi setStateList on off

setstate MQTT2_zigbee_pi online
setstate MQTT2_zigbee_pi 2022-03-15 11:49:08 IODev MQTT2_FHEM_Server
setstate MQTT2_zigbee_pi 2022-03-15 11:45:44 attrTemplateVersion 20220218
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 commit 7axxxx2
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 coordinator_meta_maintrel 0
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 coordinator_meta_majorrel 38
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 coordinator_meta_minorrel 102
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 coordinator_meta_product 0
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 coordinator_meta_revision 0x26660700
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 coordinator_meta_transportrev 0
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 coordinator_type ConBee2/RaspBee2
setstate MQTT2_zigbee_pi 2022-03-15 14:51:51 data_friendly_name ET_Dimmer
setstate MQTT2_zigbee_pi 2022-03-15 14:51:51 data_ieee_address 0xbc33xxxxxxxxdbcc
setstate MQTT2_zigbee_pi 2022-03-15 14:51:51 devices [{"definition":null,"endpoints":... XXX HIER KOMMEN CA. 30KB JSON XXX ... "type":"EndDevice"}]
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 extensions []
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 groups [{"friendly_name":"ET_Lampen","id":1,"members":... IN SUMME HIER 350 byte JSON ... ,"scenes":[]}]
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 info {"commit":"7a2ddf2","config":... XXX HIER KOMMEN CA. 20KB JSON XXX ... "restart_required":false,"version":"1.24.0"}
setstate MQTT2_zigbee_pi 2022-03-15 14:51:51 log {"message":"announce","meta":{"friendly_name":"ET_Dimmer"},"type":"device_announced"}
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 log_level warn
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 network_channel 11
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 network_extendedPanID 0xdddddddddddddddd
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 network_panID 1234
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 permit_join false
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 state online
setstate MQTT2_zigbee_pi 2022-03-15 11:50:08 subscriptions zigbee2mqtt/#
setstate MQTT2_zigbee_pi 2022-03-15 14:51:51 type device_announce
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 version 1.24.0


Die messages kommen sporadisch. Z.B. wenn ein batteriebetriebener Dimmer sich zwischendurch mal wieder meldet:

Code Auswählen Erweitern


2022-03-15_14:51:51 MQTT2_zigbee_pi devices: [{"definition":null, XXX HIER WIEDER CA. 30KB JSON XXX ....
2022-03-15_14:51:51 MQTT2_zigbee_pi data_friendly_name: ET_Dimmer
2022-03-15_14:51:51 MQTT2_zigbee_pi data_ieee_address: 0xbc33acxxxxxxxxcc
2022-03-15_14:51:51 MQTT2_zigbee_pi type: device_announce
2022-03-15_14:51:51 MQTT2_zigbee_pi log: {"message":"announce","meta":{"friendly_name":"ET_Dimmer"},"type":"device_announced"}


[Beta-User]

Mich interessiert primär, ob Ihr nach einem reboot des raspis auch die langen readings aus devices und info habt und wie Ihr damit umgeht.

Kannst du dann bitte den Thread-Titel entsprechend anpassen?

Die per attrTemplate vorgenommenen Änderungen sind jedenfalls nach dem gezeigten list weiter vollständig.

Wenn du die Readings (devices/groups) nicht brauchst, kannst du einfach {} statt des Readingnamens hintendran schreiben, und loggen musst du das ganze ja auch nicht...

[Otto123]

Ich weiß nicht was das Attribute autocreate 1 macht
Die semikolon am Ende der Zeile sehen auch wie handeditiert aus 

Ich verwende den FHEM MQTT2-Server ohne irgendwelche Besonderheiten.

Code Auswählen Erweitern

define MQTT2_FHEM_Server MQTT2_SERVER 1883 global;
attr MQTT2_FHEM_Server autocreate 1;


Wie vorgesehen ist es nicht gesetzt!

autocreate [no|simple|complex]
MQTT2_DEVICES will be automatically created upon receiving an unknown message. Set this value to no to disable autocreating, the default is simple.
With simple the one-argument version of json2nameValue is added: json2nameValue($EVENT), with complex the full version: json2nameValue($EVENT, 'SENSOR_', $JSONMAP). Which one is better depends on the attached devices and on the personal taste, and it is only relevant for json payload. For non-json payload there is no difference between simple and complex.

Kann sein, der Fehler wird ignoriert und es steht auf standard: simple

[cb2sela]

Ich versuche, mein neues System diesmal soweit es geht geskriptet aufzusetzen und dazu gehört auch, dass ich mal 5 Zeilen am Stück mit Semikolon getrennt in die Direkteingabe-Zeile eingebe, um z.b. meine notifys für ein device zu generieren.

Und genauso habe ich auch meinen MQTT2-Server aufgesetzt. Gespickt bei einer älteren Installation, wo es die Option ggf. mal gab oder ich das damals halt falsch verstanden hatte.
Ich dachte, ohne das attribut würde er überhaupt keine Devices automatisch anlegen, aber da lag ich wohl sowohl inhaltlich als auch syntaktisch knapp daneben

Das attr MQTT2_FHEM_Server autocreate 1; ist nun weg, aber das Verhalten ist noch gleich.
D.h. nach dem unmittelbaren Anwenden von set MQTT2_zigbee_pi attrTemplate zigbee2mqtt_bridge sind die großen readings für devices und info weg. Nach einem reboot des raspi sind sie wieder da.

Beta-User: Ohne die technischen Tiefen des attrTemplates zu kennen schaut das aus Anwendersicht halt einfach so aus, als würde ein wünschenswerter Effekt des attrTemplates einen reboot nicht überleben.
Welchen alternativen Thread-Titel schlägst Du vor?

Was Ihr mir noch nicht beantwortet habt: Sind die readings bei Euch auch da oder nicht?

Ich verstehe auch noch nicht, wo und wie ich an welcher Stelle die {} setzen soll, um die großen readings zu unterdrücken. Auch weiß ich nicht, ob ich damit ggf. notwendige Nutzlast unterdrücke.

Danke + guts Nächtle.

[Beta-User]

Ich versuche, mein neues System diesmal soweit es geht geskriptet aufzusetzen und dazu gehört auch, dass ich mal 5 Zeilen am Stück mit Semikolon getrennt in die Direkteingabe-Zeile eingebe, um z.b. meine notifys für ein device zu generieren.

Gefragt war aber nach der raw-DEF, also dem Ergebnis, wie FHEM den Input verarbeitet hat...
(die Vorgehensweise per script klingt nach "nicht optimal" bzw. RAW-Import ist unbekannt).

D.h. nach dem unmittelbaren Anwenden von set MQTT2_zigbee_pi attrTemplate zigbee2mqtt_bridge sind die großen readings für devices und info weg. Nach einem reboot des raspi sind sie wieder da.

Nochmal: Das ist NORMAL, das attrTemplate löscht nur erst mal alle Readings, weil die TEILWEISE besser in anderen M2D-Instanzen aufgehoben sind und/oder ggf. später anders heißen.
Dass im laufenden Betrieb dann wieder Daten (Readings) anfallen, ist doch logisch und gewollt.

=> Thread ist m.E. geklärt, weder geht das attrTemplate selbst "verloren", noch ist das sich ergebende Device nicht persistent.

Welchen alternativen Thread-Titel schlägst Du vor?

Da ich deine Frage schon nicht (mehr) verstehe, habe ich auch keinen Vorschlag...
Von daher würde ich für einen [geklärt] als Einleitung für den Thread-Titel für angezeigt halten.

Ich verstehe auch noch nicht, wo und wie ich an welcher Stelle die {} setzen soll, um die großen readings zu unterdrücken. Auch weiß ich nicht, ob ich damit ggf. notwendige Nutzlast unterdrücke.

Es gibt doch Zeilen in der readingList, in denen das so schon gesetzt ist...
Und was du brauchst oder nicht, musst du schon selbst entscheiden. Loggen würde ich z.B. das Reading  "devices" jedenfalls nicht, aber das ist ein anderes Thema...

[Otto123]

Moin,

habe ich das richtig verstanden: erfüllt die Bridge ihre eigentliche Aufgabe nicht? Eigentlich dient sie ja der Verteilung der Nachrichten und es müssten statt Readings in der Bridge neue MQTT2 Devices entstehen, die die zigbee Geräte darstellen. Ich hatte nicht herausgelesen, dass letzteres passiert. Vielleicht ist das das eigentliche Problem?

Gruß Otto

[Beta-User]

Das raw-list sah diesbezüglich "sauber" aus, und die verbleibende Frage war m.E. eigentlich auch klar:

Mich interessiert primär, ob Ihr nach einem reboot des raspis auch die langen readings aus devices und info habt und wie Ihr damit umgeht.

Code Auswählen Erweitern


setstate MQTT2_zigbee_pi 2022-03-15 14:51:51 devices [{"definition":null,"endpoints":... XXX HIER KOMMEN CA. 30KB JSON XXX ... "type":"EndDevice"}]
setstate MQTT2_zigbee_pi 2022-03-15 11:49:48 info {"commit":"7a2ddf2","config":... XXX HIER KOMMEN CA. 20KB JSON XXX ... "restart_required":false,"version":"1.24.0"}


Auch im Eingangspost ging es nur darum:

Wenn ich in FHEM das attrTemplate auf mein bridgedevice anwende:

Code Auswählen Erweitern

set MQTT2_zigbee_pi attrTemplate zigbee2mqtt_bridgedann sind die je ca. 30kb großen readings für devices und info weg.
Sie erscheinen nicht mehr im Event-Monitor und werden auch nicht geloggt, wenn ich z.B. einen Dimmer betätige.

Nach einem reboot meines raspberrys sind die readings wieder da und tauchen auch immer wieder im logfile MQTT2_zigbee_pi auf.
Das hat beim setup jetzt mal eben zu 11MB logdaten geführt.

Sehe nicht, dass irgendwas an Frage nicht beantwortet wäre (wenn auch ggf. Verständnisprobleme bei der "Übersetzung" der Antwort da sind, aber das sind v.a. bzgl. FileLog Anfängerfragen).
_sehr vielleicht_ kann man die Frage stellen, ob ins attrTemplate noch event-on.*-Attribute rein sollten (die dann ggf. auch ausschließen, was man nicht zu loggen braucht). An der Stelle bin ich für Vorschläge offen...

[cb2sela]

Ich denke Otto versteht, warum ich so verwundert bin.

Ich häng mal zwei Screenshots an: Nach_Anwendung_attrTemplate.png. Hier gefällt mir alles gut und so sollte es imho sein und auch bleiben.

Nach_reboot.png ist das, was mich stört. Der Screenshot ist unten abgeschnitten und geht noch ganz viel weiter.

Technisch funktioniert trotzdem alles und meine Devices gehen, aber das Bridge-Device sieht einfach falsch und kaputt aus.

Edit: Das einzige Reading, welches nach dem Anwenden des attrTemplates da ist, ist "attrTemplateVersion 20220218 2022-03-16 16:03:55".
Ich sehe grade zum ersten mal, dass die bridge selber vermutlich gleich geblieben ist, aber dass der Block "readings" von ursprünglich einer Zeile so massiv auf den beigefügten Screenshot angewachsen ist.

Edit2: Ich habe dafür auch mal die besseren Screenshots Vor_Reboot und Nach_Reboot hinzugefügt, die das Problem besser zeigen.

[Beta-User]

Ich sehe grade zum ersten mal, dass die bridge selber vermutlich gleich geblieben ist, aber dass der Block "readings" von ursprünglich einer Zeile so massiv auf den beigefügten Screenshot angewachsen ist.

Aha, wir kommen voran...

Dass im laufenden Betrieb dann wieder Daten (Readings) anfallen, ist doch logisch und gewollt.

Von daher nochmal: die Fragestellung aus dem Thread-Titel ist geklärt .

Die weitere Frage, ob diese "Mega-Reading"-Inhalte für irgendwas benötigt werden, ist ja durchaus berechtigt, und _vielleicht_ hatten wird das in Bezug auf "devices" in der Vergangenheit ja auch mal so gelöst gehabt, dass das im digitalen Nirvana landet, was da kommt (damals aber noch unter einem anderen Topic, der evtl. auch raus kann). Im Moment ist es "wenigstens" so gelöst, dass die JSON-Daten nicht auch noch ausgepackt werden und eine Unmenge Readings erzeugen, mit denen keiner was anfängt.
Ob man diese Zweige ganz nach "devstrichnull" schicken sollte, kann gerne diskutiert werden, aber bitte eben unter der korrekten Begrifflichkeit. Ich bitte um Rückmeldung von jemandem, der das im Einsatz hat und die Historie dazu in etwa nachvollziehen kann...