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

apollon77

@Einstein67 Hab den Grund gefunden. Wird in nächster version gefixt sein

apollon77

@snador SocketIo Adapter bleibt und Auch Admin und so nutzen SocketIO Weiterhin. Nur der js.controller für seine interne Kommunikation nicht mehr. Hat darauf keine Auswirkung

apollon77

@darkiop Der ZIP Download läuft anders, da loggt der JS Adapter nix.

log.level in der iobroker.json ist das Loglevel vom JS-Controller selbst ...

apollon77 · Mit der 2.0.17 wars noch ok Gruß Sven

@sven12 tut er noch oder nur "rot?

sven12

@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:

@sven12 tut er noch oder nur "rot?

Ob er noch tut kann ich jetzt gerade nicht testen. Reiche ich aber morgen nach....
Gruß
Sven

Hier das Logfile

2019-10-03 22:19:06.731  - debug: shelly.0 (20158) objectDB connected
2019-10-03 22:19:06.735  - debug: shelly.0 (20158) Redis States: Use Redis connection: 0.0.0.0:9000
2019-10-03 22:19:06.738  - debug: shelly.0 (20158) Objects connected to redis: 0.0.0.0:9001
2019-10-03 22:19:06.742  - debug: shelly.0 (20158) statesDB connected
2019-10-03 22:19:06.757  - debug: shelly.0 (20158) States connected to redis: 0.0.0.0:9000
2019-10-03 22:19:07.699  - info: shelly.0 (20158) starting. Version 3.1.0 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.16.1
2019-10-03 22:19:07.755  - info: shelly.0 (20158) Stating Shelly adapter in CoAP modus.
2019-10-03 22:19:07.824  - info: host.iobroker-host instance system.adapter.shelly.0 terminated with code 0 (NO_ERROR)
2019-10-03 22:19:07.825  - info: host.iobroker-host Restart adapter system.adapter.shelly.0 because enabled
2019-10-03 22:19:08.676  - info: host.iobroker-host instance system.adapter.shelly.0 started with pid 20387
2019-10-03 22:19:09.600  - debug: shelly.0 (20387) Redis Objects: Use Redis connection: 0.0.0.0:9001
2019-10-03 22:19:09.642  - debug: shelly.0 (20387) objectDB connected
2019-10-03 22:19:09.644  - debug: shelly.0 (20387) Redis States: Use Redis connection: 0.0.0.0:9000
2019-10-03 22:19:09.645  - debug: shelly.0 (20387) Objects connected to redis: 0.0.0.0:9001
2019-10-03 22:19:09.649  - debug: shelly.0 (20387) statesDB connected
2019-10-03 22:19:09.659  - debug: shelly.0 (20387) States connected to redis: 0.0.0.0:9000
2019-10-03 22:19:10.512  - info: shelly.0 (20387) starting. Version 3.1.0 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.16.1
2019-10-03 22:19:10.558  - info: shelly.0 (20387) Stating Shelly adapter in CoAP modus.
2019-10-03 22:19:10.645  - info: host.iobroker-host instance system.adapter.shelly.0 terminated with code 0 (NO_ERROR)
2019-10-03 22:19:10.646  - info: host.iobroker-host Restart adapter system.adapter.shelly.0 because enabled
2019-10-03 22:19:22.846  - info: host.iobroker-host instance system.adapter.poolcontroller.0 terminated with code 0 (NO_ERROR)
2019-10-03 22:19:40.682  - info: host.iobroker-host instance system.adapter.shelly.0 started with pid 21308
2019-10-03 22:19:41.789  - debug: shelly.0 (21308) Redis Objects: Use Redis connection: 0.0.0.0:9001
2019-10-03 22:19:41.834  - debug: shelly.0 (21308) objectDB connected
2019-10-03 22:19:41.835  - debug: shelly.0 (21308) Redis States: Use Redis connection: 0.0.0.0:9000
2019-10-03 22:19:41.837  - debug: shelly.0 (21308) Objects connected to redis: 0.0.0.0:9001
2019-10-03 22:19:41.841  - debug: shelly.0 (21308) statesDB connected
2019-10-03 22:19:41.853  - debug: shelly.0 (21308) States connected to redis: 0.0.0.0:9000
2019-10-03 22:19:43.147  - info: shelly.0 (21308) starting. Version 3.1.0 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.16.1
2019-10-03 22:19:43.884  - info: shelly.0 (21308) Stating Shelly adapter in CoAP modus.
2019-10-03 22:19:44.298  - info: host.iobroker-host instance system.adapter.shelly.0 terminated with code 0 (NO_ERROR)
2019-10-03 22:19:44.298  - info: host.iobroker-host Restart adapter system.adapter.shelly.0 because enabled
2019-10-03 22:20:00.050  - info: host.iobroker-host instance system.adapter.poolcontroller.0 started with pid 21795

Stuebi · Mit der 2.0.17 wars noch ok Gruß Sven

@sven12 , ich habe gerade den Fall nachgestellt. D.h. Shelly Adapter 3.1.0 und js-controller in Version 2.0.21 im CoAP Modus installiert. Funktioniert bei mir wunderbar. Der Adapter wird nicht neu gestartet. Siehst Du irgendwelche Fehlermeldungen im Logfile (rote Error Meldungen)?
Hast Du Redis installiert? Das habe ich mir auf der Maschine nicht.

VG
Stübi

apollon77

Hi All,

auf GitHub wartet die 2.0.22 auf Euch. Das JavaScript ZIP Download sollte damit gefixt sein und ich habe auch etwas an der Performance gearbeitet.

@SBorg Wie lange braucht daswetter jetzt? (Aber nicht zuviel erwarten ...)

SBorg

Juckt zwar in den Fingern, aber jetzt laufen bei mir gleich sämtliche Tagesskripte, muss bis morgen früh warten :(

apollon77

@SBorg Also auf meinem redis/redis system braucht daswetter mit 2700 Werten 10s :-) Ich stelle das dann mal auf file/file um ...

apollon77

@SBorg Brauchst nicht traurig sein ... meine Optimierungen haben weniger gebracht als ich dachte :-(

redis/redis laufen 2700 Werte in 10s durch
file/file sinds 130s

:-(

Bin dran

MathiasJ

..ich warte mal, bis der neue JS-Controller läuft.
OT:
Weiß jemand, ob man nodejs 12 schon gefahrlos installieren kann?
Bei meiner Testinstallation wollte ja Radar2 und BLE nicht.

apollon77

@MathiasJ

Generell läuft alles. Es gibt nur bei Adaptern wie daswetter die in einem Schlag mehrere tausend Objekte anlegen und solche Dinge tun noch Performance-Themen.

nodejs12 - der controller kanns ... ich bin leider zeitlich komplett damit gebunden sodass ich gerade keinen Überblick habe welche Adapter aufgrund Ihrer Dependencies mit nodejs 12 laufen und welche nicht. Ich würde weiterhin auf 10 setzen

e-s

@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:

@SBorg Brauchst nicht traurig sein ... meine Optimierungen haben weniger gebracht als ich dachte :-(

redis/redis laufen 2700 Werte in 10s durch

file/file sinds 130s

:-(

Bin dran

Kann das auch zu generellen Performanceproblemen führen? Gefühlt ist das ganze System recht träge, nutze derzeit nur File.
Besonders stark ist mir das aufgefallen, als ich unter Adapter die Suche nutzen wollte. Kann dies damit zusammenhängen?

apollon77

@e-s Im Admin wird an sich alles initial geladen und alles andere (Filtern der Adapter und so) findet dann nur im Browser statt ... also in dem Fall eher nicht.
Ob man die aktuellen Performancethemen wirklich merkt weiss ich gerade nicht. Es kommt gerade vor allem bei Adaptern mit sehr vielen Object/State anlagen in einzelnen Aufrufen dazu das man es merkt weil sich da Dinge summieren ...

SBorg

@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:

@SBorg Brauchst nicht traurig sein ... meine Optimierungen haben weniger gebracht als ich dachte :-(

redis/redis laufen 2700 Werte in 10s durch

file/file sinds 130s

:-(

Bin dran

Och, traurig bin ich nicht ;)
...aber wie du schon befürchtet hattest:

2.0.22
host.Ubuntu	2019-10-04 09:28:58.714	info	instance system.adapter.daswetter.0 terminated with code 0 (NO_ERROR)
daswetter.0	2019-10-04 09:26:07.998	info	(15967) starting. Version 2.8.1 in /opt/iobroker/node_modules/iobroker.daswetter, node: v8.16.1
host.Ubuntu	2019-10-04 09:26:00.090	info	instance system.adapter.daswetter.0 started with pid 15967

2.0.19
2019-10-03 23:28:55.784 - info: host.Ubuntu instance system.adapter.daswetter.0 terminated with code 0 (NO_ERROR)
2019-10-03 23:28:55.484 - info: daswetter.0 (1180) Terminated (NO_ERROR): Without reason
2019-10-03 23:26:06.438 - info: daswetter.0 (1180) starting. Version 2.8.1 in /opt/iobroker/node_modules/iobroker.daswetter, node: v8.16.1

Also round about ~180 Sekunden und immer noch etwas mehr als 5x langsamer wie der 1.5.14. Aktuell würde bei mir nur noch ein Raspberry 4 mit 4GB RAM funktionieren.

sigi234

@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:

Hi All,

auf GitHub wartet die 2.0.22 auf Euch. Das JavaScript ZIP Download sollte damit gefixt sein und ich habe auch etwas an der Performance gearbeitet.

@SBorg Wie lange braucht daswetter jetzt? (Aber nicht zuviel erwarten ...)

Aktualisiert, war extrem langsam danach. Nach einem Neustart ging es aber wieder.

@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:

Das JavaScript ZIP Download sollte damit gefixt sein

Ja

@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:

auch etwas an der Performance gearbeitet

Ja, kommt mir schneller vor. Die Ram-Auslastung wurde deutlich weniger. Kann das sein?

apollon77

@sigi234 sagte in [Aufruf] js-controller 2.0 Beta Test:

Ja, kommt mir schneller vor. Die Ram-Auslastung wurde deutlich weniger. Kann das sein?

RAM an sich eher nicht :-) Auch nach aktuellen tests sollten die Geschwindigkeitsgewinne eher klein ausgefallen sein :-(

sven12

@apollon77

bin jetzt auf 2.0.22. Shelly am Host immer noch rot und ohne Funktion.
Bei mir läuft ioBroker Host auf Debian 9 in einer VM unter Proxmox.
Ein Multihostclient auf Raspi.
Der Shelly Adapter auf dem Host läuft nicht und ist rot, wenn ich den auf den PI verschiebe funktioniert er dort aber.
Edit: Wobei ich erwähnen sollte, das die ip 192.168.10.57 der debian host ist, der client auf dem es läuft hat 192.168.10.25
Hier das Log vom pi

2019-10-04 14:24:08.435  - info: host.ccu2rfdpieasy instance system.adapter.shelly.0 started with pid 30156
2019-10-04 14:24:13.261  - debug: shelly.0 (30156) Redis Objects: Use Redis connection: 192.168.10.57:9001
2019-10-04 14:24:13.691  - debug: shelly.0 (30156) objectDB connected
2019-10-04 14:24:13.701  - debug: shelly.0 (30156) Redis States: Use Redis connection: 192.168.10.57:9000
2019-10-04 14:24:13.711  - debug: shelly.0 (30156) Objects connected to redis: 192.168.10.57:9001
2019-10-04 14:24:13.731  - debug: shelly.0 (30156) statesDB connected
2019-10-04 14:24:13.811  - debug: shelly.0 (30156) States connected to redis: 192.168.10.57:9000
2019-10-04 14:24:14.538  - info: shelly.0 (30156) starting. Version 3.1.0 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.16.1
2019-10-04 14:24:14.768  - info: shelly.0 (30156) Stating Shelly adapter in CoAP modus.
2019-10-04 14:24:15.312  - info: shelly.0 (30156) Listening for Shelly packets in the network
2019-10-04 14:24:19.295  - debug: shelly.0 (30156) CoAP status package received: {"3332":"SHSW-1#5BAC87#1","3412":38400,"3420":1024,"Uri-Path":"cit/s"} / {"G":[[0,112,1],[0,118,0]]}
2019-10-04 14:24:19.298  - debug: shelly.0 (30156) Status update received for SHSW-1#5BAC87#1: {"G":[[0,112,1],[0,118,0]]}
2019-10-04 14:24:19.303  - debug: shelly.0 (30156) CoAP device description request for SHSW-1#5BAC87#1 to 192.168.10.79(0)
2019-10-04 14:24:19.341  - debug: shelly.0 (30156) CoAP response: {"3332":"SHSW-1#5BAC87#1"}
2019-10-04 14:24:19.343  - debug: shelly.0 (30156) Device description received: {"3332":"SHSW-1#5BAC87#1"} / {"blk":[{"I":0,"D":"Relay0"},{"I":118,"T":"S","D":"Input","R":"0/1/2","L":1}],"sen":[{"I":112,"T":"Switch","R":"0/1","L":0}],"act":[{"I":211,"D":"Switch","L":0,"P":[{"I":2011,"D":"ToState","R":"0/1"}]}]}
2019-10-04 14:24:19.352  - info: shelly.0 (30156) Shelly device 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1) with CoAP connected!
2019-10-04 14:24:19.430  - debug: shelly.0 (30156) CoAP Message for SHSW-1#5BAC87#1 : {"G":[[0,112,1],[0,118,0]]}
2019-10-04 14:24:19.432  - debug: shelly.0 (30156) Create State : SHSW-1#5BAC87#1.Relay0.Switch, Payload: {"G":[[0,112,1],[0,118,0]]}for SHSW-1#5BAC87#1
2019-10-04 14:24:19.435  - debug: shelly.0 (30156) State change : SHSW-1#5BAC87#1.Relay0.Switch, Value: true for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:19.649  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.Relay0.AutoTimerOff, Value: 0 for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:19.654  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.Relay0.AutoTimerOn, Value: 0 for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:19.658  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.version, Value: "20190821-094851/v1.5.2@4148d2b7" for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:19.749  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.firmware, Value: false for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:19.755  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.uptime, Value: "01:31:39" for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:19.757  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.hostname, Value: "192.168.10.79" for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:19.760  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.rssi, Value: -56 for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:24.939  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.uptime, Value: "01:31:44" for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:24.942  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.rssi, Value: -57 for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:30.121  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.uptime, Value: "01:31:50" for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:30.126  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.rssi, Value: -56 for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:34.249  - debug: shelly.0 (30156) CoAP data ignored: {"3332":"SHSW-1#5BAC87#1","3412":38400,"3420":1024,"Uri-Path":"cit/s"} / {"G":[[0,112,1],[0,118,0]]}
2019-10-04 14:24:35.308  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.uptime, Value: "01:31:55" for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:35.313  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.rssi, Value: -54 for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:40.493  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.uptime, Value: "01:32:00" for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)
2019-10-04 14:24:40.496  - debug: shelly.0 (30156) Set state SHSW-1#5BAC87#1.rssi, Value: -55 for 192.168.10.79 (shelly1 / shelly1-5BAC87 / SHSW-1#5BAC87#1)

@Stuebi könnte also mit Redis zusammen hängen, möglicherweise ist es auf dem Pi drauf und auf dem Debian 9 x64 Host nicht.... Weiß nur nicht wie ich das rausfinden kann

coyote

@apollon77 update auf 2.0.22 mit Umstellung auf redis/redis sieht jetzt gut aus. Alles ohne Fehler in der Konsole durchgelaufen. web Adapter musste ich einmal neu durchstarten, der blieb rot.
Jetzt sind alle Adapter grün.
Aber es kamen öfter warn Meldungen im Log:

hm-rega.0	2019-10-04 16:47:32.742	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.742	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.742	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.742	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.742	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.742	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.742	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.742	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.742	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.742	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.741	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.741	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.741	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.741	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.741	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.741	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.741	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.740	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.725	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.725	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
hm-rega.0	2019-10-04 16:47:32.725	warn	(1855) get state ReplyError: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.

Was sagt mir das?

apollon77

@sven12 Werden denn die Werte die da im log stehen so aktualisert? Auf was stehen die werte im Admin? Kannst Du schalten? bzw jetzt sag mal bitte ganz genau was "ist rot" bedeutet ... oder kannst Du nichts mehr schalten udn es kommen keine Werte an? Wo geprüft? Admin?

Community Forum

NEWS

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

Support us

793

32.4k

81.4k

1.3m