Test js-controller v2.0.x (GitHub)
-
So, und weil es so schön ist (und doch noch ein paar Kleinigkeiten aufgekommen sind):
2.0.42 ist verfügbar im latest ab gleich:
- (Apollon77) Correct error message if certificate can not be parsed
- (bluefox) Fix upload of material adapter
- (Apollon77) prevent crash when adapter instance is deleted which is also running currently and if stopped by deletion
- (bluefox) make sure getForeignStates do not modify the input ids list
- (Apollon77) enhance
list instancesand only show compact infos if adapter supports it
-
@ilovegym sagte in Test js-controller v2.0.x (GitHub):
könnte aber auch an der Webseite des Servers liegen
Die Timeouts ja, dass ist aber mehr oder minder normal. no connection to objects DB bedeutet aber IMO, dass er keine Verbindung zur ioB-(Objekt)-Datenbank bekommt, was der JS-Controller handelt.
ical.0 2019-11-10 16:30:23.439 warn (29151) no connection to objects DB luftdaten.0 2019-11-10 16:30:23.426 warn (28495) no connection to objects DB luftdaten.0 2019-11-10 16:25:06.510 warn (7526) no connection to objects DB luftdaten.0 2019-11-10 16:10:05.805 warn (3914) no connection to objects DB luftdaten.0 2019-11-10 16:00:13.490 warn (24956) Error: ESOCKETTIMEDOUT luftdaten.0 2019-11-10 16:00:06.653 warn (24956) no connection to objects DB luftdaten.0 2019-11-10 15:50:12.066 warn (16006) Error: ESOCKETTIMEDOUT daswetter.0 2019-11-10 15:46:06.646 warn (31864) no connection to objects DB luftdaten.0 2019-11-10 15:40:06.208 warn (6917) no connection to objects DB luftdaten.0 2019-11-10 15:10:11.149 warn (8437) Error: ESOCKETTIMEDOUT luftdaten.0 2019-11-10 15:00:15.790 warn (32582) Error: ESOCKETTIMEDOUT daswetter.0 2019-11-10 14:46:05.561 warn (9004) no connection to objects DB -
@SBorg Sehr interessant. Dieser Fehler kommt an sich nur in zwei Situationen:
1.) Der Adapter startet und bekommt keine Verbindung zur DB (ioBroker? Redis?)
2.) Es gibt ein "connectTimeout" Event, was an sich nur kommt wenn socketIo auf der Gegenseite ist.Also hier müsste man jetzt mal vollständigere Logs sehen. und Infos haben. Master/Slave oder nur Single-Host und und und
-
@apollon77 sagte in Test js-controller v2.0.x (GitHub):
@ilovegym sagte in Test js-controller v2.0.x (GitHub):
Sollte an sich so nicht sein, Das ist an sich ein schedule adapter ... Die meldungen sollten dann an sich anders sein. Zeig mal bitte system.adapter.meteoalarm.0 die Raw ansicht
ja, der Schedule steht da auf 30 Minuten.. versteh ich auch nicht.. und es läuft auch nur der eine Task..
schau hier:
-
@ilovegym ne da ist was falsch. da steht "mode: "deamon"" und damit ist der schedule egal. ich würde sagen:mach mal "iobroker upload meteoalarm". fixt das das? Sonst manuell ändern, dann iobroker komplett neu starten. Irgendwie ist das Objekt "kaputt"
-
@ilovegym
Die Instanz läuft als Daemon, nicht scheduled. -
@paul53 @apollon77 ja, im letzten Update ist das auf daemon geändert worden...
so siehts nach nem Upload aus, auch nicht besser..
-
@apollon77 sagte in Test js-controller v2.0.x (GitHub):
@ilovegym ne da ist was falsch. da steht "mode: "deamon"" und damit ist der schedule egal. ich würde sagen:mach mal "iobroker upload meteoalarm". fixt das das? Sonst manuell ändern, dann iobroker komplett neu starten. Irgendwie ist das Objekt "kaputt"
ok, mach jetzt sowieso n Update auf die 2.0.42, dabei installier ich den Adapter auch noch mal komplett neu.
-
@ilovegym letztes update von was? Controller? Der ändert da an sich nix. Beim Adapter steht auf GitHub mal mindestens noch schedule ... Also so oder so strange.
Das das upload den typ nicht anfasst kann absicht sein, AM besten Adapter nochmal drüber installieren, Sonst manuell im Objekt ändern und neu starten alles
-
@apollon77 sagte in Test js-controller v2.0.x (GitHub):
@SBorg Sehr interessant. Dieser Fehler kommt an sich nur in zwei Situationen:
1.) Der Adapter startet und bekommt keine Verbindung zur DB (ioBroker? Redis?)
2.) Es gibt ein "connectTimeout" Event, was an sich nur kommt wenn socketIo auf der Gegenseite ist.Also hier müsste man jetzt mal vollständigere Logs sehen. und Infos haben. Master/Slave oder nur Single-Host und und und
Sind alles augenscheinlich nur schedule Adapter. Ist nur ein einfacher Single-Host mit file/file
Log habe ich mal umgestellt ob noch mehr kommt.
Normales Log ist wohl wenig aussagefähig:luftdaten.0 2019-11-10 16:25:18.937 info (7526) Terminated (NO_ERROR): Without reason luftdaten.0 2019-11-10 16:25:08.755 info (7526) starting. Version 0.0.9 in /opt/iobroker/node_modules/iobroker.luftdaten, node: v8.16.2 luftdaten.0 2019-11-10 16:25:06.510 warn (7526) no connection to objects DB host.Ubuntu 2019-11-10 16:25:00.433 info instance system.adapter.luftdaten.0 started with pid 7526 host.Ubuntu 2019-11-10 16:20:21.555 info instance system.adapter.luftdaten.0 terminated with code 0 (NO_ERROR) -
@SBorg Ok, also die Meldung ist nur eine Warnung wenn Sie bei einem normalen Start kommt. Sie besagt das innerhalb von 2s nach dem Adapterstart die Objects-DB noch nicht verbunden war. Da danach aber alles läuft ists erstmal ok ... sehr ungewöhnlich dennoch. Reboote vllt mal ... nicht das sich da irgendwie noch ein Prozess verklemmt hat - bzw schau beim 2.0.42 Update ob wirklich alles an prozessen weg ist
-
@apollon77 sagte in Test js-controller v2.0.x (GitHub):
Reboote vllt mal ... nicht das sich da irgendwie noch ein Prozess verklemmt hat
Schon öfters, aber aus anderen Gründen
Wenn es nichts ausmacht, ist es ja Ok. Werde nur bei warn etwas unruhig, zumal das erst seit den letzten 2 oder 3 Versionen auftritt. -
@ilovegym
Offenbar wurde der Mode beim Update nicht geändert. Dann solltest Du es manuell ändern.
-
@SBorg Mal schauen ob noch mehrere User sowas berichten. Ich hätte gerade keine Idee durch was hier was geändert wurde. Wie geht es dem System? RAM? CPU und so
-
@paul53 @apollon77
so, hab den meteoalarm Instanz gelöscht, iobroker gestoppt, dabei das Update auf die 2.0.42 (so gern stopp ich den halt nicht) gemacht, dann wieder neu gestartet, nachdem die meisten Adapter grün waren, dann den Meteoalarm neu installiert, und siehe da, jetzt passt es. Er läuft jetzt als daemon und das logfile sieht auch ganz entspannt aus..Ich weiß, hat nix mit dem 2.0.42 zu tun, aber wenn man schon stopp und start macht...
Und wieder Fehlermeldungen weniger.. prima! Danke euch allen ! -
@ilovegym sagte in Test js-controller v2.0.x (GitHub):
Er läuft jetzt als daemon und das logfile sieht auch ganz entspannt aus..
Du meinst er läuft als schedule ... korrekt?
-
@apollon77 sagte in Test js-controller v2.0.x (GitHub):
@ilovegym sagte in Test js-controller v2.0.x (GitHub):
Er läuft jetzt als daemon und das logfile sieht auch ganz entspannt aus..
Du meinst er läuft als schedule ... korrekt?
ja, genau
sieht man jetzt auch im Admin Adapter mit 30 Minuten.. -
@apollon77 sagte in Test js-controller v2.0.x (GitHub):
@SBorg Mal schauen ob noch mehrere User sowas berichten. Ich hätte gerade keine Idee durch was hier was geändert wurde. Wie geht es dem System? RAM? CPU und so
Gut
Dual-Core Celeron mit 2GB RAM, CPU-Last ~10-20%, RAM 500MB frei/SWAP 1.5GB frei
Seit ich vor 4 Stunden die entsprechenden Adapter von "info --> silly" umgestellt habe ist übrigens Ruhe, kein einziger Fehlversuch mehr. -
@SBorg dann stell mal zurück. Silly macht log halt voll.
-
@apollon77 Keine Ahnung ob Zufall, aber wieder auf "Info" zurück und schon:
ical.0 2019-11-10 23:00:24.701 warn (28785) no connection to objects DB dwd.0 2019-11-10 23:00:24.675 warn (28686) no connection to objects DB luftdaten.0 2019-11-10 23:00:24.642 warn (28427) no connection to objects DBWenn es aber eh keine Auswirkung hat, Wayne...
