NEWS
Zigbee wechsel von CC2531 zu CC2652P funktioniert nicht
-
- Adaptername: zigbee
- Link zu Adapterrepository: https://github.com/ioBroker/ioBroker.zigbee
- Adapterversion: 1.10.14
- js-controller Version: 7.0.6
- Admin Version: 7.4.10
- Hardwaresystem: Pi4
- Arbeitsspeicher: 4 GB
- Festplattenart: SD-Karte
- Betriebssystem: raspbian buster
- Nodejs-Version: 18.20.5
- NPM-Version: 10.8.2
- Installationsart: Skript
- Image, Docker genutzt: Nein
- Ort, Name der Imagedatei: ...
Liebes Forum,
Ich habe vom CC2531 zu CC2652P (Sonoff Zigbee 3.0 USB Dongle Plus) gewechselt.pi@raspberrypi4:~ $ ls -la /dev/serial/by-id/
insgesamt 0
drwxr-xr-x 2 root root 60 Feb 2 11:54 .
drwxr-xr-x 4 root root 80 Feb 2 11:54 ..
lrwxrwxrwx 1 root root 13 Feb 2 11:54 usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_8cdcbb53ef6aef11b281a4adc169b110-if00-port0 -> ../../ttyUSB0Ich habe nvbackup.json gelöscht mit sudo rm /opt/iobroker/iobroker-data/zigbee_0/nvbackup.json und in den Einstellungen /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_8cdcbb53ef6aef11b281a4adc169b110-if00-port0 eingetragen.
Trotzdem kommt immer
Error
You need save and run adapter before pairing!Im Log steht Starting zigbee-herdsman problem : "Error Resource temporarily unavailable Cannot lock port"
Deshalb habe ich sudo chmod 666 /dev/ttyUSB0 versucht. Ohne Erfolg
Könntet ihr mir bitte weiterhelfen?
Andi
-
@andi2308 Ich habe alle IDs beibehalten. Ist das vielleicht der Fehler? Im Log steht auch
Starting zigbee-herdsman problem : "network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby (Error: AREQ - ZDO - stateChangeInd after 60000ms\n at Object.start (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/waitress.ts:59:23)\n at ZnpAdapterManager.beginCommissioning (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:370:31)\n at ZnpAdapterManager.start (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:91:21)\n at ZStackAdapter.start (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:158:16)\n at Controller.start (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/controller.ts:137:29)\n at ZigbeeController.start (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:133:13)\n at Zigbee.doConnect (/opt/iobroker/node_modules/iobroker.zigbee/main.js:316:13))" -
@andi2308 sagte in Zigbee wechsel von CC2531 zu CC2652P funktioniert nicht:
Betriebssystem: raspbian buster
Nodejs-Version: 18.20.5Beides zu alt, muss beides auf Stand gebracht werden.
Ja, das ist unabhängig von deinem Kampf mit zigbee, aber mindestens als Grundlage für alles genauso richtig und wichtig. -
@andi2308 sagte in Zigbee wechsel von CC2531 zu CC2652P funktioniert nicht:
Deshalb habe ich sudo chmod 666 /dev/ttyUSB0 versucht. Ohne Erfolg
Quatsch, weil du in /dev/ gar nichts dauerhaft einzustellen hast.
-
@thomas-braun Danke, ist wahrscheinlich besser alles auf einer 2. SD-Karte mal neu zu machen. Kann man auf der neuen Installation das Backup ohne Zigbee wiederherstellen oder besser alles neu? Brauche eigentlich nur Vis und meine Skripts.
-
- so gepostet ist das log unlesbar. Bitte code-tags nutzen.
- durch das löschen der nvbackup.json (und nicht der Shepherd.dB) hast du diesen Fehler erzeugt.
Du hast 2 Optionen (3);
- Adapter anhalten. nvbackup wiederherstellen, Adapter starten
- Adapter anhalten, Shepherd.dB und nvbackup.json löschen, Adapter starten, alle Geräte erneut anlernen
- (erst das machen was @Thomas-Braun geschrieben hat - wird aber am Fehler nichts ändern)
A.
-
@asgothian
Danke dir. Ich habe auf https://github.com/ioBroker/ioBroker.zigbee/blob/master/docs/de/readme.md gelesen, man solle nvbackup.json löschen.Also nvbackup.json und shepherd.dB nicht löschen beim Upgrade auf neueren Chipsatz.
-
@andi2308 sagte in Zigbee wechsel von CC2531 zu CC2652P funktioniert nicht:
@asgothian
Danke dir. Ich habe auf https://github.com/ioBroker/ioBroker.zigbee/blob/master/docs/de/readme.md gelesen, man solle nvbackup.json löschen.Also nvbackup.json und shepherd.dB nicht löschen beim Upgrade auf neueren Chipsatz.
Das gilt für neu-Installationen, bei denen eine nvbackup.json ggf. Mit falschen Parametern angelegt wird. Wenn diese nach der Korrektur der Parameter nicht gelöscht wird gibt es Probleme.
A.