Alexa, der Hub mit dem das … reagiert nicht

[Obi-Biber]

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!!!

[Nepomukl]

@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

[Semenchkare]

Hallo,

gleiches hier: nach der Zwangstrennung keine wiederaufnahme. Also habe ich nun 5.04 Uhr einen Restart der cloud eingegeben.

[weimaraner]

@Nepomukl:

@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

[justr]

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>

[BBTown]

@justr:

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?

[Nepomukl]

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

[no_engel]

Hallo Zusammen!

Ich bin absolut neu hier beim io Broker…..

ich habe das gleiche Probelm.

Allerdings wohl verschärft. Nach gelungenem Neustart läuft alles einige minuten. Dann erscheint die Meldung "Hub nicht erreichbar..." wieder (Keine Trennung der Internetverbindung)

Zusätzlich:

hm-rega.0 2017-03-09 15:07:14.365 error CCU 192.168.1.63 unreachable

hm-rpc.0 2017-03-09 15:07:07.849 error Socket error: Error: connect ENETUNREACH 192.168.1.63:2001 - Local (0.0.0.0:0)

Nach händischem Neustart läuft alles wieder. Allerdings ist es eine Frage der Zeit bis wieder die Hub-Meldung auftritt.

Noch eine Frage an Start

Wohin gehört das Skript?

Danke !

Gruß Aus Hessen

[justr]

Hallo und willkommen no_engel,

ich denke wir reden von unterschiedlichen Sachen. In diesem Thread geht es ja um Alexa und den cloud-Adapter. Wo erscheint bei dir die Meldung "Hub nicht erreichbar…"? Deine Meldung klingt für mich eher nach Harmony-Adapter. Und dein Log mit dem "CCU ... unreachable" stammt definitiv vom Homematic-Adapter bzw. einer fehlenden/wackligen Verbindung zur Homematic-CCU. Welche Instanz startest du denn neu, damit es wieder geht?

Ansonsten benötigst du für jedes Javascript den javascript-Adapter. Und wenn dein TR-064-Adapter, dessen Datenpunkt in diesem speziellen Fall das Script triggert, in den letzten Tagen aktualisiert wurde, musst du auch noch das Script anpassen, da ein Tippfehler im Datenpunkt korrigiert wurde:

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

Gruß, justr

[no_engel]

Hallo !

Nein ich bin hier schon richtig..

Es geht um das zusammenspiel mit Alexa.

Immer wieder sagt mir Alexa freundlich aber nachdrücklich Hub mit dem das … reagiert nicht....

Nach Neustart der Clod.0 Instanz gehts dann meistens wieder eine Zeit lang gut.

Gruß no_engel

[no_engel]

Hallo Justr!

Danke für das Skript…

Nur weiß ich dummer Anfänger nicht wo es hingehört.....

Soll es als Shellskript laufen ?

Gruß und Danke

[justr]

@no_engel:

Danke für das Skript…

Nur weiß ich dummer Anfänger nicht wo es hingehört.....

Soll es als Shellskript laufen ? `
Vielleicht kam es aus meiner Antwort von oben nicht korrekt rüber, aber der zweite Teil der Antwort bezog sich genau auf diese Frage. Ich zitiere mich mal selbst:
@justr:

Ansonsten benötigst du für jedes Javascript den javascript-Adapter. Und wenn dein TR-064-Adapter, dessen Datenpunkt in diesem speziellen Fall das Script triggert, in den letzten Tagen aktualisiert wurde, musst du auch noch das Script anpassen, da ein Tippfehler im Datenpunkt korrigiert wurde:

externalP -> externalIP (das große I fehlte) `
Also javascript-Adapter installieren, tr-064-Adapter installieren (sofern dein Router tr064 spricht), obiges Script als neues javascript anlegen (reinkopieren) und starten.

Allerdings bin ich mir dennoch unsicher, ob es dir weiterhilft. Die CCU-Fehlermeldung weist ja eher darauf hin, dass du ein grundsätzliches Verbindungsproblem (unabhängig von cloud) hast. Aber probieren kann ja nicht schaden.

[no_engel]

Danke!

Ich probiers mal…

Neun die Verbindungen zum ccu (läuft auf einem Raspberry (Rasopberrymatic) ist stabil.

Ich kann zum Beispiel währen der Fehlermelldung über das Webinterface der Raspberrymatic CCU alles steuern. Auch die Internetverbindung vom Raspberry steht (Test mit ping auf google)

Danke

[no_engel]

Hallo !

Ich habe heute eine sehr angenehme Überraschung erlebt.

Da wir am Wochenende nicht zuhause waren konnte ich auch keine Änderungen am System vornehmen.

Aber siehe Da: "Alexa schalte das Licht im Esszimmer an" Alexa:"OK"

Also trotz mehrerer Zwangstrennungen des Serviceproviders (auch einiger von mir provozierten) klappt alles!!!

Was hat sich geändert? Hat jemand am Cloud-Server geschraubt?

LG no_engel

[no_engel]

Hallo Zusammen!

Zu früh gefreut….

nach Systemupate der Fritz.Box und damit verbundenem Neustart der Box wieder das gleiche Problem: Der Hub an dem das Gerät hängt reagiert nicht...

Also muss ich das Skript wohl doch noch installieren.

ich melde mich dann nächste Woche wieder.

Gruß aus Hessen