Änderungen durch zigbee2mqtt Vers.2

[rob]

Hallo.

Vielleicht bei Euch auch der Fall: zigbee2mqtt hat mit v2 Änderungen mitgebracht.
- zwingende Angabe des Adaptertyps (z.B. "adapter: zstack") in der configuration.yaml nötig, sonst startete z2m nicht
- Devices wurden aus den Gruppen in z2m entfernt, sodass sie dort und über Fhem funktionslos sind -> musste die Geräte erst wieder den Gruppen hinzufügen
- in Fhem wurde ein neues MQTT-Device angelegt "MQTT2_mqttjs_a329d2bb", das anscheinend nur mit Homeassistant-topics befüttert wird (ich hab kein HA, weshalb das für mich unnütz erscheint)

Vielleicht gibt es noch mehr, muss noch schauen, was es so tut (oder eben nicht ).

VG
rob

Edit: hier die Release Notes: https://github.com/Koenkk/zigbee2mqtt/releases
Bei mir ist eigentlich alles zu HA im zigbee2mqtt WebIF deaktiviert. Warum dann trotzdem das HA-config-Zeugs kommt, weiß ich nicht. Scheint aber nicht weiter zu stören - das Bridge-Device zu z2m tut jedenfalls.

[eisman]

hi,

ja,

$DEVICETOPIC/availability:.* availability

===>  {"state":"online"}

topic
  zigbee2mqtt/EG/VS_0202/availability
Value
  {"state":"online"}

es wird nicht mehr online oder offline angezeigt sonder {"state":"online"}

Gruß

[TomLee]

Hi,

evtl. ist legacy_availability_payload mit der neuen Version jetzt default false?

https://forum.fhem.de/index.php?msg=1316578

[eisman]

hi,

in der configuration.yaml habe ich es eingeschaltet

Verfügbarkeit Online

wird auch nach der Einstellung angezeigt

$DEVICETOPIC/availability:.* { json2nameValue($EVENT) } ==> wird immer noch {"state":"online"} angezeigt..
availability wird aber aktualliesiert

die Einstellungen sind so gesehen korrekt,

action        on_l1                         2025-01-05 14:58:00
availability {"state":"online"}       2025-01-05 14:37:44
last_seen 2025-01-05T15:55:45+01:00  2025-01-05 15:55:45
linkquality                           208 2025-01-05 15:55:45
power_on_behavior              off 2025-01-05 15:55:45
power_on_behavior_l1          off 2025-01-05 15:55:45
state                                       on 2025-01-05 15:48:56
state_l1                                  on 2025-01-05 15:55:45
state_l2                              OFF  2025-01-05 15:55:45
state_l3                               OFF 2025-01-05 15:55:45
gruss

[TomLee]

$DEVICETOPIC/availability:.* { json2nameValue($EVENT) } ==> wird immer noch {"state":"online"} angezeigt..
availability wird aber aktualliesiert

Komm nicht ganz mit, bzw. kann ich es mir nicht vorstellen. Mit json2nameValue($EVENT) ändert sich der Zeitstempel des "alten" Readings availability?

Rate nur, hab selbst noch nicht aktualisiert. online/offline sollte mit json2nameValue doch jetzt in state landen und der wird sofort wieder vom "Devicestatus" überschrieben, darum sieht man nix im Device? Meine Vorstellung.

[eisman]

hi,

nein er ändert sich nur nach dem neu starten von zigbee2mqtt.

sonst zeig der Status keine Reaktionen.

Zeitstempel des "alten" Readings availability? nein nur nach reboot

Rate nur, hab selbst noch nicht aktualisiert. online/offline sollte mit json2nameValue doch jetzt in state

nein der wert ändert sich auch nicht (mehrere male ausprobiert.

nach löschen aller readings wird availability auch nicht neu geschrieben
er wird nur beim neustart von zigbee2mqtt wieder angelegt

so hab es nochmal getestet, es wird nur das availability genutzt und es wird
in state geschrieben (Schlimmer Fehler). Warum war das nicht zu sehen....
es wird in zigbee2mqtt nicht ausgelöst,
wenn ich es direkt schreibe, wird es in state angezeigt (mist)

ich habe es jetzt erstmal so gelöst das ich das reading fest auf online gestellt habe
ist zwar blöd, falls das device offline ist

gruss

[TomLee]

Bin jetzt auch auf 2.0.0

Kommt wohl nur noch als Json, egal ob true oder false. Hab das zuvor noch getestet mit der Version davor, da hat das noch geklappt umzustellen.

Vorschlag:

Code Auswählen Erweitern

$DEVICETOPIC/availability:.* { $EVENT=~s/state/availability/;json2nameValue($EVENT) }

[eisman]

teste ich gleich mal.....

okay jetzt kommt wieder offline und online, Dankeschön
ich lass es so mal etwas laufen

wenn man unter Einstellung erweitert
MQTT output type = attribute
Examples when 'state' of a device is published json: topic: 'zigbee2mqtt/my_bulb' payload '{"state": "ON"}' attribute: topic 'zigbee2mqtt/my_bulb/state' payload 'ON' attribute_and_json: both json and attribute (see above)

einstellt kommt availability bei mir garnicht

gruss

[eisman]

hi,

lief soweit auf der einen Installation gut,
auf der zweiten hat es mir den kompletten zigbee zweig zerlegt,
hab dort erstmal wieder auf phoscon umgestellt.

gruss

[betateilchen]

- in Fhem wurde ein neues MQTT-Device angelegt "MQTT2_mqttjs_a329d2bb",

In aktuellen FHEM Installationen sollte der Präfix MQTT2_ bei automatisch angelegten devices eigentlich nicht mehr auftauchen.

Scheint aber nicht weiter zu stören - das Bridge-Device zu z2m tut jedenfalls.

Wozu man dieses bridge-device überhaupt braucht, erschließt sich mir bis heute noch nicht.
Meine zigbee devices funktionieren auch ohne diese bridge alle perfekt mit zigbee2mqtt in FHEM.
Und das, was man über die bridge von FHEM aus in zigbee2mqtt machen könnte, ist über die eigene WebGUI von z2m in einem Bruchteil der Zeit erledigt.

[Beta-User]

- in Fhem wurde ein neues MQTT-Device angelegt "MQTT2_mqttjs_a329d2bb", das anscheinend nur mit Homeassistant-topics befüttert wird (ich hab kein HA, weshalb das für mich unnütz erscheint)

Kommt vermutlich darauf an, wie die bridgeRegexp im bridge-Device definiert war. Habe da in meiner Installation ein paar Dinge geändert/ergänzt, das ist aber alles noch nicht konsolidiert...

Wozu man dieses bridge-device überhaupt braucht, erschließt sich mir bis heute noch nicht.

Niemand "braucht" das... V.a. nicht, seit es die WebUI gibt, gehen viele Konfigurationen in der Tat darüber sehr viel einfacher.
Ich "brauche" das, weil ich den Zustand des Interfaces - wie bei vielen anderen externen Diensten auch - sehen will und ggf. darauf reagieren. Als "Nebeneffekt" kann ich autocreate eingeschaltet lassen (das auch "niemand braucht"), um mir die Topics vorsortieren zu lassen.

Wenn man weiß, was man tut, geht das alles selbstredend auch "irgendwie anders" - wie immer bei FHEM. Bisher habe ich allerdings noch keine verallgemeinerungsfähigen Vorschläge dazu gehört .

[betateilchen]

Niemand "braucht" das
...
autocreate eingeschaltet lassen (das auch "niemand braucht")

Einfaches Prinzip:

Je mehr solcher Dinge, die "niemand braucht" man in seiner FHEM Installation hat, umso mehr mögliche Fehler- bzw. Störungsquellen muss man auch im Auge behalten. Damit schafft man lediglich vermeidbaren zusätzlichen Aufwand, der keinen in vernünftiger Relation stehenden Nutzen schafft.

[rudolfkoenig]

Diese "niemand braucht" Sachen wie autocreate ermoeglichen FHEM zu benutzen, ohne vorher fuer jedes einzelne Geraet stundenlang Doku zu studieren und zu experimentieren. Klar hat man nach Studieren alles besser im Griff (bis man es wieder vergessen hat), aber Software ist auch dazu da, um Zeit zu sparen.
 
In manchen Faellen wie ZWave ist die manuelle Inlusion ohne autocreate fast unmoeglich, weil die Kommunikation innerhalb von wenigen Sekunden erledigt werden muss.

Immerhin wird keiner dazu gezwungen, es zu benutzen.

[Beta-User]

Je mehr solcher Dinge, die "niemand braucht" man in seiner FHEM Installation hat, umso mehr mögliche Fehler- bzw. Störungsquellen muss man auch im Auge behalten. Damit schafft man lediglich vermeidbaren zusätzlichen Aufwand, der keinen in vernünftiger Relation stehenden Nutzen schafft.

Ob man "autocreate" immer angeschaltet lassen sollte, sei mal dahingestellt, aber für den jüngst erfolgten Umzug von deconz nach zigbee2mqtt fand (und finde) ich beide Tools (und "Automatismen" wie $DEVICETOPIC) ausgesprochen hilfreich.
Aber da darf ja jeder, wie er will...

Bei anderen Dingen (wie z.B. der "availability"-Behandlung) muss man m.E. eh selbst Hand anlegen, wenn man "Spezialfälle" abfangen will wie Devices, die aus baulichen Gegebenheiten heraus halt auch mal vom Netz gehen und dann über diesen Automatismus zutreffend als "off" behandelt werden.
Und ganz abgesehen von vielen Dingen, die v.a. beim attrTemplate-Satz für zigbee2mqtt verbessert werden könnten, wären wir heute sicher weder bei der Funktionalität, die MQTT2_DEVICE heute bietet, noch - und das finde ich besonders wichtig - hätten wir derart viele User, die halbwegs sicher mit dem Baukasten MQTT2_DEVICE umgehen können.
(Was teils an Konfigurationen für Tasmota-Devices in MQTT_DEVICE zu finden war, war imo einfach grausam und komplett uneinheitlich).

[betateilchen]

Diese "niemand braucht" Sachen wie autocreate ermoeglichen FHEM zu benutzen, ohne ...

... zu verstehen, warum etwas wie funktioniert. Und das geht genau so lange gut, bis die erste Störung auftritt. Und dann wird es langwierig und der ursprüngliche vermeintliche Zeitvorteil ist komplett im Ar...

Immerhin wird keiner dazu gezwungen, es zu benutzen.

immerhin...

[87insane]

Hey zusammen,

ein wenig doof, dass man diesen Beitrag nicht direkt auf der ersten Seite sieht aber es gibt ihn:
https://github.com/Koenkk/zigbee2mqtt/discussions/24198

Dort sind eigentlich alle wichtigen Änderungen.
Ich habe meinen Kampf mit availability zuerstmal so gelöst:

ReadingList:

Code Auswählen Erweitern

$DEVICETOPIC/availability:.* {json2nameValue($EVENT, 'av_', $JSONMAP)}
jsonMap:

Code Auswählen Erweitern

av_state:availability
Alle anderen Versuche haben Querschläger gebracht oder neue Themen. Da ich nicht glaube, dass diese Geschichte so bleiben wird, kann ich mit diesem Weg erstmal leben. Die Variante weiter oben ist auch gut (suchen und ersetzen in ReadingsList) aber da ich nicht an ein Ende dieses Themas glaube, zum aktuellem Zeitpunkt, möchte ich ggf. zukünftig vorkommende Readings erstmal nicht aus dem Zweig verbannen (oder ggf. aus versehen suchen und ersetzen).

[eisman]

hi,

heute das nächste Problem festgestellt,

ich habe in der Küche 3 Nous Modell A1Z Steckdosen laufen,
die haben heute Morgen nicht ausgeschlafen, sie werden grade
nach dem Zufallsprinzip geschaltet.
mal Einzel, mal zusammen und mal das Radio anstelle der Ladestation.

aktuell geht es mit der Version garnicht

gruss


PS: habe jetzt auch auf der 2. Installation phoscon aufgesetzt,
lieber ein paar Schalter weniger, als eine nicht laufende Installation

[betateilchen]

Gestern Abend habe ich das Update auf zigbee2mqtt 2.0.0 durchgeführt, bis jetzt laufen alle elf Geräte unterschiedlicher Typen und Hersteller völlig unauffällig.

Im Vorfeld waren nur zwei Änderungen - gemäß der Angaben hier - notwendig:

• pnpm installieren
• den Adaptertyp in die configuration.yaml eintragen

[Beta-User]

Meine Erfahrungen beim Umzug von deconz nach z2m (docker). Dabei bin ich erst (Ende Ovember oder so) auf die letzten 1.x-er Versionen (zuletzt 1.42), habe dann kurz vor Torschluss die latest-dev (Testversion zu 2.0) draufgemacht und bin dann jetzt wieder auf der "normalen" 2.0.

Für 2.0 (-preview) war nicht mehr erforderlich wie die Angabe des Adapter-Typs (zstack), dann ist das sauber gestartet.

Ein Gerät ist irgendwann mal verloren gegangen (eine meistens stromlose IKEA-Bulb); wann das genau passiert ist: keine Ahnung, jedenfalls war z.B. auch die "description" wieder da, nachdem die wieder "gejoint" war. Mysteriös...

Die Aqara-Dinger (v.a. ein bestimmter Bewegungsmelder) scheinen hin und wieder den Funkkontakt zu verlieren (Standort im Mesh ist eigentlich nicht so schlecht).

Es gehen viele der Geräte, die ich zum Experimentieren besorgt hatte bzw. bei deconz nur unzureichend einhinden konnte (CO-Melder, Feuermelder, RCBO-Hutschienen-Aktoren). V.a. letztere liefern sehr viel mehr Daten (4phases mit Messungen), manches ist nicht (bei allen) plausibel (Gesamtleistung entspricht nicht bei allen Lastsituationen der Summe der einzelnen Phasen). Da wird wohl noch eine "event-on-change"-Orgie erforderlich werden...

Ein Gerät funktioniert auch nicht gem. Beschreibung (Thermostat, Begrenzungstemperaturen lassen sich nicht setzen, es gibt ein issue dazu.)

Manche Gruppen hatten ihre Mitglieder verloren (ein Prinzip war dahinter nicht zu erkennen).
Probleme mit unmotivierten Schaltungen sind mir eher von deconz in Erinnerung, da half ein update der ConBee-II-firmware.

[betateilchen]

Manche Gruppen hatten ihre Mitglieder verloren (ein Prinzip war dahinter nicht zu erkennen).

Die Konfiguration von Gruppen und deren Mitgliedern über die configuration.yaml ist mit v2 weggefallen - falls das bei Dir der Fall gewesen sein sollte.

[Beta-User]

Die Konfiguration von Gruppen und deren Mitgliedern über die configuration.yaml ist mit v2 weggefallen - falls das bei Dir der Fall gewesen sein sollte.

Hmm, vorab gelesen hatte ich wohl, dass es mit Gruppen Probleme geben könnte, daher auch der Blick in die diesbezügliche Konfiguration (bisher noch ohne Check, wie das intern gehandhabt wird).

Was befremdet: Es waren nur etwa eine Handvoll Gruppen definiert. Von denen war ein Teil leer, es gab eine (neue?) Gruppe mit hoher Nummer. Soweit so "klar", aber warum gab es bei einer Gruppe mittendrin (2) weiter Mitglieder, nur eben weniger (2 statt ursprünglich 3)?  Die eigenen Gruppen waren alle direkt nach der Migration erstellt worden...

Na ja. Ist im Zweifel nicht dramatisch, man muss es halt ggf. reparieren...
Weitere Sonderbarkeit, die aber nichts mit dem Umzug oder update zu tun hat:
Die RCBO-Dinger (ähnlich https://zigbee.blakadder.com/Hoch_ZJSBL7.html) liesen sich unter deconz gar nicht (mehr?) schalten (ursprünglich m.E. schon, da müßte es irgendwann eine Änderung gegeben haben), sondern haben nur noch den Zustand und die Messwerte ausgeworfen (genauer: eigentlich nur den Gesamt-Power-Wert und die kumulierte Leistung, die einzelnen Phasen gingen unter deconz nicht - was in dem Fall nicht schlimm ist, ich will v.a. die genannten Messwerte).
Unter z2m kann man nicht per (z2m-internem) "toggle" schalten, ein dezidiertes on oder off funktioniert dagegen...

OT:
Aus anderem Anlass habe ich mal wieder geschaut, was es so neues gibt in der ZigBee-Welt, und da gibt es echt interessantes Zeug; Hutschienenmodul mit 6 Ein- und Ausgängen für <40 Euro?!? Muss ich mir mal ansehen...

[betateilchen]

OT:
Aus anderem Anlass habe ich mal wieder geschaut, was es so neues gibt in der ZigBee-Welt, und da gibt es echt interessantes Zeug

Falls Dir bei solchen Expeditionen irgendwann mal ein Fenster-Drehgriff-Sensor für Zigbee über den Weg läuft, lass es mich bitte wissen 

[eisman]

Gestern Abend habe ich das Update auf zigbee2mqtt 2.0.0 durchgeführt, bis jetzt laufen alle elf Geräte unterschiedlicher Typen und Hersteller völlig unauffällig.

Im Vorfeld waren nur zwei Änderungen - gemäß der Angaben hier - notwendig:

• pnpm installieren
• den Adaptertyp in die configuration.yaml eintragen

hi,

bei mir gingen die meisten geräte auch, die Installation auch nach den vorgaben.
hauptsächlich waren es geräte von Aqara.

es sind auch sehr viele Meldungen von Problemen im Internet zu finden.

gruss

PS: heute morgen hatte ich komplette neu Installation z2m ohne Geräte gemacht
eingebunden einen Taster, Reaktionszeit bis zu einer Minute

[Beta-User]

Falls Dir bei solchen Expeditionen irgendwann mal ein Fenster-Drehgriff-Sensor für Zigbee über den Weg läuft, lass es mich bitte wissen 

Werde es melden...

Bisher aber negativ. Es gibt einen "Bitron" mit zwei Kontakteingängen, der ist allerdings ziemlich groß und von daher für den Zweck m.E. nicht zu gebrauchen.
ABER: Es gibt ja den Selbstbau-HM. "Eigentlich" sollte es nicht allzu schwer sein, den (CC2530-basiert?) in ZigBee zu bauen. Gibt z.B. hier eine Firmware, die aber für bestromte Devices zu sein scheint: https://ptvo.info/zigbee-switch-configurable-firmware-v2-210/ Irgendwo gab es auch mal eine Seite, mit der man die mehr oder beliebig angepasste firmware direkt bauen konnte, finde das aber auf die Schnelle grade nicht.

[Beta-User]

es sind auch sehr viele Meldungen von Problemen im Internet zu finden.

Zumindest auf die Schnelle finde ich v.a. Dinge, die mit der Adapter-Angabe und "legacy"-Einstellungen für HomeAssistant zu tun haben... Generell eben mit den Themen, die bei "breaking changes" gelistet werden, und von daher eigentlich nicht überraschend sind.

Lange Reaktionszeiten auf Tastendrücke kenne ich auch, habe allerdings das Gefühl, dass es mit dem Wechsel von deconz nach zigbee2mqtt seltener und eher kürzer geworden ist - vielleicht auch, weil der jetzige Adapter eine externe Antenne hat.

Falls du beim Testen parallel noch eine weitere ZigBee-Installation am Laufen hast, solltest du in jedem Fall die Frequenzen trennen (kommt dann aber tendenziell eher zu Interferenzen mit den WLAN-üblichen Kanälen) und bedenken, dass du ggf. eben keinen näheren Mesh-Hopp hast.

Allgemein wäre es hilfreich, wenn du etwas mehr Infos zu deinem Umfeld (ConBee II für beide Varianten? Welche firmware?) liefern würdest. Ggf. können Mitleser dann anhand dieser Infos besser entscheiden, ob ein Wechsel ggf. mit zusätzlichem Stress verbunden wäre.

[eisman]

hi,

ja ich habe noch eine 2. Installation, sie laufen aber auf unterschiedliche Kanälen,
von Anfang an um Problemen zu vermeiden.
ich habe jetzt noch einen RPI mit deConz 2 (1. hat deConz 3) aufgesetzt, neuen Speicher usw.
die Installation läuft aktuell besser als die 1.

bei der 1. Installation fallen nach und nach die Geräte aus....

vielleicht hat ja noch jemand in der nähe eine zigbee Installation und die Probleme kommen dort her.

gruss

[privat58]

Hallo, habe jetzt auch umgestellt und mein readingList nun so abgeändert:

Code Auswählen Erweitern

$DEVICETOPIC:.* { my $ret=json2nameValue($EVENT); $ret->{state}=lc($ret->{state}) if defined $ret->{state}; return $ret }
$DEVICETOPIC/availability:.* { json2nameValue($EVENT, 'availability_', $JSONMAP) }
$DEVICETOPIC.* {}das reading sieht dann so aus: availability_state online
Grüße

[TomLee]

Eine generelle Frage betreffend MQTT und des Json vom jetzigen availability-Topic.

Ist es einfach nicht üblich das doppelte Schlüssel in unterschiedlichen Ebenen einer Hierarchie vorkommen sollen?

Im MQTT2_DEVICE-Kontext wäre es doch sonst das einfachste der Schlüssel wäre jetzt availability. Keine Änderungen sind nötig, man übergibt as is $EVENT json2nameValue in der readingList.

Also ein "z2m-Problem"?

[betateilchen]

Im MQTT2_DEVICE-Kontext wäre es doch sonst das einfachste der Schlüssel wäre jetzt availability. Keine Änderungen sind nötig, man übergibt as is $EVENT json2nameValue in der readingList.

Also ein "z2m-Problem"?

Welches Problem?

Code Auswählen Erweitern

$DEVICETOPIC/availability:.* { availability=>(json2nameValue($EVENT))->{state} }

[betateilchen]

(Offtopic)

Code Auswählen Erweitern

$DEVICETOPIC/availability:.* { json2nameValue($EVENT, 'availability_', $JSONMAP) }


Ob mir irgendwann mal jemand erklären kann,
warum der in 999 von 1000 geposteten Fällen
völlig sinnfreie^* Zusatz "$JSONMAP"
in solchen Codeschnipseln immer wieder auftaucht?

^*sinnfrei, weil ich noch nie irgendwo das dazu passend gesetzte Attribut gesehen habe

[TomLee]

Code Auswählen Erweitern

$DEVICETOPIC/availability:.* { availability=>(json2nameValue($EVENT))->{state} }
Wohl eine der elegantesten Möglichkeiten das in FHEM anzugehen.

Das war aber nicht meine Frage.

Angenommen Du bastelst Dir was mit MQTT. Würdest Du von vornherein darauf achten, doppelte Schlüssel in unterschiedlichen Ebenen einer Topic-Hierarchie zu vermeiden?

[Beta-User]

Code Auswählen Erweitern

$DEVICETOPIC/availability:.* { availability=>(json2nameValue($EVENT))->{state} }
Wohl eine der elegantesten Möglichkeiten das in FHEM anzugehen.

Das war aber nicht meine Frage.

Angenommen Du bastelst Dir was mit MQTT. Würdest Du von vornherein darauf achten, doppelte Schlüssel in unterschiedlichen Ebenen einer Topic-Hierarchie zu vermeiden?

Ich würde nie auf die Idee kommen, einen einzigen Datenpunkt auf einem separaten topic in JSON zu verpacken. Und den dann noch state zu benennen...
Ansonsten ist es m.E. auch eine Frage der Toipcstruktur und der Funktionalität des Geräts. Rollladenaktor mit mehreren Rollläden => warum nicht für jeden Rollladen einen eigenen Zustand-topic mit identischer JSON-Struktur?

(Offtopic)

Code Auswählen Erweitern

$DEVICETOPIC/availability:.* { json2nameValue($EVENT, 'availability_', $JSONMAP) }


Ob mir irgendwann mal jemand erklären kann,
warum der in 999 von 1000 geposteten Fällen
völlig sinnfreie^* Zusatz "$JSONMAP"
in solchen Codeschnipseln immer wieder auftaucht?

^*sinnfrei, weil ich noch nie irgendwo das dazu passend gesetzte Attribut gesehen habe

Mein Tipp: weil sich irgendwoher die allgemeine Überzeugung eingestellt hat, dass "complex" als Voreinstellung für autocreate sinnvoll sei.
Viele Leute scheinen überkomplexe Readingnamen zu mögen und das Gefühl, nix verpasst zu haben.
Muss man nicht verstehen...

[betateilchen]

Angenommen Du bastelst Dir was mit MQTT. Würdest Du von vornherein darauf achten, doppelte Schlüssel in unterschiedlichen Ebenen einer Topic-Hierarchie zu vermeiden?

Nein, weil mehrfach vorkommende Schlüssel auf verschiedenen Ebenen völlig normal und durch ihre verschiedenen Ebenen auch eindeutig sind.
Solche Sachen habe ich schon dutzendfach in ESP-Projekten umgesetzt und hatte damit noch nie ein Problem in der Auswertung.

[betateilchen]

Ich würde nie auf die Idee kommen, einen einzigen Datenpunkt auf einem separaten topic in JSON zu verpacken.

Oh doch, das macht softwareseitig durchaus Sinn, wenn man über Standardisierung und Zukunftssicherheit (aka Erweiterbarkeit) nachdenkt.
Man könnte z.B. auf die Idee kommen, Werte wie "lastseen" irgendwann mit in das Topic "availability" zu verpacken.

Und ob man den "state" nennt oder anders, ist vermutlich eine Frage, die nur in FHEM Relevanz hat, weil state da ohnehin schon eine Sonderrolle einnimmt.

[Beta-User]

Ich würde nie auf die Idee kommen, einen einzigen Datenpunkt auf einem separaten topic in JSON zu verpacken.

Oh doch, das macht softwareseitig durchaus Sinn, wenn man über Standardisierung und Zukunftssicherheit (aka Erweiterbarkeit) nachdenkt.
Man könnte z.B. auf die Idee kommen, Werte wie "lastseen" irgendwann mit in das Topic "availability" zu verpacken.

Und ob man den "state" nennt oder anders, ist vermutlich eine Frage, die nur in FHEM Relevanz hat, weil state da ohnehin schon eine Sonderrolle einnimmt.

Schon klar; deswegen würde/werde ich auch die (nicht so effiziente) substitution-Lösung einsetzen, statt nur den derzeitigen einzigen Datenpunkt rauszupicken.
Aber warum man den separaten Topic belassen hat? Klar, die Logik dahinter ist eine andere wie die Auswertung von Daten, die direkt vom jeweiligen Gerät gesendet würden. Na ja, letztlich egal.

[TomLee]

Nein, weil mehrfach vorkommende Schlüssel auf verschiedenen Ebenen völlig normal und durch ihre verschiedenen Ebenen auch eindeutig sind.

Danke

Aber warum man den separaten Topic belassen hat?

Weil er deaktivierbar ist/sein soll? Kann ich mir vorstellen.

[betateilchen]

Aber warum man den separaten Topic belassen hat?

Spontan fallen mir mindestens drei Gründe dafür ein, die eine solche Trennung rechtfertigen:

• Die availability ist generell kein "Verhaltens"-Wert eines device, wie z.B. eine Helligkeit oder ein Zustand ein/aus.
• Der availability-Check mit seinen pings stellt je nach Größe der Installation eine massive Belastung für zigbee dar, deshalb kann man das auch komplett abschalten bzw. nur für bestimmte devices aktivieren.
• Nicht jeder zigbee2mqtt Anwender verwendet auch FHEM.

[betateilchen]

Heute bin ich von master auf dev gewechselt, weil ich zwei neue Sensoren bekommen habe, die im master noch nicht bekannt sind, aber in dev schon implementiert wurden.

Interessanterweise funktioniert in dev mein zigbee2mqtt problemlos ohne Angabe des serial: parts in der configuration.yaml wieder.

Wichtiger Tipp: man sollte die gesamte Konfiguration in ./data unbedingt in einen regelmäßigen backup task einbauen. Dummerweise ist beim hin- und herschalten die Datei irgendwo verloren gegangen und ich habe gerade zwei Stunden damit zugebracht, meine zigbee devices neu anzulernen. Insbesondere bei den verbauten Unterputzaktoren macht das sehr wenig Spaß. Als zweitschlimmste devices haben sich die zigbee-Leuchtmittel herausgestellt, die sich sehr zickig bezüglich eines resets verhielten.

Aber inzwischen läuft alles wieder und meine Konfiguration wird nun einmal pro Tag per cronjob in einen S3-Speicher gesichert.

Code Auswählen Erweitern

#!/bin/sh

cd ~/z2mbackup
find ./*.tar.gz -type f -mtime +30 -delete
backname=`date "+backup_zigbee2mqtt_%Y%m%d-%H%M.tar.gz"`
tar -czvf $backname /opt/zigbee2mqtt/data/
aws s3 sync . s3://<bucketName>/zigbee2mqtt --delete


[fhem_olsi]

Aber inzwischen läuft alles wieder und meine Konfiguration wird nun einmal pro Tag per cronjob in einen S3-Speicher gesichert.

Warum einmal am Tag? Ändert sich Deine Konfiguration täglich?

[Beta-User]

Aber inzwischen läuft alles wieder und meine Konfiguration wird nun einmal pro Tag per cronjob in einen S3-Speicher gesichert.

Warum einmal am Tag? Ändert sich Deine Konfiguration täglich?

Dir ist schon klar, dass es bei "Konfiguration" nicht nur um die "cfg" geht, oder?
Viele andere Teile werden woanders gespeichert, und falls man nicht mit einem Filesysstem arbeitet, hat man eben mit der Sicherung der configDB alle diese Teile komplett und synchron beieinander...

[betateilchen]

Dir ist schon klar, dass es bei "Konfiguration" nicht nur um die "cfg" geht, oder?
Viele andere Teile werden woanders gespeichert, und falls man nicht mit einem Filesysstem arbeitet, hat man eben mit der Sicherung der configDB alle diese Teile komplett und synchron beieinander...

Dir ist schon klar, dass es hier um meine Konfiguration von zigbee2mqtt geht und nicht um FHEM?
Und mit z2m hat configDB mal gar nix zu tun.

[fhem_olsi]

Also, ich möchte vorausschicken, dass ich die Frage nur aus reinem Interesse gestellt hatte; ich wollte niemanden provozieren. Und ich bin auch davon ausgegangen, dass es sich bei der Diskussion der letzten Tage ausschließlich um z2m dreht.

Aber inzwischen läuft alles wieder und meine Konfiguration wird nun einmal pro Tag per cronjob in einen S3-Speicher gesichert.

Darum wiederhole ich meine Frage, die offenkundig noch nicht beantwortet wurde:

Warum einmal am Tag? Ändert sich Deine Konfiguration täglich?

Aus meiner Sicht - ich benutze noch die Version 1.42.0 - sollte das Sichern folgender Dateien ausreichen, wenn man von den Log-Dateien absieht:

Code Auswählen Erweitern

state.json
database.db
configuration.yaml
Hat sich diesbezüglich für Version 2 etwas geändert?

[betateilchen]

Darum wiederhole ich meine Frage, die offenkundig noch nicht beantwortet wurde:

Warum einmal am Tag? Ändert sich Deine Konfiguration täglich?

• weil ich dann nicht daran denken muss, wann ich sichern müsste
• weil es einfacher ist, ein ganzes Verzeichnis zu sichern als einzelne Dateien
• weil sich das Volumen der zu sichernden Daten in Grenzen hält (weniger als 1 MB)
• weil ich die Konfiguration sämtlicher Systeme, die in den Backup-Prozess eingebunden sind, täglich sichere. Im Sinne der Einheitlichkeit.

[fhem_olsi]

Darum wiederhole ich meine Frage, die offenkundig noch nicht beantwortet wurde:

Warum einmal am Tag? Ändert sich Deine Konfiguration täglich?

• weil ich dann nicht daran denken muss, wann ich sichern müsste
• weil es einfacher ist, ein ganzes Verzeichnis zu sichern als einzelne Dateien
• weil sich das Volumen der zu sichernden Daten in Grenzen hält (weniger als 1 MB)
• weil ich die Konfiguration sämtlicher Systeme, die in den Backup-Prozess eingebunden sind, täglich sichere. Im Sinne der Einheitlichkeit.

Geht doch; danke! Also nein - keine Besonderheiten, nur Routine...

Und, da Du ja schon Version 2 benutzt und vielleicht Erfahrung damit hast: Hat sich bezüglich

Aus meiner Sicht - ich benutze noch die Version 1.42.0 - sollte das Sichern folgender Dateien ausreichen, wenn man von den Log-Dateien absieht:

state.json
database.db
configuration.yaml

etwas geändert?

[passibe]

etwas geändert?

Soweit ich sehe, nicht. So sieht es jedenfalls bei mir nach Update auf v2 aus:

Code Auswählen Erweitern

-rw-r--r--  1 root root 2.8K Jan 12 19:33 configuration_backup_v1.yaml
-rw-r--r--  1 root root 2.5K Jan 12 19:33 configuration_backup_v2.yaml
-rw-r--r--  1 root root 2.6K Jan 12 19:33 configuration_backup_v3.yaml
-rw-r--r--  1 root root 2.6K Jan 20 12:00 configuration.yaml
-rw-r--r--  1 root root  53K Jan 20 13:22 database.db
drwxr-xr-x 12 root root  12K Jan 16 18:22 log
-rw-r--r--  1 root root  213 Jan 12 19:33 migration-1-to-2.log
-rw-r--r--  1 root root  303 Jan 12 19:33 migration-2-to-3.log
-rw-r--r--  1 root root  120 Jan 12 19:33 migration-3-to-4.log
-rw-------  1 root root  148 Feb  9  2024 secret.yaml
-rw-r--r--  1 root root  13K Jan 20 14:07 state.jsonWenn du eine secret.yaml verwendest, dann die ggfs. noch mit aufnehmen.

Ansonsten re Backup-Häufigkeit:
Ich sichere auch 1x täglich. Normalerweise verwendet man ja auch deduplicated Backups (z.B. über Duplicacy), sodass Dateien nur dann zusätzlichen Speicherplatz im Backup verbrauchen, wenn sie sich ändern, und nicht bei jedem Backup-Vorgang. Dann gibt es eine retention policy, wo man festlegt wie lange die Versionen aufbewahrt werden, sodass nach und nach auch wieder Speicherplatz freigegeben wird.

[betateilchen]

Dann gibt es eine retention policy, wo man festlegt wie lange die Versionen aufbewahrt werden, sodass nach und nach auch wieder Speicherplatz freigegeben wird.

Das gibt es ja in meinem Skript oben auch, es werden immer nur die letzten 30 Backups aufbewahrt.

[passibe]

Ah ja, sehr gut. Hatte das gar nicht gesehen, sorry. Das, was ich geschrieben habe, war auch einfach allgemein auf Backups bezogen.

[kennymc.c]

Hat schon jemand eine Bridge über die 2.0 API im Betrieb? Wenn ich das richtig verstanden habe ist die Bridge nur notwendig, wenn man nicht das eigene Frontend von zb2mqtt nutzen möchte und autocreate funktionieren soll, oder? Für autocreate müsste aber ein Device nur mit dem gleichen 1.x bridgeRegexp Attribut reichen? Die Änderungen durch den Wegfall der Legacy API beziehen sich ansonsten ja nur auf die Steuerung, die auch durch das Frontend passieren kann?

[passibe]

Zu autocreate kann ich nichts sagen, weil ich das nicht nutze.
Ich weiß also nicht wie das von der Umstellung auf 2.0 betroffen ist oder ob man dazu überhaupt die Bridge braucht (ich dachte MQTT2_SERVER macht das von selbst?).

Die restliche Steuerung kann tatsächlich rein über das Frontend passieren, da braucht man eigentlich kein Device in FHEM.

Ich habe aber einen Zigbee-Zwischenstecker, den ich einmal am Tag löschen und dann neu anlernen muss (sonst wird der unavailable), deshalb brauche ich zumindest permit_join und remove/rename am Bridge-Device – das hatte ich mal für v2 angepasst (setList):

Code Auswählen Erweitern

permit_join:true,false {my $payload = qq({"value": $EVTPART1, "time": 120}); if ($EVTPART1 eq "false") {$payload = qq("value": false)}; return qq {$DEVICETOPIC/bridge/request/permit_join $payload};; }
device_remove $DEVICETOPIC/bridge/request/device/remove {"id": "$EVTPART1"}
device_rename $DEVICETOPIC/bridge/request/device/rename {"from": "$EVTPART1", "to": "$EVTPART2"}
Und das hier als readingList (gibt für alles bis auf den state stumpf json zurück, aber reicht mir, wird sowieso nicht ausgewertet):

Code Auswählen Erweitern

$DEVICETOPIC/bridge/state:.* { state=>(json2nameValue($EVENT))->{state} }
$DEVICETOPIC/bridge/response/permit_join:.* permit_join
$DEVICETOPIC/bridge/response/device/rename:.* device_rename
$DEVICETOPIC/bridge/response/device/remove:.* device_remove