[iot] iot-Adapter verbindet sich nicht bzw Verbindung ist "gelb"
-
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 -
@matze77 sagte in [iot] iot-Adapter verbindet sich nicht bzw Verbindung ist "gelb":
Ist es ratsam dies zutun?
nicht nur ratsam, sondern notwendig, wenn es sich um andere node-Versionen (auch für andere Hardware) handelt.
-
@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 -
Hi...
Ich hab jetzt auch das Problem. Hab heute meinen Pro-Account bestellt und aktiviert...
- Versucht Instanz durchzustarten -> Gelb
- Instanz/Adapter Deinstalliert, Installiert, Konfiguriert -> Gelb
- Zertifikate neu angefordert -> Gelb
- User/Pass gelöscht, gespeichert, nochmal richtig eingegeben und wieder neu gestartet -> Gelb
- npm rebuild ausgeführt, iot Instanz neu gestartet -> Gelb
Fehlermeldung:
iot.0
2022-02-24 14:54:56.413 error Cannot read URL key: {}Keine Ahnung, was ich noch machen kann/soll, um das Problem evtl. beheben zu können.
AdapterVersion: v1.9.7
Verbunden mit Host -> Grün
Lebenszeichen -> Grün
Verbunden mit Gerät oder Dienst -> RotJemand eine Idee?
Danke!
-
Versuch mal in den Objekten die Certs zu löschen.
-
@thomas-braun leider bringt das keine Änderung
Kann das etwas damit zu tun haben, dass ioBroker bei mir im Container läuft?
-
Bin ich ja bekanntermaßen kein Freund von, sollte aber hier keine Rolle spielen (Wenn da nicht als root herumgehampelt wird...).
Ein Start des Adapters schlägt sich wie genau im Log nieder? -
iot.0 2022-02-24 15:17:30.117 error Cannot read URL key: {} iot.0 2022-02-24 15:17:28.084 info starting. Version 1.9.7 in /opt/iobroker/node_modules/iobroker.iot, node: v14.19.0, js-controller: 3.3.22Mehr seh ich nicht.
MOD Edit: Das bisschen log in Code Tags gepackt
-
@great-sun Stell doch das loggen mal auf Debug:
Und Poste dann das ergebnis hier als Text in Code Tags:
Kannst auch gerne mal einen Screenshot der Objekte posten
-
Hi an alle,
sorry, ich kam gestern nicht mehr dazu die Hinweise von @thomas-braun im Chat noch umzusetzen.Die Lösung war denkbar einfach:
- iot Instanz & Adapter deinstallieren
- npm cache clean (--force)
- Neustart des containers
- Umstellen auf stable Repo
- iot Adapter installieren und konfigurieren (in meinem Fall zunächst ohne Alexa, Google &Co. um pot. Einwirkungen zu vermeiden)
- iot Adapter starten
-> Grün!
Vielen lieben Dank für die prompte und freundliche Unterstützung!
-
@great-sun
Selbes spiel bei mir, es kam immer Cannot read URL key: {}
Hatte immer google home beim ersten Start "angehakt".Lösung bei mir ganz ähnlich:
Instanz löschen
Instanz hinzufügen
Vor dem ersten Start die drei Haken bei den Dienste Alexa, Amazon und Yandex entfernen.-> Funktioniert
-
@schnup89 Da bin ich ja sehr froh, das mein Leid Dir geholfen hat
Immer schön, wenn man das auch zurückgemeldet bekommt!DANKE !
-
Hallo zusammen,
möchte gerne meine bisherige Installation auf einem RPI4 auf einen anderen RPI4 umziehen.
Habe dazu ein Backup mit backitup vom alten auf den neuen RPI4 eingespielt.
IoT Adapter auf dem alten RPI4 gestoppt, aber es lässt sich auf dem neuen einfach nicht starten:iot.0 2022-10-30 17:43:42.008 error Cannot read connection certificates iot.0 2022-10-30 17:43:42.007 error Cannot fetch connection certificates: "ENETUNREACH"Habe das Adapter mehrfach neugestartet, nochmal die korrekten ioBroker.pro Login Daten eingegeben und neue Verbindungszertifikate angefordert.
Woran könnte das liegen?
Viele Grüße
Peter -
@pepito82 zeig mal bitte:
iob list instances -
@djmarc75 Sieht so aus:
pi@fhemio:~ $ iob list instances + system.adapter.admin.0 : admin : fhemio - enabled, port: 8081, bind: 0.0.0.0, run as: admi n + system.adapter.backitup.0 : backitup : fhemio - enabled system.adapter.discovery.0 : discovery : fhemio - disabled + system.adapter.fhem.0 : fhem : fhemio - enabled, port: 7072 system.adapter.info.0 : info : fhemio - disabled + system.adapter.iot.0 : iot : fhemio - enabled + system.adapter.node-red.0 : node-red : fhemio - enabled, port: 1880, bind: 192.168.178.13 system.adapter.smartgarden.0 : smartgarden : fhemio - disabled system.adapter.zigbee.0 : zigbee : fhemio - disabled, port: /dev/ttyUSB0 + instance is aliveDie AWS Adresse kann ich auch pingen.
-
@pepito82 sagte in [iot] iot-Adapter verbindet sich nicht bzw Verbindung ist "gelb":
ENETUNREACH
Das bedeutet Network unreachable ... kann der neue ins Internet verbinden?
-
@apollon77 Also ich kann die AWS Adresse damit pingen:
pi@fhemio:~ $ pi@fhemio:~ $ ping a18wym7vjdl22g.iot.eu-west-1.amazonaws.com PING a18wym7vjdl22g.iot.eu-west-1.amazonaws.com(2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223)) 56 data bytes 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=1 ttl=49 time=34.9 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=2 ttl=49 time=33.9 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=3 ttl=49 time=33.8 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=4 ttl=49 time=33.7 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=5 ttl=49 time=33.8 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=6 ttl=49 time=34.0 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=7 ttl=49 time=33.9 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=8 ttl=49 time=33.8 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=9 ttl=49 time=33.8 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=10 ttl=49 time=33.8 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=11 ttl=49 time=33.9 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=12 ttl=49 time=33.7 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=13 ttl=49 time=33.4 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=14 ttl=49 time=33.8 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=15 ttl=49 time=33.8 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=16 ttl=49 time=33.8 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=17 ttl=49 time=33.9 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=18 ttl=49 time=34.0 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=19 ttl=49 time=33.9 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=20 ttl=49 time=33.9 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=21 ttl=49 time=33.9 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=22 ttl=49 time=34.5 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=23 ttl=49 time=34.6 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=24 ttl=49 time=34.2 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=25 ttl=49 time=34.2 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=26 ttl=49 time=34.2 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=27 ttl=49 time=34.0 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=28 ttl=49 time=34.0 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=29 ttl=49 time=34.1 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=30 ttl=49 time=33.8 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=31 ttl=49 time=34.0 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=32 ttl=49 time=34.1 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=33 ttl=49 time=33.7 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=34 ttl=49 time=33.8 ms 64 bytes from 2a01:578:3::34d3:4223 (2a01:578:3::34d3:4223): icmp_seq=35 ttl=49 time=33.9 ms ^C --- a18wym7vjdl22g.iot.eu-west-1.amazonaws.com ping statistics --- 35 packets transmitted, 35 received, 0% packet loss, time 34049ms rtt min/avg/max/mdev = 33.440/33.958/34.914/0.268 msIch weiß nicht, ob die Einstellungen Einstellungen in raspi-config dazu geführt haben können.
Dort habe ich dhcpcd aktiviert.
Und in /etc/dhcpcd.conf eine fest IP vergeben. -
@pepito82 sagte in [iot] iot-Adapter verbindet sich nicht bzw Verbindung ist "gelb":
Einstellungen in raspi-config
warum fummelt man da rum ??
Wie hast Du ioBroker prinzipiell installiert? -
@pepito82 und iobroker.pro?
-
Hab es auf NetworkManager umgestellt und jetzt ist das Adapter auch direkt grün geworden.
@DJMarc75: Ich hatte das mit /etc/dhcpcd.conf gefunden für die Vergabe einer festen IP.
Danke für Eure Hilfe.
