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

[Telefisch]

Also das hat ganz hervorragend geklappt.
Jetzt hab ich nur noch das Problem, dass einige Adapter nicht upgedatet werden können, darunter der Admin :(

@andre kann man das volume im nachhinein im portainer ändern?
Zumindest die Kommandozeile scheint da gut zu laufen und schmeisst mir beim manuellen update des cloud-adapters einen Fehler, der auf die Rechte hindeutet.
Ich würde dann vorerst nochmal das iobroker-mount Verzeichnis aus meiner alten Installation probieren.

Edit: hab nen neuen Container mit dem „alten“ Volume-Pfad angelegt, bekomme aber immernoch komische Fehler:

[tcfigge]

@andre
Hallo andre!
Danke für die Hilfe!
Die Container laufen im HOST.
npm rebuild:

[andre]

@Telefisch
Wie du schon raus gefunden hast, muss man bei Docker in den meisten Fällen einen neuen Container anlegen. Sollte aber auch kein riesen Ding sein. Dazu gibt es ja schließlich den "Edit/ Duplicate" Button im Portainer....

Was deinen Fehler aus dem Screenshot angeht, da würde ich die Dateien einfach per Hand löschen/ umkopieren und nochmal versuchen... Sieht mir nicht nach nem großen Ding aus...

MfG,
André

[andre]

@tcfigge
Sieht mir nach dem bekannten Bug aus... Wenn du im Host-Modus versuchst sudo zu verwenden (auch wenn du es nicht aktiv machst, sondern etwas was du aufrufst) dann kommt der Fehler.
Das liegt daran, dass der Synology DSM immernoch auf einer veralteten Linux-Kernel-Version läuft...

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

Außerdem noch kurz was zum netzwerkthema.
In v2 war es kein Problem mit der Option "host" zu arbeiten. Allerdings nutzt das neue ioBroker setup ab sofort sudo (intern). Aufgrund eines Bugs im von synology derzeit für den dsm verwendeten Betriebssystem kernel lässt sich in einem Container, der "host" network verwendet aktuell kein sudo nutzen. Ergebnis iobroker läuft unter Umständen nicht, oder startet z. B. Nicht.
Lösung: bridge oder macvlan als netzwerkoption verwenden. Nachteil:
macvlan = eher für fortgeschrittene,
bridge = jeder von Adaptern und iob selbst verwendete port muss manuell konfigutiert/ weitergeleitet werden.

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

Issue Report für das Kernel Problem kenne ich nicht und habe ich aufgrund der geringen Fix-Wahrscheinlichkeit auch nicht bei Synology gemeldet.
Wenn man aber die audit-Fehlermeldung, welche man beim Verwenden von sudo in dem entsprechenden Fall bekommt mal sucht, dann bekommt man stack overflow beiträge wo es genau darum geht (ist nicht synology spezifisch!).
Aber wie gesagt (und sehr ärgerlich) es betrifft die Kernel Version die der DSM aktuell verwendet. Ich habe ein Debian mit aktuellem Linux Kernel da ist das kein Problem. Da läuft der ioBroker auch im Host-Mode...

Das Thema ist hier schon mehrfach diskutiert worden. Für die Probleme beim Start des ioBrokers habe ich einen Fix in das Startupscript eingebaut. Alle weiteren Befehle kranken weiterhin an dieser Einschränkung...

Ein Workaround könnte sein für die Durchführung z.B. eines "npm rebuild" einen Container mit Bridge Netzwerk zu erstellen, die Befehle durchlaufen zu lassen und wieder auf host-modus zurück zu kehren.
Theoretisch ließe es sich sogar so arrangieren, dass man zwei Container anlegt, die auf das selbe Verzeichnis zugreifen. Darf dann natürlich immer nur einer zur Zeit laufen...

MfG,
André

[tcfigge]

@andre
Danke für die Info´s!
Da werde ich mich jetzt mit beschäftigen...werde mich bemühen auf macvlan zu gehen. Alles besser als jetzt direkt alle Scripte und Scenen neu zu schreiben!

Im macvlan braucht man auch das Startscript nicht?

Dann werde ich mich daran versuchen. Host hatte ich nur der Einfachheit halber gewählt...
Danke und einen schönen Restsonntag.
Thorsten

[gerald123]

Hallo Andre,
Ich habe bei mir auf der Synology 918 über Portainer deinen Container mit macvlan am laufen.
Jetzt möchte ich zu Testzwecken einen zweiten Container aufsetzten der komplett getrennt mit eigenem macvlan läuft.
Kann ich da jetzt nach deiner Anleitung einfach ein zweites macvlan mit eigener IP Adresse anlegen oder ist da noch was anderes zu berücksichtigen?

Lg. Gerald

[jogge]

Servus,

ich hätte da auch mal eine Frage. Bei mir läuft auf der DS218+ unter Docker auch der iObroker Container von André. Jetzt würde ich gerne das ganze auch auf Portainer umziehen um so via macvlan dem Iobroker eine eigene IP zu geben. Das hat den Hintergrund das ich beim Node Red Adapter den Port 80 brauche, der aber schon von der DS belegt ist. Meine Hoffnung ist, dass es so dann klappen müsste und ich meine Geräte via Node Red Echo Plugin über Alexa steuern kann.
Leider scheitere ich beim Starten des Containers. Auch nach etlichen Minuten ist der Iobroker-Admin nicht aufrufbar. Bei den Prozessen sieht alles so aus wie immer aber im Protokoll sehe ich Fehlermeldungen die wohl von den Homematic-Adaptern kommen. Die finden die IP des Hosts nicht mehr....scheint ja auch logisch weil da ja noch die alte eingetragen ist...

2020-01-07 07:12:58	stderr	  port: 12010 }
2020-01-07 07:12:58	stderr	  address: '172.17.0.1',
2020-01-07 07:12:58	stderr	  syscall: 'listen',
2020-01-07 07:12:58	stderr	  errno: 'EADDRNOTAVAIL',
2020-01-07 07:12:58	stderr	  code: 'EADDRNOTAVAIL',
2020-01-07 07:12:58	stderr	    at process._tickCallback (internal/process/next_tick.js:63:19)
2020-01-07 07:12:58	stderr	    at doListen (net.js:1461:7)
2020-01-07 07:12:58	stderr	    at listenInCluster (net.js:1328:12)
2020-01-07 07:12:58	stderr	    at Server.setupListenHandle [as _listen2] (net.js:1263:19)
2020-01-07 07:12:58	stderr	{ Error: listen EADDRNOTAVAIL: address not available 172.17.0.1:12010
2020-01-07 07:12:54	stderr	
2020-01-07 07:12:54	stderr	  port: 12001 }
2020-01-07 07:12:54	stderr	  address: '172.17.0.1',
2020-01-07 07:12:54	stderr	  syscall: 'listen',
2020-01-07 07:12:54	stderr	  errno: 'EADDRNOTAVAIL',
2020-01-07 07:12:54	stderr	  code: 'EADDRNOTAVAIL',
2020-01-07 07:12:54	stderr	    at process._tickCallback (internal/process/next_tick.js:63:19)
2020-01-07 07:12:54	stderr	    at doListen (net.js:1461:7)
2020-01-07 07:12:54	stderr	    at listenInCluster (net.js:1328:12)
2020-01-07 07:12:54	stderr	    at Server.setupListenHandle [as _listen2] (net.js:1263:19)
2020-01-07 07:12:54	stderr	{ Error: listen EADDRNOTAVAIL: address not available 172.17.0.1:12001
2020-01-07 07:12:51	stderr	
2020-01-07 07:12:51	stderr	  port: 18701 }
2020-01-07 07:12:51	stderr	  address: '172.17.0.1',
2020-01-07 07:12:51	stderr	  syscall: 'listen',
2020-01-07 07:12:51	stderr	  errno: 'EADDRNOTAVAIL',
2020-01-07 07:12:51	stderr	  code: 'EADDRNOTAVAIL',
2020-01-07 07:12:51	stderr	    at process._tickCallback (internal/process/next_tick.js:63:19)
2020-01-07 07:12:51	stderr	    at doListen (net.js:1461:7)
2020-01-07 07:12:51	stderr	    at listenInCluster (net.js:1328:12)
2020-01-07 07:12:51	stderr	    at Server.setupListenHandle [as _listen2] (net.js:1263:19)
2020-01-07 07:12:51	stderr	{ Error: listen EADDRNOTAVAIL: address not available 172.17.0.1:18701
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.node-red.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.vis-plumb.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.vis-rgraph.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.vis-players.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.vis-timeandweather.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.vis-metro.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.vis-fancyswitch.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.vis.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.cloud.1" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.info.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.netatmo.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.pushover.1" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.pushover.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.tuya.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.alexa2.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.mihome-vacuum.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.scenes.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.zigbee.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.terminal.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.mobile.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.cloud.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.sonos.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.javascript.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.history.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.web.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.hm-rega.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.hm-rpc.2" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.hm-rpc.1" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.hm-rpc.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.ping.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.discovery.0" for host "iobroker"
2020-01-07 07:12:36	stdout	host.iobroker check instance "system.adapter.admin.0" for host "iobroker"
2020-01-07 07:12:36	stdout	================================== > LOG REDIRECT system.adapter.admin.0 => true [starting]
2020-01-07 07:12:33	stdout	 
2020-01-07 07:12:33	stdout	Starting ioBroker...
2020-01-07 07:12:33	stdout	 
2020-01-07 07:12:33	stdout	------------------------------------------------------------
2020-01-07 07:12:33	stdout	-----          Step 5 of 5: ioBroker startup           -----
2020-01-07 07:12:33	stdout	------------------------------------------------------------
2020-01-07 07:12:28	stdout	 
2020-01-07 07:12:28	stdout	For more information take a look at readme.md
2020-01-07 07:12:28	stdout	Some adapters have special requirements which can be activated by the use of environment variables.
2020-01-07 07:12:28	stdout	 
2020-01-07 07:12:28	stdout	------------------------------------------------------------
2020-01-07 07:12:28	stdout	-----      Step 4 of 5: Applying special settings      -----
2020-01-07 07:12:28	stdout	------------------------------------------------------------
2020-01-07 07:12:28	stdout	 
2020-01-07 07:12:28	stdout	Done.
2020-01-07 07:12:28	stdout	Fixing "sudo-bug" by replacing sudo with gosu...
2020-01-07 07:12:28	stdout	 
2020-01-07 07:12:28	stdout	Done.
2020-01-07 07:12:22	stdout	(Re)Setting folder permissions (This might take a while! Please be patient!)...
2020-01-07 07:12:22	stdout	 
2020-01-07 07:12:22	stdout	Done.
2020-01-07 07:12:22	stderr	usermod: Keine Änderungen
2020-01-07 07:12:22	stdout	Changing UID to 1000 and GID to 1000...
2020-01-07 07:12:22	stdout	 
2020-01-07 07:12:22	stdout	This is the first run of a new container. Time for some preparation.
2020-01-07 07:12:22	stdout	 
2020-01-07 07:12:22	stdout	------------------------------------------------------------
2020-01-07 07:12:22	stdout	-----   Step 3 of 5: Checking ioBroker installation    -----
2020-01-07 07:12:22	stdout	------------------------------------------------------------
2020-01-07 07:12:22	stdout	 
2020-01-07 07:12:22	stdout	Installation of ioBroker detected in /opt/iobroker.
2020-01-07 07:12:22	stdout	 
2020-01-07 07:12:22	stdout	------------------------------------------------------------
2020-01-07 07:12:22	stdout	-----   Step 2 of 5: Detecting ioBroker installation   -----
2020-01-07 07:12:22	stdout	------------------------------------------------------------
2020-01-07 07:12:22	stdout	 
2020-01-07 07:12:22	stdout	Done.
2020-01-07 07:12:08	stdout	The following packages will be installed: nano...
2020-01-07 07:12:08	stdout	 
2020-01-07 07:12:08	stdout	------------------------------------------------------------
2020-01-07 07:12:08	stdout	-----   Step 1 of 5: Installing additional packages    -----
2020-01-07 07:12:08	stdout	------------------------------------------------------------
2020-01-07 07:12:08	stdout	 
2020-01-07 07:12:08	stdout	------------------------------------------------------------
2020-01-07 07:12:08	stdout	-----               SETUID:    1000                    -----
2020-01-07 07:12:08	stdout	-----               SETGID:    1000                    -----
2020-01-07 07:12:08	stdout	-----               PACKAGES:  nano                    -----
2020-01-07 07:12:08	stdout	-----               AVAHI:     false                   -----
2020-01-07 07:12:08	stdout	-----                       ENV                        -----
2020-01-07 07:12:08	stdout	-----                                                  -----
2020-01-07 07:12:08	stdout	-----               npm:       6.13.4                  -----
2020-01-07 07:12:06	stdout	-----               node:      v10.18.0                -----
2020-01-07 07:12:06	stdout	-----               image:     v4.0.0                  -----
2020-01-07 07:12:06	stdout	-----                     Versions                     -----
2020-01-07 07:12:06	stdout	-----                                                  -----
2020-01-07 07:12:06	stdout	-----               arch:      x86_64                  -----
2020-01-07 07:12:06	stdout	-----                      System                      -----
2020-01-07 07:12:06	stdout	-----                                                  -----
2020-01-07 07:12:06	stdout	-----              Debugging information               -----
2020-01-07 07:12:06	stdout	------------------------------------------------------------
2020-01-07 07:12:06	stdout	 
2020-01-07 07:12:06	stdout	------------------------------------------------------------
2020-01-07 07:12:06	stdout	-----                Please be patient!                -----
2020-01-07 07:12:06	stdout	-----          Startupscript is now running.           -----
2020-01-07 07:12:06	stdout	-----       Welcome to your ioBroker-container!        -----
2020-01-07 07:12:06	stdout	------------------------------------------------------------
2020-01-07 07:12:06	stdout	 
2020-01-07 07:12:06	stdout	------------------------------------------------------------
2020-01-07 07:12:06	stdout	---------------     2020-01-07 08:12:06      ---------------
2020-01-07 07:12:06	stdout	------------------------------------------------------------
2020-01-07 07:12:06	stdout	 

Ich habe hier auch schon Probehalber versucht vor dem Einspielen des Backups etwas umzustellen an den IPs. Das hat aber auch nicht funktioniert. Muss ich die Adapter vorher löschen, dann das Backup machen und damit dann den Container erstellen?

Grüße,
Joscha

[jogge]

So ich konnte das Problem lösen.
Habe vor dem Erstellen des Backups die Callback Adressen der HM-Adapter auf die neue IP des Containers eingestellt und unter Adapter Adresse "auf alle IPs hören". Dann das Backup gemacht und im mount-Verzeichnis entpackt, den neuen Container unter Portainer erstellt und zack geht alles. Die Anbindung meiner Geräte über Node Red an Alexa war nun auch möglich. Leider habe ich mir wohl mit dem macvlan Einstellungen die Möglichkeit genommen auf meinen Zigbee-Stick an der DS zugreifen zu können. Im Log steht auch was:

zigbee.0	2020-01-07 21:09:34.854	error	(13470) Error while starting zigbee-shepherd!. Error: Error: No such file or directory, cannot open /dev/ttyACM0

Hat jemand eine Idee wie ich das wieder zum Laufen bekomme?

Grüße,
Joscha

[Troya]

@jogge
Hatte ich mit dem Z-wave Stick:

https://forum.iobroker.net/post/332260

Vielleicht hilft dir das. Ist ein wenig wirr, aber bei den Nachträgen kommt dein Fall...

[jogge]

@Troya MEGA!!! Vielen vielen DANK!!!
Hat geklappt. Jetzt läuft alles wie ich es mir vorstelle ;)

Und ich hab schon im Kopf ein Multihost System aus Docker Containern aufgebaut mit dem Master im macvlan und einen Slave im host Modus um das Problem zu umschiffen. So ist das natürlich super elegant!

Grüße,
Joscha

[andre]

@gerald123
Hallo Gerald,
soweit ich weiß, kannst du pro Netzwerkadapter nur ein MACVLAN definieren.
Was aber geht ist einfach ein größeres MACVLAN zu konfigurieren.
Zum Beispiel mit einem 192.168.0.80/29 Netz. Da hättest du dann 6 IP-Adressen drin und würdest deinen Test-Container dort mit rein hängen. Natürlich mit einem separaten Hostnamen!

Vielleicht reicht es dir aber auch wenn du deinen Test-Container einfach im Bridge-Modus betreibst und nur die benötigten Ports nach außen gibst...

MfG,
André

[andre]

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

Im macvlan braucht man auch das Startscript nicht?

Hallo Thorsten,
die Frage verstehe ich nicht. Das hat beides nichts miteinander zu tun.
Das Startscript ist Teil des Containers und sorgt dafür das ioBroker gestartet wird... grundsätzlich und egal wie dein Netzwerk aussieht...

MfG,
André

[gerald123]

@andre Danke für die Info, ich werde es mal mit dem /29 Netz testen.
Kann ich das Bestehende Netz ändern oder muss ich da ein neuse anlegen?
Hab da noch eine frage, bei den Versuchen mit einem weiteren MACVLAN habe ich nun im Portainer einige nicht funktionierende Netze angelegt. Kann ich die irgendwie wieder Löschen?
Mfg. Gerald

[dos1973]

@gerald123
https://forum.iobroker.net/topic/4733/howto-anleitung-installation-iobroker-in-docker-auf-synology-diskstation/1354

[gerald123]

@dos1973 Hast du es komplett gelöscht oder kann man es bearbeiten und die falschen Netze entfernen?

[dos1973]

Musste es komplett löschen...
Aber die Daten im filesystem bleiben erhalten. Du musst nur in Portainer wieder einrichten

Backup trotzdem!!

[gerald123]

@dos1973 Danke, werde es am Wochenende mal probieren.

[dtp]

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

Backup trotzdem!!

Muss man aber nicht extra machen, wenn man das Docker-Verzeichnis eh schon mit Hyper Backup sichert.

Übrigens, André hatte ja hier beschrieben, wie man den Portainer anlegt. Kleiner Tipp: die mit dem Aufgabenplaner erstellte Aufgabe nicht löschen. Damit kann man nämlich nachträglich sehr einfach den Portainer aktualisieren bzw. neu erstellen. Einfach den alten Portainer löschen, das neue Portainer-Abbild herunterladen und dann wieder die Aufgabe ausführen. Fertig.

[Telefisch]

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

@Telefisch
Wie du schon raus gefunden hast, muss man bei Docker in den meisten Fällen einen neuen Container anlegen. Sollte aber auch kein riesen Ding sein. Dazu gibt es ja schließlich den "Edit/ Duplicate" Button im Portainer....

Was deinen Fehler aus dem Screenshot angeht, da würde ich die Dateien einfach per Hand löschen/ umkopieren und nochmal versuchen... Sieht mir nicht nach nem großen Ding aus...

MfG,
André

Hallo @andre ,
ja, das funktioniert hier anscheinend, ist nur sehr mühselig und kann ja auch nicht des Rätsels Lösung sein.
Ich muss für jede Datei, die nicht gelöscht werden kann einmal das Update laufen lassen weil immer nur die erste in den Meldungen ausgegeben wird :(

Wer ist denn normalerweise Besitzer bzw. wie sind die Rechte der Verzeichnisse einzustellen?
Muss ich vielleicht einen neuen User anlegen? Hat sich da was geändert in der iob Installation?
Ich hab mal chmod -R 777 /opt/iobroker laufen lassen, was ja eigentlich solche Probleme beseitigen müsste aber das hat auch nicht geholfen.

[andre]

@Telefisch Eine andere Lösung habe ich nicht parat. Da müssen die node und npm Profis ran. An den rechten sollte es nicht liegen, die werden eigentlich bei jedem Container start neu gesetzt...

MfG,
André