NEWS
Tester für Zigbee Adapter 2.0.x gesucht
-
22
-
@homoran sagte in Tester für Zigbee Adapter 2.0.x gesucht:
Also sind da nicht wirklich Probleme, die zu den Meldungen führen?
Jein. Du hast da einen ganzen Rattenschwanz an TS011F Geräten, die auf die routing und LQI Anfrage einfach nicht reagieren. Das ist eigentlich nicht ok. Wenn die Geräte funktionieren hast du da erst einmal kein Problem, nur gilt dann, das alles was die Karte zu diesen Geräten zeigt mit grosser Vorsicht zu geniessen ist.
A.
@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:
die auf die routing und LQI Anfrage einfach nicht reagieren
und genau das könnte dann mein Problem mit dem Routing sein
@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:
Wenn die Geräte funktioniere
Frei nach Radio Eriwan: Im Prinzip ja, nur versuchen diese sich anscheinend immer direkt mit dem Controller zu verbinden, anstelle über stärkere Router, was auch schon mal zu LQI 24 -> 11 -> 3 -> tot führt
-
@david-g das ist die Erklärung. Ich hatte 12 in meinem Test-Aufbau, da war auch alles Stabil. Mit 80 im Live System lief es nicht.
A.
Hi,
habe deine Testversion hier auf meinen beiden Instanzen laufen, der Fehler scheint weg zu sein, bei der kleinen mit 20 devices war er nach 2 Minuten fertig mit konfigurieren, bei der grossen mit 220 Devices hat er gute 10min gebraucht, bis er alles durch hatte.. waren etliche wiederholungen drin..
Wenn du magst, kann ich das Log mal zusammen schneiden .. hier gings nicht hochzuladen, war zu gross.. -
Hi,
habe deine Testversion hier auf meinen beiden Instanzen laufen, der Fehler scheint weg zu sein, bei der kleinen mit 20 devices war er nach 2 Minuten fertig mit konfigurieren, bei der grossen mit 220 Devices hat er gute 10min gebraucht, bis er alles durch hatte.. waren etliche wiederholungen drin..
Wenn du magst, kann ich das Log mal zusammen schneiden .. hier gings nicht hochzuladen, war zu gross..@neuschwansteini sagte in Tester für Zigbee Adapter 2.0.x gesucht:
Wenn du magst, kann ich das Log mal zusammen schneiden .. hier gings nicht hochzuladen, war zu gross..
Wär mal interessant. Insbesondere wenn du eine Statistik machen könntest:
- Anzahl Geräte in Instanz
- Anzahl Geräte die eine Konfiguration versucht haben
- Anzahl Geräte bei denen dabei ein 'Timeout' aufgetreten ist, so das sie neu versucht haben
- Anzahl Geräte die sich nicht konfigurieren liessen, es aber auch nicht wieder versucht haben
- Anzahl der Versuche nach Timeout bis zum Abbruch / Erfolg.
Insbesondere die Anzahl die abgebrochen wurden ohne 2. Versuch sind interessant - diese sollten bei Neustart wieder auftauchen, während die einmal erfolgreich konfigurierten eigentlich nicht neu konfiguriert werden. Wobei es auch da Abweichungen gibt - Es gibt eine Hand voll Gerätetypen bei denen eine Konfiguration bei jedem Start gefordert wird.
@neuschwansteini sagte in Tester für Zigbee Adapter 2.0.x gesucht:
bei der kleinen mit 20 devices war er nach 2 Minuten fertig mit konfigurieren, bei der grossen mit 220 Devices hat er gute 10min gebraucht, bis er alles durch hatte.. waren etliche wiederholungen drin..
Das macht Sinn - ich hab die Konfiguration auf max 1 alle 5 Sekunden begrenzt. Da braucht er bei 220 Geräten alleine fast 9 Minuten wenn er wirklich alle durchgehen muss - wenn das alle sofort zulassen.
ggf. kann man das nochmal auf 1 Versuch pro Sekunde erhöhen.
A.
-
@Neuschwansteini @Shadowhunter23
So, jetzt gibt es besagte Testversion. Bitte von hier installieren:
https://github.com/asgothian/ioBroker.zigbee/tarball/1.11
was ich geändert hab:
- Anpassungen am Configure - da war ggf. ein Bug drin der so viele Configure versuche am Anfang ausgelöst hat
- Anpassungen an den Debug Messages -
aktuell werden keine Warn-Meldungen im Log ausgegeben. Die Meldungen landen nur im Debug InterfaceIst weg. Man kann das jetzt im dem Debug Interface umschalten (mit Debug messages im Log:
ohne Debug messages im Log. 
Standard ist 'mit' - Ich bin zurück auf die ZHC 21.38.0. Erst dieser Versuch hat wirklich was gebracht. Der identische Adapter-Code lief mit ZHC23.1.1 nicht sauber.
wenn das bei euch stabil ist fixe ich heute Abend noch die Debug-Messages, und dann bitte ich @arteck um eine 2.0.4 :)
A.
@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:
@Neuschwansteini @Shadowhunter23
So, jetzt gibt es besagte Testversion. Bitte von hier installieren:
https://github.com/asgothian/ioBroker.zigbee/tarball/1.11
was ich geändert hab:
- Anpassungen am Configure - da war ggf. ein Bug drin der so viele Configure versuche am Anfang ausgelöst hat
- Anpassungen an den Debug Messages -
aktuell werden keine Warn-Meldungen im Log ausgegeben. Die Meldungen landen nur im Debug InterfaceIst weg. Man kann das jetzt im dem Debug Interface umschalten (mit Debug messages im Log: ohne Debug messages im Log.
Standard ist 'mit' - Ich bin zurück auf die ZHC 21.38.0. Erst dieser Versuch hat wirklich was gebracht. Der identische Adapter-Code lief mit ZHC23.1.1 nicht sauber.
wenn das bei euch stabil ist fixe ich heute Abend noch die Debug-Messages, und dann bitte ich @arteck um eine 2.0.4 :)
A.
Was ich gemerkt habe bei Version 2.0.3 die Ordnerstruktur von ZHC 23.x.x hat sich geändert.
Ich musste meine externe Converter anpassen.
Da ist ein Ordner dazwischen gekommen /dist/.
Vielleicht hängt es da dran....Die zwei unabhängige Instanzen mit 2.0.3. haben bei mir auch alle paar Stunden Aussetzer gehabt. Eine hat 14, andere 59 Geräte.
ioBroker- NUC8i3 / Proxmox / VM
Node.js v22.21.0
NPM v10.9.4
JS controller 7.0.7
Admin 7.7.19
ZigBee Adapter 3.2.5
Zigbee LAN Gateway CC2652P
Zigbee Firmware 20250321 -
@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:
@Neuschwansteini @Shadowhunter23
So, jetzt gibt es besagte Testversion. Bitte von hier installieren:
https://github.com/asgothian/ioBroker.zigbee/tarball/1.11
was ich geändert hab:
- Anpassungen am Configure - da war ggf. ein Bug drin der so viele Configure versuche am Anfang ausgelöst hat
- Anpassungen an den Debug Messages -
aktuell werden keine Warn-Meldungen im Log ausgegeben. Die Meldungen landen nur im Debug InterfaceIst weg. Man kann das jetzt im dem Debug Interface umschalten (mit Debug messages im Log: ohne Debug messages im Log.
Standard ist 'mit' - Ich bin zurück auf die ZHC 21.38.0. Erst dieser Versuch hat wirklich was gebracht. Der identische Adapter-Code lief mit ZHC23.1.1 nicht sauber.
wenn das bei euch stabil ist fixe ich heute Abend noch die Debug-Messages, und dann bitte ich @arteck um eine 2.0.4 :)
A.
Was ich gemerkt habe bei Version 2.0.3 die Ordnerstruktur von ZHC 23.x.x hat sich geändert.
Ich musste meine externe Converter anpassen.
Da ist ein Ordner dazwischen gekommen /dist/.
Vielleicht hängt es da dran....Die zwei unabhängige Instanzen mit 2.0.3. haben bei mir auch alle paar Stunden Aussetzer gehabt. Eine hat 14, andere 59 Geräte.
@dimaiv sagte in Tester für Zigbee Adapter 2.0.x gesucht:
Was ich gemerkt habe bei Version 2.0.3 die Ordnerstruktur von ZHC 23.x.x hat sich geändert.
Ich musste meine externe Converter anpassen.Das hatte ich eigentlich umgestellt. Die externen Konverter werden sauber geladen - zumindest die die ich zum Testen habe. Umstellen in den Konvertern selber musste ich nichts.
Hast du mal die Version von git probiert, ob dann auch bei Dir die Probleme weg sind ?
A.
-
@dimaiv sagte in Tester für Zigbee Adapter 2.0.x gesucht:
Was ich gemerkt habe bei Version 2.0.3 die Ordnerstruktur von ZHC 23.x.x hat sich geändert.
Ich musste meine externe Converter anpassen.Das hatte ich eigentlich umgestellt. Die externen Konverter werden sauber geladen - zumindest die die ich zum Testen habe. Umstellen in den Konvertern selber musste ich nichts.
Hast du mal die Version von git probiert, ob dann auch bei Dir die Probleme weg sind ?
A.
@asgothian
Die läuft seit paar Minuten. Hier musste ich die Converter wieder zurück anpassen.ioBroker- NUC8i3 / Proxmox / VM
Node.js v22.21.0
NPM v10.9.4
JS controller 7.0.7
Admin 7.7.19
ZigBee Adapter 3.2.5
Zigbee LAN Gateway CC2652P
Zigbee Firmware 20250321 -
@asgothian
Die läuft seit paar Minuten. Hier musste ich die Converter wieder zurück anpassen. -
@asgothian
Update von 2.0.2 auf 2.0.3 und dann kamm folgender Meldung:2025-03-08 11:35:42.109 - info: zigbee.0 (59376) starting. Version 2.0.3 in /opt/iobroker/node_modules/iobroker.zigbee, node: v20.18.3, js-controller: 7.0.6 2025-03-08 11:35:42.150 - warn: zigbee.0 (59376) trying to add "fz = require(../zigbee-herdsman-converters/converters/fromZigbee)" to sandbox 2025-03-08 11:35:42.152 - error: zigbee.0 (59376) Sandbox error: Cannot find module '../zigbee-herdsman-converters/converters/fromZigbee' Require stack: - /opt/iobroker/node_modules/iobroker.zigbee/main.js 2025-03-08 11:35:42.153 - warn: zigbee.0 (59376) trying to add "tz = require(../zigbee-herdsman-converters/converters/toZigbee)" to sandbox 2025-03-08 11:35:42.154 - error: zigbee.0 (59376) Sandbox error: Cannot find module '../zigbee-herdsman-converters/converters/toZigbee' Require stack: - /opt/iobroker/node_modules/iobroker.zigbee/main.js 2025-03-08 11:35:42.155 - warn: zigbee.0 (59376) trying to add "exposes = require(../zigbee-herdsman-converters/lib/exposes)" to sandbox 2025-03-08 11:35:42.155 - error: zigbee.0 (59376) Sandbox error: Cannot find module '../zigbee-herdsman-converters/lib/exposes' Require stack: - /opt/iobroker/node_modules/iobroker.zigbee/main.js 2025-03-08 11:35:42.156 - warn: zigbee.0 (59376) trying to add "reporting = require(../zigbee-herdsman-converters/lib/reporting)" to sandbox 2025-03-08 11:35:42.157 - error: zigbee.0 (59376) Sandbox error: Cannot find module '../zigbee-herdsman-converters/lib/reporting' Require stack: - /opt/iobroker/node_modules/iobroker.zigbee/main.js 2025-03-08 11:35:42.162 - warn: zigbee.0 (59376) Trying to run sandbox for /opt/iobroker/iobroker-data/zigbee_0/Flower_Neu.js 2025-03-08 11:35:42.179 - error: zigbee.0 (59376) Unable to apply converter from module: /opt/iobroker/iobroker-data/zigbee_0/Flower_Neu.js - the code does not run: ReferenceError: exposes is not definedConverter sieht so aus am Anfang:
const fz = require('zigbee-herdsman-converters/converters/fromZigbee'); const tz = require('zigbee-herdsman-converters/converters/toZigbee'); const exposes = require('zigbee-herdsman-converters/lib/exposes'); const reporting = require('zigbee-herdsman-converters/lib/reporting'); const e = exposes.presets; const ea = exposes.access;und ich musste es ändern auf:
const fz = require('zigbee-herdsman-converters/dist/converters/fromZigbee'); const tz = require('zigbee-herdsman-converters/dist/converters/toZigbee'); const exposes = require('zigbee-herdsman-converters/dist/lib/exposes'); const reporting = require('zigbee-herdsman-converters/dist/lib/reporting'); const e = exposes.presets; const ea = exposes.access; -
@Neuschwansteini @Shadowhunter23
So, jetzt gibt es besagte Testversion. Bitte von hier installieren:
https://github.com/asgothian/ioBroker.zigbee/tarball/1.11
was ich geändert hab:
- Anpassungen am Configure - da war ggf. ein Bug drin der so viele Configure versuche am Anfang ausgelöst hat
- Anpassungen an den Debug Messages -
aktuell werden keine Warn-Meldungen im Log ausgegeben. Die Meldungen landen nur im Debug InterfaceIst weg. Man kann das jetzt im dem Debug Interface umschalten (mit Debug messages im Log: ohne Debug messages im Log.
Standard ist 'mit' - Ich bin zurück auf die ZHC 21.38.0. Erst dieser Versuch hat wirklich was gebracht. Der identische Adapter-Code lief mit ZHC23.1.1 nicht sauber.
wenn das bei euch stabil ist fixe ich heute Abend noch die Debug-Messages, und dann bitte ich @arteck um eine 2.0.4 :)
A.
@asgothian
Gerade installiert. -
@homoran sagte in Tester für Zigbee Adapter 2.0.x gesucht:
Also sind da nicht wirklich Probleme, die zu den Meldungen führen?
Jein. Du hast da einen ganzen Rattenschwanz an TS011F Geräten, die auf die routing und LQI Anfrage einfach nicht reagieren. Das ist eigentlich nicht ok. Wenn die Geräte funktionieren hast du da erst einmal kein Problem, nur gilt dann, das alles was die Karte zu diesen Geräten zeigt mit grosser Vorsicht zu geniessen ist.
A.
@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:
Das ist eigentlich nicht ok
Hab da gerade noch etwas entdeckt!
Vorab:
die angemeckerten Geräte sind meine gesamten Lidl-Messteckdosen.
Wegen des anscheinend falschen Routings hatte ich bereits angefangen einzelne gegen IKEA Inspelning zu tauschen.
Von denen macht keine einzige Probleme.
Aber die Lidl befinden sich (noch) im Netz.Hab jetzt eine Lidl aus dem System gelöscht, auf Werkseinstellungen zurückgesetzt, und wieder angelernt.
keine Änderung!Habe dann gesehen, dass "configured" auf false steht.
Das war bereits mit der 1.x so.
und ist es auch jetzt bei allen Geräten.Mit dem branch der 2.0.3 von @arteck stand configured auf true!
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
Aktuelle Test Version 2.0.1 Veröffentlichungsdatum 25.02.2025 Github Link https://github.com/ioBroker/ioBroker.zigbee Repository latest. Die Version 2.0.x des Zigbee Adapters ist inzwischen im Latest veröffentlicht. Sie bringt eine grosse Zahl von Neuerungen in den Zigbee-Adapter.
1.10.x -> 2.0.1
Die Entscheidende Neuerung ist der Wechsel auf den Zigbee-Herdsman 3.5 und die Zigbee-Herdsman-Converter 21.x, sowie der Wechsel weg von den im Adapter definierten Gerätebeschreibungen. Daraus resultiert das sich für eine Vielzahl von Geräten die Datenpunkte ändern. Betroffen sind ca. 200 Gerätetypen - wobei es durchaus sein kann das einzelne Nutzer wenig bis gar nicht betroffen sind. Eine Liste von Geräten findet sich in dieser Diskussion auf Github. Es ist nicht auszuschliessen das auch Gerätetypen betroffen sind die sich nicht auf dieser Liste befinden.Trennung von Adapter-Konfiguration und Adapter GUI:
ab 2.0.1 ist die Benutzeroberfläche des Adapters in 2 explizit getrennte Teile gespalten. Die Adapter-Konfiguration, die von der 'Instanzen' Seite aufgerufen wird und das GUI, welches über den Button in der Seitenleiste aufgerufen wird. Die Trennung ist wie folgt gedacht:- GUI: Funktionen zur Bedienung des Adapters. Alles was hier ausgelöst werden kann wird ohne Neustart des Adapters aktiv. (Tabs Geräte, Netzwerkkarte, Binding, Debug (ab 2.0.3))
- Konfiguration: Funktionen zur Konfiguration des Instanz-Verhaltens. Wenn hier Änderungen vorgenommen werden kann ein Adapter-Neustart erforderlich werden. Aus Bequemlichkeit ist die Geräte-Ansicht in GUY und Konfiguration identisch und hat auch die gleiche Funktionalität. (Tabs Einstellungen, Geräte, Legacy Overrides, Entwickler)
Der Adapter zeigt dabei sowohl im Adapter-UI als auch im Objektbaum an das entsprechend verwaiste Datenpunkte existieren. Im Adapter UI zeigt die Schaltfläche zum State Cleanup an das sich im Objektbaum verwaiste Datenpunkte befinden. Nachdem diese alle gelöscht wurden wird die Schaltfläche nach einem Neustart des Adapters entfernt.
Im Objektbaum werden die verwaisten Datenpunkte in Orange eingefärbt, so das offensichtlich ist, welche Datenpunkte in Skripten, Aliasen und Visualisierungen angepasst werden müssen.
des Weiteren unterdrückt der Adapter widerkehrende Meldungen über die Verletzung der Wertebereichsgrenzen bei numerischen Datenpunkten. Die entsprechenden Meldungen werden pro Neustart 1x pro Datenpunkt als Fehler ausgegeben, und in der Folge unterdrückt. Im UI des Adapters zeigt eine Schaltfläche an das es unterdrückte Meldungen gibt. Ein Click auf diese Schaltfläche zeigt diese Meldungen im UI an.
Die Netzwerkkarte wird ab 2.0.1 nicht mehr automatisch beim Start sondern erst auf Anforderung durch den Nutzer generiert. Dabei wird nach Erzeugung der Karte eine Auflistung der dabei entstandenen Meldungen gezeigt. Dieses lässt sich über die Konfiguration der Netzwerkkarte selber unterbinden.
Die Konfiguration kann über den orangenen Button oben links geöffnet werden, das Erstellen der Karte erfolgt nach Betätigen des blauen Button unten rechts.
Die Erzeugung der Netzwerkkarte wurde dabei parallelisiert so das insbesondere bei grossen Netzen die Karte schneller aufgebaut werden kann. Dieses erzeugt allerdings eine signifikante Last im Zigbee-Netzwerk weswegen diese nicht direkt nach dem Start des Adapters automatisch generiert wird.Die Verwaltung der Bilder für die Geräte wurde aktualisiert. Insbesondere nach einer Neuinstallation kann es dazu kommen das die Bilder der Geräte noch nicht herunter geladen sind. Diese werden beim ersten Start nach der Installation herunter geladen und im Admin hinterlegt, so das ggf. in den ersten 120 sekunden nach dem ersten Start nach einer Neuinstallation des Adapters nicht alle Bilder verfügbar sind. Dieses kann aber alleine durch Neu-Laden der Adapterseite behoben werden, sofern für das Gerät ein Bild verfügbar ist.
Auch die Erhaltung von Gerätenamen wurde umgestellt - die Datei
dev_names.jsonwird nicht weiter verwendet. Einzig beim ersten Start der 2.0.1er Version wird diese Datei geladen um bereits gemachte Einstellungen zu erhalten. Die Geräte und Modellspezifischen Einstellungen werden in der DateiLocalOverrides.jsonabgelegt und sind damit automatisch im Backup der Adapterdaten enthalten. In diesem Zusammenhang wurde auch der Kanalzigbee.x.exposesaufgegeben. Dieser ist weiterhin vorhanden, hat aber keine Funktion mehr.Zusätzlich ist es inzwischen möglich eigene Bilder für Geräte, Gerätetypen oder Gruppen zu definieren. Diese müssen als PNG < 100 kb im Datenverzeichnis des Zigbee-Adapters (oder einem Unterverzeichnis davon) abgelegt werden damit sie über die Gerätekachel ausgewählt werden können.
Dazu zeigt die Gerätekachel auf der Rückseite weitere Schaltflächen. Auch die Farben / Zuordnungen der Schaltflächen wurde angepasst. In der Reihenfolge von Links nach Rechts haben die Schaltflächen die folgenden Bedeutungen:
Geräte Informationen (i), Debug An/Aus, Gerät Aktiv/Deaktiv, Rekonfiguration, Bild/Name Anpassen, Name/Gruppen anpassen, Gerät Löschen- Geräte Informationen (i) zeigt die alt bekannte Ansicht mit den Hardware-Details des Gerätes
- Debug An/Aus aktiviert / deaktiviert die Debug Meldungen im Log (äquivalent zur Nutzung des Datenpunktes
zigbee.x.info.debugmessages) - Gerät An/Aus aktiviert/deaktivert das Gerät. Deaktivierte Geräte werden mit rotem Hintergrund dargestellt. Ihre Datenpunkte werden weder überwacht noch vom Adapter aktualisiert. Deaktivierte Geräte werden in der Netzwerkkarte nicht dargestellt.
- Reconfiguration löst einen Versuch der Konfiguration des Gerätes aus (wie bisher). wichtig Eine Rekonfiguration kann nur erfolgreich sein wenn das Gerät erreichbar und wach ist. Ansonsten wird eine Fehlermeldung ausgegeben.
- Bild/Name anpassen: öffnet den folgenden Dialog:
Sofern keine weiteren Bilder bereitgestellt wurden bietet der Dialog 2 oder 3 Bilder zur Auswahl an:
-- current: das ist das aktuell eingestellte Bild. Wenn dieses Ausgewählt bleibt wird das Bild nicht verändert
-- default: das ist das Standard-Bild welches vom System vorgegeben wird.
-- legacy: Falls vorhanden, ist dies das alte vom Zigbee-Adapter verwendete Bild
Alle weiteren Bilder werden mit ihrem Dateinamen angegeben.
Der Dialog bietet über die Checkbox 'Apply to Model' die Option die Einstellungen für alle Geräte dieses Types zu übernehmen. Dabei gilt die die Prioritat wie folgt: Höchste Priorität haben die 'pro Gerät' Einstellungen, danach die 'pro Modell' Einstellungen. Nur wenn beide leer sind (Standard) werden die vorgaben genutzt. Um Sicher zu dem vom System vorgegebenen Bild zurück zu kehren muss daher einmal 'pro Modell' und 'pro Gerät' das Bild default ausgewählt werden. Beim Namen wird nur dann zur Vorgabe zurück gekehrt wenn das Feld Name leer ist.
Diese Einstellungen sind sowohl für Geräte als auch für Gruppen verfügbar - Name/Gruppen anpassen: Diese Schaltfläche öffnet den Dialog zum ändern von Name und/oder Gruppeneinstellungen. Dabei gibt es 3 Möglichkeiten:
-- Geräte mit gruppierbaren Endpunkten - Hier kann für jeden Endpunkt ausgewählt werden in welchen Gruppen dieser Mitglied sein soll
-- Geräte ohne gruppierbarkeit - es wird keine Einstellung zu den Gruppen vorgegeben
-- Gruppen - hier können Mitglieder durch Abwahl von Geräten / Endpunkten aus der Gruppe entfernt werden
Weiterhin hat es weitreichende Anpassungen im Adapter gegeben die sowohl der Stabilität als auch der Kompatibilität mit dem neuen Herdsman 3.x dienen. Auch die Kompatibilität mit externen Konvertern wurde verbessert. Dieses zu beschreiben sprengt den Rahmen dieses Posts.
Als letztes hat es signifikante Anpassungen bei der Ansteuerung von Farb-Leuchtmitteln gegeben:
- Immer vorhanden ist der Datenpunkt
color. Dieser nimmt auf:
-- #rrggbb
-- Benannte Farben aus dieser Liste (ggf. muss die css3 Namenstabelle geöffnet werden)
-- alle bei zigbee2mqtt.io für die entsprechenden Geräte vorgegebenen payloads. - Nur bei Bedarf vorhanden sind die Kanäle
-- color_xy mit den Datenpunktenxundy
-- color_hs mit den Datenpunktenhueundsaturation
-- color_rgb mit den Datenpunktenr,g,b
Diese Datenpunkte sind nicht direkt mit dem Gerät verbunden Vielmehr wird automatisch 500 ms nach einer Änderung basierend auf den Datenpunkten eines der Kanäle der Datenpunktcolormit dem entsprechenden Payload befüllt um das Gerät zu steuern. Bei Anpassung aus dem Admin wird statt 500 ms 5 sekunden gewartet bis dieses Stattfindet, damit genügend Zeit vorhanden ist um alle Datenpunkte eines Kanals anzupassen.
In diesem Zusammenhang ist es jetzt auch möglich die Farbe eines Leuchtmittels aus der Gerätekachel einzustellen - durch Wahl der geeigneten benannten Farbe.
-> 2.0.2
- Zusätzlicher Datenpunkt action bei Fernbedienungen / Wandschaltern : Ein zusätzlicher Datenpunkt der in einem Eventartigen Datenpunkt die Änderung von allen Schaltelementen abbildet. Dabei wird der Wert des Datenpunkt für 300 ms auf den Bezeichner eines Events gesetzt. nach 300 ms wird der Wert auf '' zurück gesetzt. Eine Liste der möglichen Bezeichner ist in den Objektdaten hinterlegt und kann da ausgelesen werden (Siehe Bild)
- Wiederkehrende Nachrichten über Werte-Überschreitungen bei numerischen States werden abgefangen und tauchen pro Adapter-Start nur 1x im Log auf. Über eine entsprechende Schaltfläche (nur sichtbar wenn Daten vorhanden sind) kann eine Liste dieser Meldungen angezeigt werden. Dieses funktioniert für die meisten derartiger Meldungen, aber ggf. noch nicht für alle - die Funktionalität wird aber in der Zukunft erweitert wenn sie als Hilfreich angesehen wird.
- press/hold/release handling. Sofern ein Gerät (Wandschalter, Fernbedienung, etc.) Nachrichtenpaare der Form
<prefix>press<postfixund<prefix>release<postfix>sendet, so werden diese zu einem State<prefix><postfix>zusammengefasst, der beipressmitwahrund beireleasemitfalseaktualisiert wird. Das gleiche gilt für hold/release Paare. - Bugfixes gegenüber 2.0.1
Bekannte Bugs: (Ja, gibt es leider )
Bestimmte Fernbedienungen (insbesondere Ikea) verweigern eine Konfiguration. Dieses ist auf eine Anpassung an den Zigbee-Herdsman-Converters zurück zu führen und wird in der Zwischenzeit untersucht und in der näheren Zukunft behoben seinIn 2.0.2 gefixed- Es har vereinzelt Effekte gegeben bei denen die Anzeige des Paring-Modes nicht sauber intiailisert. Das Netzwerk wird aber dennoch geöffnet so das ein Pairing möglich ist. Ein Reload im WebBrowser löst das üblicherweise
Es gibt ein Problem mit dem OTA Update. Ein Fix ist in Arbeitin 2.0.2 gefixedEs gibt Auffälligkeiten beim Zurücksetzen bestimmter event-States, z.Bsp. Ikea Fernbedienungen. Dieses wird untersucht.in 2.0.2 gefixed, siehe press/hold/releaseAnpassung der Fehlermeldung beim Device-Configure - die Fehlermeldung suggeriert das das System automatisch bis zu 10 mal versucht die Konfiguration durchzuführen. Das funktioniert aktuell so leider nicht(in 2.0.5 gefixed)- Der Device-Detektor erkennt farbige Leuchten / Leuchtmittel nicht mehr, da die 'Kanäle' im Device dieses verhindern (2.0.1. - 2.0.5)
Über Tests und Berichte würde ich mich freuen - auch über Anregungen / Kommentare zu den neuen Funktionalitäten.
Wichtg Die 'breaking changes' werden von Entwicklerseite nicht zurück gedreht. Es besteht die Möglichkeit das Personen die die entsprechenden Geräte haben die 'alten' Datenpunkte wieder aktivieren und deren Funktionalität auch mit dem aktuellen Herdsman gewährleisten. Wir werden dabei durchaus unterstützen - die Haupt-Arbeit muss aber von den Nutzern dieser Geräte geleistet werden: Wir geben Hinweise und Anhaltspunkte wo Anpassungen notwendig sind und wie man an die notwendigen Informationen heran kommt, die Anwender müssen sich um die Programmierung und den Test, bis hin zu einem PR auf den Adapter kümmern. Das können wir aktuell nicht leisten.
A.
Ich kann dich verstehen, aber dafuer muss ich mir das gesamte Logfile von heute durchforsten.. und mit Statistiken bin ich eh sowas von fern.. aber ich schau mal, was ich so herausfinde..
Zur Zeit warnt er noch damit:
Edit:
das muesste ein Tuya-Motion-Sensor sein 00124b002a524ccb wenn ich das richtig sehe im Log.. wundert mich nicht, der ist sowieso "speziell" was sein ganzes verhalten angeht.. hab irgendwo noch 10 von den Dingern, 2 sind noch im Einsatz, der rest liegt in der Kruschkiste.. :) -
@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:
Das ist eigentlich nicht ok
Hab da gerade noch etwas entdeckt!
Vorab:
die angemeckerten Geräte sind meine gesamten Lidl-Messteckdosen.
Wegen des anscheinend falschen Routings hatte ich bereits angefangen einzelne gegen IKEA Inspelning zu tauschen.
Von denen macht keine einzige Probleme.
Aber die Lidl befinden sich (noch) im Netz.Hab jetzt eine Lidl aus dem System gelöscht, auf Werkseinstellungen zurückgesetzt, und wieder angelernt.
keine Änderung!Habe dann gesehen, dass "configured" auf false steht.
Das war bereits mit der 1.x so.
und ist es auch jetzt bei allen Geräten.Mit dem branch der 2.0.3 von @arteck stand configured auf true!
-
Ich kann dich verstehen, aber dafuer muss ich mir das gesamte Logfile von heute durchforsten.. und mit Statistiken bin ich eh sowas von fern.. aber ich schau mal, was ich so herausfinde..
Zur Zeit warnt er noch damit:
Edit:
das muesste ein Tuya-Motion-Sensor sein 00124b002a524ccb wenn ich das richtig sehe im Log.. wundert mich nicht, der ist sowieso "speziell" was sein ganzes verhalten angeht.. hab irgendwo noch 10 von den Dingern, 2 sind noch im Einsatz, der rest liegt in der Kruschkiste.. :) -
@neuschwansteini das ist eine Meldung die ich zum Testen da rein gepackt hab. So oft sollte die aber nicht kommen - da ist noch was faul. Ich schau mal.
@asgothian
Habe heute Nachmittag noch mal deine Testversion installiert mit ZHC 23.4.0 , hat wieder nicht funktioniert. Nach 2 Stunden mit 14 Geräten keine Funktion mehr... CPU Last über 100%...ioBroker- NUC8i3 / Proxmox / VM
Node.js v22.21.0
NPM v10.9.4
JS controller 7.0.7
Admin 7.7.19
ZigBee Adapter 3.2.5
Zigbee LAN Gateway CC2652P
Zigbee Firmware 20250321 -
@asgothian
Habe heute Nachmittag noch mal deine Testversion installiert mit ZHC 23.4.0 , hat wieder nicht funktioniert. Nach 2 Stunden mit 14 Geräten keine Funktion mehr... CPU Last über 100%... -
@dimaiv Das ist seltsam - bei mir läuft sie stabil ohne Effekte. Du hast direkt von meinem Fork dem Branch 1.11 installiert ?
@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:
@dimaiv Das ist seltsam - bei mir läuft sie stabil ohne Effekte. Du hast direkt von meinem Fork dem Branch 1.11 installiert ?
Ja, direkt.
Jetzt läuft 2.0.4. überall über Nacht. Morgen werde ich deine Testversion noch mal wo anders testen.
ioBroker- NUC8i3 / Proxmox / VM
Node.js v22.21.0
NPM v10.9.4
JS controller 7.0.7
Admin 7.7.19
ZigBee Adapter 3.2.5
Zigbee LAN Gateway CC2652P
Zigbee Firmware 20250321 -
@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:
@dimaiv Das ist seltsam - bei mir läuft sie stabil ohne Effekte. Du hast direkt von meinem Fork dem Branch 1.11 installiert ?
Ja, direkt.
Jetzt läuft 2.0.4. überall über Nacht. Morgen werde ich deine Testversion noch mal wo anders testen.
@dimaiv Seltsam. Tu mir mal bitte einen gefallen:
Patch mal dasshouldConfigureso das es- ins Log schreibt wenn es aufgerufen wird
- immer direkt ein false zurück liefert, so das keine Konfiguration gestartet wird.
Und dann lass den Adapter nochmal laufen. Ich vermute das sich da irgend etwas aufschaukeln könnte. Ansonsten hab ich in diesem issue bei Koenkk nachgefragt, aber er steht auch auf dem Schlauch.
Ein anderer Test wäre folgender : Installier von diesem Branch: https://github.com/asgothian/ioBroker.zigbee/tarball/2.0.5ZHC21. Das ist der identische Code zum branch 1.11, nur mit der dependency auf ZHC21.38.0
A.
-
@dimaiv Seltsam. Tu mir mal bitte einen gefallen:
Patch mal dasshouldConfigureso das es- ins Log schreibt wenn es aufgerufen wird
- immer direkt ein false zurück liefert, so das keine Konfiguration gestartet wird.
Und dann lass den Adapter nochmal laufen. Ich vermute das sich da irgend etwas aufschaukeln könnte. Ansonsten hab ich in diesem issue bei Koenkk nachgefragt, aber er steht auch auf dem Schlauch.
Ein anderer Test wäre folgender : Installier von diesem Branch: https://github.com/asgothian/ioBroker.zigbee/tarball/2.0.5ZHC21. Das ist der identische Code zum branch 1.11, nur mit der dependency auf ZHC21.38.0
A.
Support us
397
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge