Conbee II, Firmware nicht verbunden
-
Hallo Gemeinde,
leider kämpfe ich auch einige Tage mit dem Problem.
Mein Phoscon läuft auf Port 8090, ansonsten hatte ich vor einigen Jahren dan Stick so installiert, wie damals vorgeschrieben. Da es nie Probleme gab, hab ich mich nicht mehr drum gekümmert. Sprich, ich weiß nicht mehr die genauen Installationsschritte von damals.Nach dem überfälligen Systemupgrade auf Version 11 war die Phosconfirmware nicht mehr verbunden, alles wie oben schon mehrfach beschrieben. Auf der Gataway-Seite steht eine definitiv neue Version: 2.22.02 / 19.9.2022
Es nützt auch nichts, das vor dem Systemupgrade erstellte Image einzulegen, offenbar wurde etwas am Stick geändert.
Das aktuelle System istapt policy udev udev: Installiert: 247.3-7+rpi1+deb11u2 Installationskandidat: 247.3-7+rpi1+deb11u2 Versionstabelle: *** 247.3-7+rpi1+deb11u2 500 500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages 100 /var/lib/dpkg/statusDann hab ich die oben verlinkten Schritte durchgeführt:
cd /tmp wget https://project-downloads.drogon.net/wiringpi-latest.deb sudo dpkg -i wiringpi-latest.deb sudo systemctl stop deconz wget https://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26780700.bin.GCFEs hat den Anschein, dass es keine Probleme gab. Trotzdem geht es nicht.
ls -la insgesamt 252 drwxrwxrwt 10 root root 4096 2. Sep 17:31 . drwxr-xr-x 23 root root 4096 1. Sep 15:02 .. -rw-r--r-- 1 pi pi 163244 16. Mai 2022 deCONZ_ConBeeII_0x26780700.bin.GCF drwxrwxrwt 2 root root 4096 2. Sep 15:17 .font-unix drwxrwxrwt 2 root root 4096 2. Sep 15:17 .ICE-unix drwx------ 2 pi pi 4096 2. Sep 15:17 runtime-pi drwx------ 3 root root 4096 2. Sep 15:17 systemd-private-427077883599423d9d2fff1d2d8b1bf4-systemd-logind.service-DUBK Bi drwx------ 3 root root 4096 2. Sep 15:17 systemd-private-427077883599423d9d2fff1d2d8b1bf4-systemd-timesyncd.service-B 0rH3i drwxrwxrwt 2 root root 4096 2. Sep 15:17 .Test-unix -rw-r--r-- 1 pi pi 52260 12. Apr 09:17 wiringpi-latest.deb drwxrwxrwt 2 root root 4096 2. Sep 15:17 .X11-unix drwxrwxrwt 2 root root 4096 2. Sep 15:17 .XIM-unixWarum bei mir bei li -la deutlich weniger aufgelistet wird, als bei @fkontakt oben, weiß ich nicht.
Es gibt bei mir auch keinen Ordner /dev/serial/by-id wie bei @Gabe oben, aber einen Ordner
/dev/serial/by-path Darin liegt eine Verknüpung auf eine Datei /dev/ttyACM0 die 0 byte groß ist.
Ansonsten auch:sudo GCFFlasher_internal -t 60 -d /dev/ttyACM0 -f deCONZ_ConBeeII_0x26780700.bin.GCF GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh retry, failedViele Grüße vom im Nebel stochernden DocAdams
-
Du fällst mit deinem 32bit-Bullseye darunter:
https://forum.iobroker.net/topic/65017/zigbee-conbee2-funktioniert-nach-update-nicht-mehr-udev
-
@thomas-braun sagte in Conbee II, Firmware nicht verbunden:
Du fällst mit deinem 32bit-Bullseye darunter:
https://forum.iobroker.net/topic/65017/zigbee-conbee2-funktioniert-nach-update-nicht-mehr-udev
Oha, das kannte ich noch nicht, danke.
-
Insbesondere den
EDIT 10.06.2023
beachten. -
Danke, da gibt es erst mal einiges zu lesen ...
Was mir auffällt, auch dort wird immer auf /dev/serial/by-id verwiesen.
Ich hab das nicht, aber /dev/serial/by-path.ls -l /dev/serial/by-path insgesamt 0 lrwxrwxrwx 1 root root 13 2. Sep 18:42 platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0 -> ../../ttyACM0Könnte ich_vorsorglich den Ordner by-path in by-id umbenennen? Oder bin ich jetzt zu naiv. Also völlig abgesehen von dem UDEV-Problem...
Noch einen Unterschied habe ich:
apt policy udev udev: Installiert: 247.3-7+rpi1+deb11u2 Installationskandidat: 247.3-7+rpi1+deb11u2 Versionstabelle: *** 247.3-7+rpi1+deb11u2 500 500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages 100 /var/lib/dpkg/status... armhf , bei den anderen steht arm64
Kann das eine bedeutung haben? -
@docadams Warum machst Du nicht, was im verlinkten Beitrag steht? Dann erledigt sich Dein Problem vermutlich von selbst.
Zur ersten Frage: Du siehst /dev/serial/by-id nicht, weil Du eben (noch) die fehlerhafte udev-Version deb11u2 hast (siehe Link). Da kannst Du auch nix von Hand umbenennen, das aktuelle Paket behebt den Fehler.Zur zweiten Frage: arm64 bezieht sich auf 64bit-Betriebssysteme. Da Du auf 32bit unterwegs bist, heisst das bei Dir armhf.
Wenn es Deine Hardware hergibt, könntest Du ja jetzt ein komplett frisches 64bit-Betriebssystem installieren, das Deconz-Backup einspielen und glücklich werden. Wenn es die Hardware nicht hergibt (Raspi X?) dann eben dem Link folgen, das für 32bit-Systeme durchführen und hoffen, dass 32bit-Systeme möglichst noch lange unterstützt werden.
Egal wie, um das Lesen und Abarbeiten der Punkte kommst Du nicht rum.
Gruss, Jürgen
-
Von dem Ganzen mal ab, updaten machste über Windows am Bequemsten.
https://flemmingss.com/how-to-update-conbee-conbee-ii-firmware-in-windows-10/
Stick in den Laptop und Anleitung folgen.
-
@haselchen Das war bei mir unter Linux noch nie nötig. Davon ab hätte ich gar kein Windows rumstehen. Unter Linux funktionieren die Firmware-Updates jedenfalls bei mir problemlos. Natürlich vorausgesetzt, der Unterbau passt.
Gruss, Jürgen
-
@docadams sagte in Conbee II, Firmware nicht verbunden:
Könnte ich_vorsorglich den Ordner by-path in by-id umbenennen?
NEIN! Fummel in den Tiefen des Systems nicht so grobschlächtig herum. Diese Dateien werden vom Kernel/udev angelegt, nicht durch hin- und herkopieren von irgendwas.
Du musst es gescheit beheben, Anleitung dazu kennst du schon, muss nur noch umgesetzt werden.
-
Die Anleitung ist halt so für Plug and Play gedacht.
Für Linux Cracks ist das natürlich kein Problem
Über die Windowsgeschichte ist das Ganze bei mir in 5min erledigt, da ich es als DAU einfach mag -
Ist in der Konsole genauso einfach. Die Anleitung ist nur eine andere.
-
Hängt mit Verlängerung an einer Synology.
So einfach ist es dann doch nicht
-
Das ist ja auch kein vollständiges Linux...
-
Ich wollte jetzt garnicht so eine Diskussion anstoßen
Ich hätte nicht gedacht, dass eben auch das ..by-id bzw. bypath Problem auch mit der UDEV zu tun haben könnte.
Ja, es ist ein RasPi4 4GB, aber die allererste ioBroker-Installation stammt von einem RasPi3, die nur umgezogen ist.Ich hatte es auch schon mal mit einem völlig neuem System und dann Umzug des ioBroker versucht. wäre tatsächlich die sauberste Lösung. Aber ich habe einfach nicht gepackt, die OWFS-Sensoren zum laufen bekommen. Dann kam zu der Zeit das böse C und ich habe es sein gelassen. Nur kurz zur Begründung...
