Änderungen durch zigbee2mqtt Vers.2

[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