NEWS
Tester für Zigbee Adapter 2.0.x gesucht
-
@kaffler Fangen wir mal vorne an:
- das Log im Debug ist wertlos - da stehen extrem viele Daten drin die nicht wirklich helfen. Darin irgend etwas zu finden ist wie das Suchen nach einer Nadel im Heuhaufen.
- Die LQ von 10 wird immer dann bei allen Geräten gesetzt wenn der Adapter neu gestartet wird. Diese ändert sich erst wenn ein Geräte eine Nachricht sendet.
- Der Conbee II ist seitens ZHC nicht mehr als empfohlen gelistet, und üblicherweise schlechter als der Sonoff Stick.
- Löschen der Datenbank bedeutet das die Geräte neu angelernt werden müssen - löst aber ansonsten die Probleme nicht.
Ich gehe davon aus das es ein Problem mit Störungen im 2.4 gHz Frequenzband gibt, ausgelöst durch
- WLan (ggf. das des Nachbarn)
- USB3 Festplatten / SSD's am PI4
- Funk-Tastaturen/Mäuse/Kopfhörer, etc. im 2.4 GHz Band
Alternativ kann es auch sein das der SNZB-02 sich nicht mit einem der Router versteht und dadurch aus dem Netz fliegt.
Notwendige Massnahmen:
- Zurück auf den Sonoff Stick wechseln
- Adapter zum laufen bringen, über den Adapter einen Kanal-Scan durchführen, um zu sehen welche Kanäle die wenigsten Störungen haben
- Auf besagten Kanal umstellen
- Geräte anlernen
- Nach erfolgreichem Anlernen die Geräte über den Adapter 'Konfigurieren' (siehe Anleitung auf Github) Wichtig: Batteriebetriebene Geräte dabei wach halten.
- System für mindestens 24 h laufen lassen
Dann mal schauen wie sich die LQ entwickelt hat.
Sollten dann Probleme auftreten, die betroffenen Geräte in Debug schalten (siehe Doku auf Github, bzw. den Wiki Artikel dazu.
A.
@asgothian so hatte mal Zeit:
habe folgendes aufgebaut:
-Reserve PI aufgesetzt. (Pi OS Legacy 64-bit lite)
-neuer SONOFF Zigbee Gateway, ZBDongle-E 3.0 USB Dongle Plus mit 3m USB-Verlängerung Sensor 30 cm daneben.- Iobroker nur Zigbee-Adapter
Das verhalten ist das Gleiche wie auf dem anderen PI, somit schließe ich das System aus.
Konfiguration zum Testen.
Log von dem Pairing eines Adapter
zigbee.0 2025-05-29 21:01:07.199 info Closing Zigbee network, 1 seconds remaining zigbee.0 2025-05-29 21:00:32.637 info Device '0x00124b00292843c9' is supported, identified as: SONOFF Temperature and humidity sensor (SNZB-02) zigbee.0 2025-05-29 21:00:32.637 info Successfully interviewed '0x00124b00292843c9', device has successfully been paired zigbee.0 2025-05-29 21:00:27.934 info debug devices set to [] zigbee.0 2025-05-29 21:00:27.919 warn Device 0x00124b00292843c9 "SNZB-02" not found. zigbee.0 2025-05-29 21:00:16.737 info Starting interview of '0x00124b00292843c9' zigbee.0 2025-05-29 21:00:07.200 info Opening zigbee Network for 60 seconds zigbee.0 2025-05-29 20:59:46.816 info Zigbee started zigbee.0 2025-05-29 20:59:46.813 info Currently no devices. zigbee.0 2025-05-29 20:59:46.811 info Unable to disable LED, unsupported function. zigbee.0 2025-05-29 20:59:46.809 info Zigbee-Herdsman started successfully with Coordinator firmware version: {"type":"EZSP v8","meta":{"product":8,"majorrel":"6","minorrel":"10","maintrel":"3 ","revision":"6.10.3.0 build 297"}} zigbee.0 2025-05-29 20:59:41.835 info Starting Zigbee-Herdsman zigbee.0 2025-05-29 20:59:41.833 info Installed Version: iobroker.zigbee@2.0.5 (Converters 23.6.0 Herdsman 3.5.2) zigbee.0 2025-05-29 20:59:41.783 info Starting Adapter npm ... zigbee.0 2025-05-29 20:59:41.782 info --- creating device debug --- zigbee.0 2025-05-29 20:59:41.766 info --> transmitPower : normal zigbee.0 2025-05-29 20:59:41.758 info init localConfig zigbee.0 2025-05-29 20:59:41.728 info starting. Version 2.0.5 in /opt/iobroker/node_modules/iobroker.zigbee, node: v20.19.2, js-controller: 7.0.6Gerät wurde angelegt
Reconfig durchgeführt
zigbee.0 2025-05-29 21:06:21.463 info DeviceConfigure successful 0x00124b00292843c9 SNZB-02 zigbee.0 2025-05-29 21:06:11.425 info Configuring 0x00124b00292843c9 SNZB-02 zigbee.0 2025-05-29 21:04:58.529 info debug devices set to ["00124b00292843c9"] zigbee.0 2025-05-29 21:04:53.718 info List of port: [{"path":"/dev/ttyUSB0","manufacturer":"Itead","serialNumber":"06e595039338ef118eed357af3d9b1e5","pnpId":"usb-Itead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_V2_06e595039338ef118eed357af3d9b1e5-if00-port0","vendorId":"10c4","productId":"ea60"},{"path":"/dev/ttyAMA0"}]
Log vom andereren System aus dem Zigbee Adapter
c04 {"type":"attributeReport", "data":{"batteryPercentageRemaining":178}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":12, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":89} battery 89 SUCCESS {"linkquality":255} link_quality 255 SUCCESS 1f80 {"type":"attributeReport", "data":{"batteryPercentageRemaining":177}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":11, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":88.5} battery 88.5 SUCCESS {"linkquality":255} link_quality 255 SUCCESS 9308 {"type":"attributeReport", "data":{"batteryPercentageRemaining":176}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":10, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":88} battery 88 SUCCESS {"linkquality":255} link_quality 255 SUCCESS abd3 {"type":"attributeReport", "data":{"batteryPercentageRemaining":176}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":9, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":88} battery 88 SUCCESS {"linkquality":255} link_quality 255 SUCCESS c321 {"type":"attributeReport", "data":{"batteryPercentageRemaining":176}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":8, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":88} battery 88 SUCCESS {"linkquality":255} link_quality 255 SUCCESS 9413 {"type":"attributeReport", "data":{"batteryPercentageRemaining":177}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":7, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":88.5} battery 88.5 SUCCESS {"linkquality":255} link_quality 255 SUCCESS abae {"type":"attributeReport", "data":{"batteryPercentageRemaining":177}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":6, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":88.5} battery 88.5 SUCCESS {"linkquality":255} link_quality 255 SUCCESS f162 {"type":"attributeReport", "data":{"batteryPercentageRemaining":175}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":5, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":87.5} battery 87.5 SUCCESS {"linkquality":255} link_quality 255 SUCCESS 7d1f {"type":"attributeReport", "data":{"batteryPercentageRemaining":174}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":4, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":87} battery 87 SUCCESS {"linkquality":255} link_quality 255 SUCCESS 955e {"type":"attributeReport", "data":{"batteryPercentageRemaining":174}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":3, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":87} battery 87 SUCCESS {"linkquality":255} link_quality 255 SUCCESS 0953 {"type":"attributeReport", "data":{"batteryPercentageRemaining":173}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":2, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":86.5} battery 86.5 SUCCESS {"linkquality":255} link_quality 255 SUCCESS ac80 {"type":"attributeReport", "data":{"batteryPercentageRemaining":129}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":1, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":64.5} battery 64.5 SUCCESS {"linkquality":255} link_quality 255 SUCCESS -
@asgothian so hatte mal Zeit:
habe folgendes aufgebaut:
-Reserve PI aufgesetzt. (Pi OS Legacy 64-bit lite)
-neuer SONOFF Zigbee Gateway, ZBDongle-E 3.0 USB Dongle Plus mit 3m USB-Verlängerung Sensor 30 cm daneben.- Iobroker nur Zigbee-Adapter
Das verhalten ist das Gleiche wie auf dem anderen PI, somit schließe ich das System aus.
Konfiguration zum Testen.
Log von dem Pairing eines Adapter
zigbee.0 2025-05-29 21:01:07.199 info Closing Zigbee network, 1 seconds remaining zigbee.0 2025-05-29 21:00:32.637 info Device '0x00124b00292843c9' is supported, identified as: SONOFF Temperature and humidity sensor (SNZB-02) zigbee.0 2025-05-29 21:00:32.637 info Successfully interviewed '0x00124b00292843c9', device has successfully been paired zigbee.0 2025-05-29 21:00:27.934 info debug devices set to [] zigbee.0 2025-05-29 21:00:27.919 warn Device 0x00124b00292843c9 "SNZB-02" not found. zigbee.0 2025-05-29 21:00:16.737 info Starting interview of '0x00124b00292843c9' zigbee.0 2025-05-29 21:00:07.200 info Opening zigbee Network for 60 seconds zigbee.0 2025-05-29 20:59:46.816 info Zigbee started zigbee.0 2025-05-29 20:59:46.813 info Currently no devices. zigbee.0 2025-05-29 20:59:46.811 info Unable to disable LED, unsupported function. zigbee.0 2025-05-29 20:59:46.809 info Zigbee-Herdsman started successfully with Coordinator firmware version: {"type":"EZSP v8","meta":{"product":8,"majorrel":"6","minorrel":"10","maintrel":"3 ","revision":"6.10.3.0 build 297"}} zigbee.0 2025-05-29 20:59:41.835 info Starting Zigbee-Herdsman zigbee.0 2025-05-29 20:59:41.833 info Installed Version: iobroker.zigbee@2.0.5 (Converters 23.6.0 Herdsman 3.5.2) zigbee.0 2025-05-29 20:59:41.783 info Starting Adapter npm ... zigbee.0 2025-05-29 20:59:41.782 info --- creating device debug --- zigbee.0 2025-05-29 20:59:41.766 info --> transmitPower : normal zigbee.0 2025-05-29 20:59:41.758 info init localConfig zigbee.0 2025-05-29 20:59:41.728 info starting. Version 2.0.5 in /opt/iobroker/node_modules/iobroker.zigbee, node: v20.19.2, js-controller: 7.0.6Gerät wurde angelegt
Reconfig durchgeführt
zigbee.0 2025-05-29 21:06:21.463 info DeviceConfigure successful 0x00124b00292843c9 SNZB-02 zigbee.0 2025-05-29 21:06:11.425 info Configuring 0x00124b00292843c9 SNZB-02 zigbee.0 2025-05-29 21:04:58.529 info debug devices set to ["00124b00292843c9"] zigbee.0 2025-05-29 21:04:53.718 info List of port: [{"path":"/dev/ttyUSB0","manufacturer":"Itead","serialNumber":"06e595039338ef118eed357af3d9b1e5","pnpId":"usb-Itead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_V2_06e595039338ef118eed357af3d9b1e5-if00-port0","vendorId":"10c4","productId":"ea60"},{"path":"/dev/ttyAMA0"}]Log vom andereren System aus dem Zigbee Adapter
c04 {"type":"attributeReport", "data":{"batteryPercentageRemaining":178}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":12, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":89} battery 89 SUCCESS {"linkquality":255} link_quality 255 SUCCESS 1f80 {"type":"attributeReport", "data":{"batteryPercentageRemaining":177}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":11, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":88.5} battery 88.5 SUCCESS {"linkquality":255} link_quality 255 SUCCESS 9308 {"type":"attributeReport", "data":{"batteryPercentageRemaining":176}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":10, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":88} battery 88 SUCCESS {"linkquality":255} link_quality 255 SUCCESS abd3 {"type":"attributeReport", "data":{"batteryPercentageRemaining":176}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":9, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":88} battery 88 SUCCESS {"linkquality":255} link_quality 255 SUCCESS c321 {"type":"attributeReport", "data":{"batteryPercentageRemaining":176}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":8, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":88} battery 88 SUCCESS {"linkquality":255} link_quality 255 SUCCESS 9413 {"type":"attributeReport", "data":{"batteryPercentageRemaining":177}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":7, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":88.5} battery 88.5 SUCCESS {"linkquality":255} link_quality 255 SUCCESS abae {"type":"attributeReport", "data":{"batteryPercentageRemaining":177}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":6, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":88.5} battery 88.5 SUCCESS {"linkquality":255} link_quality 255 SUCCESS f162 {"type":"attributeReport", "data":{"batteryPercentageRemaining":175}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":5, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":87.5} battery 87.5 SUCCESS {"linkquality":255} link_quality 255 SUCCESS 7d1f {"type":"attributeReport", "data":{"batteryPercentageRemaining":174}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":4, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":87} battery 87 SUCCESS {"linkquality":255} link_quality 255 SUCCESS 955e {"type":"attributeReport", "data":{"batteryPercentageRemaining":174}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":3, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":87} battery 87 SUCCESS {"linkquality":255} link_quality 255 SUCCESS 0953 {"type":"attributeReport", "data":{"batteryPercentageRemaining":173}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":2, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":86.5} battery 86.5 SUCCESS {"linkquality":255} link_quality 255 SUCCESS ac80 {"type":"attributeReport", "data":{"batteryPercentageRemaining":129}, "linkquality":255, "groupID":0, "cluster":"genPowerCfg", "meta":{"zclTransactionSequenceNumber":1, "frameControl":{"frameType":0, "manufacturerSpecific":false, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1} {"battery":64.5} battery 64.5 SUCCESS {"linkquality":255} link_quality 255 SUCCESS -
@asgothian Moin und danke für die Hilfe.
Scan wurde mit Error abgebrochen.
Festgestellt das Firmware alt war mit 6.x.x. update auf 7.4.4 durchgeführt.
Adaptereinstellungen IOB angepasst.
SL EFR32 (EMBER)
Quelle Firmwareupdate
ncp-uart-sw_EZNet7.4.4_V1.0.0 (1)Neustart des System.
Adapter Gestartet (alles Grün)
Meldung System IOBzigbee.0 2025-05-30 10:49:10.426 warn ELEVATED:I02 (8117) value generated '10' from device 00124b00292843c9 for 'Link quality' zigbee.0 2025-05-30 10:49:10.426 warn ELEVATED:I01 (8117) message received '{"linkquality":10}' from device 00124b00292843c9 type 'SNZB-02' zigbee.0 2025-05-30 10:49:10.425 warn ELEVATED:I02 (8117) value generated 'true' from device 00124b00292843c9 for 'Available' zigbee.0 2025-05-30 10:49:10.424 warn ELEVATED:I01 (8117) message received '{"available":true}' from device 00124b00292843c9 type 'SNZB-02' zigbee.0 2025-05-30 10:49:09.458 info debug devices set to ["00124b00292843c9"] zigbee.0 2025-05-30 10:49:09.428 info Zigbee started zigbee.0 2025-05-30 10:49:09.425 info Currently 1 devices are joined: zigbee.0 2025-05-30 10:49:09.424 info 0x00124b00292843c9 (addr 39685): SNZB-02 - SONOFF Temperature and humidity sensor (EndDevice) zigbee.0 2025-05-30 10:49:09.353 info Unable to disable LED, unsupported function. zigbee.0 2025-05-30 10:49:09.350 info Zigbee-Herdsman started successfully with Coordinator firmware version: {"type":"EmberZNet","meta":{"ezsp":13,"revision":"7.4.4 [GA]","build":0,"major":7,"minor":4,"patch":4,"special":0,"type":170}} zigbee.0 2025-05-30 10:49:07.347 info Starting Zigbee-Herdsman zigbee.0 2025-05-30 10:49:07.345 info Installed Version: iobroker.zigbee@2.0.5 (Converters 23.6.0 Herdsman 3.5.2) zigbee.0 2025-05-30 10:49:07.285 info Starting Adapter npm ... zigbee.0 2025-05-30 10:49:07.283 info --- creating device debug --- zigbee.0 2025-05-30 10:49:07.277 info delete old Backup files. keep only last 10 zigbee.0 2025-05-30 10:49:07.262 info --> transmitPower : normal zigbee.0 2025-05-30 10:49:07.252 info init localConfig zigbee.0 2025-05-30 10:49:07.223 info starting. Version 2.0.5 in /opt/iobroker/node_modules/iobroker.zigbee, node: v20.19.2, js-controller: 7.0.6Reconfig
zigbee.0 2025-05-30 10:56:05.460 info DeviceConfigure successful 0x00124b00292843c9 SNZB-02 zigbee.0 2025-05-30 10:56:00.622 info Configuring 0x00124b00292843c9 SNZB-02 zigbee.0 2025-05-30 10:55:46.758 info List of port: [{"path":"/dev/ttyUSB0","manufacturer":"Itead","serialNumber":"06e595039338ef118eed357af3d9b1e5","pnpId":"usb-Itead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_V2_06e595039338ef118eed357af3d9b1e5-if00-port0","vendorId":"10c4","productId":"ea60"},{"path":"/dev/ttyAMA0"}]Sensor keine Veränderung auch nach Reconfig
DEIN VORSCHLAG SCANNEN DER NW
Also das ist bei beiden Installationen.
Scan startet und bricht mit Error Popup ab.
Fehlermeldung IOBroker
zigbee.0 2025-05-30 11:01:26.503 error Failed to scan channels Error: {"target":0,"apsFrame":{"profileId":0,"clusterId":56,"sourceEndpoint":0,"destinationEndpoint":0,"options":4416,"groupId":0,"sequence":58},"zdoResponseClusterId":32824} timed out after 15000ms at Object.start (/opt/iobroker/node_modules/zigbee-herdsman/dist/adapter/ember/adapter/oneWaitress.js:133:23) at EmberOneWaitress.startWaitingFor (/opt/iobroker/node_modules/zigbee-herdsman/dist/adapter/ember/adapter/oneWaitress.js:152:47) at /opt/iobroker/node_modules/zigbee-herdsman/dist/adapter/ember/adapter/emberAdapter.js:1346:51 at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/dist/utils/queue.js:29:20) at async EmberAdapter.sendZdo (/opt/iobroker/node_modules/zigbee-herdsman/dist/adapter/ember/adapter/emberAdapter.js:1307:16) at async ZigbeeController.getChannelsEnergy (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:1186:32) at async Commands.getChannels (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:568:28) zigbee.0 2025-05-30 11:01:09.637 info List of port: [{"path":"/dev/ttyUSB0","manufacturer":"Itead","serialNumber":"06e595039338ef118eed357af3d9b1e5","pnpId":"usb-Itead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_V2_06e595039338ef118eed357af3d9b1e5-if00-port0","vendorId":"10c4","productId":"ea60"},{"path":"/dev/ttyAMA0"}]Grüße
-
@asgothian Moin und danke für die Hilfe.
Scan wurde mit Error abgebrochen.
Festgestellt das Firmware alt war mit 6.x.x. update auf 7.4.4 durchgeführt.
Adaptereinstellungen IOB angepasst.
SL EFR32 (EMBER)
Quelle Firmwareupdate
ncp-uart-sw_EZNet7.4.4_V1.0.0 (1)Neustart des System.
Adapter Gestartet (alles Grün)
Meldung System IOBzigbee.0 2025-05-30 10:49:10.426 warn ELEVATED:I02 (8117) value generated '10' from device 00124b00292843c9 for 'Link quality' zigbee.0 2025-05-30 10:49:10.426 warn ELEVATED:I01 (8117) message received '{"linkquality":10}' from device 00124b00292843c9 type 'SNZB-02' zigbee.0 2025-05-30 10:49:10.425 warn ELEVATED:I02 (8117) value generated 'true' from device 00124b00292843c9 for 'Available' zigbee.0 2025-05-30 10:49:10.424 warn ELEVATED:I01 (8117) message received '{"available":true}' from device 00124b00292843c9 type 'SNZB-02' zigbee.0 2025-05-30 10:49:09.458 info debug devices set to ["00124b00292843c9"] zigbee.0 2025-05-30 10:49:09.428 info Zigbee started zigbee.0 2025-05-30 10:49:09.425 info Currently 1 devices are joined: zigbee.0 2025-05-30 10:49:09.424 info 0x00124b00292843c9 (addr 39685): SNZB-02 - SONOFF Temperature and humidity sensor (EndDevice) zigbee.0 2025-05-30 10:49:09.353 info Unable to disable LED, unsupported function. zigbee.0 2025-05-30 10:49:09.350 info Zigbee-Herdsman started successfully with Coordinator firmware version: {"type":"EmberZNet","meta":{"ezsp":13,"revision":"7.4.4 [GA]","build":0,"major":7,"minor":4,"patch":4,"special":0,"type":170}} zigbee.0 2025-05-30 10:49:07.347 info Starting Zigbee-Herdsman zigbee.0 2025-05-30 10:49:07.345 info Installed Version: iobroker.zigbee@2.0.5 (Converters 23.6.0 Herdsman 3.5.2) zigbee.0 2025-05-30 10:49:07.285 info Starting Adapter npm ... zigbee.0 2025-05-30 10:49:07.283 info --- creating device debug --- zigbee.0 2025-05-30 10:49:07.277 info delete old Backup files. keep only last 10 zigbee.0 2025-05-30 10:49:07.262 info --> transmitPower : normal zigbee.0 2025-05-30 10:49:07.252 info init localConfig zigbee.0 2025-05-30 10:49:07.223 info starting. Version 2.0.5 in /opt/iobroker/node_modules/iobroker.zigbee, node: v20.19.2, js-controller: 7.0.6Reconfig
zigbee.0 2025-05-30 10:56:05.460 info DeviceConfigure successful 0x00124b00292843c9 SNZB-02 zigbee.0 2025-05-30 10:56:00.622 info Configuring 0x00124b00292843c9 SNZB-02 zigbee.0 2025-05-30 10:55:46.758 info List of port: [{"path":"/dev/ttyUSB0","manufacturer":"Itead","serialNumber":"06e595039338ef118eed357af3d9b1e5","pnpId":"usb-Itead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_V2_06e595039338ef118eed357af3d9b1e5-if00-port0","vendorId":"10c4","productId":"ea60"},{"path":"/dev/ttyAMA0"}]Sensor keine Veränderung auch nach Reconfig
DEIN VORSCHLAG SCANNEN DER NW
Also das ist bei beiden Installationen.
Scan startet und bricht mit Error Popup ab.
Fehlermeldung IOBroker
zigbee.0 2025-05-30 11:01:26.503 error Failed to scan channels Error: {"target":0,"apsFrame":{"profileId":0,"clusterId":56,"sourceEndpoint":0,"destinationEndpoint":0,"options":4416,"groupId":0,"sequence":58},"zdoResponseClusterId":32824} timed out after 15000ms at Object.start (/opt/iobroker/node_modules/zigbee-herdsman/dist/adapter/ember/adapter/oneWaitress.js:133:23) at EmberOneWaitress.startWaitingFor (/opt/iobroker/node_modules/zigbee-herdsman/dist/adapter/ember/adapter/oneWaitress.js:152:47) at /opt/iobroker/node_modules/zigbee-herdsman/dist/adapter/ember/adapter/emberAdapter.js:1346:51 at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/dist/utils/queue.js:29:20) at async EmberAdapter.sendZdo (/opt/iobroker/node_modules/zigbee-herdsman/dist/adapter/ember/adapter/emberAdapter.js:1307:16) at async ZigbeeController.getChannelsEnergy (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:1186:32) at async Commands.getChannels (/opt/iobroker/node_modules/iobroker.zigbee/lib/commands.js:568:28) zigbee.0 2025-05-30 11:01:09.637 info List of port: [{"path":"/dev/ttyUSB0","manufacturer":"Itead","serialNumber":"06e595039338ef118eed357af3d9b1e5","pnpId":"usb-Itead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_V2_06e595039338ef118eed357af3d9b1e5-if00-port0","vendorId":"10c4","productId":"ea60"},{"path":"/dev/ttyAMA0"}]Grüße
@kaffler
Dein Zigbee Dongle kann die Kanäle gar nicht scannen, unterstützt es nicht. Das können nur die CC.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 -
@kaffler
Dein Zigbee Dongle kann die Kanäle gar nicht scannen, unterstützt es nicht. Das können nur die CC.@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.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
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.
-
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 Bitte die Logs vom Start des Adapters durchschauen - da gibt es Meldungen zu den externen Konvertern.
Es ist denkbar das durch das Update der ZHC Anpassungen an den externen Konvertern notwendig werden. Diese sind erst mit der 3.0.1 in den Adapter gezogen. Sollte das der Fall sein, gibt es 2 Optionen:
- manuelles anpassen der externen Konverter
- Update auf die 3.0.1 aus dem Latest. Dann bitte den dazu gehörigen Thread lesen und die Hinweise beachten.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@gaspode Bitte die Logs vom Start des Adapters durchschauen - da gibt es Meldungen zu den externen Konvertern.
Es ist denkbar das durch das Update der ZHC Anpassungen an den externen Konvertern notwendig werden. Diese sind erst mit der 3.0.1 in den Adapter gezogen. Sollte das der Fall sein, gibt es 2 Optionen:
- manuelles anpassen der externen Konverter
- Update auf die 3.0.1 aus dem Latest. Dann bitte den dazu gehörigen Thread lesen und die Hinweise beachten.
@asgothian said in [Verkaufe] Zigbee Bodenfeuchtesensor:
Bitte die Logs vom Start des Adapters durchschauen - da gibt es Meldungen zu den externen Konvertern.
2025-06-02 17:22:48.523 - info: zigbee.0 (27240) starting. Version 2.0.5 in C:/ioBroker/lonwolf/node_modules/iobroker.zigbee, node: v20.18.2, js-controller: 7.0.6 2025-06-02 17:22:48.567 - warn: zigbee.0 (27240) trying to add "fz = require(../zigbee-herdsman-converters/converters/fromZigbee)" to sandbox 2025-06-02 17:22:48.569 - error: zigbee.0 (27240) Sandbox error: Cannot find module '../zigbee-herdsman-converters/converters/fromZigbee' Require stack: - C:\ioBroker\lonwolf\node_modules\iobroker.zigbee\main.js 2025-06-02 17:22:48.570 - warn: zigbee.0 (27240) trying to add "tz = require(../zigbee-herdsman-converters/converters/toZigbee)" to sandbox 2025-06-02 17:22:48.571 - error: zigbee.0 (27240) Sandbox error: Cannot find module '../zigbee-herdsman-converters/converters/toZigbee' Require stack: - C:\ioBroker\lonwolf\node_modules\iobroker.zigbee\main.js 2025-06-02 17:22:48.571 - warn: zigbee.0 (27240) trying to add "exposes = require(../zigbee-herdsman-converters/lib/exposes)" to sandbox 2025-06-02 17:22:48.572 - error: zigbee.0 (27240) Sandbox error: Cannot find module '../zigbee-herdsman-converters/lib/exposes' Require stack: - C:\ioBroker\lonwolf\node_modules\iobroker.zigbee\main.js 2025-06-02 17:22:48.573 - warn: zigbee.0 (27240) trying to add "reporting = require(../zigbee-herdsman-converters/lib/reporting)" to sandbox 2025-06-02 17:22:48.573 - error: zigbee.0 (27240) Sandbox error: Cannot find module '../zigbee-herdsman-converters/lib/reporting' Require stack: - C:\ioBroker\lonwolf\node_modules\iobroker.zigbee\main.js 2025-06-02 17:22:48.577 - warn: zigbee.0 (27240) Trying to run sandbox for E:\iobroker\lonwolf\iobroker-data\zigbee_0\Flower_Neu.js 2025-06-02 17:22:48.590 - error: zigbee.0 (27240) Unable to apply converter from module: E:\iobroker\lonwolf\iobroker-data\zigbee_0\Flower_Neu.js - the code does not run: ReferenceError: exposes is not definedWürde ungerne auf Version drei gehen, kannst du mir auf die Sprünge helfen?
Das ist die Datei für den externen Konverter:
Flower_Neu.js -
@asgothian said in [Verkaufe] Zigbee Bodenfeuchtesensor:
Bitte die Logs vom Start des Adapters durchschauen - da gibt es Meldungen zu den externen Konvertern.
2025-06-02 17:22:48.523 - info: zigbee.0 (27240) starting. Version 2.0.5 in C:/ioBroker/lonwolf/node_modules/iobroker.zigbee, node: v20.18.2, js-controller: 7.0.6 2025-06-02 17:22:48.567 - warn: zigbee.0 (27240) trying to add "fz = require(../zigbee-herdsman-converters/converters/fromZigbee)" to sandbox 2025-06-02 17:22:48.569 - error: zigbee.0 (27240) Sandbox error: Cannot find module '../zigbee-herdsman-converters/converters/fromZigbee' Require stack: - C:\ioBroker\lonwolf\node_modules\iobroker.zigbee\main.js 2025-06-02 17:22:48.570 - warn: zigbee.0 (27240) trying to add "tz = require(../zigbee-herdsman-converters/converters/toZigbee)" to sandbox 2025-06-02 17:22:48.571 - error: zigbee.0 (27240) Sandbox error: Cannot find module '../zigbee-herdsman-converters/converters/toZigbee' Require stack: - C:\ioBroker\lonwolf\node_modules\iobroker.zigbee\main.js 2025-06-02 17:22:48.571 - warn: zigbee.0 (27240) trying to add "exposes = require(../zigbee-herdsman-converters/lib/exposes)" to sandbox 2025-06-02 17:22:48.572 - error: zigbee.0 (27240) Sandbox error: Cannot find module '../zigbee-herdsman-converters/lib/exposes' Require stack: - C:\ioBroker\lonwolf\node_modules\iobroker.zigbee\main.js 2025-06-02 17:22:48.573 - warn: zigbee.0 (27240) trying to add "reporting = require(../zigbee-herdsman-converters/lib/reporting)" to sandbox 2025-06-02 17:22:48.573 - error: zigbee.0 (27240) Sandbox error: Cannot find module '../zigbee-herdsman-converters/lib/reporting' Require stack: - C:\ioBroker\lonwolf\node_modules\iobroker.zigbee\main.js 2025-06-02 17:22:48.577 - warn: zigbee.0 (27240) Trying to run sandbox for E:\iobroker\lonwolf\iobroker-data\zigbee_0\Flower_Neu.js 2025-06-02 17:22:48.590 - error: zigbee.0 (27240) Unable to apply converter from module: E:\iobroker\lonwolf\iobroker-data\zigbee_0\Flower_Neu.js - the code does not run: ReferenceError: exposes is not definedWürde ungerne auf Version drei gehen, kannst du mir auf die Sprünge helfen?
Das ist die Datei für den externen Konverter:
Flower_Neu.js@gaspode sagte in [Verkaufe] Zigbee Bodenfeuchtesensor:
Würde ungerne auf Version drei gehen
warum nicht?
läuft bei mir schon ewig und stabil....oder ist das, weil du Windows hast :duckundwech:
EDIT:
Hab das mal hierhin geschobenkein 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 -
-
@gaspode sagte in [Verkaufe] Zigbee Bodenfeuchtesensor:
Würde ungerne auf Version drei gehen
warum nicht?
läuft bei mir schon ewig und stabil....oder ist das, weil du Windows hast :duckundwech:
EDIT:
Hab das mal hierhin geschoben@homoran said in [Verkaufe] Zigbee Bodenfeuchtesensor:
warum nicht?
Weil ich im Moment keine Zeit habe, mir das alles durch zu lesen, ich will mir nix kaputt machen. An Windows liegt's sicher nicht. ;)
Ich hab auf den ersten Blick ehrlich gesagt nicht 100%ig verstanden, was ich beim Umstieg auf Version 3 alles tun muss. Ich hab keinen blassen Schimmer von der Zigbee Funktionsweise, ich bin da nur doofer Anwender.
-
@gaspode said in Tester für Zigbee Adapter 2.0.x gesucht:
Weil ich im Moment keine Zeit habe, mir das alles durch zu lesen, ich will mir nix kaputt machen. An Windows liegt's sicher nicht. ;)
Ich hab auf den ersten Blick ehrlich gesagt nicht 100%ig verstanden, was ich beim Umstieg auf Version 3 alles tun muss. Ich hab keinen blassen Schimmer von der Zigbee Funktionsweise, ich bin da nur doofer Anwender.
Der Umstieg von iobroker.zigbee 1.x auf 2.x ist der "böse" Sprung, danach müssen gfs. Skripte und Datenpunkte umkonfiguriert / nachgezogen werden. Der Sprung von 2.x auf 3.x ist da wesentlich schmerzfreier, beachten muss man einzig den Haken in den Adapter-Einstellungen, den man jetzt nach dem Upgrade einmalig setzen muss.
-
@asgothian said in [Verkaufe] Zigbee Bodenfeuchtesensor:
Bitte die Logs vom Start des Adapters durchschauen - da gibt es Meldungen zu den externen Konvertern.
2025-06-02 17:22:48.523 - info: zigbee.0 (27240) starting. Version 2.0.5 in C:/ioBroker/lonwolf/node_modules/iobroker.zigbee, node: v20.18.2, js-controller: 7.0.6 2025-06-02 17:22:48.567 - warn: zigbee.0 (27240) trying to add "fz = require(../zigbee-herdsman-converters/converters/fromZigbee)" to sandbox 2025-06-02 17:22:48.569 - error: zigbee.0 (27240) Sandbox error: Cannot find module '../zigbee-herdsman-converters/converters/fromZigbee' Require stack: - C:\ioBroker\lonwolf\node_modules\iobroker.zigbee\main.js 2025-06-02 17:22:48.570 - warn: zigbee.0 (27240) trying to add "tz = require(../zigbee-herdsman-converters/converters/toZigbee)" to sandbox 2025-06-02 17:22:48.571 - error: zigbee.0 (27240) Sandbox error: Cannot find module '../zigbee-herdsman-converters/converters/toZigbee' Require stack: - C:\ioBroker\lonwolf\node_modules\iobroker.zigbee\main.js 2025-06-02 17:22:48.571 - warn: zigbee.0 (27240) trying to add "exposes = require(../zigbee-herdsman-converters/lib/exposes)" to sandbox 2025-06-02 17:22:48.572 - error: zigbee.0 (27240) Sandbox error: Cannot find module '../zigbee-herdsman-converters/lib/exposes' Require stack: - C:\ioBroker\lonwolf\node_modules\iobroker.zigbee\main.js 2025-06-02 17:22:48.573 - warn: zigbee.0 (27240) trying to add "reporting = require(../zigbee-herdsman-converters/lib/reporting)" to sandbox 2025-06-02 17:22:48.573 - error: zigbee.0 (27240) Sandbox error: Cannot find module '../zigbee-herdsman-converters/lib/reporting' Require stack: - C:\ioBroker\lonwolf\node_modules\iobroker.zigbee\main.js 2025-06-02 17:22:48.577 - warn: zigbee.0 (27240) Trying to run sandbox for E:\iobroker\lonwolf\iobroker-data\zigbee_0\Flower_Neu.js 2025-06-02 17:22:48.590 - error: zigbee.0 (27240) Unable to apply converter from module: E:\iobroker\lonwolf\iobroker-data\zigbee_0\Flower_Neu.js - the code does not run: ReferenceError: exposes is not definedWürde ungerne auf Version drei gehen, kannst du mir auf die Sprünge helfen?
Das ist die Datei für den externen Konverter:
Flower_Neu.js@gaspode Schau mal bitte nach wo sich die Dateien
/lib/reporting.jsund,converters/toZigbee.jsundconverters/toZigbee.jsauf deinem System befinden. Da muss im Pfad meines Wissens irgendwo ein/disteingeschoben werden damit es geht.Wichtig - diese Anpassung muss nach dem Update auf 3.0.x wieder entfernt werden.
A.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@gaspode Schau mal bitte nach wo sich die Dateien
/lib/reporting.jsund,converters/toZigbee.jsundconverters/toZigbee.jsauf deinem System befinden. Da muss im Pfad meines Wissens irgendwo ein/disteingeschoben werden damit es geht.Wichtig - diese Anpassung muss nach dem Update auf 3.0.x wieder entfernt werden.
A.
OK, überzeugt. :blush: Danke euch. Ich versuche es dann morgen mit Version 3. Bin jetzt unterwegs.
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. Sonst bin ich eigentlich nicht so schwer von Begriff.
:grin: -
OK, überzeugt. :blush: Danke euch. Ich versuche es dann morgen mit Version 3. Bin jetzt unterwegs.
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. Sonst bin ich eigentlich nicht so schwer von Begriff.
:grin:@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.
ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
"Shit don't work" ist keine Fehlermeldung, sondern ein Fluch. -
@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.
Support us
749
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge