USB in Docker via neuer Container über Compose u.a. andere
-
@oliverio ok, perfekt, das image wurde erfolgreich gebaut und auch der neu docker-stack basierend auf diesem image.
Die Telefonfunktion vom asterisk läuft allerdings immer noch nicht, immer noch die gleichen Fehler.
Was mich allerdings wundert: in dem docker-file von andrius steht jetzt wieder port 5060 drin:EXPOSE 5060/udp 5060/tcpWas allerdings seltsam ist, denn ich habe im Asterisk-IOBroker-Adapter ja 5038 drin und der Adapter verbindet auch.
Dennoch versuche ich es nochmals alles konsistent mit dem gleichen Port zu machen, um diese Fehlerquelle auf jeden Fall ausschließen zu können. -
@chrisham btw, das war das log-file vom image-build:
Step 1/10 : FROM alpine:latest ---> 8ca4688f4f35 Step 2/10 : LABEL maintainer="Andrius Kairiukstis <k@andrius.mobi>" ---> Using cache ---> 80d70b682d6f Step 3/10 : ENV LANG=C.UTF-8 ---> Using cache ---> c2ab84f9a8a9 Step 4/10 : ENV LC_ALL C.UTF-8 ---> Using cache ---> 05efc4fd9d07 Step 5/10 : RUN set -e && apk add --update --quiet asterisk asterisk-sample-config >/dev/null ffmpeg lame sox && asterisk -U asterisk &>/dev/null && sleep 5s && [ "$(asterisk -rx "core show channeltypes" | grep PJSIP)" != "" ] && : || rm -rf /usr/lib/asterisk/modules/*pj* && pkill -9 ast && sleep 1s && truncate -s 0 /var/log/asterisk/messages /var/log/asterisk/queue_log || : && mkdir -p /var/spool/asterisk/fax && chown -R asterisk: /var/spool/asterisk && rm -rf /var/run/asterisk/* /var/cache/apk/* /tmp/* /var/tmp/* ---> Using cache ---> c1549981d129 Step 6/10 : EXPOSE 5060/udp 5060/tcp ---> Using cache ---> d9a50fc83bdc Step 7/10 : VOLUME /var/lib/asterisk/sounds /var/lib/asterisk/keys /var/lib/asterisk/phoneprov /var/spool/asterisk /var/log/asterisk ---> Using cache ---> 21c0dffb3708 Step 8/10 : ADD docker-entrypoint.sh /docker-entrypoint.sh ---> Using cache ---> f57c57d310c7 Step 9/10 : RUN chmod +x docker-entrypoint.sh ---> Running in 33be21150960 Removing intermediate container 33be21150960 ---> 5b4dc32de023 Step 10/10 : ENTRYPOINT ["/docker-entrypoint.sh"] ---> Running in 99c1d96acab9 Removing intermediate container 99c1d96acab9 ---> addfc0678e66 Successfully built addfc0678e66 Successfully tagged chris-asterisk:latest -
@chrisham said in USB in Docker via neuer Container über Compose u.a. andere:
Was mich allerdings wundert: in dem docker-file von andrius steht jetzt wieder port 5060 drin:
das hatte ich dir oben schon mal versucht zu sagen. aber du warst anderweitig überzeugt.
ich weiß auch nicht welcher port da für was da ist. es kann durchaus sein, das es mehrere ports sind, die nach außen durchgereicht werden müssen.
https://forum.iobroker.net/topic/69281/usb-in-docker-via-neuer-container-über-compose-u-a-andere/85?_=1698757422545im normalen bridge modus müssen alle ports deklariert werden
im host mode sind eh alle offen. -
@oliverio jetzt habe ich beide Varianten durchgespielt:
a) überall 5060 eingetragen
b) überall 5038 eingetragenüberall heißt:
- im docker-file von andrius (wie original)
- im docker-compose-file
- in config des IOBroker Asterisk-Adapters
- im manager.conf file des asterisk containers
Ergebnis:
- bei a) Adapter kann gar nicht zu asterisk container verbinden
- bei b) Verbindung zu asterisk-container funktioniert, aber telefon-funktion geht nicht
also bei 5038 geht noch etwas mehr als bei 5060.
Da wirds jetzt natürlich knifflig, muss wohl doch mal den andrius kontaktieren...
-
@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.
-
@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 setzenprivileged: trueeigentlich 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.
-
@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/ttyUSB0so wie dann auch im docker compose file auch verwendet unter devices:
devices: - /dev/ttyUSB0:/dev/ttyUSB0dann musst du schauen unter welchem pfad das device ansprechbar ist
s.o.:
/dev/ttyUSB0diesen 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 erkenntInnerhalb des Containers (IObroker container) sieht es dann so aus:
D.h. also auch dort ist es unter dem Pfad
/dev/ttyUSB0erreichbar.
falls nicht, kannst du im docker-compose eine ebene unterhalb der service-konfiguration die folgende option setzen
privileged: trueeigentlich 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_imgToDpDafü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 -
@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 Falls jemand hier auch folgen möchte:
https://forum.iobroker.net/topic/69975/iobroker-in-container-mit-asterisk-adapter-installation -
@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 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 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?
-
@chrisham
Auf der Kommandozeile fehlt die Null (oder *) am Ende und zeig mal die aktuelle Compose Datei (den ioBroker Teil). -
@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 directoryDas 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 wobei bei > lsusb wird der USB-Port bzw. Device angezeigt:
-
@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 -
@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) hubAber so wird nichts erkannt:
Chrisham@DS920-Plus:/$ ls -l /dev/ttyUSB* ls: cannot access '/dev/ttyUSB*': No such file or directorydmesg (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"....
-
@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.kohast du auch an das Start-Script gedacht !?
Zitat :
"Leider gehen die Einstellungen mit dem Neustart der Synology DiskStation wieder verloren," -
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 -
@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/ttyUSB0Wie 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....
