[Workaround] Cloud-Verbindungsprobleme

[justr]

Hallo zusammen,

wie im Thread http://forum.iobroker.net/viewtopic.php?f=37&t=5100 bereits beschrieben, habe ich in dem folgenden Workaround-Script eine praktikable Lösung gefunden, um die Verbindungsabbrüche mit dem cloud-Backend möglichst kurz zu halten.

// ######################## 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);
});

Der Vorteil ist, dass der Instanz-Restart immer zeitnah zum Ausfall (also der neuen externen IP-Adresse) passiert, egal wann der Provider die Verbindung erneuert oder eure DSL-Leitung wackelt. Der Nachteil ist, ihr benötigt einen Datenpunkt, der die externe IP vorhält/aktualisiert (bei mir der tr-064-Adapter). Solltet ihr keinen tr-064-fähigen Router besitzen, wäre vielleicht der Parser-Adapter und die Webseite https://www.wieistmeineip.de/ eine Lösung. Der Cron-Job für den Restart sollte dann natürlich nicht mehr benötigt werden.

Der Cloud-Restart in meinem Script darf tatsächlich frühestens nach 60 Sekunden passieren, andernfalls funktioniert die Lösung nicht. Ich habe den Fred auch bewusst mit "[Workaround]" beschrieben, da es keine Lösung des eigentlichen Problems ist. Ich vermute übrigens, dass der Fehler nicht im Adapter sondern im Backend, also der iobroker.net-cloud liegt. Der Adapter scheint den Verbindungsabbruch korrekt zu detektieren und Verbindung sofort neu aufzubauen. Diese neue Verbindung funktioniert anschließend auch einwandfrei - aber leider nur für die ersten 60 Sekunden (deswegen auch die 60s-Verzögerung im Script). Da ich nicht erkennen kann, dass der Adapter nach den besagten 60 Sekunden irgendwas macht, kann ich nur vermuten, dass die Cloud hier die Verbindung kappt (evtl. durch fehlende/fehlerhafte Authentifizierung?). Die Frage ist somit, warum die adapter-interne Verbindungserkennung bei vielen ausreicht (vermutlich auch bei Bluefox, sonst hätte er im Adapter nicht so einen Aufwand zu Erkennung betrieben), andere aber 60 Sekunden später rausgekickt werden.

Beste Grüße, justr

<size size="85">edit 09.03.2017: Datenpunkt "externalIP" korrigiert, wg. TR-064-Adapter-Update 0.3.11</size>

[Bluefox]

Auf dem git liegt eine Version, die sich restarten sollte nach dem als die Verbindung weg ist.

Man muss Checkbox in der Config aktivieren.
48_2017-03-06_17_34_13-iobroker.admin.png

[justr]

Hi Bluefox,

klappt leider noch nicht wie erwartet. Seltsamerweise hat es beim zweiten von vier Versuchen funktioniert, aber bei den drei anderen ist ein paar Sekunden nach dem erfolgreichen Zweit-Connect (der ca. 40s nach Disconnect passiert) die Verbindung wieder unerwartet abgebrochen ohne (Debug-)Meldung im Log (ca. 75s nach Disconnect, ca. 19:41:32). Die erste Connect-Meldung des Reconnects kommt noch vor dem Instanz-Restart nach wenigen Sekunden.

	2017-03-06 19:40:58.056	info	Connection changed: CONNECTED
cloud.0	2017-03-06 19:40:57.901	debug	Created ALEXA device: ...
[..]
cloud.0	2017-03-06 19:40:57.900	debug	Created ALEXA device: ...
cloud.0	2017-03-06 19:40:57.892	info	2017-03-06T18:40:57.892Z Connected system.user.admin
cloud.0	2017-03-06 19:40:57.817	info	Connecting with https://iobroker.net:10555 with "justr_xxx"
cloud.0	2017-03-06 19:40:57.815	info	starting. Version 0.6.10 in /Users/Shared/iobroker/node_modules/iobroker.cloud, node: v6.10.0
cloud.0	2017-03-06 19:40:57.780	debug	statesDB connected
cloud.0	2017-03-06 19:40:57.763	debug	objectDB connected
host.Juergens-Mini13.fritz.box	2017-03-06 19:40:57.244	info	instance system.adapter.cloud.0 started with pid 68645
host.Juergens-Mini13.fritz.box	2017-03-06 19:40:27.171	info	Restart adapter system.adapter.cloud.0 because enabled
host.Juergens-Mini13.fritz.box	2017-03-06 19:40:27.171	error	instance system.adapter.cloud.0 terminated with code 156 ()
cloud.0	2017-03-06 19:40:27.160	info	Connection changed: DISCONNECTED
cloud.0	2017-03-06 19:40:24.683	debug	reconnect
cloud.0	2017-03-06 19:40:24.683	info	Connection changed: CONNECTED
cloud.0	2017-03-06 19:40:22.160	error	Ping timeout
cloud.0	2017-03-06 19:40:17.110	info	Connection changed: DISCONNECTED

Übrigens heißt die Einstellung "Neustart nach dem Verbindungsabbruch:" bei mir "Restart on disconnect:", obwohl die weiteren Einstellungen alle in Deutsch sind.

Vielen Dank und schöne Grüße, justr

[justr]

Kleine Korrektur:

In einem der letzten TR-064-Adapter-Updates (0.3.5 - 0.3.11; gab ziemlich viele in den letzten Tagen) wurde offenbar der Tippfehler im oben genutzten Datenpunkt korrigiert:

externalP -> externalIP (das große I fehlte)

Das muss natürlich auch im Script nachgezogen werden. Habe es oben im original Post korrigiert.

[kesaloh13]

Hallo,

ich habe das Problem mit dem reconnect auch. Bei mir wird scheinbar täglich mehrmals die Verbindung gekappt (A1 Telekom).

Vielleicht habe ich aber auch ein Problem mit meinem Router.

Die neueste Version des cloud adapters hilft auch nicht aus, gleiches Problem wie von justr beschrieben.

Da ich keine Fritzbox verwende musste ich den Workaround mit dem "Radar Adapter for IP" realisieren. Hat einwandfrei funktioniert.

// ######################## Restart cloud due to new external IP address ########################

on({
    id: "radar.0.ExternalNetwork.IP4",
    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}})}, 10000);
    setTimeout(function(){extendObject('system.adapter.cloud.0', {common: {enabled: true }})}, 10000);
});

Nachdem der Radar Adapter nur alle 5 Minuten (auch kürzer einstellbar) die externe IP prüft, reicht die Zeit von insgesamt 20 Sekunden für einen Neustart aus.

Bei einem manuellen Test (disconnect und connect am router) hat das super funktioniert. Nun lasse ich das mal ein paar Tage laufen.

Danke an justr für das Script!

lg, kesaloh13

[justr]

Hi kesaloh13,

du hast da leider einen kleinen Verständnisfehler. Javascript wartet nicht die ersten 10 Sekunden bis der 2. Timeout startet, sondern startet den Timer und macht sofort weiter. Soll heißen, dass der 2. Timer nur Microsekunden nach dem ersten getriggert wird und somit beide nach 10 Sekunden ablaufen.

Und wenn dein Radar-Adapter alle fünf Minuten aktualisiert, hast du immer noch eine signifikante Wahrscheinlichkeit, dass der Reconnect innerhalb der letzten 60 Sekunden passiert ist. D.h. dein Script wird jedes 6. mal fehlschlagen (50s/300s).

Würde dir also empfehlen auf die oben genutzten 50 bzw. 60 Sekunden abzuändern.

Beste Grüße, justr

[kesaloh13]

Hi Justr,

klar, da hatte ich wohl einen Knopf im Hirn. Danke für den Hinweis.

lg, kesaloh13

[FuXXz]

Also bei mir ist und bleibt es unverändert.

Will ich täglich mein Licht einschalten mache ich folgendes:

PC an machen, ioBroker Oberfläche öffnen, Adapter neu starten, Alexa öffnen, Geräte suchen klicken, danach verschwindet dann auch das (offline) hinter den Namen.

Licht an sagen!

Hey ich habe in 5 Minuten das Licht an gemacht, vielleicht sollte ich den Lichtschalter nutzen

Spaß beiseite! In den Logs gibt es keine Fehler oder Auffälligkeiten. Trotzdem sind täglich die Geräte unter SmartHome in Alexa offline.

[FuXXz]

Sollte ich einen neuen Beitrag eröffnen oder ist damit zu rechnen dass mir hier jemand helfen kann ?

[Bluefox]

Cloud version? Restart eingesetzt? Wann wird ip gewechselt?

[FuXXz]

Version 0.6.10, Restart ist nach Router reset und Neustart bei dem Verbindungsabbruch ist aktiv.

Geräte in Alexa täglich offline und im iobroker log ist kein roter Eintrag.

` > cloud.0 2017-03-19 15:07:34.664 info Connection changed: CONNECTED

cloud.0 2017-03-19 15:07:34.278 info 2017-03-19T14:07:34.277Z Connected system.user.admin

cloud.0 2017-03-19 15:07:34.110 info Connecting with https://iobroker.net:10555 with "xxx"

cloud.0 2017-03-19 15:07:34.047 info starting. Version 0.6.10 in /opt/iobroker/node_modules/iobroker.cloud, node: v4.8.0

cloud.0 2017-03-19 15:07:28.888 info terminating

cloud.0 2017-03-19 15:07:28.854 info Connection changed: DISCONNECTED `

[weimaraner]

Ich habe trotz Workaround script mit Cloud-Adapter 0.6.8. weiter Probleme, daß der "Hub… nicht reagiert". Mein Internetanbieter wechselt mehrmals am Tag die IP. erst hatte ich es mit dem cronjob probiert, aber da waren mir immer noch zu viele Wechsel, so das es nicht zuverlässig funktioneirte. Seit gestern habe ich das script laufen (muß man da noch was händisch anpassen???) und heute kam leider wieder die "hub reagiert nicht" Meldung.

Um es einzugrenzen, was soll ich an screenshots posten?

Danke und Grüße

Andreas

[justr]

Sorry für die späte Antwort (war im Skiurlaub ).

Da offensichtlich viele diesen Workaround testen möchten und bisher wenig bis keine javascript-Erfahrungen haben, hier mal ein paar Tipps:

• Laufende javascript-Instanz (grüne Ampel) sollte selbsterklärend sein

• Über Bleistift-Icon im Admin rechts oben, links neben dem Login-Namen kann der "Skripte"-Reiter ein-/ausgeblendet werden.

• Im "Skripte"-Reiter unter Common ein neues Skript anlegen und obiges Skript reinkopieren, speichern und starten (roter Play-Button).

• Roter Play-Button wechselt zu grünem Pause-Button und im Log unter dem Skript sollte etwa das folgende stehen ("SystemIOB" ist bei mir der Name des Skripts und irrelevant; im dedizierten "Log"-Reiter in umgekehrter Reihenfolge):

12:23:36.829	[info]	javascript.0 Start javascript script.js.common.SystemIOB
12:23:36.829	[info]	javascript.0 script.js.common.SystemIOB: subscribe: {"pattern":{"id":"tr-064.0.states.externalIP","change":"ne","ack":true},"name":"script.js.common.SystemIOB"}
12:23:36.829	[info]	javascript.0 script.js.common.SystemIOB: registered 1 subscription and 0 schedules

• Die "id" im subscribe-Statement muss eurem Trigger entsprechen und in meinem Fall muss natürlich der "tr-064"-Adapter installiert sein und laufen (grüne Ampel!).

• Ein Reconnect der Internet-Verbindung zum Testen lässt sich in der Regel in der Router-Oberfläche provozieren.

• Beim erfolgreichen Triggern des Skripts muss ein "mylog: Restart cloud adapter due to new external IP address" im Log erscheinen.

• Ob die Verbindung (unabhängig von Alexa) zwischen Cloud-Instanz und Cloud-Backend funktioniert, kann gut man testen, indem man sich unter https://iobroker.net/intro einloggt (Login rechts oben; manueller Refresh bei Bedarf!). Eine Fehlerseite mit "501" kann dabei als Connect verstanden werden (habe ich auch) und liegt wohl an meiner verschlüsselten Web-Instanz.

• Wenn der Haken "Neustart bei dem Verbindungsabbruch" in den cloud-Einstellungen bei euch nicht geholfen hatte, dann nehmt ihn besser wieder raus. Ich hatte bei mir festgestellt, dass dadurch das ganze automatische cloud-Reconnect-Prozedere verzögert wird und damit auch das Rauskicken erst nach mehr als einer Minute passiert. Somit triggert mein Skript (eine Minute Verzögerung) zu früh und der Abbruch passiert erst danach.

• Testweise könnt ihr im Skript die einminütige Verzögerung auch mal auf 2 Minuten setzen (false auf 110000 und true auf 120000 Millisekunden).

Hoffe das hilft dem einen oder anderen weiter.

Beste Grüße, justr