Änderungen durch zigbee2mqtt Vers.2

Begonnen von rob, 05 Januar 2025, 13:26:28

Vorheriges Thema - Nächstes Thema

betateilchen

Zitat von: passibe am 20 Januar 2025, 14:12:22Dann 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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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):
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):
$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