Test js-controller v2.0.x (GitHub)

[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

[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

[darkiop]

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

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.

Testfall 1:
master + slave = alive
master beenden
nicht wieder starten
= iobroker-hwr lauert

2019-10-16 12:45:46.903  - error: host.iobroker-hwr No connection to databases possible, restart                                                                                                                                                                                               
2019-10-16 12:45:46.912  - info: host.iobroker-hwr iobroker _restart                                                                                                                                                                                                                           
2019-10-16 12:45:47.467  - info: host.iobroker-hwr iobroker Starting node restart.js                                                                                                                                                                                                           
2019-10-16 12:45:48.878  - info: host.iobroker-hwr iobroker.js-controller version 2.0.33 js-controller starting                                                                                                                                                                                
2019-10-16 12:45:48.885  - info: host.iobroker-hwr Copyright (c) 2014-2019 bluefox, 2014 hobbyquaker                                                                                                                                                                                           
2019-10-16 12:45:48.886  - info: host.iobroker-hwr hostname: iobroker-hwr, node: v10.16.3                                                                                                                                                                                                      
2019-10-16 12:45:48.888  - info: host.iobroker-hwr ip addresses: 10.3.1.22 fe80::561e:8619:1900:f27                                                                                                                                                                                            
2019-10-16 12:45:48.892  - debug: host.iobroker-hwr Redis Objects: Use Redis connection: 192.168.1.82:9001

Testfall 2:
master + slave = alive
master beenden
20s warten
master starten
= beide wieder verbunden

Testfall 3:
master + slave = alive
redis beenden
einige Minuten warten, wieder starten
= Reconnect nach 2min, wieder verbunden

Testfall 4:
master + slave = alive
redis beenden
paar Sekunden warten
redis starten
prüfen ob States die innerhalb der 40s erzeugt werden nach dem starten von redis verfügbar sind

┬─[darkiop@odin:~]─[13:12:42]
╰─>$ docker stop iobroker-redis

┬─[darkiop@odin:~]─[13:13:45]
╰─>$ docker start iobroker-redis

--> Ich habe keine Werte dazwischen. Habe extra die Entprellzeit runtergestellt damit aufjedenfall kommen - sieht man auch nachdem der Redis wieder da war (nach 13:13:51).

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

Die Frage ist dann aber wie groß das Log wird wenn der Redis mal unbemerkt einen Tag oder mehr ausfällt Nach ein paar Minuten hatte ich schon 8MB reinen Text

[MathiasJ]

Ich will ja nicht unverschämt klingen.
Aber könnte man diesen Threat nicht vielleicht schließen?
Ersatzweise dazu gibt es ja diesen:
https://forum.iobroker.net/topic/25692/js-controller-2-0-ab-sofort-im-latest-repo?page=1
Nun muß man sich bei 2 Threats durch wursteln, um (vielleicht) auf die Lösung mancher Probleme zu kommen.

[Jan1]

@MathiasJ
Nö weil hier ist Beta, der andere eigentlich latest

[MathiasJ]

@Jan1
Der damalige Beta, um den es hier geht, ist jetzt lastet, oder sehe ich das falsch?

[Jan1]

@MathiasJ
So sollte das eigentlich sein, wobei Du ja schon gemerkt hast, dass alles kreuz und quer gepostet wird.
apollon77 hat da ein paar mal versucht die User in den richtigen Thread zu leiten, hat aber anscheinend aufgegeben.

Beta ist immer das was man über NPM installiert und was man "normal" updatet ist latest. Deshalb steht der NPM Befehl auch nur im Beta Thread im ersten Post.

[apollon77]

@darkiop Vielen Dank, also nehmen wir die 2.0.33 als nächste Latest Version.

Ich denke mal: Jemand der einen Tag kein ioBroker hat (und das Log ist ja nur einmalig so voll, dann sind es die 20-30 Teilen alle 30Sekunden ... Aber ja ... mal schauen

[apollon77]

@MathiasJ Ich nutze diesen Thread für Beta Versionen, die - wie korrekt erwähnt - per GitHub direkt installiert werden. Auch nach dem Release der 2.0.25 gab es noch fixes die zur 2.0.29 geführt haben und jetzt als nächstes kommt die 2.0.33 auf NPM ... Alle Versionen dzwischen waren Betas die hier gecheckt wurden.

[darkiop]

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

Vielen Dank, also nehmen wir die 2.0.33 als nächste Latest Version.

Keine Ursache!

[e-i-k-e]

Guten Abend zusammen,

habe soeben meine Slave von 2.0.25 auf 2.0.33 gebracht.

Folgendes habe ich im Terminal entdecken können.

make: *** [Release/obj.target/epoll/src/epoll.o] Fehler 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/lib/node_modules/npm/node_module                 s/node-gyp/lib/build.js:196:23)
gyp ERR! stack     at ChildProcess.emit (events.js:198:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_proces                 s.js:248:12)
gyp ERR! System Linux 4.19.66-v7+
gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gy                 p/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /opt/iobroker/node_modules/rpi-gpio/node_modules/epoll
gyp ERR! node -v v10.16.3
gyp ERR! node-gyp -v v5.0.3
gyp ERR! not ok
../src/unix_dgram.cc: In function ‘void {anonymous}::OnRecv({anonymous}::SocketC                 ontext*)’:
../src/unix_dgram.cc:121:25: warning: ‘v8::Local<v8::Value> Nan::MakeCallback(v8                 ::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*)’ is de                 precated [-Wdeprecated-declarations]

anbei das log-file.
iobroker.2019-10-16.log
syslog
Das Update habe ich gegen 22.30 Uhr gemacht.

[apollon77]

@e-i-k-e Die üblichen unix-dgram Compile Fehler ... Tut alles?

[e-i-k-e]

Bis jetzt läuft alles.

Bei diesem Slave hatte ich auch schon des öfters Probleme mit dem rpi-Adapter. Ist dies ein Indiz dafür?

Komplette System soeben auf 2.0.33 redis/redis. Soll noch etwas bestimmtest getestet werden?

[apollon77]

@e-i-k-e Ja doch epoll ist glaube was was der rpi braucht.

Ansonsten nichts besonderes mehr zu testen

[darkiop]

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

Ansonsten nichts besonderes mehr zu testen

Läuft wie geschmiert die 2.0.33

[apollon77]

Und weils so schön ist 2.0.34 auf GitHub

Die 2.0.33 hatte ein Problem "custom" state Settings (History und so) bei nutzung von "file" für Objekte wieder zu deaktivieren