NEWS
Tester für Zigbee Adapter 2.0.x gesucht
-
@gaspode sagte in Tester für Zigbee Adapter 2.0.x gesucht:
Das Häkchen hatte mich in der Beschreibung irritiert, das las sich für mich so, wie ein Workaround, den man normalerweise nicht verwendet. Heute ist irgendwie nicht mein Tag.
Da kann ich was zu Scheiben:
Ab Adapter 2.0.0 gab es immer wieder Probleme bei einer Neuinstallatopn des Adapters. Beim ersten Start wo das zigbee subsystem aktiviert wird werden Backup Daten geschrieben. Wenn in der Folge die parametrierung geändert wird mussten diese teilweise von Hand entfernt werden - was immer wieder zu Problemen geführt hat,
Was dem Adapter gefehlt hat ist eine Mögkichkeit das vom UI aus zu steuern. Beim Aufbau dieser Möglichkeit fiel auf das es am besten ist wenn das zigbee Netzwerk nicht automatisch gestartet wird bis die Konfiguration erfolgreich abgeschlossen und getestet ist.
Bei späteren Starts soll danach das zigbee subsystem automatisch durchgestartet werden.
Das hätte durch einen anderen Workflow auch abgebildet würden können - aber das wäre gerade für Neulinge noch komplexer und unhandlicher gewesen. Deswegen die Entscheidung für den Haken, der bei ‚alten‘ Installationen einmal gesetzt werden muss.
A.
@asgothian
Will nicht ätzen oder kritisieren. Und da mittlerweile 3.x.x existiert ist es wahrscheinlich eh schon zu spät. Wenn was super toll funktioniert kommen dann halt immer noch die "Vergoldungswünsche". Bitte nicht bös nehmen - Adapter ist super toll!Hier nur eine Anregung für die Zukunft oder ähnliche Fälle:
Man kann bei der Adapterinstallation auch ein Script ausführen und dort erkennen ob schon eine (ältere) Installation vorliegt. Damit hätte man bei Upgrade von 1.x.x auf 2.x.x das Hakerl automatisch setzen können.Ist bei einem Hackerl kein großes Ding. Aber für andere Migrationen ev. von Interesse.
Und für den IST Stand ev. zum Andenken:
Ev. würde eine Warning im Log sinnvoll sein, so in der Art:
Warning: Subsystem not yet started. If you configuration has been completed, please check xxxx box at configuration UI to start subsystem automatically.
Zumindest User die ins Log schaun (und das sind sicher nicht alle :-) hätte da nen Hinweis.Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer Danke sagen will, kann nen Kaffee spendieren: https://paypal.me/mcm1957atiobroker
-
@asgothian
Will nicht ätzen oder kritisieren. Und da mittlerweile 3.x.x existiert ist es wahrscheinlich eh schon zu spät. Wenn was super toll funktioniert kommen dann halt immer noch die "Vergoldungswünsche". Bitte nicht bös nehmen - Adapter ist super toll!Hier nur eine Anregung für die Zukunft oder ähnliche Fälle:
Man kann bei der Adapterinstallation auch ein Script ausführen und dort erkennen ob schon eine (ältere) Installation vorliegt. Damit hätte man bei Upgrade von 1.x.x auf 2.x.x das Hakerl automatisch setzen können.Ist bei einem Hackerl kein großes Ding. Aber für andere Migrationen ev. von Interesse.
Und für den IST Stand ev. zum Andenken:
Ev. würde eine Warning im Log sinnvoll sein, so in der Art:
Warning: Subsystem not yet started. If you configuration has been completed, please check xxxx box at configuration UI to start subsystem automatically.
Zumindest User die ins Log schaun (und das sind sicher nicht alle :-) hätte da nen Hinweis.@mcm1957 said in Tester für Zigbee Adapter 2.0.x gesucht:
Damit hätte man bei Upgrade von 1.x.x auf 2.x.x das Hakerl automatisch setzen können.
Der Haken kommt ja erst mit Version 3. Ich hab ehrlich gesagt noch nicht ganz verstanden, wann es sinnvoll ist, den Haken zunächst nicht zu setzen. Wenn das wirklich immer nur eine Neuinstallation des Adapters beträfe, wäre das bestimmt eine gute Sache, dass die Upgrader nicht davon behelligt werden.
-
@asgothian
Will nicht ätzen oder kritisieren. Und da mittlerweile 3.x.x existiert ist es wahrscheinlich eh schon zu spät. Wenn was super toll funktioniert kommen dann halt immer noch die "Vergoldungswünsche". Bitte nicht bös nehmen - Adapter ist super toll!Hier nur eine Anregung für die Zukunft oder ähnliche Fälle:
Man kann bei der Adapterinstallation auch ein Script ausführen und dort erkennen ob schon eine (ältere) Installation vorliegt. Damit hätte man bei Upgrade von 1.x.x auf 2.x.x das Hakerl automatisch setzen können.Ist bei einem Hackerl kein großes Ding. Aber für andere Migrationen ev. von Interesse.
Und für den IST Stand ev. zum Andenken:
Ev. würde eine Warning im Log sinnvoll sein, so in der Art:
Warning: Subsystem not yet started. If you configuration has been completed, please check xxxx box at configuration UI to start subsystem automatically.
Zumindest User die ins Log schaun (und das sind sicher nicht alle :-) hätte da nen Hinweis.@mcm1957 sagte in Tester für Zigbee Adapter 2.0.x gesucht:
@asgothian
Will nicht ätzen oder kritisieren. Und da mittlerweile 3.x.x existiert ist es wahrscheinlich eh schon zu spät. Wenn was super toll funktioniert kommen dann halt immer noch die "Vergoldungswünsche". Bitte nicht bös nehmen[...snip]
Keine Sorge - ich nehm das als Anregung und Vorschlag zur Verbesserung. Und bin Dankbar dafür.
Und für den IST Stand ev. zum Andenken:
Ev. würde eine Warning im Log sinnvoll sein, so in der Art:
Warning: Subsystem not yet started. If you configuration has been completed, please check xxxx box at configuration UI to start subsystem automatically.
Zumindest User die ins Log schaun (und das sind sicher nicht alle :-) hätte da nen Hinweis.Aktuell gibt es (in aktuellen Github Version) die folgende Meldung wenn der Adapter gestartet wird ohne das der Haken da ist:
Zigbee autostart option not set - omitting start of zigbee substystem!@gaspode sagte in Tester für Zigbee Adapter 2.0.x gesucht:
@mcm1957 said in Tester für Zigbee Adapter 2.0.x gesucht:
Damit hätte man bei Upgrade von 1.x.x auf 2.x.x das Hakerl automatisch setzen können.
Der Haken kommt ja erst mit Version 3. Ich hab ehrlich gesagt noch nicht ganz verstanden, wann es sinnvoll ist, den Haken zunächst nicht zu setzen. Wenn das wirklich immer nur eine Neuinstallation des Adapters beträfe, wäre das bestimmt eine gute Sache, dass die Upgrader nicht davon behelligt werden.
Bestehende Installationen die vor dem Update gelaufen sind sollten den Haken immer setzen. Einfach betrachtet wäre ein Skript also eine interessante option, aber
- Leider gehen viele Nutzer wenig 'systematisch' vor wenn etwas nicht sofort geht - da wird dieses und jenes neu installiert / über installiert / krumm gedreht. Mal von NPM, mal von Github, mal eine ältere Version. Ich hab im Forum an vielen Stellen mehr Probleme damit die komischen Lösungsversuche von Nutzern gerade zu biegen als das eigentlich ursächliche Problem zu lösen.
Könnte ich das alles in einem Skript sauber abfangen - vielleicht.
Ist es das für diesen einfachen Fall wert - in meinen Augen nicht. Einmal in die Einstellungen zu gehen und den Haken zu setzen ist jetzt nicht wirklich zuviel verlangt.
- Dadurch das die Nutzer in die Konfiguration gehen werden sie gleich noch mit einer weiteren Eigenschaft der 3.x konfrontiert - einer Verifikation von Zigbee-Einstellungen und den vom Koordinator gesicherten Einstellungen. Passen die nicht übereinander wird das angezeigt. Zusätzlich bekommen alle die noch die unsäglichen 16D ExtPanID nutzen nochmal einen Hinweis darauf das das vielleicht nicht gut ist.
Über die Einstellungen lassen sich dann für die Nutzer halbwegs komfortabel auch Auffälligkeiten beheben, wie z.Bsp. die "Unart" einfach den Adapter mit dem Haken bei
laufen zu lassen.Dieses ist gewünscht - zumindest von mir :)
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@mcm1957 sagte in Tester für Zigbee Adapter 2.0.x gesucht:
@asgothian
Will nicht ätzen oder kritisieren. Und da mittlerweile 3.x.x existiert ist es wahrscheinlich eh schon zu spät. Wenn was super toll funktioniert kommen dann halt immer noch die "Vergoldungswünsche". Bitte nicht bös nehmen[...snip]
Keine Sorge - ich nehm das als Anregung und Vorschlag zur Verbesserung. Und bin Dankbar dafür.
Und für den IST Stand ev. zum Andenken:
Ev. würde eine Warning im Log sinnvoll sein, so in der Art:
Warning: Subsystem not yet started. If you configuration has been completed, please check xxxx box at configuration UI to start subsystem automatically.
Zumindest User die ins Log schaun (und das sind sicher nicht alle :-) hätte da nen Hinweis.Aktuell gibt es (in aktuellen Github Version) die folgende Meldung wenn der Adapter gestartet wird ohne das der Haken da ist:
Zigbee autostart option not set - omitting start of zigbee substystem!@gaspode sagte in Tester für Zigbee Adapter 2.0.x gesucht:
@mcm1957 said in Tester für Zigbee Adapter 2.0.x gesucht:
Damit hätte man bei Upgrade von 1.x.x auf 2.x.x das Hakerl automatisch setzen können.
Der Haken kommt ja erst mit Version 3. Ich hab ehrlich gesagt noch nicht ganz verstanden, wann es sinnvoll ist, den Haken zunächst nicht zu setzen. Wenn das wirklich immer nur eine Neuinstallation des Adapters beträfe, wäre das bestimmt eine gute Sache, dass die Upgrader nicht davon behelligt werden.
Bestehende Installationen die vor dem Update gelaufen sind sollten den Haken immer setzen. Einfach betrachtet wäre ein Skript also eine interessante option, aber
- Leider gehen viele Nutzer wenig 'systematisch' vor wenn etwas nicht sofort geht - da wird dieses und jenes neu installiert / über installiert / krumm gedreht. Mal von NPM, mal von Github, mal eine ältere Version. Ich hab im Forum an vielen Stellen mehr Probleme damit die komischen Lösungsversuche von Nutzern gerade zu biegen als das eigentlich ursächliche Problem zu lösen.
Könnte ich das alles in einem Skript sauber abfangen - vielleicht.
Ist es das für diesen einfachen Fall wert - in meinen Augen nicht. Einmal in die Einstellungen zu gehen und den Haken zu setzen ist jetzt nicht wirklich zuviel verlangt.
- Dadurch das die Nutzer in die Konfiguration gehen werden sie gleich noch mit einer weiteren Eigenschaft der 3.x konfrontiert - einer Verifikation von Zigbee-Einstellungen und den vom Koordinator gesicherten Einstellungen. Passen die nicht übereinander wird das angezeigt. Zusätzlich bekommen alle die noch die unsäglichen 16D ExtPanID nutzen nochmal einen Hinweis darauf das das vielleicht nicht gut ist.
Über die Einstellungen lassen sich dann für die Nutzer halbwegs komfortabel auch Auffälligkeiten beheben, wie z.Bsp. die "Unart" einfach den Adapter mit dem Haken bei
laufen zu lassen.Dieses ist gewünscht - zumindest von mir :)
A.
@asgothian said in Tester für Zigbee Adapter 2.0.x gesucht:
Ich hab im Forum an vielen Stellen mehr Probleme damit die komischen Lösungsversuche von Nutzern gerade zu biegen als das eigentlich ursächliche Problem zu lösen.
Guter Punkt. :D
@asgothian said in Tester für Zigbee Adapter 2.0.x gesucht:
Aktuell gibt es (in aktuellen Github Version) die folgende Meldung wenn der Adapter gestartet wird ohne das der Haken da ist:
Zigbee autostart option not set - omitting start of zigbee substystem!Finde ich persönlich auch absolut ausreichend. :+1:
-
@mcm1957 sagte in Tester für Zigbee Adapter 2.0.x gesucht:
@asgothian
Will nicht ätzen oder kritisieren. Und da mittlerweile 3.x.x existiert ist es wahrscheinlich eh schon zu spät. Wenn was super toll funktioniert kommen dann halt immer noch die "Vergoldungswünsche". Bitte nicht bös nehmen[...snip]
Keine Sorge - ich nehm das als Anregung und Vorschlag zur Verbesserung. Und bin Dankbar dafür.
Und für den IST Stand ev. zum Andenken:
Ev. würde eine Warning im Log sinnvoll sein, so in der Art:
Warning: Subsystem not yet started. If you configuration has been completed, please check xxxx box at configuration UI to start subsystem automatically.
Zumindest User die ins Log schaun (und das sind sicher nicht alle :-) hätte da nen Hinweis.Aktuell gibt es (in aktuellen Github Version) die folgende Meldung wenn der Adapter gestartet wird ohne das der Haken da ist:
Zigbee autostart option not set - omitting start of zigbee substystem!@gaspode sagte in Tester für Zigbee Adapter 2.0.x gesucht:
@mcm1957 said in Tester für Zigbee Adapter 2.0.x gesucht:
Damit hätte man bei Upgrade von 1.x.x auf 2.x.x das Hakerl automatisch setzen können.
Der Haken kommt ja erst mit Version 3. Ich hab ehrlich gesagt noch nicht ganz verstanden, wann es sinnvoll ist, den Haken zunächst nicht zu setzen. Wenn das wirklich immer nur eine Neuinstallation des Adapters beträfe, wäre das bestimmt eine gute Sache, dass die Upgrader nicht davon behelligt werden.
Bestehende Installationen die vor dem Update gelaufen sind sollten den Haken immer setzen. Einfach betrachtet wäre ein Skript also eine interessante option, aber
- Leider gehen viele Nutzer wenig 'systematisch' vor wenn etwas nicht sofort geht - da wird dieses und jenes neu installiert / über installiert / krumm gedreht. Mal von NPM, mal von Github, mal eine ältere Version. Ich hab im Forum an vielen Stellen mehr Probleme damit die komischen Lösungsversuche von Nutzern gerade zu biegen als das eigentlich ursächliche Problem zu lösen.
Könnte ich das alles in einem Skript sauber abfangen - vielleicht.
Ist es das für diesen einfachen Fall wert - in meinen Augen nicht. Einmal in die Einstellungen zu gehen und den Haken zu setzen ist jetzt nicht wirklich zuviel verlangt.
- Dadurch das die Nutzer in die Konfiguration gehen werden sie gleich noch mit einer weiteren Eigenschaft der 3.x konfrontiert - einer Verifikation von Zigbee-Einstellungen und den vom Koordinator gesicherten Einstellungen. Passen die nicht übereinander wird das angezeigt. Zusätzlich bekommen alle die noch die unsäglichen 16D ExtPanID nutzen nochmal einen Hinweis darauf das das vielleicht nicht gut ist.
Über die Einstellungen lassen sich dann für die Nutzer halbwegs komfortabel auch Auffälligkeiten beheben, wie z.Bsp. die "Unart" einfach den Adapter mit dem Haken bei
laufen zu lassen.Dieses ist gewünscht - zumindest von mir :)
A.
@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:
Zusätzlich bekommen alle die noch die unsäglichen 16D ExtPanID nutzen nochmal einen Hinweis darauf das das vielleicht nicht gut ist.
Vielleicht kannst du für die ganz Unkreativen auch einen Link zu einem Hex-Generator verlinken?
Ich lass mich da nämlich auch ganz gerne von solchen Diensten 'beraten'. -
@mcm1957 sagte in Tester für Zigbee Adapter 2.0.x gesucht:
@asgothian
Will nicht ätzen oder kritisieren. Und da mittlerweile 3.x.x existiert ist es wahrscheinlich eh schon zu spät. Wenn was super toll funktioniert kommen dann halt immer noch die "Vergoldungswünsche". Bitte nicht bös nehmen[...snip]
Keine Sorge - ich nehm das als Anregung und Vorschlag zur Verbesserung. Und bin Dankbar dafür.
Und für den IST Stand ev. zum Andenken:
Ev. würde eine Warning im Log sinnvoll sein, so in der Art:
Warning: Subsystem not yet started. If you configuration has been completed, please check xxxx box at configuration UI to start subsystem automatically.
Zumindest User die ins Log schaun (und das sind sicher nicht alle :-) hätte da nen Hinweis.Aktuell gibt es (in aktuellen Github Version) die folgende Meldung wenn der Adapter gestartet wird ohne das der Haken da ist:
Zigbee autostart option not set - omitting start of zigbee substystem!@gaspode sagte in Tester für Zigbee Adapter 2.0.x gesucht:
@mcm1957 said in Tester für Zigbee Adapter 2.0.x gesucht:
Damit hätte man bei Upgrade von 1.x.x auf 2.x.x das Hakerl automatisch setzen können.
Der Haken kommt ja erst mit Version 3. Ich hab ehrlich gesagt noch nicht ganz verstanden, wann es sinnvoll ist, den Haken zunächst nicht zu setzen. Wenn das wirklich immer nur eine Neuinstallation des Adapters beträfe, wäre das bestimmt eine gute Sache, dass die Upgrader nicht davon behelligt werden.
Bestehende Installationen die vor dem Update gelaufen sind sollten den Haken immer setzen. Einfach betrachtet wäre ein Skript also eine interessante option, aber
- Leider gehen viele Nutzer wenig 'systematisch' vor wenn etwas nicht sofort geht - da wird dieses und jenes neu installiert / über installiert / krumm gedreht. Mal von NPM, mal von Github, mal eine ältere Version. Ich hab im Forum an vielen Stellen mehr Probleme damit die komischen Lösungsversuche von Nutzern gerade zu biegen als das eigentlich ursächliche Problem zu lösen.
Könnte ich das alles in einem Skript sauber abfangen - vielleicht.
Ist es das für diesen einfachen Fall wert - in meinen Augen nicht. Einmal in die Einstellungen zu gehen und den Haken zu setzen ist jetzt nicht wirklich zuviel verlangt.
- Dadurch das die Nutzer in die Konfiguration gehen werden sie gleich noch mit einer weiteren Eigenschaft der 3.x konfrontiert - einer Verifikation von Zigbee-Einstellungen und den vom Koordinator gesicherten Einstellungen. Passen die nicht übereinander wird das angezeigt. Zusätzlich bekommen alle die noch die unsäglichen 16D ExtPanID nutzen nochmal einen Hinweis darauf das das vielleicht nicht gut ist.
Über die Einstellungen lassen sich dann für die Nutzer halbwegs komfortabel auch Auffälligkeiten beheben, wie z.Bsp. die "Unart" einfach den Adapter mit dem Haken bei
laufen zu lassen.Dieses ist gewünscht - zumindest von mir :)
A.
Alles klar und für mich OK. DU entscheidest als dev was du für sinnvoll haltest.
Und wenn es dir was hilft um schräge Installationen zu minimieren: Eine Installation von Github kannst du blocken. Damit zwingst du user zumindest eine (ggF Alpha) von npm zu installieren. Die mag zwar auch defekt sein aber wenigsten in sich ein definierter Zustand. (https://github.com/ioBroker/ioBroker.js-controller/blob/6ade4045339082a9408e17e0871ad26dc41206ca/schemas/io-package.json#L1371)
Muss aber jeder dev selbst entscheiden was hilfreicher ist.
-
Hallo,
nach Update auf Zigbee Adapter 2.0.5 funktioniert der Sensor nicht mehr, Fehlermeldung im Adapter:
Woran kann das liegen?
@arteck Muss man bei der neuen Adapter Version etwas beachten?
Edit: hier gibt es noch weitere Fragen zum Zigbee Adapter 2.x: https://forum.iobroker.net/post/1275544
Edit nach Verschiebung: Es geht um dieses Gerät hier: https://forum.iobroker.net/post/606728
Hatte es dort gepostet, weil ich ursprünglich gehofft hab, dass @dimaiv was dazu sagen kann bzw. schon Anpassungen dazu hat.
@gaspode
Hier, im Thread, gibt's sogar die Lösung für dein Problem, aber, wenn man kein Zeit für Lesen hat...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 -
@dimaiv said in Tester für Zigbee Adapter 2.0.x gesucht:
@gaspode
Hier, im Thread, gibt's sogar die Lösung für dein Problem, aber, wenn man kein Zeit für Lesen hat...Mein Problem ist mit V 3 des Adapters ja gelöst. Ist halt nicht einfach, in einem Thread mit über 500 Beiträgen die Übersicht zu behalten. Also sehe es mir bitte nach, dass ich die Lösung übersehen habe.
Edit:
So, jetzt wieder daheim und nicht mehr nur am Handy.
Nochmal zur Erklärung: Ich hatte ja eigentlich direkt in deinem Thread gepostet, weil ich diesen Thread hier nicht gefunden hatte. @Homoran war dann so nett, den Teil hierher zu verschieben, wodurch es jetzt aussieht, als hätte ich direkt hier gefragt.Konstruktiver Vorschlag: Willst du in deinem Eingangspost deines Threads einen kurzen Hinweis schreiben, was bei Umstieg auf den Zigbee Adapter 2 zu beachten ist und dass man die Anpassung im Adapter Version 3 gar nicht mehr braucht? Damit würdest du den Käufern deines Feuchtesensors bestimmt viel Sucherei ersparen, nicht jeder findet zielgenau den richtigen Tipp im Tester Thread. Ich war zumindest zu blind dafür.
-
@dimaiv said in Tester für Zigbee Adapter 2.0.x gesucht:
@gaspode
Hier, im Thread, gibt's sogar die Lösung für dein Problem, aber, wenn man kein Zeit für Lesen hat...Mein Problem ist mit V 3 des Adapters ja gelöst. Ist halt nicht einfach, in einem Thread mit über 500 Beiträgen die Übersicht zu behalten. Also sehe es mir bitte nach, dass ich die Lösung übersehen habe.
Edit:
So, jetzt wieder daheim und nicht mehr nur am Handy.
Nochmal zur Erklärung: Ich hatte ja eigentlich direkt in deinem Thread gepostet, weil ich diesen Thread hier nicht gefunden hatte. @Homoran war dann so nett, den Teil hierher zu verschieben, wodurch es jetzt aussieht, als hätte ich direkt hier gefragt.Konstruktiver Vorschlag: Willst du in deinem Eingangspost deines Threads einen kurzen Hinweis schreiben, was bei Umstieg auf den Zigbee Adapter 2 zu beachten ist und dass man die Anpassung im Adapter Version 3 gar nicht mehr braucht? Damit würdest du den Käufern deines Feuchtesensors bestimmt viel Sucherei ersparen, nicht jeder findet zielgenau den richtigen Tipp im Tester Thread. Ich war zumindest zu blind dafür.
@gaspode
Mit aktuelle Zigbee Adapter Version , also, 3.0.1 läuft alles gut wie gewohnt.
Mein einziger Vorschlag wäre, so schnell wie es geht, Zigbee Adapter auf die Version 3.x.x updaten.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 -
@gaspode
Mit aktuelle Zigbee Adapter Version , also, 3.0.1 läuft alles gut wie gewohnt.
Mein einziger Vorschlag wäre, so schnell wie es geht, Zigbee Adapter auf die Version 3.x.x updaten.@dimaiv said in Tester für Zigbee Adapter 2.0.x gesucht:
Mein einziger Vorschlag wäre, so schnell wie es geht, Zigbee Adapter auf die Version 3.x.x updaten.
Ich habe das ja inzwischen längst gemacht. Ich schlage ja nur vor, dass du einen kurzen Hinweis in dein Posting zum Verkauf der Devices schreibst. Denn da werden die meisten wohl als erstes rein gucken, wenn sie Probleme haben. Ich hab das zumindest so gemacht. Wie gesagt, keine Kritik, kein Vorwurf an dich. Nur ein Vorschlag.
-
@dimaiv sagte in Tester für Zigbee Adapter 2.0.x gesucht:
Dein Zigbee Dongle kann die Kanäle gar nicht scannen, unterstützt es nicht. Das können nur die CC.
Das ist schade - war mir nicht klar, da ich keine EZSP Firmware Koordinatoren habe.
@kaffler Das macht die Analyse komplizierter. Ich gehe aktuell davon aus das der gewählte Kanal so stark frequentiert ist das die Meldungen untergehen. Zigbee arbeitet mit vergleichsweise geringen Sende- und Empfangsleistungen. Damit ist es durchaus anfällig dafür das Meldungen durch stärkere Sender 'überstimmt' werden. Deswegen auch der Wunsch nach dem Kanal-Scan. da kann man dann sehen welche Kanäle wie 'voll' sind.
Leider ist nicht nur WLan als Konkurrenz im 2.4 GHz Netz präsent. Auch ist nicht nur das eigene WLan, sondern auch die der Nachbarn ggf. zu berücksichtigen. Mögliche Störquellen sind:
- 2.4 GHz WLan
- Bluetooth
- freie herstellerspezifische 2.4 GHz Sender/Empfänger paare (Steckdosenfernbedienungen, Funk-Kopfhörer, Funk-Tastaturen / Mäuse, etc.)
- USB3 Geräte. (durch schlechte Kabel / Hardware-Implementierung kann bei der Kommunikation bei USB3 stark im 2.4 GHz Bereich gestreut werden - stark genug um sogar WLan zu übersteuern.
Da insbesondere die Meldungen von Sensoren als 'fire and forget' gesandt werden gehen diese gerne mal unter.
A.
@asgothian
Moin noch mal in Runde,
hatte jetzt mal ein wenig Zeit zum Testen.Habe mir ein neues System mit meinem Ersatz Pi auf gesetzt und einem neuen SonOff Stick mit aktueller Firmware.
Hatte dort den gleichen Effekt. (Schließe dadurch mein aktives System aus)Steckdosen, Türsensoren von Aquara alles lief nur nicht diese SNZB-02 nicht.
Habe dann mit meinem einfachen Wissen, zwei Sensoren neu geflashed mit der Firmware Efekta (SNZB-02_EFEKTA_H.hex)
Damit Senden die Sensoren wieder regelmäßig ein Batteriesignal.Jetzt die Herausforderung für den Cracks der Software.
Wenn ich den Sensor anlerne alles gut.
Datenpunkte werden angelegt.
Jetzt Kann ich über den Reiter "Entwickler" den Sensor triggern.
Erhalte auch den angeforderten Werte welche er dann auch brave in die Datenpunkt einträgt. (Wiederholbar)Diese läuft jetzt seit 3 Tagen, sendet regelmäßig sein Batteriestand aber keine Werte (Feuchte,Temperatur)
Da das Problem auf beiden PIs gleich ist und die Sensoren beim Test-Pi nur 10 cm von der Antenne weg lagen, und der Sensor Daten sendet. Würde ich ein Funkproblem auf unwahrscheinlich setzten.
Habe noch ein paar Logs vom Sensor angehängt vielleicht hat Jemand noch eine Idee.
Zum wegschmeißen sind die zu Schade.
-
@asgothian
Moin noch mal in Runde,
hatte jetzt mal ein wenig Zeit zum Testen.Habe mir ein neues System mit meinem Ersatz Pi auf gesetzt und einem neuen SonOff Stick mit aktueller Firmware.
Hatte dort den gleichen Effekt. (Schließe dadurch mein aktives System aus)Steckdosen, Türsensoren von Aquara alles lief nur nicht diese SNZB-02 nicht.
Habe dann mit meinem einfachen Wissen, zwei Sensoren neu geflashed mit der Firmware Efekta (SNZB-02_EFEKTA_H.hex)
Damit Senden die Sensoren wieder regelmäßig ein Batteriesignal.Jetzt die Herausforderung für den Cracks der Software.
Wenn ich den Sensor anlerne alles gut.
Datenpunkte werden angelegt.
Jetzt Kann ich über den Reiter "Entwickler" den Sensor triggern.
Erhalte auch den angeforderten Werte welche er dann auch brave in die Datenpunkt einträgt. (Wiederholbar)Diese läuft jetzt seit 3 Tagen, sendet regelmäßig sein Batteriestand aber keine Werte (Feuchte,Temperatur)
Da das Problem auf beiden PIs gleich ist und die Sensoren beim Test-Pi nur 10 cm von der Antenne weg lagen, und der Sensor Daten sendet. Würde ich ein Funkproblem auf unwahrscheinlich setzten.
Habe noch ein paar Logs vom Sensor angehängt vielleicht hat Jemand noch eine Idee.
Zum wegschmeißen sind die zu Schade.
@kaffler
Probier mal die Sensoren reconfigurieren. Dann sollte es funktionieren.
Im Log muss unbedingt folgende Meldung kommen:
"DeviceConfigure successful....."Ich habe gemerkt, ab Zigbee Adapter 2.0.x werden nicht alle Geräte nach anlernen configuriert.
Manuele Reconfiguration bringt Erfolg. -
@asgothian
Moin noch mal in Runde,
hatte jetzt mal ein wenig Zeit zum Testen.Habe mir ein neues System mit meinem Ersatz Pi auf gesetzt und einem neuen SonOff Stick mit aktueller Firmware.
Hatte dort den gleichen Effekt. (Schließe dadurch mein aktives System aus)Steckdosen, Türsensoren von Aquara alles lief nur nicht diese SNZB-02 nicht.
Habe dann mit meinem einfachen Wissen, zwei Sensoren neu geflashed mit der Firmware Efekta (SNZB-02_EFEKTA_H.hex)
Damit Senden die Sensoren wieder regelmäßig ein Batteriesignal.Jetzt die Herausforderung für den Cracks der Software.
Wenn ich den Sensor anlerne alles gut.
Datenpunkte werden angelegt.
Jetzt Kann ich über den Reiter "Entwickler" den Sensor triggern.
Erhalte auch den angeforderten Werte welche er dann auch brave in die Datenpunkt einträgt. (Wiederholbar)Diese läuft jetzt seit 3 Tagen, sendet regelmäßig sein Batteriestand aber keine Werte (Feuchte,Temperatur)
Da das Problem auf beiden PIs gleich ist und die Sensoren beim Test-Pi nur 10 cm von der Antenne weg lagen, und der Sensor Daten sendet. Würde ich ein Funkproblem auf unwahrscheinlich setzten.
Habe noch ein paar Logs vom Sensor angehängt vielleicht hat Jemand noch eine Idee.
Zum wegschmeißen sind die zu Schade.
@kaffler entweder nochmal neu pairen..
steht zumindest so hier
https://www.zigbee2mqtt.io/devices/SNZB-02.htmloder kannst mit dem configure knopp versuchen..
ansonsten kannst den über send_payload manuell triggern.. dann aber mit vorsicht. sonst müllst du dir dein Netzwerk zu
-
Ich hoffe, ich werfe jetzt nix durcheinander, aber wenn ich das richtig verstehe, hat @Asgothian hier eine ausführliche Erklärung für das Verhalten gepostet. Eine Lösung dazu auch, allerdings im Zusammenhang mit der Version 3.x des Zigbee Adapters.
-
Ich hoffe, ich werfe jetzt nix durcheinander, aber wenn ich das richtig verstehe, hat @Asgothian hier eine ausführliche Erklärung für das Verhalten gepostet. Eine Lösung dazu auch, allerdings im Zusammenhang mit der Version 3.x des Zigbee Adapters.
@gaspode sagte in Tester für Zigbee Adapter 2.0.x gesucht:
Eine Lösung dazu auch, allerdings im Zusammenhang mit der Version 3.x des Zigbee Adapters.
die Themtik ist Version unabhängig..
-
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.
@asgothian
hallo ich bin ein Zigbee Anfänger und habe folgendes Problem.
Ich habe mir ein Vibrationssensor gekauft, bekomme ihn aber nicht korrekt eingebunden.
Der Sensor gekoppelt aber er hat kein Ikon und es werden unter Objekten keine DP angezeigt.
Laut Zigbee2MQTT wird er unterstützt.
https://www.zigbee2mqtt.io/devices/ZG-102ZM.htmlBei "Reconfigure" kommt eine Fehlermeldung.
Laut Log muss ich koppeln neu versuchen, klappt aber nicht.
zigbee.0 2025-06-25 17:59:09.318 error Failed to interview '0xa4c138d46d61f7fd', device has not successfully been paired. Try again !!!!!!!!!! zigbee.0 2025-06-25 17:58:40.808 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:58:40.251 info Starting interview of '0xa4c138d46d61f7fd' zigbee.0 2025-06-25 17:58:25.447 error Failed to interview '0xa4c138d46d61f7fd', device has not successfully been paired. Try again !!!!!!!!!! zigbee.0 2025-06-25 17:57:55.426 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:57:54.862 info Starting interview of '0xa4c138d46d61f7fd' zigbee.0 2025-06-25 17:57:41.355 error Failed to interview '0xa4c138d46d61f7fd', device has not successfully been paired. Try again !!!!!!!!!! zigbee.0 2025-06-25 17:57:13.527 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:57:13.018 info Starting interview of '0xa4c138d46d61f7fd' zigbee.0 2025-06-25 17:57:02.395 error Failed to interview '0xa4c138d46d61f7fd', device has not successfully been paired. Try again !!!!!!!!!! zigbee.0 2025-06-25 17:56:44.197 info Opening zigbee Network for 240 seconds zigbee.0 2025-06-25 17:56:43.319 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:56:29.235 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:56:29.077 warn Blocked interview for 'undefined' because the network is closed zigbee.0 2025-06-25 17:56:23.569 info Closing Zigbee network, 1 seconds remaining zigbee.0 2025-06-25 17:55:39.863 error Failed to interview '0xa4c138d46d61f7fd', device has not successfully been paired. Try again !!!!!!!!!! zigbee.0 2025-06-25 17:55:02.811 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:55:02.278 info Starting interview of '0xa4c138d46d61f7fd' zigbee.0 2025-06-25 17:54:48.897 error Failed to interview '0xa4c138d46d61f7fd', device has not successfully been paired. Try again !!!!!!!!!! zigbee.0 2025-06-25 17:54:20.923 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:54:20.431 info Starting interview of '0xa4c138d46d61f7fd' zigbee.0 2025-06-25 17:54:06.591 info List of port: [{"path":"/dev/ttyS0"},{"path":"/dev/ttyS1"},{"path":"/dev/ttyS10"},{"path":"/dev/ttyS11"},{"path":"/dev/ttyS12"},{"path":"/dev/ttyS13"},{"path":"/dev/ttyS14"},{"path":"/dev/ttyS15"},{"path":"/dev/ttyS16"},{"path":"/dev/ttyS17"},{"path":"/dev/ttyS18"},{"path":"/dev/ttyS19"},{"path":"/dev/ttyS2"},{"path":"/dev/ttyS20"},{"path":"/dev/ttyS21"},{"path":"/dev/ttyS22"},{"path":"/dev/ttyS23"},{"path":"/dev/ttyS24"},{"path":"/dev/ttyS25"},{"path":"/dev/ttyS26"},{"path":"/dev/ttyS27"},{"path":"/dev/ttyS28"},{"path":"/dev/ttyS29"},{"path":"/dev/ttyS3"},{"path":"/dev/ttyS30"},{"path":"/dev/ttyS31"},{"path":"/dev/ttyS4"},{"path":"/dev/ttyS5"},{"path":"/dev/ttyS6"},{"path":"/dev/ttyS7"},{"path":"/dev/ttyS8"},{"path":"/dev/ttyS9"}] zigbee.0 2025-06-25 17:52:58.285 error Failed to interview '0xa4c138d46d61f7fd', device has not successfully been paired. Try again !!!!!!!!!! zigbee.0 2025-06-25 17:52:28.785 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:52:28.282 info Starting interview of '0xa4c138d46d61f7fd' zigbee.0 2025-06-25 17:52:23.570 info Opening zigbee Network for 240 seconds zigbee.0 2025-06-25 17:52:07.362 info List of port: [{"path":"/dev/ttyS0"},{"path":"/dev/ttyS1"},{"path":"/dev/ttyS10"},{"path":"/dev/ttyS11"},{"path":"/dev/ttyS12"},{"path":"/dev/ttyS13"},{"path":"/dev/ttyS14"},{"path":"/dev/ttyS15"},{"path":"/dev/ttyS16"},{"path":"/dev/ttyS17"},{"path":"/dev/ttyS18"},{"path":"/dev/ttyS19"},{"path":"/dev/ttyS2"},{"path":"/dev/ttyS20"},{"path":"/dev/ttyS21"},{"path":"/dev/ttyS22"},{"path":"/dev/ttyS23"},{"path":"/dev/ttyS24"},{"path":"/dev/ttyS25"},{"path":"/dev/ttyS26"},{"path":"/dev/ttyS27"},{"path":"/dev/ttyS28"},{"path":"/dev/ttyS29"},{"path":"/dev/ttyS3"},{"path":"/dev/ttyS30"},{"path":"/dev/ttyS31"},{"path":"/dev/ttyS4"},{"path":"/dev/ttyS5"},{"path":"/dev/ttyS6"},{"path":"/dev/ttyS7"},{"path":"/dev/ttyS8"},{"path":"/dev/ttyS9"}] -
@asgothian
hallo ich bin ein Zigbee Anfänger und habe folgendes Problem.
Ich habe mir ein Vibrationssensor gekauft, bekomme ihn aber nicht korrekt eingebunden.
Der Sensor gekoppelt aber er hat kein Ikon und es werden unter Objekten keine DP angezeigt.Laut Zigbee2MQTT wird er unterstützt.
https://www.zigbee2mqtt.io/devices/ZG-102ZM.htmlBei "Reconfigure" kommt eine Fehlermeldung.
Laut Log muss ich koppeln neu versuchen, klappt aber nicht.
zigbee.0 2025-06-25 17:59:09.318 error Failed to interview '0xa4c138d46d61f7fd', device has not successfully been paired. Try again !!!!!!!!!! zigbee.0 2025-06-25 17:58:40.808 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:58:40.251 info Starting interview of '0xa4c138d46d61f7fd' zigbee.0 2025-06-25 17:58:25.447 error Failed to interview '0xa4c138d46d61f7fd', device has not successfully been paired. Try again !!!!!!!!!! zigbee.0 2025-06-25 17:57:55.426 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:57:54.862 info Starting interview of '0xa4c138d46d61f7fd' zigbee.0 2025-06-25 17:57:41.355 error Failed to interview '0xa4c138d46d61f7fd', device has not successfully been paired. Try again !!!!!!!!!! zigbee.0 2025-06-25 17:57:13.527 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:57:13.018 info Starting interview of '0xa4c138d46d61f7fd' zigbee.0 2025-06-25 17:57:02.395 error Failed to interview '0xa4c138d46d61f7fd', device has not successfully been paired. Try again !!!!!!!!!! zigbee.0 2025-06-25 17:56:44.197 info Opening zigbee Network for 240 seconds zigbee.0 2025-06-25 17:56:43.319 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:56:29.235 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:56:29.077 warn Blocked interview for 'undefined' because the network is closed zigbee.0 2025-06-25 17:56:23.569 info Closing Zigbee network, 1 seconds remaining zigbee.0 2025-06-25 17:55:39.863 error Failed to interview '0xa4c138d46d61f7fd', device has not successfully been paired. Try again !!!!!!!!!! zigbee.0 2025-06-25 17:55:02.811 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:55:02.278 info Starting interview of '0xa4c138d46d61f7fd' zigbee.0 2025-06-25 17:54:48.897 error Failed to interview '0xa4c138d46d61f7fd', device has not successfully been paired. Try again !!!!!!!!!! zigbee.0 2025-06-25 17:54:20.923 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:54:20.431 info Starting interview of '0xa4c138d46d61f7fd' zigbee.0 2025-06-25 17:54:06.591 info List of port: [{"path":"/dev/ttyS0"},{"path":"/dev/ttyS1"},{"path":"/dev/ttyS10"},{"path":"/dev/ttyS11"},{"path":"/dev/ttyS12"},{"path":"/dev/ttyS13"},{"path":"/dev/ttyS14"},{"path":"/dev/ttyS15"},{"path":"/dev/ttyS16"},{"path":"/dev/ttyS17"},{"path":"/dev/ttyS18"},{"path":"/dev/ttyS19"},{"path":"/dev/ttyS2"},{"path":"/dev/ttyS20"},{"path":"/dev/ttyS21"},{"path":"/dev/ttyS22"},{"path":"/dev/ttyS23"},{"path":"/dev/ttyS24"},{"path":"/dev/ttyS25"},{"path":"/dev/ttyS26"},{"path":"/dev/ttyS27"},{"path":"/dev/ttyS28"},{"path":"/dev/ttyS29"},{"path":"/dev/ttyS3"},{"path":"/dev/ttyS30"},{"path":"/dev/ttyS31"},{"path":"/dev/ttyS4"},{"path":"/dev/ttyS5"},{"path":"/dev/ttyS6"},{"path":"/dev/ttyS7"},{"path":"/dev/ttyS8"},{"path":"/dev/ttyS9"}] zigbee.0 2025-06-25 17:52:58.285 error Failed to interview '0xa4c138d46d61f7fd', device has not successfully been paired. Try again !!!!!!!!!! zigbee.0 2025-06-25 17:52:28.785 info Device '0xa4c138d46d61f7fd' announced itself zigbee.0 2025-06-25 17:52:28.282 info Starting interview of '0xa4c138d46d61f7fd' zigbee.0 2025-06-25 17:52:23.570 info Opening zigbee Network for 240 seconds zigbee.0 2025-06-25 17:52:07.362 info List of port: [{"path":"/dev/ttyS0"},{"path":"/dev/ttyS1"},{"path":"/dev/ttyS10"},{"path":"/dev/ttyS11"},{"path":"/dev/ttyS12"},{"path":"/dev/ttyS13"},{"path":"/dev/ttyS14"},{"path":"/dev/ttyS15"},{"path":"/dev/ttyS16"},{"path":"/dev/ttyS17"},{"path":"/dev/ttyS18"},{"path":"/dev/ttyS19"},{"path":"/dev/ttyS2"},{"path":"/dev/ttyS20"},{"path":"/dev/ttyS21"},{"path":"/dev/ttyS22"},{"path":"/dev/ttyS23"},{"path":"/dev/ttyS24"},{"path":"/dev/ttyS25"},{"path":"/dev/ttyS26"},{"path":"/dev/ttyS27"},{"path":"/dev/ttyS28"},{"path":"/dev/ttyS29"},{"path":"/dev/ttyS3"},{"path":"/dev/ttyS30"},{"path":"/dev/ttyS31"},{"path":"/dev/ttyS4"},{"path":"/dev/ttyS5"},{"path":"/dev/ttyS6"},{"path":"/dev/ttyS7"},{"path":"/dev/ttyS8"},{"path":"/dev/ttyS9"}] -
@arteck
ich habe jetzt auf 3.0.1 umgestiegen.
Aber Instanz stürzt jetzt immer ab beim versuchen zu koppeln.
Edit:
zigbee.0 2025-06-25 19:07:06.317 error Failed to remove Error: AREQ - ZDO - mgmtLeaveRsp after 10000ms at Object.start (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/waitress.ts:67:23) at func (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:423:47) at processTicksAndRejections (node:internal/process/task_queues:95:5) at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:36:20) at ZStackAdapter.sendZdoInternal (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:428:43) at ZStackAdapter.sendZdo (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:305:16) at Device.removeFromNetwork (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/model/device.ts:1125:30) at ZigbeeController.remove (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:736:21)
Support us
891
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge