Weihnachtsangebot 2025! 🎄

[A Former User]

@paul53 @apollon77 ja, im letzten Update ist das auf daemon geändert worden...

so siehts nach nem Upload aus, auch nicht besser..

[A Former User]

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

[apollon77]

@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

[SBorg]

@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)

[apollon77]

@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

[SBorg]

@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 :grin:
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.

[paul53]

@ilovegym

Offenbar wurde der Mode beim Update nicht geändert. Dann solltest Du es manuell ändern.

[apollon77]

@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

[A Former User]

@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 !

[apollon77]

@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? ;-)

[A Former User]

@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.. :-)

[SBorg]

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

[apollon77]

@SBorg dann stell mal zurück. Silly macht log halt voll.

[SBorg]

@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... :grin:

[apollon77]

@SBorg hattest du so ein silly log mal gepostet? Bzw was ist bei debug?

[SBorg]

@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

[apollon77]

@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?

[SBorg]

@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
    }

[apollon77]

@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

[apollon77]

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