Hallo Leute,
vielen Dank für eure Hilfe, den Port habe ich gefunden. Es ist der Port 8883 Secure MQTT (Message Queue Telemetry Transport over SSL). Falls Ihr eure Firewall auch entsprechend bearbeitet und ihr den iot-Adapter nutzt solltet ihr diesen Port mit öffnen.
Gruß
Matze77
Hallo,
also erstmal Danke das Ihr auf meine Frage reagiert habt und sorry das ich mich hier so spät erst wieder melde.
Wie es Wildbill schon richtig erkannt hat, ist ein steuern über den Unifi Adapter nicht möglich.
Auf die Frage "Aber, warum sollte man den Edgerouter von iobroker aus herunter fahren wollen?", kann ich wie folgt Antworten:
Ich möchte gerne etwas meine Stromkosten senken und daher soll meine Technik (Server, Switche, Gateway, Raspberry und der Edgerouter) in der Nacht vom Stromnetz automatisch getrennt werden und da der Edgerouter aber vor dem abschalten der Spannung gerne einen Shutdown möchte soll er diesen halt bekommen. Des Weiteren können die Zeiten für einen Shutdown dann auch variieren oder sogar ausgesetzt werden.
Nach einigen Recherchen im Netz und Tests habe ich die Lösung gefunden und kann nun Mittels Blockly Script den Router herunterfahren oder auch einen Reboot durchführen und wenn ich wollte ( das fällt mir übrigens gerade ein 
) einen VPN -Tunnel Starten oder beenden. Die Möglichkeiten sind wieder vielfältig 
Das Vorgehen ist eigentlich relativ simpel und kann einfach umgesetzt werden. Ihr müsst beachten das eine Anmeldung vom ioBroker auf dem Edgerouter nur per Zertifikat möglich ist. Und damit stehen wir am Anfang des Tutorial
Als erstes richten wir auf dem Edgerouter einen neuen User z.B. "ioBroker" ein
Ist das geschehen, nutzen wir vom ioBroker das CLI (Terminal) und melden uns als "iobroker" an - bitte nicht als root!!! Ich mache dies über Docker oder Portainer.
Sind wir im Terminal als "iobroker" angemeldet wechseln wir über cd (Change Directory) in das Verzeichnis /opt/iobroker/.ssh => das ist ein Verzeichnis, welches im Docker auch gemountet und somit bei einem Update nicht überschrieben wird.
Sind wir in dem Verzeichnis /opt/iobroker/.ssh führen wir dort den Befehl ssh-keygen aus. Es kommt nun eine Frage wie das Zertifikat genannt werden soll, drückt ihr nun einfach Enter wird dies als Standard id_rsa bezeichnet ich würde dies aber ioBroker nennen wollen und dann Enter drücken. Als nächstes werdet ihr nach einer Passphrase und dessen Wiederholung gefragt hier drücken wir aber einfach nur Enter.
Mit diesen Schritten werden in unserem Verzeichnis zwei Dateien erstellt, dies könnt Ihr mit dem Befehl ls prüfen. Es müssen folgende Dateien sein, einmal ioBroker.pub dies ist das Public-Zertifikat (Öffentliches Zertifikat) und ioBroker dies ist der Privat-Key (Privater Schlüssel) => mit diesen Privaten Schlüssel solltet ihr behutsam umgehen.
Sind die zwei Dateien nun vorhanden führen wir folgenden Befehl aus cat ioBroker.pub damit wird Euch das Public-Zertifikat angezeigt. Den Key markiert ihr und kopiert ihn euch in eine Textdatei, ist aber nicht zwingend erfoderlich da wir das Terminal vom iobroker nicht schliessen werden.
Jetzt melden wir uns mit dem am Anfang angelegten User ioBroker am Edgerouter auch im CLI über Putty an.
Sind wir im Edgerouter Terminal angemeldet so prüfen wir mit dem Befehl pwd in welchem Verzeichnis wir uns befinden. Dies sollte /home/ioBroker sein, ist das der fall können wir mit dem Befehl ls -ahl schauen ob sich hier ein Ordner .ssh befindet. Ist der Ordner vorhanden können wir mit cd in diesen wechseln.
In diesem Schritt gehe ich davon aus das Ihr mit dem Texteditor vi umgehen könnt. Also wir erstellen nun eine Datei mit dem Texteditor, der Befehl lautet vi ioBroker.pub. Die Datei wird mit drücken der Enter-Taste geöffnet, in diese Datei kopiert ihr euch den Key den wir weiter oben zwischen gespeichert haben oder holt euch diesen nochmals aus dem noch offenen Terminal vom iobroker. Ist das geschehen, speichert Ihr die Datei und schliesst diese. Wenn Ihr wollt, könnt Ihr die Datei nochmals öffnen und prüfen ob auch alles gespeichert wurde.
Haben wir die Datei ioBroker.pub nun auf dem Edgerouter im Verzeichnis /home/ioBroker/.ssh erstellt, können wir das Public-Zertifakt nun laden lassen. Diese geschieht im Config Modus, dafür geben wir einem den Befehl configure ein und danach den Befehl pwd damit sehen wir ob wir noch im entsprechenden Verzeichnis /home/ioBroker/.ssh sind. Ist das der Fall, laden wir jetzt mit dem Befehl loadkey ioBroker /home/ioBroker/.ssh ioBroker.pub das Zertifikat - zur Info befinden wir uns nicht im richtigen Verzeichnis ist das nicht weiter schlimm, da in dem load-Befehl das Verzeichnis mit angebeben wurde.
Somit sind alle Aufgaben auf dem Edgerouter erledigt und wir benden die Session mit dem Befehl save und dann zweimal mit exit
Jetzt geht es wieder in das Terminal von iobroker zurück. Da wir nun alle Voraussetzungen hergestellt haben um vom iobroker aus auf den Edgerouter zu zugreifen, werden wir jetzt noch den Fingerprint bestätigen müssen. Dafür müssen wir uns aus dem Terminal vom iobroker in den Edgerouter anmelden. Dafür nutzen wir den Befehl ssh -i /opt/iobroker/.ssh/ioBroker ioBroker@ipEdgerouter nach dem drücken der Enter-Taste kommt der sogenannte Fingerprint diesen müsst Ihr mit yes (bitte schreiben nicht nur y) einmalig bestätigen. Allerdings heist einmalig => nur sollange sich die IP vom Edgerouter oder im Netzwerk sich nichts tiefgreifendes ändert.
Wenn alles geklappt hat sollltet ihr jetzt am Edgerouter angemeldet sein. Damit wäre jetzt das Tutorial beendet.
Mit diesen Einstellungen könnt ihr jetzt aus einem Script mit dem Baustein exec und dem Befehl "ssh -i /opt/iobroker/.ssh/ioBroker ioBroker@ipEdgerouter sudo shutdown -P now den Router in den OFF-Modus setzen.
Bitte achtet auf den Buchstaben B im iobroker, ich habe gerade gesehen das es vielleicht doch für einige verwirrend sein kann, zumindest in dem Tutorial. Auch müsst ihr nicht immer in das entsprechende Verzeichnis wechseln sondern, könnte den Pfad im Command mit angeben. Die Profis werden das aber wissen
Übrigens kann man das so ähnlich auch auf Unifi-Geräten nutzen um z.B. POE zuschalten.
Ich wünsch Euch damit viel Spaß und hoffe das es verständlich war.
Beste Grüße
Matze77
Hallo Zusammen,
Sorry Jungs für die späte Rückmeldung. Der Fehler war doch recht schnell, dank dem Stichwort "Netzwerk" von Apollon77, gefunden.
Mit dem Befehl "traceroute a18wym7vjdl22g.iot.eu-west-1.amazonaws.com" konnte ich dann sehen, dass der Weg über ein anderes Gateway genommen wurde. Dazu müsst ihr vielleicht noch Wissen, dass bei mir der ioBroker in 3 VLans eingebunden ist.
Was ich bei der Installation von iobroker unter Ubuntu-Server nicht bedacht hatte, war das durch die unterschiedlichen IP´s der Gateways auch jeweils eine Default-Route mit angelegt wird. Somit hatte ich am Ende 3 Default-Routen was dann das Problem verursacht hatte. Habe die Gateway´s in der Konfiguration (Ubuntu=netplan) aus zwei Vlan´s entfernt und hier nur eine Static-Route zugewiesen, das Haupt-Lan lies ich in der Konfiguration unberührt.
Mittlerweile läuft der ioBroker sauber in der VM und er tut was er soll
@bluefox sagte in [iot] iot-Adapter verbindet sich nicht bzw Verbindung ist "gelb":
Wurde
npm rebuildnach dem Umzug ausgeführt?
@Bluefox: Nein dies habe ich nicht durchgeführt. Ist es ratsam dies zutun?
Besten Dank an Apollon77 und Bluefox.
Viele Grüße und noch einen tollen Sonnatg
Matze77
@mcm1957
Vielen Dank, für Deine Rückmeldung. Ich werde sehen was ich tun kann.
Bis bald mal wieder 
Hallo Zusammen,
ich habe mich mit dem Adpater MQTT beschäftigt und wollte mich per SSL verbinden, dabei habe ich einiges an Nerven und Test gelassen! Ich würde dazu gerne "Fehler" im AdapterCode und mögliche Korrekturen im AdapterCode melden, um diese Funktion zu gewährleisten. Auch habe ich eventuell einen aktzeptablen Ansatz um "Self Sign Certificate" zu nutzen.
Betreffen würde es die Dateien im lib Verzeichnis (client.js | server.js und ggf. securityChecker.js). Für den Checker habe ich noch nicht weitergetestet.
Es wäre Cool, wenn sich eventuell einer der Entwickler dieses Adapters melden könnte! Ich möchte mich ungern bei Github nur für ein Issue Registrien.
Sollte das Thema falsch platziert sein, habt ein Nachsehen.
Viele Grüße
Matze
Ich habe meinen Fehler gefunden.
Für die zwei Interfaces habe ich wieder jeweils ein Gateway zugewiesen. Und habe nochmal das entsprechende Subnetz eingegeben in dem sich der HUB befindet und alles funktionierte.
Mein Fehler war beim ersten mal, das ich hier das Subnetz so angegeben habe z.B. "1.1.1.0/24" und jetzt beim zweiten mal 1.1.1.0
Also mein Fehler! 
Somit braucht es nun keine Änderung mehr am Adapter.
Grüße
Matze77
@homoran Nein, das hatte ich probiert und es hat nicht funktioniert. Es müsst so sein wie z.B bei dem Homematic Adapter, Sonoff Adapter oder Shelly Adapter. Bei diesen Adaptern kann man sagen auf welchem Interface sie lauschen sollen.
Hey Leute,
mein ioBroker hat 3 Netzwerkschnittstellen, also er befindet sich in 3 Subnetzen, soweit läuft auch alles ohne Probleme.
Zur weiteren Ausführung sollte noch gesagt sein, das dieser auf einen Ubuntu-Server läuft. Die 3 Schnittstellen habe ich über Netplan (Format yaml) konfiguriert. Wobei ich für eine Schnittstelle ein Gateway angelegt habe und für die anderen Beiden Routen festgelegt habe. Wie gesagt alles funktioniert Reibungslos.
Jetzt habe ich in meinen Netzwerk einige Änderungen vorgenommen und müsste der Richtigkeit halber nun den zwei Schnittstellen auch ein Gateway zuweisen. Das hatte ich auch gemacht und auch hier lief alles bis auf den Harmony-Adapter.
Ich denke, wenn man in dem Adapter die Möglichkeit hätte zusagen, du hörst auf dem Interface, dann wäre das Problem auch behoben.
Wie könnte man das realisieren?
Vielen Dank.
Gruß
Matze77
Hey Leute,
bei mir läuft auch die Meldung seit heute Morgen ein, gibt es dazu vielleicht schon was neues!?
Grüße
@homoran vielen Dank für die Info, habe "npm-rebuild" noch durchgeführt. Nach wie vor läuft der ioBroker ohne Probleme in der VM.
Beste Grüße
Matze77
Hallo Zusammen,
Sorry Jungs für die späte Rückmeldung. Der Fehler war doch recht schnell, dank dem Stichwort "Netzwerk" von Apollon77, gefunden.
Mit dem Befehl "traceroute a18wym7vjdl22g.iot.eu-west-1.amazonaws.com" konnte ich dann sehen, dass der Weg über ein anderes Gateway genommen wurde. Dazu müsst ihr vielleicht noch Wissen, dass bei mir der ioBroker in 3 VLans eingebunden ist.
Was ich bei der Installation von iobroker unter Ubuntu-Server nicht bedacht hatte, war das durch die unterschiedlichen IP´s der Gateways auch jeweils eine Default-Route mit angelegt wird. Somit hatte ich am Ende 3 Default-Routen was dann das Problem verursacht hatte. Habe die Gateway´s in der Konfiguration (Ubuntu=netplan) aus zwei Vlan´s entfernt und hier nur eine Static-Route zugewiesen, das Haupt-Lan lies ich in der Konfiguration unberührt.
Mittlerweile läuft der ioBroker sauber in der VM und er tut was er soll
@bluefox sagte in [iot] iot-Adapter verbindet sich nicht bzw Verbindung ist "gelb":
Wurde
npm rebuildnach dem Umzug ausgeführt?
@Bluefox: Nein dies habe ich nicht durchgeführt. Ist es ratsam dies zutun?
Besten Dank an Apollon77 und Bluefox.
Viele Grüße und noch einen tollen Sonnatg
Matze77
@apollon77 sagte in [iot] iot-Adapter verbindet sich nicht bzw Verbindung ist "gelb":
@matze77 Dann wäre ich gefühlsmäßig beim Netzwerk ... weil man klar sieht das er keine Connection bekommt. DNS?
Danke apollon77 für die Rückmeldung.
Hm.. DNS war auch meine Vermutung aber ersten laufen auf dem Server mehrere VM´s die ebenso im gleichen Netzwerk laufen und keine Verbindungsprobleme haben. Ich habe jetzt nochmal eine DNS Abfrage auf den Link zur Cloud gemacht und hier sagt mir der iobroker klar die IP. Also DNS ist es denke ich nicht.... Auch habe ich als sekundären DNS Server die 8.8.8.8 hinterlegt.
xxxxx@iobroker-xxxxx:~$ nslookup a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 54.154.244.118
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 54.229.255.215
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 52.18.147.77
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 34.255.175.71
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 52.30.138.188
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 52.30.108.130
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 52.215.109.10
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 52.30.161.110
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 2a01:578:3::22fa:435d
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 2a01:578:3::3431:b404
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 2a01:578:3::3413:a7c4
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 2a01:578:3::3432:3d2
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 2a01:578:3::3430:1717
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 2a01:578:3::36c2:ffaf
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 2a01:578:3::3413:a81a
Name: a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
Address: 2a01:578:3::34d0:73e5
xxxxx@iobroker-xxxxx:~$
Vielleicht noch eine Idee?
Gruß
Matze77
Guten Morgen Zusammen,
ich habe auch ein Problem mit dem iot Adapter.
Vor dem Umzug vom Docker (Buanet Image) in eine virtuelle Maschine mit Ubuntu Server habe ich mir ein Backup erstellt und nach der Installation von ioBroker in der VM wieder eingespielt. Soweit hat alles geklappt, nur der iot-Adapter bleibt Gelb.
Was habe ich probiert:
Die Meldungen im Log irritieren mich allerdings ein wenig, trotz das alle Geräte gelöscht wurden, werden beim Start des iot-Adapters immer wieder Geräte angelegt. Ich denke das wird das Problem sein oder?
iot.0 2021-06-03 06:41:19.626 debug (248915) reconnect
iot.0 2021-06-03 06:41:14.626 info (248915) Connection changed: disconnect
iot.0 2021-06-03 06:41:14.625 debug (248915) offline
iot.0 2021-06-03 06:40:44.580 debug (248915) URL key is "YYYYYYYYYYYYYYYYYYYYYYYYYYYYY", clientId: XXXXXXXXXXXXXXXXXXX
iot.0 2021-06-03 06:40:43.301 debug (248915) Fetching URL key...
iot.0 2021-06-03 06:40:41.914 debug (248915) [ALEX3] Created entertainment ALEXA device: Commands
iot.0 2021-06-03 06:40:41.914 debug (248915) [ALEX3] Created entertainment ALEXA device: Commands
iot.0 2021-06-03 06:40:41.914 debug (248915) [ALEX3] Created entertainment ALEXA device: Commands
iot.0 2021-06-03 06:40:41.914 debug (248915) [ALEX3] Created entertainment ALEXA device: HmIP FROLL 001158A99291ED 5
iot.0 2021-06-03 06:40:41.914 debug (248915) [ALEX3] Created entertainment ALEXA device: HmIP FROLL 001158A99291ED 6
iot.0 2021-06-03 06:40:41.914 debug (248915) [ALEX3] Created entertainment ALEXA device: HmIP FROLL 001158A99291F1 5
iot.0 2021-06-03 06:40:41.913 debug (248915) [ALEX3] Created entertainment ALEXA device: HmIP FROLL 001158A99291F1 6
iot.0 2021-06-03 06:40:41.913 debug (248915) [ALEX3] Created entertainment ALEXA device: HmIP FROLL 001158A9929205 5
iot.0 2021-06-03 06:40:41.913 debug (248915) [ALEX3] Created entertainment ALEXA device: HmIP FROLL 001158A9929205 6
iot.0 2021-06-03 06:40:41.913 debug (248915) [ALEX3] Created entertainment ALEXA device: HmIP FROLL 001158A9929207 5
iot.0 2021-06-03 06:40:41.913 debug (248915) [ALEX3] Created entertainment ALEXA device: HmIP FROLL 001158A9929207 6
iot.0 2021-06-03 06:40:41.913 debug (248915) [ALEX3] Created entertainment ALEXA device: HmIP FROLL 001158A992921C 5
iot.0 2021-06-03 06:40:41.913 debug (248915) [ALEX3] Created entertainment ALEXA device: HmIP FROLL 001158A992921C 6
iot.0 2021-06-03 06:40:41.913 debug (248915) [ALEX3] Created entertainment ALEXA device: HmIP FROLL 001158A9929294 5
iot.0 2021-06-03 06:40:41.912 debug (248915) [ALEX3] Created entertainment ALEXA device: HmIP FROLL 001158A9929294 6
iot.0 2021-06-03 06:40:41.912 debug (248915) [ALEX3] Created entertainment ALEXA device: HmIP FROLL 001158A992BD0B 5
iot.0 2021-06-03 06:40:41.912 debug (248915) [ALEX3] Created entertainment ALEXA device: HmIP FROLL 001158A992BD0B 6
iot.0 2021-06-03 06:40:41.912 debug (248915) [ALEX3] Created entertainment ALEXA device: Main Zone
iot.0 2021-06-03 06:40:41.912 debug (248915) [ALEX3] Created entertainment ALEXA device: Player
iot.0 2021-06-03 06:40:41.912 debug (248915) [ALEX3] Created entertainment ALEXA device: Player
iot.0 2021-06-03 06:40:41.912 debug (248915) [ALEX3] Created entertainment ALEXA device: R Ank Empfänger
iot.0 2021-06-03 06:40:41.912 debug (248915) [ALEX3] Created entertainment ALEXA device: R B Empfänger
iot.0 2021-06-03 06:40:41.911 debug (248915) [ALEX3] Created entertainment ALEXA device: R Bad Empfänger
iot.0 2021-06-03 06:40:41.911 debug (248915) [ALEX3] Created entertainment ALEXA device: R K Empfänger
iot.0 2021-06-03 06:40:41.911 debug (248915) [ALEX3] Created entertainment ALEXA device: R Schl Empfänger
iot.0 2021-06-03 06:40:41.911 debug (248915) [ALEX3] Created entertainment ALEXA device: R W S Empfänger
iot.0 2021-06-03 06:40:41.911 debug (248915) [ALEX3] Created entertainment ALEXA device: R W T Empfänger
iot.0 2021-06-03 06:40:41.911 debug (248915) [ALEX3] Created entertainment ALEXA device: Zone 2
iot.0 2021-06-03 06:40:41.911 debug (248915) [ALEX3] Created entertainment ALEXA device: Zone 3
iot.0 2021-06-03 06:40:41.908 debug (248915) [ALEX3] Invalid state "sonoff.0.Lampe.alive". Not exist or no native part.
iot.0 2021-06-03 06:40:41.907 debug (248915) [ALEX3] Invalid state "hm-rpc.3.updated". Not exist or no native part.
iot.0 2021-06-03 06:40:41.906 debug (248915) [ALEX3] Invalid state "hm-rpc.2.updated". Not exist or no native part.
iot.0 2021-06-03 06:40:41.906 debug (248915) [ALEX3] Invalid state "hm-rpc.1.updated". Not exist or no native part.
iot.0 2021-06-03 06:40:41.904 debug (248915) [ALEX3] Invalid state "hm-rpc.0.updated". Not exist or no native part.
iot.0 2021-06-03 06:40:41.903 debug (248915) [ALEX3] Invalid state "admin.0.info.newsfeed". Not exist or no native part.
iot.0 2021-06-03 06:40:41.903 debug (248915) [ALEX3] Invalid state "admin.0.info.newsETag". Not exist or no native part.
iot.0 2021-06-03 06:40:41.903 debug (248915) [ALEX3] Invalid state "admin.0.connected". Not exist or no native part.
iot.0 2021-06-03 06:40:41.902 debug (248915) [ALEX3] Invalid state "0_userdata.0.example_state". Not exist or no native part.
iot.0 2021-06-03 06:40:41.857 debug (248915) [ALEXA] Name "R-W-T = Empfänger.ACTIVITY_STATE" cannot be written and will be ignored
iot.0 2021-06-03 06:40:41.555 debug (248915) Fetching keys...
iot.0 2021-06-03 06:40:41.543 info (248915) Connecting with a18wym7vjdl22g.iot.eu-west-1.amazonaws.com
iot.0 2021-06-03 06:40:41.522 info (248915) starting. Version 1.8.16 in /opt/iobroker/node_modules/iobroker.iot, node: v12.22.1, js-controller: 3.2.16
iot.0 2021-06-03 06:40:41.519 debug (248915) Plugin sentry destroyed because not initialized correctly
iot.0 2021-06-03 06:40:41.517 debug (248915) Plugin sentry Do not initialize Plugin (enabled=false)
iot.0 2021-06-03 06:40:41.314 debug (248915) statesDB connected
iot.0 2021-06-03 06:40:41.313 debug (248915) States connected to redis: 127.0.0.1:6379
iot.0 2021-06-03 06:40:41.306 debug (248915) States create User PubSub Client
iot.0 2021-06-03 06:40:41.306 debug (248915) States create System PubSub Client
iot.0 2021-06-03 06:40:41.302 debug (248915) Redis States: Use Redis connection: 127.0.0.1:6379
iot.0 2021-06-03 06:40:41.301 debug (248915) objectDB connected
iot.0 2021-06-03 06:40:41.297 debug (248915) Objects connected to redis: 127.0.0.1:9001
iot.0 2021-06-03 06:40:41.291 debug (248915) Objects client initialize lua scripts
iot.0 2021-06-03 06:40:41.290 debug (248915) Objects create User PubSub Client
iot.0 2021-06-03 06:40:41.290 debug (248915) Objects create System PubSub Client
iot.0 2021-06-03 06:40:41.289 debug (248915) Objects client ready ... initialize now
iot.0 2021-06-03 06:40:41.274 debug (248915) Redis Objects: Use Redis connection: 127.0.0.1:9001
host.ioBroker 2021-06-03 06:40:40.714 info instance system.adapter.iot.0 started with pid 248915
host.ioBroker 2021-06-03 06:40:40.613 info "system.adapter.iot.0" enabled
Vielleicht noch zur Info beide Systeme Docker sowie die VM und alle Adapter haben die gleichen Versionen. Wird der ioBroker im Docker wieder gestartet und die Zertifikate neu angefordert so wird der Adapter hier wieder Grün, nur aus der VM heraus bleibt er Gelb auch mit der Anforderung neuer Zertifikate.
Vielleicht habt ihr ja eine Idee woran es liegen kann und warum der iot-Adapter die Geräte beim Start anlegt?
Vielen Dank schon mal für Eure hilfe.
Gruß
Matze77
