USB in Docker via neuer Container über Compose u.a. andere

[Chrisham]

@chrisham @chrisham @chrisham , @OliverIO @Marc-Berg ,:
Mal ein Zwischenstatus, dieser Thread und ihr habt mich ja schon länger be- und geleitet:

1.) Docker-Setup Allgemein: ich habe nun wirklich einen reifen Stand meines wiederherstellbaren Docker-Konglomerats erreicht, d.h. ich kann grundsätzlich das Setup jederzeit reproduzierbar wiederherstellen oder updaten mittels "Stack-" Mechanismus von Portainer. Es laufen alle Applikationen wieder wie zuvor (beim "handgestrickten" Setup), bis auf eine kleine Ausnahme, siehe Punkt 2.)

2.) Der Asterisk-Adapter im IOBroker kann immer noch nicht die Telefonanrufe über die Asterisk-Lib (jetzt auch verpackt in eigenen Docker-Container, d.h. modifizierter basierend auf andrius/asterisk:latest) noch nicht absetzen, s.o. Aber ich werde dazu jetzt einen eigenen Thread aufmachen, das passt jetzt nicht wirklich mehr hier her.

3.) USB-Verbindung: das war ja der eigentliche Ausgangsunkt dieses Threads. Prinzipiell müsste die USB-Verbindung hergestellt sein, allerdings scheint das Device (Smartmeter-Connector) noch nicht richtig zu senden. Da warte ich noch auf den Freischaltcode vom lokalen Energieversorger. Bis jetzt gibt es diese Fehlermeldung:

D.h. ich werde noch No. 3.) im Rahmen dieses Threads (hoffentlich) zum Abschluss bringen und dann diesen Thread schließen.

Vielen Dank euch allen, die ihr mich hier durchgeführt habt, ich habe sehr viel gelernt und bin in meinem Smarthome-System einen großen Schritt weiter gekommen.

[OliverIO]

@chrisham sagte in USB in Docker via neuer Container über Compose u.a. andere:

3.) USB-Verbindung: das war ja der eigentliche Ausgangsunkt dieses Threads

weiß nicht mehr so genau ob ich oder jemand anderes dazu schon was geschrieben hat.

als erstes musst du dir sicher sein, das das usb device auf dem host erkannt wurde
dann musst du schauen unter welchem pfad das device ansprechbar ist
diesen pfad kann man durchreichen
ich sehe, du hast in der device section auch etwas benannt
dann kannst du mal im container noch die gleichen untersuchungen machen, ob das betriebssystem im container das ebenfalls erkennt
falls nicht, kannst du im docker-compose eine ebene unterhalb der service-konfiguration die folgende option setzen

privileged: true

eigentlich hat docker genau dafür die device section eingeführt, damit docker weiß, es muss hier speziell mit umgehen, aber mal schauen was das bring.
aber wie gesagt, wenn das device im container nicht sichtbar ist, dann bringt auch die Erweiterung nicht.
evtl mal noch zum besseren verständnis, weil ich auch vergessen hab was das für ein usb device ist. bei start des containers, also start des betriebssystems im container, laufen die normalen scans nach angeschlossener hardware ab. wenn dann was erkannt wird, dann wird geschaut ob ein kernel treiber dafür da ist. wenn das spezielle hardware ist, dann kann sein, das da etwas fehlt und ebenfalls im container installiert werden muss.

was war das nochmal für ein device? dann kann man im internet schauen ob es sonst da probleme gibt.

[Chrisham]

@oliverio said in USB in Docker via neuer Container über Compose u.a. andere:

@chrisham sagte in USB in Docker via neuer Container über Compose u.a. andere:

3.) USB-Verbindung: das war ja der eigentliche Ausgangsunkt dieses Threads

weiß nicht mehr so genau ob ich oder jemand anderes dazu schon was geschrieben hat.

als erstes musst du dir sicher sein, das das usb device auf dem host erkannt wurde

Das Device auf dem Host sieht man hier:

Es ist also das Device

/dev/ttyUSB0

so wie dann auch im docker compose file auch verwendet unter devices:

    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0

dann musst du schauen unter welchem pfad das device ansprechbar ist

s.o.:

/dev/ttyUSB0

diesen pfad kann man durchreichen
ich sehe, du hast in der device section auch etwas benannt
dann kannst du mal im container noch die gleichen untersuchungen machen, ob das betriebssystem im container das ebenfalls erkennt

Innerhalb des Containers (IObroker container) sieht es dann so aus:

D.h. also auch dort ist es unter dem Pfad

/dev/ttyUSB0

erreichbar.

falls nicht, kannst du im docker-compose eine ebene unterhalb der service-konfiguration die folgende option setzen

privileged: true

eigentlich hat docker genau dafür die device section eingeführt, damit docker weiß, es muss hier speziell mit umgehen, aber mal schauen was das bring.
aber wie gesagt, wenn das device im container nicht sichtbar ist, dann bringt auch die Erweiterung nicht.
evtl mal noch zum besseren verständnis, weil ich auch vergessen hab was das für ein usb device ist.

bei start des containers, also start des betriebssystems im container, laufen die normalen scans nach angeschlossener hardware ab. wenn dann was erkannt wird, dann wird geschaut ob ein kernel treiber dafür da ist. wenn das spezielle hardware ist, dann kann sein, das da etwas fehlt und ebenfalls im container installiert werden muss.

was war das nochmal für ein device? dann kann man im internet schauen ob es sonst da probleme gibt.

Es handelt sich um einen Lesekopf für ein Smartmeter:
https://www.amazon.de/dp/B01B8N0ASY?psc=1&smid=AWNZGX9P9F1X0&ref_=chk_typ_imgToDp

Dafür gibt es auch einen IOBroker-Adapter und den habe ich dann auch entsprechend konfiguriert:

Dafür gibt es auch von buanet selbst diese Anleitung:
https://smarthome.buanet.de/2020/02/usb-devices-im-iobroker-docker-container-nutzen/

Entsprechend habe ich in Container-Config auch diese Umgebungsvariable eingefügt:

      - USBDEVICES=/dev/ttyUSB0

[OliverIO]

@chrisham sagte in USB in Docker via neuer Container über Compose u.a. andere:

s.o.:

kannst du hier mal schauen, ob du damit testen kannst?
https://shop.weidmann-elektronik.de/media/files_public/9d73b590bf0752a5beff32d229d4497d/HowToRaspberryPi.pdf

[Chrisham]

@chrisham Falls jemand hier auch folgen möchte:
https://forum.iobroker.net/topic/69975/iobroker-in-container-mit-asterisk-adapter-installation

[Chrisham]

@oliverio Ok, danke für den Hinweis, also auf Linux-Ebene (also auf Host-Ebene im NAS) mit angeschlossenem Stromzähler kommt einfach nichts an auf der Konsole:

Um wirklich einen Defekt auszuschließen habe ich dann mal an Windows-Rechner angeschlossen und mit dem mitgelieferten Testprogramm getestet, dieser verläuft erfolgreich:

Das ist echt merkwürdig, das Gerät wird ja korrekt am USB-Port erkannt...

[Chrisham]

@chrisham Dieses Problem ist nun auch gelöst, d.h. der Stromzähler ist erfolgreich installiert und die Werte können ausgelesen werden. Dieser kleine Anwendungsfall hat für mich einen großen und sehr lehrreichen Umweg bedeutet:

• das Durchreichen des USB-Ports in den IOBroker-Container war nachträglich beim bestehenden Container nicht möglich.
• also musste ich neuen Container anlegen (das wollte ich eh irgendwann systematisch angehen um künftig auch Updates einfach durchführen zu können
• außerdem ist die Konfiguration der Devices über DSM-UI nicht einfach möglich, also habe ich Portainer hochgezogen.
• dann gab es Probleme mit der Netzwerk-Kommunikation zwischen den anderen (alten) Containern (influxdb, grafana,...), also habe ich noch nebenbei noch das docker-compose Verfahren bei mir eingeführt
• Wieder Netzwerkprobleme wegen KNX-Adapter -> wieder auf Host-Netzwerkmodus gewechselt
• dann viele Probleme mit dem Asterisk-Adapter/Asterisk-Manager: hier noch gelernt neue Images zu erzeugen. Dennoch konnte dieses Problem (wegen fehlender asterisk-manager library im neuesten debian linux) leider bis heute noch nicht gelöst werden, das ist aber tatsächlich der einzige noch offene Punkt
• dann gab es immer noch Probleme mit der USB-Kommunikation für den Stromzähler. Das konnte nun aber gelöst werden, es war ein einfaches Verkabelungsproblem zwischne Stromzähler-Sensor und NAS.
  Ich habe jetzt also (> 3 Wochen) mein bisheriges Setup wieder herstellen können + den Stromzähler-Sensor mit Adapter, Logging in Datenbank und Grafana-Visualisierung erweitert. Also für funktional einen eigentlich kleinen Schritt, jedoch ein deutlich sauberes und systematisches Setup für mein Smarthome-System. Zusätzlich auch noch Skripte erstellt für alle Backups aller persistenter Nutzdaten (Blockly-Scripte, InfluxDB, Grafana,...).

Damit beende ich diesen Thread und bedanke mich nochmals vielmals bei allen, die hier unterstützt haben!

[Chrisham]

@chrisham Ich muss leider diesen Thread wieder aufmachen. Nachdem nun alles einige Zeit wie gewünscht funktionierte, erlebte ich heute nach einem NAS-Neustart eine Überraschung: das USB-Gerät wurde nicht mehr erkannt. iobroker-Docker meldet das bereits beim Hochfahren:

Und auf Linux-Kommandozeile:

Chrisham@DS920-Plus:/$ ls -la /dev/ttyUSB
ls: cannot access '/dev/ttyUSB': No such file or directory
Chrisham@DS920-Plus:/$

Ideen?

[Marc Berg]

@chrisham
Auf der Kommandozeile fehlt die Null (oder *) am Ende und zeig mal die aktuelle Compose Datei (den ioBroker Teil).

[Chrisham]

@marc-berg Ok, danke.

Mit * am Ende sieht es ähnlich aus:

Chrisham@DS920-Plus:/$ ls -la /dev/ttyUSB*
ls: cannot access '/dev/ttyUSB*': No such file or directory

Das hat vor dem Restart der Synology-NAS tatsächlich funktioniert und so ausgesehen:

Das ist der docker-compose Anteil für iobroker:

version: '3'
services:
  iobroker:
    network_mode: "host"
    restart: always
    image: buanet/iobroker:latest
    container_name: iobroker-8
    hostname: iobroker-8
    ports:
      - "8081:8081"
      - "3671:3671"
    volumes:
      - /volume1/docker/iobroker-Chrisham:/opt/iobroker
      - /volume1/docker/userscripts:/opt/userscripts
      - /volume1/docker/Backup:/opt/backup/
    environment:
      - PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
      - DEBIAN_FRONTEND=teletype
      - LANG=de_DE.UTF-8
      - LANGUAGE=de_DE:de
      - LC_ALL=de_DE.UTF-8
      - SETGID=1000
      - SETUID=1000
      - TZ=Europe/Berlin
      - USBDEVICES=/dev/ttyUSB0
      - PACKAGES=influxdb2-cli
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0

[Chrisham]

@chrisham wobei bei > lsusb wird der USB-Port bzw. Device angezeigt:

[OliverIO]

@chrisham
Wenn das Gerät nicht eingehängt ist kann docker nix besser machen.
Du kannst Mal mit dmesg schauen ob es da eine Meldung dazu gibt warum

[Chrisham]

@oliverio @oliverio ja, mir ist klar, dass das Problem schon weiter vorne in der Kette besteht, also bereits auf Synology-Gerät oder DSM-Ebene. Und das wäre genau meine Frage, was da noch die Ursache sein kann. Es hat ja funktioniert bisher, bis ich die Synology einmal runtergefahren und wieder neu gestartet habe. Seit da wird auf Synology-Linux-Ebene das USB-Device nicht mehr richtig erkannt:

also so wird es noch irgendwie erkannt (1-2: das ändert sich nämlich, wenn ich USB aus- und einstecke):

Chrisham@DS920-Plus:/$ lsusb
|__usb1          1d6b:0002:0404 09  2.00  480MBit/s 0mA 1IF  (Linux 4.4.302+ xhci-hcd xHCI Host Controller 0000:00:15.0) hub
  |__1-1         051d:0002:0106 00  2.00   12MBit/s 100mA 1IF  (American Power Conversion Back-UPS BX750MI  FW:295202G -302202G  9B2207A14072)
  |__1-2         0403:6015:1000 00  2.00   12MBit/s 90mA 1IF  (FTDI FT230X Basic UART D200YUST)
  |__1-4         f400:f400:0100 00  2.00  480MBit/s 200mA 1IF  (Synology DiskStation 7F0017CD8713F213)
|__usb2          1d6b:0003:0404 09  3.00 5000MBit/s 0mA 1IF  (Linux 4.4.302+ xhci-hcd xHCI Host Controller 0000:00:15.0) hub

Aber so wird nichts erkannt:

Chrisham@DS920-Plus:/$ ls -l /dev/ttyUSB*
ls: cannot access '/dev/ttyUSB*': No such file or directory

dmesg (ich kopiere alles rein, ich hoffe, das spammt nicht den ganzen thread...) liefert:

Chrisham@DS920-Plus:/$ dmesg
...
[11638.191709] audit: type=1104 audit(1701820541.981:809): pid=27218 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/console res=success'
[12652.665632] usb 1-2: USB disconnect, device number 2
[12659.649290] usb 1-2: new full-speed USB device number 5 using xhci_hcd
[73588.912746] usb 1-2: USB disconnect, device number 5
[73672.996947] usb 1-2: new full-speed USB device number 6 using xhci_hcd
[73787.623350] usb 1-2: USB disconnect, device number 6
[73807.082495] usb 1-2: new full-speed USB device number 7 using xhci_hcd
Chrisham@DS920-Plus:/$

Am Endessteht das was mit "USB disconnect"....

[Glasfaser]

@chrisham sagte in USB in Docker via neuer Container über Compose u.a. andere:

heute nach einem NAS-Neustart

Du hast ganz am anfang des Thread nur das hier geschrieben :

Da steht, man benötigt nur das:
sudo insmod /lib/modules/usbserial.ko
sudo insmod /lib/modules/ftdi_sio.ko

hast du auch an das Start-Script gedacht !?

Zitat :
"Leider gehen die Einstellungen mit dem Neustart der Synology DiskStation wieder verloren,"

[OliverIO]

@chrisham

Schau dir bei den Meldungen auch immer Mal noch davor und dahinter an ob es da Fehler oder Warnungen gibt.

Dann könnten es auch noch die Stromspar Funktionen sein, die den USB Anschluss dann abmelden. Da muss im Internet suchen wie man das einstellen kann
Und auch die Einstellung überlebt den Neustart nicht

[Chrisham]

@Glasfaser bingo, gerade habe ich das bemerkt/gefunden, ja, das war es,zumindest auf host-Ebene ist USB-Device wieder da:

Chrisham@DS920-Plus:/$ ls -la /dev/ttyUSB*
crw------- 1 root root 188, 0 Dec  6 18:43 /dev/ttyUSB0

Wie verpacke ich das am besten in ein Startscript für die NAS, also dass solche Einstellungen beim Neustart wiederhergestellt werden?

Noch anderes Phänomen: ich habe die Container (v.a. iobroker-Container) [selbst nachdem nun das USB-Problem gelöst war...] nicht mehr gestartet bekommen, er hat sich immer wieder versucht zu starten und wieder terminiert....
Erst nachdem ich nochmals das komplette docker-compose als stack in portainer neu deployed habe, lief es wieder....

[Glasfaser]

@chrisham sagte in USB in Docker via neuer Container über Compose u.a. andere:

Wie verpacke ich das am besten in ein Startscript

Steht doch alles in deinem Link ( Threadanfang ) !

[A Former User]

@chrisham sagte in USB in Docker via neuer Container über Compose u.a. andere:

host-Ebene ist USB-Device wieder da:

Moin,

ich will mich hier nicht weiter in eine laufende Diskussion, in der ich den Überblick verloren habe, verschlimmbessern, aber ich glaube diese Rechte, beim angelegten Device

Chrisham@DS920-Plus:/$ ls -la /dev/ttyUSB*
crw------- 1 root root 188, 0 Dec  6 18:43 /dev/ttyUSB0

reichen nicht aus, damit das sauber in den Docker Container durchzureichen.

Das sollte aus meiner Sicht eher so aussehen
Chrisham@DS920-Plus:/$ ls -la /dev/ttyUSB*
crw-rw---- 1 root root 188, 0 Dec 6 18:43 /dev/ttyUSB0

Je nachdem, wer dann aus dem Docker kommt, um auf das durchgereichte Device zuzugreifen, kann es sogar nötig sein, es dahingehend abzuändern
Chrisham@DS920-Plus:/$ ls -la /dev/ttyUSB*
crw-rw-rw- 1 root root 188, 0 Dec  6 18:43 /dev/ttyUSB0

VG
Bernd

[OliverIO]

@chrisham
Ich habe auch ein wenig den Überblick verloren, was du nun auf Host-Ebene und was du nun auf Container-Ebene machen musstest, das nach einem Neustart von
a) dem Host erneut durchführen musst und
b) Neu generieren des Docker-Containers durchführen musst und
c) Neustart des Docker-Containers tun musst.

Aber generell, bei a) ist die normale Funktionsweise von Linux das unter einem start-service von linux zu definieren. was bei dir da aktuell ist (war es synology oder so?) weiß ich nicht. bei debian ist es aktuell https://de.wikipedia.org/wiki/Systemd oder früher https://de.wikipedia.org/wiki/SysVinit

für b)+c) stellt buanet entsprechende einen mechanismus zur verfügung um entsprechende skripte dem container zuzuspielen
https://docs.buanet.de/de/iobroker-docker-image/docs/#startskripte

auch würde ich dir bei komplexeren konfigurationen empfehlen zumindest docker-compose oder gar portainer mit der stacks-funktion (auch als docker-container startbar) zu nutzen