Edomi in Proxmox LXC container.

[jonofe]

Ich weiss nicht ob das eine Loesung fuer dich darstellen wuerde, aber ich habe einen DS2490 an einem ESXi seit Jahren problemlos in Betrieb (an einer USB2 Buchse des Mainboards), dahinter haengt (noch) ein CommunityGate das damit arbeitet.

Ich muss mich korrigieren, hatte es wohl falsch in Erinnerung. Das Problem hatte damals der Kartenleser für meine HD+ Karte erzeugt und nicht der 1-wire USB Hostadapter.

Habe gerade nochmal an meinem ESXI nachgeschaut, mein DS9490 ist auch an einem USB2 Anschluss an die VM durchgereicht und dies funktioniert auch sehr zuverlässig. Also genau wie von Dir, Michael, beschrieben.

André, wenn Michaels Weg bei Dir nicht klappen sollte, funktioniert der VM-Lösung vielleicht bei Dir.

Ja, bei mir läuft ja ohnehin alles auf VMs.

[wintermute]

Wie bekommst du denn das USB-Gerät in die LXC übergeben?

Sorry, das war etwas OT von mir: ich hatte mich auf Andrés ESXi bezogen, ich nutze keine LXC Container kann da also nix zu sagen.

[bas29]

Ich habe hier nur einen simplen JeeLink-LaCrosse-868MHz Stick den ich an einen ioBroker Container übergebe.

Inhalt der /etc/udev/rules.d/99-usb-serial.rules

SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="LaCrosse", MODE="0666", GROUP="dialout"

Und Zeilen in Container Conf.

lxc.cgroup.devices.allow: c 188:* rwm
lxc.mount.entry: /dev/LaCrosse dev/LaCrosse none bind,optional,create=file

Übersteht Reboots vom Host bei wechselnden Ids. Beim Umstecken muss man allerdings einmal den Container neu starten.

[saegefisch]

wintermutejonofe war ja nicht wirklich OT, sondern rundet das Bild ab mit Alternativlösungen zum Thema... alles gut...

Aber ich kann nach 2 Tagen frustriertem forschen immerhin Erfolg melden - es ist am Ende wie immer ganz einfach:

Proxmox + 1-wire Busmaster DS2490:

• Wenngleich die Übergabe diverser USB-Geräte in einen LXC-Container offenbar gut und vielfältig funktioniert (Es gibt dazu genug Anleitungen, siehe auch oben bei bas29), so scheint der passtrough des 1-wire-Busmasters es einfach nicht zu wollen. Daher schient mir der Weg über eine VM statt LXC an dieser Stelle eine valide und sinnvolle Lösung
• WICHTIG: Warum auch Übergabe an die VM nicht funktionierte, inkl. unflushable VM, reboot des proxmox-Nodes, manchmal sogar per hartem Reset ist so einfach wie banal und im Nachhinein recht logisch: Wenn der Proxmox-Host den Busmaster erkennt, wird sein Kernel Modul geladen inkl. Aufbau einer lesbaren Verzeichnisstruktur der vom Busmaster erkannten Sensoren via ls -l /sys/bus/w1/devices/. Das muss verhinder werden, wenn der Busmaster in einer VM/Container funktionieren soll:

  sudo nano /etc/modprobe.d/blacklist.conf

# Disable auto loading of Dallas USB-1-wire adapter
blacklist ds2490

Nach einem anschließenden Reboot des Nodes funktioniert das alles dann ganz geschmeidig, die VMs fühlen sich so an, wie man das erwartet und der Host zickt nicht mehr rum. Und in der VM liefert dann ls -l /sys/bus/w1/devices/ auch Sensorinformationen.

--> In der VM war die Installation des owfs dann nach 10 Minuten erledigt.
Die Zeit bis hierhin war hartes und bitteres Lehrgeld... Am Ende bin ich aber froh über meine Hartnäckigkeit - weil ich einfach wusste, dass es gehen muss. Möge dieses Fazit anderen helfen, schneller zum Ziel zu kommen.

Ergänzung:
Proxmox + NUT (USV):

• Eine Lösung im LXC per USB-passthrough wäre wohl möglich nach Lösung des Busmaster-USB-Problems gegangen, aber bei genauerer Überlegung ergibt es erheblich mehr Sinn, NUT als Master direkt auf dem Proxmox-Host zu installieren, weil Proxmox natürlich zentral ist bei der Orchestrierung eines "geregelten Untergangs" bei Stromausfall. Im Proxmox-Forum gibt es genug klare Aussagen von von Mitarbeitern und Intensiv-Nutzern, dass dies durchaus gängige Praxis und best-practise ist. Mein ursprünglicher Gedanke, den Host so unberührt wie möglich zu lassen ist bei NUT einfach nicht sinnvoll; mindestens ein nut-client wäre es ohnehin geworden.
• Installation nach "Lehrbuch" rasch und völlig problemlos. Alle 3 QNAP-NAS konnten sich erfolgreich direkt als Slave anbinden.

[uzi10]

wie hast du das jetzt gemacht? Schritte nacheinander?
In einer Unbuntu VM??
Wäre toll, wenn du das zusammenschreiben könntest

[vento66]

Ich will ja nicht meckern, aber sind wir hier nicht arg OT?

[saegefisch]

nicht wirklich OT aus meiner Sicht, weil in der VM (VM auf Proxmox) ich per Script die ganzen 1-wire-Sensordaten per MQTT an Mosquitto (Docker in LXC auf Proxmox) sende, an denen sich meine edomi (prod; bare-metal) und edomi-DEV + edomi-Projekt (beide LXC auf Proxmox) bedienen. Geht auch nach influxDB + grafana (beide Docker in LXC auf Proxmox)... OT...kann ich nicht direkt erkennen... damit alles wie vor her geht auch mit Vollzug meines Server-.Umzugs auf Proxmox... und ich endlich mit funktionierenden Infrastruktur den edomi-Umzug auch abschließen kann... dann mach' ich auch wieder mehr LBS- und Visu-Gedöns...

uzi10 : VM mit Ubuntu-Server-ISO aufbauen (ich nehme immer LTS; derzeit 20.04)

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install qemu-guest-agent
sudo mkdir /mnt/1wire
sudo apt-get -y install owfs owserver
sudo nano /etc/owfs.conf

Zusammenfassung der nicht auskommentierten Zeilen der conf:

! server: server = localhost:4304
server: usb = all
mountpoint = /mnt/1wire
allow_other
http: port = 2121
server: port = localhost:4304

reboot der VM, dann sollte http://<deine VM-IP>:2121 bereits die 1-Wire-Daten liefern.

[skyacer]

saegefisch
Wow. das sind ja gute Nachrichten. Hast du es nur in einer VM probiert oder auch in einem LXC?

Grüße

[saegefisch]

skyacer : was genau? Wen "es" der 1-wire-Busmaster ist, dann lautet die Antwort: VM. Nach dem ich tatsächlich abgekämpft den Grund für das mehrtägige nicht-klappen gefunden hatte, hatte ich mich bereits für VM entschieden und das ging auch wunderbar wie oben beschrieben; die VM liefert mir seit dem verlässlich alle 1-wire-Werte per MQTT. Passt für mich. Ist die einzige VM, der Rest ist bei mir alles LXC. Ich bin da kein Dogmatiker und finde die VM jetzt gar nicht falsch. Ich hatte anfangs nur gedacht, es würde alles per LXC gehen, weil nach meinem Verständnis ressourcenschonender. Ist halt nicht so <achselzuck>. Sicherheitstechnisch sehe ich das unkritisch, weil ich kritische Teile (z.B. ReverseProxy, Firewall) seit jeher auf dedizierter HW habe, die würde ich nie als LXC oder VM umsetzen wollen (weil ich Sorge hätte, dass ich was beim Einrichten übersehe; mache das ganze ja nur als "interessierter Laie"...)

Ob mit dem obigen Hinweis der pass-through des (im Vergleich zu anderen USB-Geräten) offenbar etwas komplexeren USB-Geräts in einen LXC-Container nun doch auch funktionieren würde bis zur sauberen Verarbeitung per owfs, habe ich nicht mehr versucht - mein Forscherdrang war nach der Zeit verflogen und wollte nur noch Ergebnis. Aber wenn Du magst, kannst Du gerne hier berichten...am besten von einem erfolgreichen Versuch mit Anleitung...

[trollmar]

Ergänzung:
Proxmox + NUT (USV):

• Eine Lösung im LXC per USB-passthrough wäre wohl möglich nach Lösung des Busmaster-USB-Problems gegangen, aber bei genauerer Überlegung ergibt es erheblich mehr Sinn, NUT als Master direkt auf dem Proxmox-Host zu installieren, weil Proxmox natürlich zentral ist bei der Orchestrierung eines "geregelten Untergangs" bei Stromausfall. Im Proxmox-Forum gibt es genug klare Aussagen von von Mitarbeitern und Intensiv-Nutzern, dass dies durchaus gängige Praxis und best-practise ist. Mein ursprünglicher Gedanke, den Host so unberührt wie möglich zu lassen ist bei NUT einfach nicht sinnvoll; mindestens ein nut-client wäre es ohnehin geworden.
• Installation nach "Lehrbuch" rasch und völlig problemlos. Alle 3 QNAP-NAS konnten sich erfolgreich direkt als Slave anbinden.

Ich habe dafür nen eigenen Raspberry genommen.
der schaut halt ob alle Geräte Runtergefahren sind bevor er die USV selbst aus macht. Muss nur noch die sdcard des Pi read only setzen