Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Chrisham]

@oliverio Ok, danke. Also, mal wieder "nur" ein Teilerfolg, 2 Probleme:

1.) Das Paket "libsox-fmt-mp3" konnte er nicht finden beim image erstellen, als ich das rauslöschte, hat es funktioniert, also container wurde erstellt. Ich habe auch das file "docker-entrypoint" mit in die container-erstellung geladen

2.) als ich dann (mit dem neuen Image) den neuen stack mit docker-compose bauen wollte, kam diese Fehlermeldung:

Probleme scheint gerade das docker-entrypoint file zu machen. Lt. deiner Beschreibung wird das bei image Erstellung ausgeführt und nicht später bei Container-erstellung.

Ok, muss morgen dann weiter schauen...

[OliverIO]

@chrisham
Das Script wird ja mit im filesystem des containers mit integriert und dann gestartet.
Evtl müsste man dem den User und der Gruppe Root zuordnen
Aber ich kann tagsüber mal nochmal schauen

[OliverIO]

@chrisham
Die Datei wird ja in das Dateisystem des Containers integriert. Evtl muss man dem den User und Gruppe Root zuordnen.

Das Paket in dem die Datei enthalten ist heißt sox
https://pkgs.alpinelinux.org/contents?branch=edge&name=sox&arch=armhf&repo=community

Sox hast du ja drin, dann war das früher schon falsch

[OliverIO]

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

Probleme scheint gerade das docker-entrypoint file zu machen

es scheint wohl daran zu liegen, das der datei das execution flag fehlt.
ich habe gesehen, das im portainer nur dateien vom client rechner (also windows) hochgeladen werden können. da ist wahrscheinlich das flag nicht gesetzt. daher muss man es dann im dockerfile setzen
die zeile kommt zwischen der ADD und der ENTRYPOINT Zeile
Falls da auch was nicht funktioniert, mach noch ein / vor den Dateinamen

RUN chmod +x docker-entrypoint.sh

[Chrisham]

@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/tcp

Was 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]

@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

[OliverIO]

@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?_=1698757422545

im normalen bridge modus müssen alle ports deklariert werden
im host mode sind eh alle offen.

[Chrisham]

@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 @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