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):
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?
-
@apollon77 Zwei Sekunden:
"objects": { "type": "file", "typeComment": "Possible values: 'file' - [port 9001], redis - [port 6379], couch - [port 5984].", "host": "127.0.0.1", "port": 9001, "user": "", "pass": "", "noFileCache": false, "connectTimeout": 2000, "options": { "auth_pass": null, "retry_max_delay": 5000 }
-
@SBorg Ok, was auch default ist. Da wir beim Objects init jetzt einiges mehr tun reicht die Zeit vllt manchmal nicht, ich erhöhe das dann in der nächsten Version mal
-
Hallo liebe tester!!
Ich habe heute nochmal ein bissl Stopping mit Disconnects und sowas getestet und da war noch ein Bug drin. Weil wir dennoch gern morgen in Stable wollen brauche ich Dringe Eure Hilfe (nochmal).
Bitte 2.0.44 vom GitHub testen. Ich packe die nach positiven Feedback von Euch nachher noch ins Latest.
Gern auch wieder master/Slave Fälle testen ... alsoSlaves wenn master weg und so ... das wäre extrem super!!
-
@apollon77 die v2.0.44 bekomme ich leider nicht (system is up to date)
-
@BBTown sagte in Test js-controller v2.0.x (GitHub):
@apollon77 die v2.0.44 bekomm eich leider nicht (system is up to date)
musst du mit npm install ioBroker/ioBroker.js-controller direkt von git ziehen. (erst in iobroker-verzeichnis..)
-
Und nochmal ich ... Wer die 2.0.44 VOR 19:19 installiert hat bitte nochmal ... da war noch ein Bug
Aber jetzt schaut es bnei mir ok aus
-
@apollon77
bei mir sieht alles unauffällig aus .... aber eben auch ein einfaches System (kein slave, file/file) -
@apollon77
Edit.....jetzt ging es doch weiter.... -
@apollon77 hier alles ohne Probleme - habe nachdem alles auf der 44 war, nochmal die Clienthosts rebootet, um zu sehen, was der iobroker macht, aber er wartet und die clients haben sich sehr schnell connected.
Andersrum auch getestet, die clients warten schön bis der Masterhost wieder da ist.
-
perfekt Danke!
-
Bis jetzt sieht es top aus, nicht mal beim hochfahren einen "objects-DB"-Fehler
-
@BBTown sagte in Test js-controller v2.0.x (GitHub):
@apollon77
bei mir sieht alles unauffällig aus .... aber eben auch ein einfaches System (kein slave, file/file)Dito.
-
Perfekt dann kommt es auf npm sobald die Kids im Bett sind.