NEWS
SOLVED Gelöst: Zigbee Probleme nach Umzug auf NUC
-
Hallo,
ich ziehe gerade mein System auf einen Nuc um.
Bisher:
- Master auf Synology in Docker
- Slave auf RPI3 für zigbee
- Slave auf RPI3 für zwave
Neu:
- Alles auf Nuc (Proxmox und debian VM) https://forum.iobroker.net/topic/22387/anleitung-umstieg-raspi-multihost-auf-nuc-mit-proxmox-und-debian-vm
Ich habe erfolgreich die den Multihost aufgelöst:
- Instanzen auf Slave stoppen und auf Master verschieben
- Multihost disable auf Master
- Slave auf dem Master löschen
Dann ein Standard Backup erstellt und dieses auf dem Nuc restored.
Es läuft alles und auch die Instanzen sind bisher alle grün.
Ich kann jedoch die zigbee Geräte nicht erreichen.
Es sind alle Geräte wieder vorhanden, jedoch kommt eine Fehlermeldung z.B. beim Schalten eine Osram Plugzigbee.0 2019-12-07 20:12:45.487 error (1767) Zigbee cannot determine endpoint for '0x7cb03eaa00b07321'
Auch ein neustart der Instanz, eine ziehen des Sticks, oder laufenlassen des installations-fixer, hat geholfen:
Infos zum Stick: CC2531 ZigBee USB-Sick
zigbee.0 2019-12-07 20:13:45.351 info (1787) Shepherd ready. {"state":"Coordinator","channel":"11","panId":6754,"extPanId":[221,221,221,221,221,221,221,221],"ieeeAddr":"0x00124b0018ecdf5c","nwkAddr":0} zigbee.0 2019-12-07 20:13:45.350 info (1787) Zigbee-shepherd ready. Firmware version: 2.6.3 rev 20180815 zigbee.0 2019-12-07 20:13:45.350 info (1787) zigbee-shepherd started! zigbee.0 2019-12-07 20:13:43.954 info (1787) Reset coordinator zigbee.0 2019-12-07 20:13:43.940 info (1787) Queue is: true zigbee.0 2019-12-07 20:13:43.940 info (1787) Start on port: /dev/ttyACM0 channel 11 zigbee.0 2019-12-07 20:13:43.930 info (1787) starting. Version 0.11.5 in /opt/iobroker/node_modules/iobroker.zigbee, node: v10.17.0
-
Es funktioniert!!!
Folgendes hat geholfen:
- Stick entfernen
- Instanz stoppen
- shepherd.db kopiert
- fixer laufen lassen und die Rechte damit gerade gebogen
- Stick wieder eingesteckt
- Reboot der VM
- Start der Instanz
Ich glaube der wichtige Part war der Fixer und der Reboot der VM.
Freu, freu, freu, ... ich muss nicht meine 50+ Zigbee Geräte neu anlernen
-
@nis Ich hab nun nochmal die shepherd.db neu kopiert vom alten System.
Nun kommt eine weitere Fehlermeldung beim Starten der Instanzzigbee.0 2019-12-07 23:06:47.269 debug (3762) User stateChange zigbee.0.info.connection {"val":false,"ack":false,"ts":1575756407264,"q":0,"from":"system.adapter.zigbee.0","user":"system.user.admin","lc":1575756040550} zigbee.0 2019-12-07 23:06:47.268 debug (3762) User stateChange zigbee.0.info.pairingMessage {"val":"Error: Error while starting zigbee-shepherd!. Error: request timeout","ack":false,"ts":1575756407264,"q":0,"from":"system.adapter.zigbee.0" zigbee.0 2019-12-07 23:06:47.263 error (3762) Error while starting zigbee-shepherd!. Error: request timeout zigbee.0 2019-12-07 23:06:40.256 info (3762) Starting zigbee-shepherd zigbee.0 2019-12-07 23:05:40.254 info (3762) Error while starting zigbee-shepherd, attempting to fix... (takes 60 seconds) zigbee.0 2019-12-07 23:05:33.225 info (3762) Reset coordinator zigbee.0 2019-12-07 23:05:33.219 info (3762) Lib-Versions: ZShepherd 0.3.0, ZSConverters 10.2.7 zigbee.0 2019-12-07 23:05:33.211 info (3762) Queue is: true zigbee.0 2019-12-07 23:05:33.211 info (3762) Start on port: /dev/ttyACM0 channel 11 zigbee.0 2019-12-07 23:05:33.202 info (3762) starting. Version 0.11.5 in /opt/iobroker/node_modules/iobroker.zigbee, node: v10.17.0 host.iobroker 2019-12-07 23:05:31.903 info instance system.adapter.zigbee.0 started with pid 3762
-
Es funktioniert!!!
Folgendes hat geholfen:
- Stick entfernen
- Instanz stoppen
- shepherd.db kopiert
- fixer laufen lassen und die Rechte damit gerade gebogen
- Stick wieder eingesteckt
- Reboot der VM
- Start der Instanz
Ich glaube der wichtige Part war der Fixer und der Reboot der VM.
Freu, freu, freu, ... ich muss nicht meine 50+ Zigbee Geräte neu anlernen
-
@nis
So erging es mir auch bei meinem Slave Umzug vom RPI auf einen NUC... der VM Reboot hat bei mir geholfen.Eine Frage OT: Warum nutzt du einen RPI für Zigbee und einen weiteren für Zwave? Würde doch beides zusammen auf einem RPI funktionieren
-
@FredF kurz gesagt: war zu faul.
Ich hatte erst nur einen Slave mit zwave. Der lief wunderbar.
Dann habe ich zum Testen mit zigbee einen neuen Slave genommen. Ich wollte den zwave Slave nicht kaputt konfigurieren. Als der zweite Slave mit zigbee dann lief hab ich es einfach so gelassen mit zwei Slaves.
Es hätte ohne Probleme auf einem Slave funktioniert. -
@nis sagte in Gelöst: Zigbee Probleme nach Umzug auf NUC:
war zu faul.