UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[andre]

@rostnagel
Kann ich mir nicht vorstellen, das Script läuft als root...
Ist dein Mounting im Container wirklich korrekt? Stimmt der Pfad?

MfG,
André

[a200]

moin,

ich nutze die QNAP, aber das sollte eigentlich keine große Rolle spielen. Jetzt habe ich ein Update von einem Image von Februar auf die aktuelle Version. Hat alles ganz gut geklappt, bis auf den smartmeter.

Wenn ich den alten Container laufen lasse dann funktioniert der Smartmeter problemlos. Der neuer Container mit den gleichen iobroker-Verzeichnis macht Probleme.
/dev/ttyUSB0 liefert in beiden Fällen Daten.

root@00634d67b41e:/dev# cat /dev/ttyUSB0 | od -tx1                                                                                                                                                                                    
0000000 f8 00 ff 01 01 62 21 52 fe 53 00 5e 01 77 07 01                                                                                                                                                                               
0000020 00 20 07 00 ff 01 01 62 23 52 fe 53 59 58 01 77                                                                                                                                                                               
0000040 07 01 00 38 07 00 ff 01 01 62 1b 52 ff 53 02 57                                                                                                                                                                               
0000060 01 77 07 01 00 33 07 00 ff 01 01 62 21 52 fe 53                                                                                                                                                                               
0000100 00 29 01 77 07 01 00 34 07 00 ff 01 01 62 23 52

Allerdings bekommt der Smartmeter keine Daten rein und beschwert sich über timeout.

@andre - Ideen woran es liegen könnte? In dem neuen Image finde ich keine udev-tools. Kann es daran liegen?

Danke, a200.

[Glasfaser]

@a200

Versuche mal das in der Portainer-Konsole

apt-get update
apt-get -y install udev

chmod 777 /dev/ttyUSB0 

[a200]

@Glasfaser sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:

@a200

Versuche mal das in der Portainer-Konsole

apt-get update
apt-get -y install udev

chmod 777 /dev/ttyUSB0 

Die Nachinstallation von udev habe versucht, allerdings ohne vorher apt-get update aufzurufen. Damit wurde udev nicht gefunden. Spielt aber keine Rolle. Es liegt wirklich an den Zugriffsrechten von /dev/ttyUSB0. Aber wieso?

1. iobroker läuft unter root!
2. ttyUSB0 gehört root:

crw------- 1 root root 188, 0 Nov 13 19:54 /dev/ttyUSB0

3. ein chmod ist nicht persistent. Nach einem neustart des Containers werden die Rechte wieder auf 600 gesetzt.

Wie passt 1 und 2 zusammen? 3 kann ich lösen, ist aber eigentlich nicht die feine Art.

[Glasfaser]

@a200 sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:

Nach einem neustart des Containers werden die Rechte wieder auf 600 gesetzt.
3 kann ich lösen, ist aber eigentlich nicht die feine Art.

Ist bekannt ….das die Rechte selber gesetzt werden müssen .

Link Text

Link Text

[a200]

@Glasfaser sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:

@a200 sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:

Nach einem neustart des Containers werden die Rechte wieder auf 600 gesetzt.
3 kann ich lösen, ist aber eigentlich nicht die feine Art.

Ist bekannt ….das die Rechte selber gesetzt werden müssen .

Link Text

Link Text

ok. Danke! Das könnte man in den iobroker_startup.sh einbauen. Muss man mit @andre klären, denn es hat wenig Sinn in dem Fall (ca. 5 Zeilen code) ein eigenes Image zu erstellen.

Auf jeden Fall komme ich jetzt klar. Vielen Dank.

[rostnagel]

@andre sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:

@rostnagel
Kann ich mir nicht vorstellen, das Script läuft als root...
Ist dein Mounting im Container wirklich korrekt? Stimmt der Pfad?

MfG,
André

ich weiß nicht was ich getan habe aber jetzt läufts. hab den container gellöscht und neu erstellt. daten in den ordner kopiert und alles lief reibungslos. keine ahnung was das problem war

[andre]

@a200 sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:

Muss man mit @andre klären

Können wir gerne klären. Sollen wir dazu vor die Tür gehen? ;)

Hab ich auf dem Zettel:
https://github.com/buanet/docker-iobroker/issues/8
https://github.com/buanet/docker-iobroker/issues/36

[a200]

@andre sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:

Können wir gerne klären. Sollen wir dazu vor die Tür gehen? ;)

Hab ich auf dem Zettel:
https://github.com/buanet/docker-iobroker/issues/8
https://github.com/buanet/docker-iobroker/issues/36

Nee, viel zu kalt draußen! :fearful:

Ich habe mir ein Image gebastelt in dem ich wie du es machst, eine ENV Variable definiert mit der ich steuern kann ob der chmod-Script aufgerufen wird, oder nicht.

if [ "$usbperm" = "true" ]
then
  echo "USB permission is activated by ENV."
  chmod 764 /opt/scripts/setup_usb.sh
  sh /opt/scripts/setup_usb.sh
  echo "Done."
  echo ' '
fi

und setup_usb.sh

#!/bin/bash
echo "Checking USB permissions..."
chmod 777 /dev/ttyUSB0
exit 0

Es wäre nett, wenn du die Anpassung übernehmen könntest. :+1:

Ich glaube, dass das Ganze auf der QNAP so problematisch ist, weil die uid 0 admin gehört:

[~] # id
uid=0(admin) gid=0(administrators) groups=0(administrators),100(everyone)

und obwohl ich root in demContainer bin und des Device root gehört, die Zugriffsrechte nicht ausreichend sind. Vieleicht kann man das noch anders lösen? In der früheren Versionen deines Images funktionierte der Zugriff Problemlos.

Danke und liebe Grüße.

[BLRD]

Hallo zusammen,

mit der Installation des Alexa Adapters2 habe ich so einige Probleme:

Konstellation =

Platform: linux
Architecture: x64
CPUs: 2
Speed: 2001 MHz
Model: Intel(R) Celeron(R) CPU J3355 @ 2.00GHz
RAM: 9.5 GB
System uptime: 08:24:14
Node.js: v10.17.0
NPM: 6.11.3
Disk size: 2.6 TiB
Disk free: 1.8 TiB
adapters count: 301
Uptime: 00:06:41
Active instances: 22

Wenn ich nun versuche den Adapter zum starten zu bringen, möchte er üver den Link http://172.17.0.3:37334/ eine Verbindung herstellen twecks Erwerb des Cookie.

Dies geht aber nicht!

Anbei die Einstellung am Adapter:

Hat dies ggf. was mit dem bind am Docker oder Portainer zu tun!?

Wer hat eine Idee?

Danke.

VG

BLRD

[duffbeer2000]

@BLRD
Die 172.17.0.3 ist die interne IP im Dockereigenen Netzwerk, auf die hast du von außen keinen Zugriff deshalb klappt es nicht.

Lösung:

• Im Alexa Adapter unter Proxy-Einstellungen musst du unten bei "Externe Container-IP (Docker)" die IP-Adresse deiner Synology eintragen, dann sollte auch ein anderer Link mit der IP deiner Synology angezeigt werden.

[dos1973]

Hi zusammen, ich habe soeben erfolgreich mein Docker Image nach Portainer MacVLAN gebracht. es funktioniert alles soweit...

Hintergrund waren die Shellys, ich möchte gerne cloud und iobroker nutzen und das geht nur mit COAP und MacVlan.

das einzige was derzeit "gelb" ist ist der zigbee Adapter. ich habe an meiner Synologie so ein USB Dongle dran... gibt es dazu irgendwas zu beachten um den auch lauffähig zu bekommen.

@andre
Top Anleitung, gebe zu ich musste 2-3 Versuche starten aber jetzt läuft alles soweit.
Danke für deine Mühe das alles so genau und gut bebildert zu beschreiben!

[Negalein]

@dos1973 sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:

das einzige was derzeit "gelb" ist ist der zigbee Adapter. ich habe an meiner Synologie so ein USB Dongle dran... gibt es dazu irgendwas zu beachten um den auch lauffähig zu bekommen.

Ja, dies ist bekannt.
Hab ich hier schon beschrieben.

Du musst ein chmod 777 /dev/ttyACM0 machen.

[dos1973]

@Negalein

Klasse. Besten Dank, versuche ich heute Abend

edit:
hmm, irgendwas mache ich falsch, gebe zu ich bin mit der console & ssh nicht sehr vertraut.

ich habe auf dem portioner die console geöffnet

chmod: Zugriff auf '/dev/ttyACM0' nicht möglich: Datei oder Verzeichnis nicht gefunden
root@733f5e85428d:/dev# ls
core  fd  full  mqueue  null  ptmx  pts  random  shm  stderr  stdin  stdout  tty  urandom  zero
root@733f5e85428d:/dev#

bekomme die FM
im /dev Verzeichnis habe ich kein "ttyACM0"

@Negalein noch ein Tipp für mich?

PS. den Hostnamen änder ich nochmals...:-)
Danke

[dos1973]

ich habs gefunden.
ich musste das Häckchen mit der hohe "Priorität" setzen und danach konnte ich die Rechte mit chmod ausführen

ich habe dieses setting nicht in Portainer gefunden, bin dazu in die Docker Einstellung gewechselt... könnte mir jemand eine Tipp geben, wo ich das in Portainer setzen kann... Thx

[duffbeer2000]

@dos1973 Container sollten nur in besonderen Ausnahmefällen mit hoher Priorität ausgeführt werden. Man gibt damit dem Container weitreichende Rechte auf dem Host wie z.B. der Synology. Der Container hat dadurch z.B. vollen Zugriff auf alle Geräte unter /dev auf dem Host und könnte alle Dateien löschen...

[dos1973]

@duffbeer2000
ok, Danke für den Hinweis.
Welche Möglichkeit habe ich denn ansonsten dass mir "/dev/ttyACM0" erstellt wird...

[duffbeer2000]

Da ich nicht 100% weiß obs funktioniert bitte nur jemand testen der etwas Erfahrung hat!!!

Hi, ich hab leider keine Synology um es zu testen. Theoretisch sollte es reichen wenn der User der dialout Gruppe hinzugefügt wird. Dann hat er Zugriff auf /dev/ttyACM0 Dann müsste man im Container kein chmod 777 /dev/ttyACM0 mehr ausführen. Falls die Gruppe dialout im Container fehlen sollte könnte Andre die ohne Schmerzen integrieren.

Zum Testen folgendes ausführen:
Bevor jemand das testet bitte sicherstellen das der Container nicht priviledged gestartet wurde und das kein chmod 777 /dev/ttyACM0 im Container ausgeführt wurde sonst bringt der Test nichts.
Host = z.B. Synology

1. Auf dem Host und im Container prüfen ob es die Gruppe "dialout" gibt und wenn nicht anlegen:
   grep dialout /etc/group
   Die Ausgabe sollte sollte starten mit: dialout: x:20
   Wenn es die Gruppe nicht geben sollte dann: groupadd -g 20 dialout

2. Auf dem Host den Stick der Gruppe dialout zuordnen: chown root:dialout /dev/ttyACM0
   Achtung, diese Zuordnung bleibt nur solange bestehen bis man den Stick rauszieht oder der Host neu startet!

3. Test ob der Stick jetzt im Container funktioniert

Wenn der Stick jetzt im Container funktioniert dann folgendes machen um die Einstellung auch nach einem Reboot oder beim Stick aus und einstecken zu behalten:

1. Befehl auf dem Host ausführen: lsusb
   Die Ausgabe ist dann sowas wie: "Bus 003 Device 002: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)"
   Hier interessiert uns nur was bei ID steht.

2. Nun erstellt man eine Datei: /etc/udev/rules.d/99_zigbeestick
   In die Datei trägt man folgendes ein (Achtung die idVendor und idProduct mit der ausgabe oben ersetzen! Ist bei jedem anders.):
   SUBSYSTEM="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", MODE="0660", GROUP="dialout"

3. Jetzt mit folgendem Befehl die Regel laden (alternativ den Host neu starten):
   udevadm control --reload-rules && udevadm trigger

[dos1973]

@duffbeer2000
ich würde mich ja für eine Teamviewer Session bereit erklären ;-)
gerne per pm...

alleine traue ich es mich nicht...

[duffbeer2000]

@dos1973 Können wir später gerne machen. Ich bin allerdings noch bei der Arbeit. Sobald ich zuhause bin und die Regierung mir Freizeit gewährt melde ich mich ;)