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

[dtp]

Ich glaube, ich habe die Ursache für mein Problem gefunden.

Mit Port 9000 hatte ich schon bei der MACVLAN-Installation Probleme, so dass ich Port 8889 auf Port 9000 umgeleitet habe. Nur leider geht das im Host-Betrieb ja nicht.

Hat jemand vielleicht einen Tipp? Durch was ist Port 9000 auf der DS blockiert?

[gerald123]

@dtp Bei mir ist Portainer in der Standardinstallation auf Port 9000 angelegt.
Ist das möglicherweise bei dir auch so?

[dtp]

Ich nutze den Portainer ja nicht mehr und hatte den entsprechenden Container wieder deinstalliert. Daher dürfte da ja eigentlich keine Port-Blockierung mehr vorliegen, oder?

9000 und 9001 sind doch die Ports für den Multihost-Betrieb. Kann man den nicht einfach deaktivieren, wenn man ihn - wie ich - nicht nutzt?

EDIT: Ich glaube, es wird mal wieder Zeit für einen Clean Install. :face_with_rolling_eyes: :smirk:

EDIT2: Hab jetzt einen jungfräulichen ioBroker-Container erstellt, dann mit

iobroker backup

ein Backup der alten ioBroker-Konfiguration gemacht und es mit

iobroker restore <Dateiname_Backup_file>

in den neuen Container eingespielt. So wurden alle Adapter neu erstellt. Und jetzt funktioniert auch wieder das Löschen. Einziger Nachteil: ich muss jetzt die Home App wieder komplett neu konfigurieren, weil sie die bisherigen Bridges nicht mehr finden konte. Daher musste ich für jede jahka-Instanz einen neuen User setzen, und darf nun in der Home App wieder gut 200 Devices konfigurieren.

[cash]

Endlich habe auch ich dem Umstieg von der Docker Version 2 auf die 4.1 geschafft. Falls andere auch ein Problem haben will ich hier einmal meinen Weg zeigen. Komplett ohne Terminalbefehle und quasi als Cleaninstall

Vorbemerkungen: Ich nutze Docker im Host-Modus d. h. ioBroker ist über die selbe IP erreichbar wie mein Synology. Über die Paketverwaltung vom Synology habe ich Maria-DB installiert wo ioBroker Daten archiviert (also nicht in einen anderen Docker-Container).
Desweiteren nutze ich viele Scripte die sich mit der Uhrzeit beschäftigen. Ich schreibe einmal im Tag Dämmerungszeiten, Sonnenauf- und -untergang in Objekte. Diese nutze ich um in anderen Scripten zu berechnen wann
z. B. verschiedene Lichter angehen oder die Rollos runterfahren. Für Siri nutze ich Yahka. Für Alexa entsprechend den iot-Adapter. Die meisten Komponenten sind von eq3 also Homematic.

Für meine Zwecke reichen die Einstellmöglichkeiten die Synology für Docker vorsieht deshalb nutze ich kein Portainer.

Vor dem Update habe ich erstmal alle Scripte angepasst die die Astrozeiten in Objekte schreiben weil die neue Version 4 bzw wahrscheinlich die 10er Node-Version nicht mehr die tz-Einstellungen von Docker berücksichtigen.
Die Folge ist das Uhrzeiten in englischer Form ausgegeben werden. Statt "7:29:21" kommt die Ausgabe "7:29:21 AM". Beim ersten Updateversuch vor ein paar Wochen war das der Punkt das ich das Update abgebrochen habe weil viele Script damit bei mir nicht mehr liefen.

Konkret habe ich nach folgenden Muster geändert:

Alt: let sunrise = getAstroDate("sunrise").toLocaleTimeString();
Neu: let sunrise = getAstroDate("sunrise").toLocaleTimeString('de-DE', { hour12: false });

Danach mittels Backitup-Adapter ein Backup erstellt. Das Backup wird unter dem gemounteten Ordner auf die Synology erstellt wo auch ioBroker installiert ist. Bei mir: "docker\iobroker_daten_19-05-21". Dort legt Backitup ein Unterverzeichnis an wo das gezippte Backup liegt.
Für die neue Installation habe ich einen neuen Ordner angelegt "docker\iobrroker_20-01-26"

Mit dem Filemanager von Synology habe ich die Backupdatei dann direkt in das Hauptverzeichnis "iobrroker_20-01-26" kopiert.

Danach habe ich den Container mit der Version 2 einfach angehalten. Danach die V4.1 runtergeladen und ein neuen Container angelegt. Dort habe ich nur 3 Einstellungen vorgenommen:

1: Host-Modus
2: Mount-Verzeichnis "docker\iobrroker_20-01-26" nach "/opt/iobroker/"
3: avhai von false auf true

Danach den Container V4 starten. Das Script von Andre erkennt das im gemounteten Verzeichnis ein Backup liegt und ansonsten keine ioBroker Installation vorliegt. Somit installiert es zuerst ioBroker mit dem aktuellen js-controller und startet anschließend den restore. Nach nur wenigen Sekunden (10-30) ist iobroker über die bekannte Adresse erreichbar und unter dem Menüpunkt log sieht man wie ein Adapter nach den anderen installiert wird. Die Scripte und Datenpunkte sind schon vorhanden. Im Normalfall sollte im Log keine Fehler zu finden sein. Bei mir gab es einen Fehler mit dem Nuki-extended Adapter da dort der Name geändert wurde und er es so nicht installieren konnte (habe ich hinterher manuell gemacht.)
Die Instanzen werden nicht automatisch gestartet. Nach dem Restore (bei mir etwa 20-30 Minuten). Habe ich also die Instanzen manuell gestartet.

4 Probleme hatte ich:
1: den Nuki Adapter musste ich manuell nachinstallieren.
2: Unter den Einstellungen vom Javascript-Adaptern musste ich die GPS-Koordinaten eingeben damit die Script mit den Astrozeiten funktionierte Die Einstellung dort die GSP-Daten von der zentralen Konfig zu nehmen funktioniert nicht.
3: iot-Adapter. Beim starten vom Adapter gab es Fehlermeldungen im Log. Nach Neueingabe von User und Kennwort unter den iot-Einstellungen und Anforderung vom neuen Zertifikat lief der Adapter.
4: yahka. Der Adapter wurde grün aber in Homekit waren alle Geräte nicht erreichbar.

Problemlösung yahka: Ich habe unter den Einstellungen im Adapter eine neue Mac-Adresse eingegeben und einen neuen Namen.
Im Homekit habe ich die alte yahka-Bridge gelöscht und unter Neu anlegen tauchte die neue sofort auf. Nach PIN-Eingabe darf man direkt allen Geräten einen Raum zuordnen.

Vorteil dieser Methode: Man braucht nicht ein Terminalbefehl verwenden. Man erspart sich das manuelle Update von node oder dem js-controller. Die Problem-Punkte 1-3 sind schnell behoben einzig die Neueinrichtung von yahka ist natürlich ein großer Nachteil und je nach Geräteanzahl etwas aufwendiger.

Ein großer Vorteil ist natürlich das falls beim Update irgend etwas nicht läuft im log komische Fehler kommen kann man einfach im Admi-Bereich von Synology den Container V4.1 stoppen und den alten wieder starten. Ohne zusätzliche Sicherung oder großen Zeitverlust. Dadurch das man nicht das alte Verzeichnis nutzt oder komplett kopiert hat man quasi fast einen Cleaninstall.

[dtp]

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

Problemlösung yahka: Ich habe unter den Einstellungen im Adapter eine neue Mac-Adresse eingegeben und einen neuen Namen.

Einen neuen Namen für die Bridge bzw. die yahka-Instanz hättest du gar nicht vergeben brauchen. Die Vergabe eines neuen User-Namens (analog MAC-Adresse) hätte genügt. ;)

Was mir wirklich gut an dem yahka-Adapter gefällt, ist die simple Möglichkeit, weitere Bridges mittels Instanzen einzurichten, da ja bekanntlich Homekit nur ca. 100 Geräte pro Bridge/Instanz unterstützt.

[cash]

Den neuen Namen hat den Vorteil das man die neue und alte Bridge besser auseinander halten kann. Ich habe die alte erst gelöscht als die neue lief. Das hat den Vorteil, dass falls ich doch mit der V2 erst weiter gemacht hätte ich nur den Container neu starten musste ich die Geräte sofort verfügbar sind.

Ich habe bei mir nicht soviele Geräte eingebunden, da ich mit Siri z. B. nie die Heizung steuere also habe ich dort nur eine kleine Auswahl genommen.

Die Frage wäre ja warum man überhaupt das ganze neu machen muss. Das müsste man noch irgendwie hinkriegen dann wäre das wiederherstellen per Backup wirklich die einfachste und sauberste Lösung. Ich vermute das das Backup irgend etwas nicht mitsichert und man dadurch bei yahka eine neue Bridge benötigt...

[dos1973]

kurze Backup Frage.
ich nutze noch das Script von Andre aus der v2 Anleitung.
Im ersten Part des scripts wird der container angehalten.

ich erhalte leider seit ein paar Wochen ein Fehler - also kein Backup gemacht.

docker stop iobroker
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.39/containers/iobroker/stop: dial unix /var/run/docker.sock: connect: permission denied

hat jemand eine Idee wie ich das fixen kann... Danke

[RK62]

@dos1973 Für meinen Bitwarden Container verwende ich das folgende Script, vielleicht hilft dir das weiter, es nutzt die Synology WebAPI, dann gibts auch im DSM keine Fehlermeldungen über abgebrochene Container mehr.

Gruß, Ralf

# docker container stop
/usr/syno/bin/synowebapi --exec api=SYNO.Docker.Container version=1 method=stop name=bitwarden
zip -r $bwBackup/$bwFile $bwPfad
# docker container start 
/usr/syno/bin/synowebapi --exec api=SYNO.Docker.Container version=1 method=start name=bitwarden

[ozboss]

Ich habe versuch ein js-conroller update mit dieser Vorlage von @andre zu machen.
Leider bekomme ich bei dem Befehl iobroker update ein "Permission denied".
Wenn ich die alternative Variante mit npm install iobroker.js-controller –-production versuche bekomme ich folgende Fehler:

npm ERR! code EINVALIDTAGNAME
npm ERR! Invalid tag name "–-production": Tags may not have any characters that encodeURIComponent encodes.

npm ERR! A complete log of this run can be found in:
npm ERR!     /opt/iobroker/.npm/_logs/2020-02-02T15_05_21_768Z-debug.log

Kann mir da jemand weiterhelfen?

Edit:
Ich habe auch versucht den Befehl mit sudo auszuführen und mich in Portainer als root in den Container einzuloggen, aber beides hat nicht geholfen.
Ich habe auch den Befehl curl -sL https://iobroker.net/fix.sh | bash - versucht, wie von in der Update Anleitung von iobroker empfohlen, hat leider auch nichts gebracht.

[dos1973]

hi,
mein container heisst einfach iobroker...
so geht es nicht, erhalte Permission denied.

/usr/syno/bin/synowebapi --exec api=SYNO.Docker.Container version=1 method=stop name=iobroker

was ist dieser Teil? bwFile und Pfad
@RK62 sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:

zip -r $bwBackup/$bwFile $bwPfad

edit: mit sudo, dann klappt es.
Und via Aufgabenplanung scheint es auch zu gehen . keine DSM FM!

an dem letzen Pfad und File wäre ich dennoch interessiert.
Klasse & besten Dank dafür!

[RK62]

@dos1973 Schön, dass es funktioniert!
Ich hatte die Zeilen einfach aus einem laufenden Script kopiert.
Mit dem zip-Befehl erstelle ich ein Backup des gemounteten Bitwarden-Pfades.
$bwBackup = Variable für den Backup-Pfad
$bwFile = Variable für den Namen der zip-Datei
$bwPfad = Variable für den Pfad der gesichert werden soll.

bwToday=$(date +%Y-%m-%d_%H%M)
bwFile="bitwarden_backup_$bwToday.zip"
bwPfad='/volume1/docker/prod/bitwarden'
bwBackup='/volume1/BACKUP-1/MIRROR/bitwarden'

[dos1973]

@RK62
Alles klaro, das backup / kopieren un zippen der Daten funktioniert ja aus dem Original script. Ich habe nur die Start/Stop Befehle mit deinen ersetzt.

Backup heute Nacht ordentlich gelaufen

[ozboss]

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

Ich habe versuch ein js-conroller update mit dieser Vorlage von @andre zu machen.
Leider bekomme ich bei dem Befehl iobroker update ein "Permission denied".
Wenn ich die alternative Variante mit npm install iobroker.js-controller –-production versuche bekomme ich folgende Fehler:

Also es scheint zu funktionieren, wenn ich mich als Benutzer "iobroker" anmelde. Aber auch nur wenn ich iobroker update mit sudo ausführe. Leider werde ich dann nach einem Passwort gefragt welches ich natürlich nicht habe....

Mod-Edit: Vollzitat gekürzt! Bitte vermeidet Vollzitate! Siehe Forum Regeln, Punkt 2

[Telefisch]

Hallo...
nachdem mein container mittlerweile einwandfrei lief habe ich heute den „Fehler“ gemacht und den VMM auf der DS installiert.
Prompt kommt beim Starten des Containers der Fehler „failed to create Macvlan: device or resource busy“

Kennt da jemand ne Lösung für?
Das macvlan hat eine eigene Adresse, sodass das eigentlich nicht kollidieren dürfte aber ich denke dass sich die Netzwerkkarte hier bereits in Benutzung befindet.
Ich finde aber auch keinen Weg um den VMM kurzfristig zu Testzwecken zu deaktivieren und einfach deinstallieren ist ja keine Lösung.

Gruß
Carsten

[andre]

@Telefisch Der VMM installiert eine "Virtualisierungsschicht" auf die Netzwerkdevices. Das bedeutet dass jetzt ein virtuelles Device die IP-Adresse deiner DS hält.... Mach mal ein "ifconfig" auf der Kommandozeile deiner DS, dann siehst du was ich meine.
Du musst dein MACVLAN neu anlegen und das korrekte Netzwerkdevice angeben. Dann funktioniert dein MACVLAN und auch der Container wieder....

MfG,
André

[Telefisch]

@andre perfekt, Andre.
Vielen Dank, nu läuft es wieder :)
Netzwerkdevice heißt jetzt ovs_eth0
Dankeschööön

[tugsi]

@andre Was es nicht alles gibt ;)
Hatte VMM schon laufen, bevor ich MACVLAN eingerichtet hatte, daher ist mir das gar nicht aufgefallen, aber gut zu wissen, falls man mal alles neu machen muss.
Danke.

[Negalein]

@andre

Kann ich im Docker oder Portainer was einstellen, dass der Container nach einem Stromausfall wieder automatisch gestartet wird?

Portainer funktioniert, nur der ioBroker wird nach einem Stromausfall nicht wieder gestartet.

[Glasfaser]

@Negalein

[tugsi]

@Negalein
a) wie @Glasfaser es angibt, das geht im Docker von Synology

oder

b) unter Portainer, da musst dann aber unter Duplicate/Edit es einstellen:

Beides geht nur, wenn der Container gestoppt ist.