ZigBee Probleme mit dem CC2531 - irgendwie behebbar??
-
Stimmt beides. Sowohl Dirk wie auch die Mischung. Ich muss gestehen das ich so viele unterschiedliche Ideen bekommen habe das ich nur noch verwirrt bin. Zudem ist keine Antwort vollständig (bis auf Deine)
- 49-custom.rules gelöscht
- lsbusb -vvv
-
50-myusb.rules erstellt
-
chmod o+rw /dev/ttyACM0
-
udevadm control --reload
-
Zusätzlich habe ich in der LXC 130.conf folgendes stehen
- Neustart des LXC 130 (iobroker)
- Im LXC Container: ls -l /dev/ttyA*
So weit war ich schon des öfteren, nur nach einiger Zeit haben sich die Rechte von /dev/ttyACM0 geändert.
-
Du müsstest noch deine lxc config Datei wieder so anpassen bevor du die Änderungen von drozmotix übernommen hast.
Du brauchst die zwei Einträge wie im Coldcorner Tutorial beschrieben.
Ansonsten habe ich noch folgendes per Google gefunden:
https://maltekueppers.de/dc/index.php?post/2020/12/02/Conbee-II-Stick-im-Proxmox-LXC-Container
Hier ist zwar rede von der Deconz Software, aber vielleicht hängt das auch mit irgendeiner Eigenart vom Conbee II zusammen.
Du kannst ja mal die zwei Befehle von dem Blog Eintrag testen, vorher vielleicht einen Snapshot erstellen damit die Änderungen auch ohne Probleme rückgängig machen kannst.
-
Danke , mache ich gleich. Ich habe jetzt über 30 Min keine Veränderung der /dev/ttyACM0 gesehen. Aber zum testen mal kurz einen disconnect des USB Stick simuliert indem ich ihn gezogen habe. Und siehe da, die Rechte von /dev/ttyACM0 sind weg und mein iobroker kann nicht mehr zugreifen. evtl. liegt da mein Problem. Ich hätte schon erwarte das nach USB Verlust der Port sich automatisch wieder mit allen o+rw Rechten in den LXC Container verbindet.
LXC Container:
In der pve selber hat /dev/ttyACM0 noch alle Rechte.
-
@tenno2k5 sagte in ZigBee Probleme mit dem CC2531 - irgendwie behebbar??:
Hier ist zwar rede von der Deconz Software, aber vielleicht hängt das auch mit irgendeiner Eigenart vom Conbee II zusammen
Das ist eine Zusatzsoftware für den Conbee Stick die aber nicht nutze.
-
Mir ist gerade noch eine andere Idee gekommen, erscheint auf deinem Proxmox host eine Ausgabe mit folgendem Befehl:
ls /dev/ttyUSB* -
@tenno2k5 sagte in ZigBee Probleme mit dem CC2531 - irgendwie behebbar??:
Mir ist gerade noch eine andere Idee gekommen, erscheint auf deinem Proxmox host eine Ausgabe mit folgendem Befehl:
ls /dev/ttyUSB*gibt es leider nicht.
-
Ich glaube ich versuche doch mein Glück mit Ser2Net. Wenn dir noch etwas einfallen sollte, immer her damit
Ich kann einfach nicht verstehen das ich der einzige mit diesem Problem sein soll. -
@tenno2k5 sagte in ZigBee Probleme mit dem CC2531 - irgendwie behebbar??:
Du brauchst die zwei Einträge wie im Coldcorner Tutorial beschrieben.
erledigt, aber ohne erkennbare Besserung
-
Ja ich hätte noch folgendes gefunden:
https://monach.us/automation/connecting-zwave-stick-under-lxc/
Entspricht auf jeden Fall genau deiner Fehlerbeschreibung.
Also wenn ich das Richtig verstanden habe musst du folgendermaßen vorgehen:cd /var/lib/lxc/DeineContainerIDmkdir devicescd devicesmknod -m 660 ttyACM0 c 166 0Und dann änderst du in deiner lxc config den Eintrag zu ttyACM0
lxc.mount.entry: /var/lib/lxc/DeineContainerID/devices/ttyACM0 dev/ttyACM0 none bind,optional,create=fileGrüße
TeNNo2k5 -
@tenno2k5 sagte in ZigBee Probleme mit dem CC2531 - irgendwie behebbar??:
lxc.mount.entry: /var/lib/lxc/DeineContainerID/devices/ttyACM0 dev/ttyACM0 none bind,optional,create=file
Hurra....!
Anfangs gab es noch Zugriffsprobleme:
Der Adapter kann noch nicht zugreifen.
Im LXC hat /dev/ttyACM0 jetzt dauerhaft (auch nach ziehen des USB) folgende Berechtigungen:
Ein Kleinigkeit musste noch auf dem pva (host) angepasst werden!
Richtig wäre wohl "mknod -m 666 ttyACM0 c 166 0" gewesen.
Nach der Änderung habe ich auch im LXC Container die richtigen Berechtigungen auf /dev/ttyACM0
Im Moment schaut es sehr sehr gut aus! Ich teste das im laufe der Woche weiter und melde mich hier mit dem Ergebnis.
Vorerst möchte ich dir herzlich Danken, ohne Dich hätte ich das nie hinbekommen! -
@TeNNo2k5 Nachdem es jetzt einige Tage problemlos lief ist gestern Abend mein iobroker gecrasht. Grund hierfür ist der unnatürliche Festplattenverbrauch. Ich habe kurzerhand die Festplatte im Proxmox von 16GB um 30GB auf 46GB (47,12GB wird angezeigt) vergrößert. Aber verstehen tue ich das nicht. Muss Dich leider erneut um einen Tipp bitten
-
@smarteshome2020 sagte in ZigBee Probleme mit dem CC2531 - irgendwie behebbar??:
ist der unnatürliche Festplattenverbrauch
wie kommst du dadrauf ?
-
@smarteshome2020
Keine Screenshots, kann man nicht draus kopieren.
94GB auf /dev/ttyACM0 gemountet ist auch Quark, würde ich sagen. -
Weil jetzt bereits 36GB verbraucht werden. Das bedeutet in nur 18h einen Anstieg um 20GB.
Ich vermute einen Zusammenhang wie ich /dev/ttyACM0 eingehängt habe. Siehe Link Text Das war aber die Lösung für mein vorheriges Problem. Das ganze Läuft in einem LXC Container unter Proxmox und der wird immer mit "root" und mit der Verzeichnisstruktur angelegt. Zudem komme ich per default nur über die Proxmox Konsole drauf. Ich schätze mal das heute Abend wieder Schluß ist da die Festplatte erneut voll ist.root@iobroker:/# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/pve-vm--130--disk--0 48G 37G 8.3G 82% / none 492K 4.0K 488K 1% /dev /dev/mapper/pve-root 94G 32G 59G 35% /dev/ttyACM0 tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 1.6G 88K 1.6G 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock root@iobroker:/# -
@smarteshome2020 sagte in ZigBee Probleme mit dem CC2531 - irgendwie behebbar??:
/dev/ttyACM0
Ist ein device, da wird kein ganzes Dateisystem draufgemountet.
Ich hab zwar keine Ahnung von Containergedöns, das sieht aber für mich falsch aus. -
@thomas-braun jep hast du sogar
recht@smarteshome2020 wie kommst du zu den angaben ?
-
@arteck sagte in ZigBee Probleme mit dem CC2531 - irgendwie behebbar??:
jep hast du sogar recht
Das ich keine Ahnung von Containern habe? Ja, Danke schön!
-
@arteck sagte in ZigBee Probleme mit dem CC2531 - irgendwie behebbar??:
@smarteshome2020 wie kommst du zu den angaben ?
Ich habe es wie weiter oben beschrieben gemacht. Ein "normales" Durchreichen des USB /dev/ttyACM0 hat immer wieder Probleme bereitet. Aus diesem Grund habe ich es so https://monach.us/automation/connecting-zwave-stick-under-lxc/ gemacht.
Auszug:
I created /var/lib/lxc/112/devices and then executed this:
mknod -m 660 ttyACM0 c 166 0
This gave me the correct character file. I then modified the container’s config file in /etc/pve/lxc:lxc.mount.entry: /var/lib/lxc/112/devices/ttyACM0 dev/ttyACM0 none bind,optional,create=file
After rebooting the container the mount works correctly. Time will tell if it survives the random reset issue. -
Hi,
/dev/mapper/pve-root 94G 32G 59G 35% /dev/ttyACM0Ist ok liegt an der bindung über mknod.
Setze mal bitte folgende Befehle ab, mich würde interessieren was den deine Disk so voll schreibt.
cd / for i in G M K do du -ah | grep [0-9]$i | sort -nr -k 1 done | head -n 11Grüße
TeNNo2k5 -
@tenno2k5
Danke, bin mir zwar nicht sicher ob ich den Befehl richtig ausgeführt habe, aber finde das Ergebnis trotzdem spannend.
Ich glaube fast das ich mir das Problem mit dem Backup selber eingebaut habe.du: cannot read directory './sys/fs/fuse/connections/42': Permission denied du: cannot read directory './sys/fs/fuse/connections/40': Permission denied du: cannot read directory './lost+found': Permission denied 37G . 35G ./opt/iobroker 35G ./opt 33G ./opt/iobroker/backups 22G ./opt/iobroker/backups/historyDB_2022_02_14-02_40_16_backupiobroker.tar.gz 4.7G ./opt/iobroker/backups/historyDB_2022_02_13-02_40_17_backupiobroker.tar.gz 4.1G ./opt/iobroker/backups/historyDB_2022_02_12-02_40_16_backupiobroker.tar.gz 1.6G ./opt/iobroker/node_modules 1.5G ./opt/iobroker/backups/historyDB_2022_02_11-02_40_15_backupiobroker.tar.gz 1.3G ./usr 0 ./sys/fs/cgroup/hugetlb.1GB.rsvd.max du: cannot read directory './dev/.lxc/sys/kernel': Permission denied du: cannot read directory './dev/.lxc/sys/power': Permission denied
