UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Jan1]

@smartboart
das ist alle 4 Stunden jede Minute

[smartboart]

@Jan1 oh ok..ich glaube ich sollte mich nochmal mit den Chron Zeiten auseinanderstzen..Danke!!!

[smartboart]

@apollon77 said in [Aufruf] js-controller 2.0 Beta Test:

@smartboart denke alles nur Warnungen.

ok danke..hab ich mir gedacht, macht auch keine Probleme. Wenn du oder sonst wer dennoch ne Idee hat wie man diese gyp und nan Warnungen abstellt, gerne her damit.....

[darkiop]

@apollon77

Das ist alles von heute aufm Slave ab dem Zeitpunkt des Redis-Tests:

log_slave.txt

[apollon77]

Sooooooo @darkiop Super Feedback!!

Die 2.0.32 ist auf GitHub, könntest Du alle 4 cases nochmal checken bitte?

Bisher wurden Adapter beim verlieren der States Connection beendet, aber der Host hat nur bei Objects-DB-verlust was getan ... Damit gab es Edge cases. Ist jetzt geändert.

[darkiop]

Danke. Ich schau mal ob ich heut noch dazu komme :D

[darkiop]

@apollon77 Noch ne Frage, kann ich eigentlich auch über Github eine alte Version ziehen? Also wie müsste ich z.b. vorgehen wenn ich jetzt wieder die 2.0.25 möchte für die es aber keine NPM Version gibt?

[SBorg]

Die Versionsnummer mit anhängen (geht bei allen NPM-Paketen), also npm install ioBroker/ioBroker.js-controller@2.0.25

[darkiop]

@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:

Sooooooo @darkiop Super Feedback!!

Die 2.0.32 ist auf GitHub, könntest Du alle 4 cases nochmal checken bitte?

Bisher wurden Adapter beim verlieren der States Connection beendet, aber der Host hat nur bei Objects-DB-verlust was getan ... Damit gab es Edge cases. Ist jetzt geändert.

Das war jetzt doch Aufwändiger als Gedacht, siehe TF3 :D

tf_2-0-32.pdf

Mein Log von Heute ging eben auch per Mail an dich raus.

[darkiop]

@SBorg Jep, das kenne ich - hab mich glaub falsch ausgedrückt. Kann ich auch zu einem Zeitpunkt eines Commits springen zu dem es keine Version gibt?

[apollon77]

@darkiop geht nicht. Nur eine npm Version oder aktuellen GitHub Stand. Ansonsten ginge noch ein spezifischer GitHub Commit, was äquivalent zu einem alten Stand wäre.

Wozu brauchst Du die 2.0.25?

[darkiop]

@apollon77 die 2.0.25 musste nur als Beispiel herhalten ;) wie würde der spezifische commit ausschauen?

[apollon77]

@darkiop Ooooohhhkkkkk ... :-)

Bei testfall 3 sieht man das er "restart" aufruft aber scheinbar wieder kein Restart passiert ... :-(

[apollon77]

@darkiop puuuhh da muss ich mal schauen ...

Per Kommandozeile wäre es denke ich Bei zB 2.0.26 als https://github.com/ioBroker/ioBroker.js-controller/commit/2b2bb746da26cd06862a78a4eb1a1cf209e85d3e

dann

npm install ioBroker/ioBroker.js-controller#2b2bb746da26cd06862a78a4eb1a1cf209e85d3e

[apollon77]

@darkiop Also ich habe es mal nachgestellt und bei mir getestet. Effektiv geht alles korrekt, bei States dauert es ggf nur länger.

Bei mir steht in der Konfig (iobroker-data/iobroker.json) bei states ein

"options": {
      "auth_pass": null,
      "retry_max_delay": 15000
    }

Das MaxDelay 15000 bedeutet das ein Reconnect alle 15s versucht wird. Bei Objects steht im Default nichts, was bedeutet es sind 2s. Das sind mal mindestens die Dinge die für den Controller gelten. Es sollten 18 Connect Versuche gemacht werden ... also wenn Objects weg ist restarted alles nach 12x2=36s (grob). Bei States sind es 4:30min ... das passt zu meinen Ergebnissen. Und bei mir kam dann der Restart ...

[darkiop]

@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:

@darkiop puuuhh da muss ich mal schauen ...

Per Kommandozeile wäre es denke ich Bei zB 2.0.26 als https://github.com/ioBroker/ioBroker.js-controller/commit/2b2bb746da26cd06862a78a4eb1a1cf209e85d3e

dann

npm install ioBroker/ioBroker.js-controller#2b2bb746da26cd06862a78a4eb1a1cf209e85d3e

Danke. Werd ich ausprobieren.

[darkiop]

@apollon77 Ok, d.h. du hattest nicht die vielen Fehler bei TF3?

[apollon77]

@darkiop wenn du die viele „connection closed“ meinst dann doch. Wenn die 20 Verbindungsversuche rum sind werden alle Kommandos die in der Zeit gewartet haben auf einen Schlag mit einem Fehler beantwortet. Und je nach Adapter werden die dann geloggt. Das wäre ok Weil es ist ja so passiert.

Gibt nachher noch ein Update was die reconnect delay Synct und auf 5s stellt. Dann sollte es besser zusammenpassen. Melde mich

[darkiop]

Ja, die meinte ich - das waren ja auch ein paar Tausend ... das Logvon gestern das ich dir geschickt habe hat ja auch ein MB dadurch :D

[apollon77]

Soooo, ich habs jetzt :-) (hoffe ich) 2.0.33 auf GitHub. Ich habe alle Testcases meinerseits gecheckt, wäre super wenn Du nochmal könntest.

Das Update hinterlegt die gleichen Default Reconnection-Delay für States und Objects in der Konfig, was dann jetzt 5 Sekunden sind!
Bedeutet: Er versucht ca. 90-95 Sekunden zu reconnecten in 5s intervallen, danach (egal ob States oder Objects weg ist) beenden sich Adapter und Controller und restarten. Dann sollte der controller wieder "lauern" bzw alle 30s restarted werden.

Und ja, wenn die 95s rum sind hagelt es "Connection Close" Meldungen im Log. Würde ich so lassen erstmal. Wenn es zu oft passiert (was es nicht sollte) kann man es erkennen und nicht loggen, aber dann fehlen die Infos das was passiert ...

Danke für Feedback