NEWS
Test js-controller v2.0.x (GitHub)
-
@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. -
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 DB
Wenn es aber eh keine Auswirkung hat, Wayne...
-
@SBorg hattest du so ein silly log mal gepostet? Bzw was ist bei debug?
-
@apollon77 nein, weil es im silly/debug-Modus problemlos läuft:
2019-11-10 20:33:13.435 - info: host.Ubuntu instance system.adapter.yr.0 terminated with code 0 (NO_ERROR) 2019-11-10 20:35:00.105 - info: host.Ubuntu instance system.adapter.luftdaten.0 started with pid 28937 2019-11-10 20:35:03.705 - debug: luftdaten.0 (28937) Redis Objects: Use Redis connection: 127.0.0.1:9001 2019-11-10 20:35:05.065 - debug: luftdaten.0 (28937) Objects connected to redis: 127.0.0.1:9001 2019-11-10 20:35:05.094 - debug: luftdaten.0 (28937) objectDB connected 2019-11-10 20:35:05.099 - debug: luftdaten.0 (28937) Redis States: Use Redis connection: 127.0.0.1:9000 2019-11-10 20:35:05.123 - debug: luftdaten.0 (28937) statesDB connected 2019-11-10 20:35:05.182 - debug: luftdaten.0 (28937) States connected to redis: 127.0.0.1:9000 2019-11-10 20:35:06.135 - info: luftdaten.0 (28937) starting. Version 0.0.9 in /opt/iobroker/node_modules/iobroker.luftdaten, node: v8.16.2 2019-11-10 20:35:06.232 - debug: luftdaten.0 (28937) sensor type: remote, sensor identifier: XXX, sensor name: XXX 2019-11-10 20:35:06.243 - debug: luftdaten.0 (28937) remote request started 2019-11-10 20:35:06.424 - silly: luftdaten.0 (28937) States redis pmessage system.adapter.luftdaten.0.logLevel/system.adapter.luftdaten.0.logLevel:{"val":"silly","ack":true,"ts":1573414506361,"q":0,"from":"system.adapter.luftdaten.0","lc":1573400109996} 2019-11-10 20:35:07.298 - debug: luftdaten.0 (28937) remote request done 2019-11-10 20:35:07.299 - debug: luftdaten.0 (28937) received data (200): [{"sensor":{"id": --- langer JSON-String mit Daten --- ":null,"timestamp":"2019-11-10 19:29:54"}] 2019-11-10 20:35:16.294 - debug: luftdaten.0 (28937) cleaned everything up... 2019-11-10 20:35:16.413 - info: luftdaten.0 (28937) Terminated (NO_ERROR): Without reason 2019-11-10 20:35:16.934 - info: host.Ubuntu instance system.adapter.luftdaten.0 terminated with code 0 (NO_ERROR) 2019-11-10 20:40:00.056 - info: host.Ubuntu instance system.adapter.luftdaten.0 started with pid 6119 2019-11-10 20:40:04.292 - info: host.Ubuntu instance system.adapter.dwd.0 started with pid 6347 2019-11-10 20:40:04.435 - debug: luftdaten.0 (6119) Redis Objects: Use Redis connection: 127.0.0.1:9001 2019-11-10 20:40:05.878 - debug: luftdaten.0 (6119) Objects connected to redis: 127.0.0.1:9001 2019-11-10 20:40:05.922 - debug: luftdaten.0 (6119) objectDB connected 2019-11-10 20:40:05.931 - debug: luftdaten.0 (6119) Redis States: Use Redis connection: 127.0.0.1:9000
-
@SBorg Zeig mal bitte aus der /opt/iobroker/iobroker-data/iobroker.json den "objects" Abschnitt. Da ist ein Feld "connectTimeout" ... was steht da bei Dir?