Änderungen durch zigbee2mqtt Vers.2

[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.