Zigbee/Conbee2 funktioniert nach Update nicht mehr (udev)

Marko1974

Eigentlich kann man nur hoffen, dass es im nächsten Update gefixed wird. Ehe ich erst mal rausgefunden habe, woran es überhaupt liegt.
Hab Proxmox mit nem Debian installiert. Früher mal nen Raspberry gehabt. Ich dachte erst, der reicht die Ports nicht durch. Durch forschen bin ich erstmal zu diesem Thread gelangt. Ich habe aber einfach nur wie @MandreasB hier beschrieben hat die 60-serial.rules eingefügt.
Ich mache jetzt so lange kein Update bis ihr sagt, es funktioniert wieder. Glaube nämlich wenn ich jetzt nochmal rumfingere, hinterher wieder einzelne Lampen oder Sensoren weg sind. Die Variante hat es bei mir am schnellsten wieder zum laufen gebracht.

@markus-schlösser said in Zigbee/Conbee2 funktioniert nach Update nicht mehr (udev):

@mandreasb

Habe gestern den Abend zugebracht, die Lichter im Haus wieder zum leuchten zu bringen :-)

Ich habe eine Lösung ohne Downgrade des Paketes gesucht:

Nach Update auf debian 11.7 und anschließendem reboot (wegen kernel-update) geht deconz nicht mehr, auf der Konfigurationsseite
http://192.168.x.y:81/pwa/settings-gateway2.html
wird weder Hersteller, noch Produkt oder Firmware-Version angezeigt. Der deconz-Server bekommt also keine Verbindung zum ConBeeII-Stick.

Ursache

Update von udev/stable 247.3-7+deb11u1 auf udev/stable 247.3-7+deb11u2

danach wird der von deconz benötigte symbolische Link nicht mehr angelegt.
ls -l /dev/serial/by-id/
insgesamt 0
drwxr-xr-x 2 root root 60  2. Mai 21:01 .
drwxr-xr-x 4 root root 80  2. Mai 21:01 ..
lrwxrwxrwx 1 root root 13  2. Mai 21:01 usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2252411-if00 -> ../../ttyACM0
Lösung

Die Datei
/usr/lib/udev/rules.d/60-serial.rules
mit folgendem Inhalt anlegen:
# do not edit this file, it will be overwritten on update
ACTION=="remove", GOTO="serial_end"
SUBSYSTEM!="tty", GOTO="serial_end"

SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb"
SUBSYSTEMS=="pci", ENV{ID_BUS}=="", ENV{ID_BUS}="pci", \
  ENV{ID_VENDOR_ID}="$attr{vendor}", ENV{ID_MODEL_ID}="$attr{device}", \
  IMPORT{builtin}="hwdb --subsystem=pci"

# /dev/serial/by-path/, /dev/serial/by-id/ for USB devices
KERNEL!="ttyUSB[0-9]*|ttyACM[0-9]*", GOTO="serial_end"

SUBSYSTEMS=="usb-serial", ENV{.ID_PORT}="$attr{port_number}"

IMPORT{builtin}="path_id"
ENV{ID_PATH}=="?*", ENV{.ID_PORT}=="", SYMLINK+="serial/by-path/$env{ID_PATH}"
ENV{ID_PATH}=="?*", ENV{.ID_PORT}=="?*", SYMLINK+="serial/by-path/$env{ID_PATH}-port$env{.ID_PORT}"

ENV{ID_BUS}=="", GOTO="serial_end"
ENV{ID_SERIAL}=="", GOTO="serial_end"
ENV{ID_USB_INTERFACE_NUM}=="", GOTO="serial_end"
ENV{.ID_PORT}=="", SYMLINK+="serial/by-id/$env{ID_BUS}-$env{ID_SERIAL}-if$env{ID_USB_INTERFACE_NUM}"
ENV{.ID_PORT}=="?*", SYMLINK+="serial/by-id/$env{ID_BUS}-$env{ID_SERIAL}-if$env{ID_USB_INTERFACE_NUM}-port$env{.ID_PORT}"

LABEL="serial_end"
Danach noch
udevadm control --reload && udevadm trigger -v
Bei mir funktioniert der trigger-Befehl nicht richtig, also einmal den ConBeeII abziehen, 10 Sekunden warten und wieder anstecken.

Danach noch
systemctl restart deconz.service
und auf der Phoscon-Konfigurationsseite (s.o.) werden wieder alle Informationen angezeigt, d.h. der deconz-Server hat wieder eine Verbindung zum ConBeeII-Stick.
Die Lösung überlebt den reboot, aber wahrscheinlich nicht das nächste Update :-)
Vielleicht hilft es jemand...

Thomas Braun

@marko1974 sagte in Zigbee/Conbee2 funktioniert nach Update nicht mehr (udev):

Ich mache jetzt so lange kein Update bis ihr sagt, es funktioniert wieder.

Installier einfach eine Version die funktioniert oder setze die funktionierende Version auf hold. Ist doch im ersten Posting wunderbar erklärt.

Eine funktionierende Version über die Standard-Repos erwarte ich erst mit dem nächsten PointRelease.

Marko1974

@thomas-braun wann kommt dieses release der erfahrung nach?

Thomas Braun

@marko1974

Wenn es fertig ist. Meist so alle zwei Monate, es dürfte also bald eine Version 11.8 geben.
https://wiki.debian.org/DebianBullseye

Tip am Rande: Die aktuelle Stable 'Bookworm' hat das defekte Paket auch nicht an Bord.

Marko1974

@thomas-braun Ich will nicht wieder alles vermurksen. Kann ich von Bullseye einfach auf Bookworm? Ja kann ich

Thomas Braun

@marko1974

Ob du das kannst weiß ich nicht.
Generell ist es möglich.

Ich hab dazu auch einen Guide geschrieben.

ticaki

Ich bin wegen diesem Problem auf Zigbee2mqtt gewechselt und bis auf das fehlende hue läufts irgendwie "schneller".

Marko1974

@ticaki nunja...hue brauche ich da leider. Zu bookworm...das hab ich schon auf meinem Raspberry laufen, das steuert aber da auch keine komplette Hausautomation.
Gut unter Proxmox könnte ich ja n snapshot machen und einfach probieren.
Glaube sogar, dass ich das nach deiner Anleitung gemacht habe.
kommt mir so bekannt vor

ticaki

@marko1974
Ich auch, bekommt man über Mqtt ist nicht für jeden was.

Marko1974

@ticaki ich hab da eigentlich nur eine Lampe auf dem Balkon drin, die als Reichweitenverstärker dient.

So...ich kann es ja nicht lassen....gerade mache ich das Upgrade auf Bookworm

Während der Installation habe ich ne Menge von diesen Meldungen

dpkg: Warnung: Altes Verzeichnis »/var/lib/fwupd« kann nicht gelöscht werden: Da                                                                    s Verzeichnis ist nicht leer

dpkg: Fehler beim Bearbeiten des Paketes ca-certificates-java (--configure):
 »installiertes post-installation-Skript des Paketes ca-certificates-java«-Unterprozess gab den Fehlerwert 1 zurück
default-jre-headless (2:1.17-74) wird eingerichtet ...
tasksel (3.73) wird eingerichtet ...
task-ssh-server (3.73) wird eingerichtet ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openjdk-17-jre-headless:amd64:
 openjdk-17-jre-headless:amd64 hängt ab von ca-certificates-java (>= 20190405~); aber:
  Paket ca-certificates-java ist noch nicht konfiguriert.

dpkg: Fehler beim Bearbeiten des Paketes openjdk-17-jre-headless:amd64 (--configure):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert
tasksel-data (3.73) wird eingerichtet ...
task-desktop (3.73) wird eingerichtet ...
task-german-desktop (3.73) wird eingerichtet ...
task-german (3.73) wird eingerichtet ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openjdk-17-jre:amd64:
 openjdk-17-jre:amd64 hängt ab von openjdk-17-jre-headless (= 17.0.7+7-1~deb12u1); aber:
  Paket openjdk-17-jre-headless:amd64 ist noch nicht konfiguriert.

dpkg: Fehler beim Bearbeiten des Paketes openjdk-17-jre:amd64 (--configure):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von default-jre:
 default-jre hängt ab von openjdk-17-jre; aber:
  Paket openjdk-17-jre:amd64 ist noch nicht konfiguriert.

dpkg: Fehler beim Bearbeiten des Paketes default-jre (--configure):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert
task-gnome-desktop (3.73) wird eingerichtet ...

aber ich bin damit hier im falschen Thread.,..

MalleRalle

Moin @ All
Weiss jemand ob es da auch einen aktuelleren udev Kandidaten gibt.
Hier `vergisst´ mein System auch alle Nasenlang meinen Stick.
Läuft auf einem RockPro64

apt policy udev
udev:
  Installiert:           245.4-4ubuntu3.22
  Installationskandidat: 245.4-4ubuntu3.22
  Versionstabelle:
 *** 245.4-4ubuntu3.22 500
        500 http://ports.ubuntu.com focal-updates/main arm64 Packages
        100 /var/lib/dpkg/status
     245.4-4ubuntu3.20 500
        500 http://ports.ubuntu.com focal-security/main arm64 Packages
     245.4-4ubuntu3 500
        500 http://ports.ubuntu.com focal/main arm64 Packages

Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.6 LTS
Release:	20.04
Codename:	focal

Thomas Braun

@malleralle

Das dürfe ein anderes Problem sein.
Ich würde da zu einem aktuellen Debian raten, und wenn es schon schnubbelbuntu sein muss die aktuelle LTS-Version 22.04

LPTR

Ich bin gestern auch in die UDEV Falle getappt.
Zum Glück habe ich dann, wenn auch nur über google, diesen Thread gefunden.
Mit der Anleitung aus dem ersten Post konnte ich dann aber alles reparieren. Nur die Lösung zum 'Schlüsselfehler' passte nicht, es war ein anderer Schlüssel notwendig.

Grüße
Lars

mickym

@lptr Das mit dem Schlüssel ist ja auch nur ein Beispiel - man muss natürlich den Schlüssel eintragen, der im Log angemahnt wird. ;)

LPTR

@mickym Bin (noch) nicht so linux fit. ;-)

burberry

wow besten Dank für die Anleitung in Post 1
habe 32bit system und nun funktioniert wieder alles DANKE

DerJonas

Hallo Leute!

Ich bin neu im Game und spiele hin und wieder wenn ich Zeit habe ein bisschen mit ioBroker auf einem Raspberry 4 in Verbindung mit einem Sonoff Zigbee 3.0 USB Dongle herum.
Ein Freund hat mir bis jetzt schon bei vielen Fragen geholfen, aber ich will ihn auch nicht ewig nerven und versuche auch selbst ein bisschen etwas zu lernen dabei.
Mein Ziel war eigentlich nur ein bisschen Außenbeleuchtung zu steuen, aber so weit bin ich noch nicht.
Ich war eigentlich noch ziemlich am Anfang, als ich mir mit dem Update das Problem eingehandelt habe und es hat lange gedauert, bis ich wieder alles am laufen hatte... Die ganze Rechte-Thematik ist für mich noch sehr verwirrend.
Jetzt kommt mein Problem! :-)
Seit dem Update funktioniert mein Sonoff USB Stick nicht mehr! Er wird zwar im System wieder erkannt (unter /serial/by-id/ gelistet), aber die Zigbee-Instanz schaltet unter "Verbunden mit Gerät oder Dienst" nicht mehr auf grün.
Ich habe testweise einen CC2531 über /dev/serial/by-id/ eingebunden und der läuft!
Kann es sein, dass ic mir mit dem ganzen herumgeteste des Sonoff-Stick zerschossen habe?
Hat jemand schon von solchen Problemen gehört?
Vielen Dank und beste Grüße!

Jonas

DJMarc75

@derjonas sagte in Zigbee/Conbee2 funktioniert nach Update nicht mehr (udev):

Seit dem Update

seit welchem update ?

Und so ohne Infos ist das Lesen aus der Glaskugel fast nicht machbar :)

https://forum.iobroker.net/topic/51555/hinweise-für-gute-forenbeiträge

Thomas Braun

@derjonas sagte in Zigbee/Conbee2 funktioniert nach Update nicht mehr (udev):

Kann es sein, dass ic mir mit dem ganzen herumgeteste

Wenn mann wüsste was mit 'herumgeteste' konkret gemeint ist...

Ist aber auch eine Frage für einen eigenen Thread.
Ausgaben des LogFiles wären dann dort auch hilfreich.

lukas.g · EDIT 29.5.2023

Ich habe ein ähnliches Problem mit meinem Hichi IR Lesegerät und wurde hierher verwiesen.
"proposed updates" werden nicht als neuer erkannt.
"backports" führt zu einem segmentation fault.
Ist dieser backport nicht kompatibel mit meinem Raspi Zero?
WARNUNG: Siehe unten!

proposed updates:

lukas@rpi-lg2:/etc/apt/sources.list.d $ apt policy udev
udev:
  Installed: 247.3-7+rpi1+deb11u2
  Candidate: 247.3-7+rpi1+deb11u2
  Version table:
 *** 247.3-7+rpi1+deb11u2 500
        500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages
        100 /var/lib/dpkg/status
     247.3-7+deb11u4 500
        500 http://deb.debian.org/debian bullseye-proposed-updates/main armhf Packages
lukas@rpi-lg2:/etc/apt/sources.list.d $ sudo apt -t bullseye-proposed-updates install udev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
udev is already the newest version (247.3-7+rpi1+deb11u2).
0 upgraded, 0 newly installed, 0 to remove and 19 not upgraded.

backports:

lukas@rpi-lg2:/etc/apt/sources.list.d $ sudo apt -t bullseye-backports install udev
[...hier wurden die Ausgaben teilweise überschrieben...]
See "systemctl status systemd-udevd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript udev, action "restart" failed.
● systemd-udevd.service - Rule-based Manager for Device Events and Files
     Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static)
     Active: activating (start) since Sat 2023-07-22 10:39:29 CEST; 121ms ago
TriggeredBy: ● systemd-udevd-kernel.socket
             ● systemd-udevd-control.socket
       Docs: man:systemd-udevd.service(8)
             man:udev(7)
   Main PID: 2989 ((md-udevd))
      Tasks: 1
        CPU: 49ms
     CGroup: /system.slice/systemd-udevd.service
             └─2989 (md-udevd)

Jul 22 10:39:29 rpi-lg2 systemd[1]: Starting Rule-based Manager for Device Events and Files...
Jul 22 10:39:29 rpi-lg2 systemd[1]: systemd-udevd.service: Main process exited, code=killed, status=11/SEGV
Jul 22 10:39:29 rpi-lg2 systemd[1]: systemd-udevd.service: Failed with result 'signal'.
Jul 22 10:39:29 rpi-lg2 systemd[1]: Failed to start Rule-based Manager for Device Events and Files.
Jul 22 10:39:29 rpi-lg2 systemd[1]: systemd-udevd.service: Scheduled restart job, restart counter is at 2.
Jul 22 10:39:29 rpi-lg2 systemd[1]: Stopped Rule-based Manager for Device Events and Files.
Jul 22 10:39:29 rpi-lg2 systemd[1]: Starting Rule-based Manager for Device Events and Files...
dpkg: error processing package udev (--configure):
 installed udev package post-installation script subprocess returned error exit status 1
Setting up libudev-dev:armhf (252.5-2~bpo11+1) ...
Processing triggers for libc-bin (2.31-13+rpt2+rpi1+deb11u5) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for initramfs-tools (0.140) ...
Errors were encountered while processing:
 udev
E: Sub-process /usr/bin/dpkg returned an error code (1)

Anschließend war das System kaputt. Ich werde es neu Aufsetzen und gleich das "hold" auf udev setzen...

Community Forum

NEWS

Zigbee/Conbee2 funktioniert nach Update nicht mehr (udev)

Ursache

Lösung

Ursache

Lösung

Support us

632

32.5k

81.6k

1.3m