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

@apollon77 hm jetzt kommt kein Fehler mehr.. die jenigen, die ich sah, waren auch nur Timeout ( Server no response after 8 sec ).
Allerdings läuft er hier alle paar Sekunden.. muss das so sein? Ist mir vorher nicht aufgefallen..

2019-11-10 15:55:00.167  - info: host.iobroker instance system.adapter.meteoalarm.0 terminated with code 0 (NO_ERROR)
2019-11-10 15:55:00.168  - info: host.iobroker Restart adapter system.adapter.meteoalarm.0 because enabled
2019-11-10 15:55:30.187  - info: host.iobroker instance system.adapter.meteoalarm.0 started with pid 13646
2019-11-10 15:55:30.908  - debug: meteoalarm.0 (13646) Redis Objects: Use Redis connection: 0.0.0.0:9001
2019-11-10 15:55:30.941  - debug: meteoalarm.0 (13646) objectDB connected
2019-11-10 15:55:30.942  - debug: meteoalarm.0 (13646) Redis States: Use Redis connection: 0.0.0.0:9000
2019-11-10 15:55:30.944  - debug: meteoalarm.0 (13646) Objects connected to redis: 0.0.0.0:9001
2019-11-10 15:55:30.950  - debug: meteoalarm.0 (13646) statesDB connected
2019-11-10 15:55:31.002  - debug: meteoalarm.0 (13646) States connected to redis: 0.0.0.0:9000
2019-11-10 15:55:31.569  - info: meteoalarm.0 (13646) starting. Version 1.0.6 in /opt/iobroker/node_modules/iobroker.meteoalarm, node: v10.17.0
2019-11-10 15:55:31.595  - info: meteoalarm.0 (13646) Requesting data from http://meteoalarm.eu/documents/rss/de/DE047.rss
2019-11-10 15:55:31.633  - silly: meteoalarm.0 (13646) States redis pmessage system.adapter.meteoalarm.0.logLevel/system.adapter.meteoalarm.0.logLevel:{"val":"silly","ack":true,"ts":1573397731592,"q":0,"from":"system.adapter.meteoalarm.0","lc":1573396804153}
2019-11-10 15:55:31.678  - info: meteoalarm.0 (13646) Received data for "Darmstadt-Dieburg / Darmstadt"
2019-11-10 15:55:31.682  - debug: meteoalarm.0 (13646) Loaded today data
2019-11-10 15:55:31.684  - debug: meteoalarm.0 (13646) Loaded tomorrow data
2019-11-10 15:55:39.689  - debug: meteoalarm.0 (13646) All done
2019-11-10 15:55:39.690  - info: meteoalarm.0 (13646) Terminated (NO_ERROR): Without reason
2019-11-10 15:55:40.209  - info: host.iobroker instance system.adapter.meteoalarm.0 terminated with code 0 (NO_ERROR)
2019-11-10 15:55:40.209  - info: host.iobroker Restart adapter system.adapter.meteoalarm.0 because enabled
2019-11-10 15:56:10.225  - info: host.iobroker instance system.adapter.meteoalarm.0 started with pid 13679
2019-11-10 15:56:10.913  - debug: meteoalarm.0 (13679) Redis Objects: Use Redis connection: 0.0.0.0:9001
2019-11-10 15:56:10.943  - debug: meteoalarm.0 (13679) objectDB connected
2019-11-10 15:56:10.946  - debug: meteoalarm.0 (13679) Redis States: Use Redis connection: 0.0.0.0:9000
2019-11-10 15:56:10.948  - debug: meteoalarm.0 (13679) Objects connected to redis: 0.0.0.0:9001
2019-11-10 15:56:10.955  - debug: meteoalarm.0 (13679) statesDB connected
2019-11-10 15:56:11.015  - debug: meteoalarm.0 (13679) States connected to redis: 0.0.0.0:9000
2019-11-10 15:56:11.495  - info: meteoalarm.0 (13679) starting. Version 1.0.6 in /opt/iobroker/node_modules/iobroker.meteoalarm, node: v10.17.0
2019-11-10 15:56:11.519  - info: meteoalarm.0 (13679) Requesting data from http://meteoalarm.eu/documents/rss/de/DE047.rss
2019-11-10 15:56:11.557  - silly: meteoalarm.0 (13679) States redis pmessage system.adapter.meteoalarm.0.logLevel/system.adapter.meteoalarm.0.logLevel:{"val":"silly","ack":true,"ts":1573397771516,"q":0,"from":"system.adapter.meteoalarm.0","lc":1573396804153}
2019-11-10 15:56:11.606  - info: meteoalarm.0 (13679) Received data for "Darmstadt-Dieburg / Darmstadt"
2019-11-10 15:56:11.609  - debug: meteoalarm.0 (13679) Loaded today data
2019-11-10 15:56:11.611  - debug: meteoalarm.0 (13679) Loaded tomorrow data
2019-11-10 15:56:19.659  - debug: meteoalarm.0 (13679) All done
2019-11-10 15:56:19.659  - info: meteoalarm.0 (13679) Terminated (NO_ERROR): Without reason
2019-11-10 15:56:20.185  - info: host.iobroker instance system.adapter.meteoalarm.0 terminated with code 0 (NO_ERROR)
2019-11-10 15:56:20.185  - info: host.iobroker Restart adapter system.adapter.meteoalarm.0 because enabled

apollon77

@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

apollon77

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 instances and only show compact infos if adapter supports it

SBorg

@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

apollon77

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

apollon77

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

paul53

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

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

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

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

NEWS

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

Support us

687
Online

31.9k
Users

80.1k
Topics

1.3m
Posts

NEWS

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

Support us

687Online

31.9kUsers

80.1kTopics

1.3mPosts

687
Online

31.9k
Users

80.1k
Topics

1.3m
Posts