Alexa, der Hub mit dem das … reagiert nicht
-
-
Super. Danke Euch.
-
Das Problem habe ich auch immer wieder, gelöst habe ich es aber leider nicht
Zudem verbindet sich der Cloud Adapter wohl selber wieder, nur bleiben in Alexa die Geräte Offline. Um 4:40 habe ich dann manuell 2x neu gestartet. Aber auch hier bleibt alles offline in Alexa.
cloud.0 2017-02-17 04:42:27.658 info Connection changed: CONNECTED cloud.0 2017-02-17 04:42:27.312 info 2017-02-17T03:42:27.311Z Connected system.user.admin cloud.0 2017-02-17 04:42:27.158 info Connecting with https://iobroker.net:10555 with "123" cloud.0 2017-02-17 04:42:27.139 info starting. Version 0.6.7 in /opt/iobroker/node_modules/iobroker.cloud, node: v4.7.3 cloud.0 2017-02-17 04:42:15.718 info Adapter is disabled => stop cloud.0 2017-02-17 04:42:15.674 info Connection changed: DISCONNECTED cloud.0 2017-02-17 04:42:12.056 info Request devices cloud.0 2017-02-17 04:42:11.372 info Request enums cloud.0 2017-02-17 04:42:09.048 info Request devices cloud.0 2017-02-17 04:42:09.041 info Request devices cloud.0 2017-02-17 04:41:52.896 info Request devices cloud.0 2017-02-17 04:41:13.998 info Request devices cloud.0 2017-02-17 04:40:56.347 info Connection changed: CONNECTED cloud.0 2017-02-17 04:40:56.177 info 2017-02-17T03:40:56.176Z Connected system.user.admin cloud.0 2017-02-17 04:40:55.833 info Connecting with https://iobroker.net:10555 with "123" cloud.0 2017-02-17 04:40:55.811 info starting. Version 0.6.7 in /opt/iobroker/node_modules/iobroker.cloud, node: v4.7.3 cloud.0 2017-02-17 04:40:50.740 info terminating cloud.0 2017-02-17 04:40:50.712 info Connection changed: DISCONNECTED cloud.0 2017-02-17 04:40:17.633 info Request devices cloud.0 2017-02-17 04:40:17.629 info Request devices cloud.0 2017-02-17 04:39:51.704 info Request devices cloud.0 2017-02-17 04:39:51.701 info Request devices cloud.0 2017-02-17 04:29:49.960 info Request devices cloud.0 2017-02-17 04:29:49.958 info Request devices cloud.0 2017-02-17 00:28:22.047 info Connection changed: CONNECTED cloud.0 2017-02-17 00:28:16.965 info Connection changed: DISCONNECTED -
Denke es wäre für Bluefox hilfreich wenn wir versuchen mal genau raus zu bekommen, was nicht funktioniert.
Ich habe bei mir alle schedules raus, und es funktioniert jetzt seit mehreren Tagen ohne Probleme Cloud Version 0.6.5
Wenn Probleme auftreten vielleicht folgende Informationen posten (bitte um Sinnvolle ergänzen)
1. Version Cloud Adapter
2. Anzeige Cloud Adapter (grün, gelb, rot)
3. Ist von der iobroker Maschine Internet erreichbar (http://www.google.de) z.B.
4. Ist die https://iobroker.net Webseite erreichbar und man kann sich anmelden
5. Wann war der letzte Router Neustart
Geändert: Punkt 5 Erweitert
-
Alexa: "der Hub mit dem das … reagiert nicht" mit der Cloud Version 0.6.8:
Der Cloudadapter ist grün, anmelden per https://iobroker.net geht nicht.
Bekomme folgende Meldung: IOBROKER IS NOT YET CONNECTED -> PRESS TO RECONNECT
Mit Reconnect passiert dann aber erstmal nichts.
Lösung: Cloud-Adapter manuell stopen und neu starten, dann funktioniert alles wieder.
Ich werde als Problemumgehung die von nuhr70 Lösung einrichten und dann berichten.
-
Hallo zusammen,
ich lese hier nun schon eine ganze Weile mit und konnte meinen IOBroker auch dank des Forums erfolgreich in Betrieb nehmen.
Leider habe ich auch immer wieder das oben geschilderte Problem.
Alexa meldet nach einiger Zeit, das die angeschlossenen Geräte nicht verfügbar wären.
Ich habe auch den Neustart bereits eingerichtet, leider auch ohne Erfolg.
Irgendwann verbindet sich der Cloud Adapter einfach nicht mehr sauber.
Ein Neustart des Cloud Adapters, ist bei mir auf 2 Uhr Nachts Konfiguriert, da die Zwangstrennung durch den Provider zwischen 1 und 2 geschieht.
Ich habe auch mal probiert eine zweite Instanz des Cloud Adapters einzurichten. Natürlich habe ich die erste auch angehalten, jedoch ohne Änderung am Verhalten.
Eine Anmeldung bei https://iobroker.net/ ist erst nach einem manuellen Neustart des Cloud Adapters möglich. Danach funktioniert auch wieder alles ohne Probleme.
EDIT:
1. Version Cloud Adapter0.6.8
2. Anzeige Cloud Adapter (grün, gelb, rot)Grün
3. Ist von der iobroker Maschine Internet erreichbar (http://www.google.de) z.B. Ja/DNS sowie IP
4. Ist die https://iobroker.net Webseite erreichbar und man kann sich anmelden Website ist erreichbar/Anmeldung ist möglich/es besteht aber keine Verbindung zu eigenen Diensten
5. Wann war der letzte Router Neustart 19.02.17/01:02 Uhr
Gruß
Tante
-
Ist auch Web Adapter und nicht cloud Adapter gemeint?
Es sollte cloud Adapter gestartet werden .
Btw: welche Version vom cloud Adapter ist installiert?
-
Hallo und Willkommen im Forum!
Meinst du wirklich den web Adapter oder den Cloud Adapter?
Wobei es wahrscheinlich auch mit dem reset des web Adapters klappen könnte, da sich iobroker ja darüber mit der Cloud verbindet.
Gruß
Rainer
-
Hi….Ich habs falsch aufgeschrieben....sorry dafür, bin noch relativ neu im Thema. Hab es oben aber nochmal angepasst.
Gemeint ist natürlich der Cloud Adapter.
Ihr seid ech sehr Flink unterwegs hier.
-
Hallo @all,
also der Neustart wie von nuhr70 beschrieben funktioniert wunderbar, der Zeitpunkt muss aber nach
der täglichen Netztrennung des Routers erfolgen. Bei mir trennt die Telekom die Verbindung zwischen
4:00 und 5:00 Uhr. Ich hatte zuvor den Neustart des Cloud-Adapters auf 2 Uhr stehen und die besagten
Probleme. Seitdem ich den Cloud-Adapters um 6:00 Uhr neu starte funktioniert alles wunderbar!
Beste Grüße
Pantau
-
Hi,
dann werde ich das bei mir auch mal so einstellen. Hoffe, dass es klappt.
Danke
-
der Zeitpunkt muss aber nach der täglichen Netztrennung des Routers erfolgen. `
das ist ja wohl selbstverständlich, sonst ergibt das ja keinen Sinn. Die Ursache für den Disconnect ist ja die Zwangstrennung.Siehe:
http://forum.iobroker.net/viewtopic.php … 540#p50544
` > der Neustart ist notwendig, weil viele Provider einmal am Tag eine kurze Zwangstrennung der Internetverbindung durchführen (man bin ich froh, das das meiner nicht macht.).danach muss man den Cloud Adapter neu starten. `
Gruß
Rainer
-
Ich habe auch besagtes Problem des nicht reagierenden Hubs. Werde mal den automatischen Start versuchen.
Vielleicht noch ein Hinweis, der evtl. zur Lösungsfindung beiträgt. Ich hatte einen smartname erst "Rolladen Terrasse" benannt. Diesen dann allerdings in "Rollo Terrasse" umbenannt.
Wenn ich nun "Schalte -> Rollo Terrasse -> AN sage, antwortet mir Alexa, daß sie ROL<u>LADEN</u> Terrasse nicht finden kann. Woher hat sie noch die Bezeichnung "Rolladen"? Hat sie hier irgendwas zwischengespeichert, an dem sie sich verheddert?
Grüße Andreas
-
Hi,
ich habe meine Neustart auf 6 Uhr gelegt. Da bin ich zwar schon wach, aber noch in Reichweite von Alexa :lol: und sowieso vor dem ersten Kaffee noch nicht in der Lage zu sprechen ….
Aber: Es funktioniert!!!
-
@Weimaraner, hast du danach auch Alexa nach neuen Geräten suchen lassen? Denn dann übernimmt die geschmeidige Dame erst die neuen Befehle.
Das mit dem neu starten des Cloud-Adapters ist leider für mich keine Option. :evil:
Ich bin bei Encoline, und da habe ich trotz sehr guter Leitung am Tag 3-5 disconnects.
Merke das immer wenn Alexa meint den Hub nicht zu finden. Dann muss ich mich doch
mit ioBroker verbinden und den Adapter neu starten.
Möchte auch nicht nen Cron jede halbe Stunde starten nur weil Encoline so unzuverlässig ist.
Ich hoffe das es irgendwann einmal eine Lösung für das Problem gibt.
Ist es nicht möglich anhand einer neuen externen IP einen Neustart zu initiieren?
Gruß Andreas
-
Hallo,
gleiches hier: nach der Zwangstrennung keine wiederaufnahme. Also habe ich nun 5.04 Uhr einen Restart der cloud eingegeben.
-
@Weimaraner, hast du danach auch Alexa nach neuen Geräten suchen lassen? Denn dann übernimmt die geschmeidige Dame erst die neuen Befehle. `
Ja, habe ich. Auf meinem Handy sehe ich in der Alexa-App auch die richtigen "Rufnamen". Umso erstaunter war ich, daß sie noch den alten Namen kannte.Grüße Andreas
-
Hallo zusammen,
ich habe jetzt noch mal ein wenig mit dem automatischen Restart der cloud-Instanz gespielt.
Also "eigentlich" schaut es ja gut aus: Meine Fritz macht zwischen 4 und 5 Uhr einen Reconnect der Internetverbindung, um der 24-Stunden-Zwangstrennung zuvor zu kommen. Etwa 5 Sekunden später meldet die cloud-Instanz im Log "disconnect". Anschließend "scheint" die Instanz die Verbindung zu iobroker.net neu aufzubauen, da sie ca. 5 weitere Sekunden später "connect" meldet. Leider stimmt das aber nicht, zumindest reagiert Alexa anschließend eben weiterhin mit "Hub … reagiert nicht".
Da ein manueller Restart oder eben auch ein Cronjob später Abhilfe schafft, dachte ich, ich könnte die Ausfallzeit möglichst kurz halten, indem ich abhängig von der externen IP-Adresse den Restart provoziere:
// ######################## Restart cloud due to new external IP address ######################## on({ id: "tr-064.0.states.externalIP", change: "ne", ack: true }, function (obj) { log('mylog: Restart cloud adapter due to new external IP address'); setTimeout(function(){extendObject('system.adapter.cloud.0', {common: {enabled: false}})}, 20000); setTimeout(function(){extendObject('system.adapter.cloud.0', {common: {enabled: true }})}, 30000); });Sobald meine tr-064-Instanz also eine neue externe IP-Adresse feststellt, beendet das Script nach 20 Sekunden die cloud-Instanz (um dem instanz-internen Prozedere nicht in die Quere zu kommen eben erst nach 20 Sekunden und nicht sofort). 10 weitere Sekunden später wird die cloud-Instanz wieder gestartet und meldet im Log auch brav wieder sein "connected". Dennoch bekomme ich von Alexa den Fehler. Wenn ich das gleiche Script am Morgen aber (natürlich dann unabhängig von der externen IP) ausführe, funktioniert Alexa anschließend. Das heißt für mich, dass das Script für sich funktioniert, nur am Timing scheint es zu scheitern. Ich habe also versucht, den Mindestabstand zwischen Reconnect der Internetverbindung und Restart der cloud-Instanz zu finden. Und siehe da:
-
Deaktivierung nach 40 Sekunden und Reaktivierung nach 50 Sekunden schlägt noch fehl, aber
-
Deaktivierung nach 50 Sekunden und Reaktivierung nach 60 Sekunden funktioniert.
Hab den cron-Job also raus genommen und bin mit meinem Script glücklich. Leider verstehe ich aber nicht, warum das so ist. :?
// ######################## Restart cloud due to new external IP address ######################## on({ id: "tr-064.0.states.externalIP", change: "ne", ack: true }, function (obj) { log('mylog: Restart cloud adapter due to new external IP address'); setTimeout(function(){extendObject('system.adapter.cloud.0', {common: {enabled: false}})}, 50000); setTimeout(function(){extendObject('system.adapter.cloud.0', {common: {enabled: true }})}, 60000); });Evtl. hat @Bluefox noch eine Idee oder Erklärung…
<size size="85">edit 09.03.2017: DP "externalIP" korrigiert wg. aktueller tr-064-Version</size>
-
-
Da ein manueller Restart oder eben auch ein Cronjob später Abhilfe schafft, dachte ich, ich könnte die Ausfallzeit möglichst kurz halten, indem ich abhängig von der externen IP-Adresse den Restart provoziere: `
Du sprichst mir aus der Seele
Während ich mich durch diesen Fred lese, kam mir genau der gleiche Gedanke:
"Kann ein Neustart denn nicht aufgrund der aktualisierten IP angeschoben werden?"
Das würde auch das Problem von Nepomuckl beheben (täglich mehrfacher diconnect und neue IP)
Kann ein reconnect ggf. auch anderes erkannt werden? (ich denke gerade an alle ohne AVM Router)
Vielleicht kann so etwas dann generisch im Adapter abgefangen und ein Adapter-Neustart ausgelöst werden?
-
Guten Abend,
hab die Sache mal ein paar Tage getestet.
LÄUFT SUPER :mrgreen: :mrgreen: :mrgreen:
@justr mach doch mal einen eigenen Fred auf mit deiner Lösung. Ich glaube hier geht es etwas unter.
Habe auch den cron heraus genommen und keine Ausfallzeiten.
Hab ja wie gesagt öffters DSL Abbrüche bei Encoline, immer wenn ich es gemerkt habe hab ich Alexa 2 Minuten später Geräte suchen lassen und nicht einmal war der verschwundene Hub dabei.
Besten Dank für die Lösung
Gruß Andreas
