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

e-i-k-e

kurze Rückmeldung.

Mein Multihost System läuft jetzt komplett auf 2.0.9. Objekte und neuerdings auch Files laufen auf redis.
Auch das reconnect der Slave nach einem Neustart des Masters funktionirt einwandfrei.
Ich musste allerdings den js.controller mit dem Befehl

sudo -H -u iobroker npm install ioBroker/ioBroker.js-controller

installieren. Egal ob root oder normaler user, auch der fixer brachte keine besserung.

Alle Adapter sind grün, bis jetzt konnte ich keine Fehler feststellen.

Mir ist aufgefallen, das laut Anzeige 19 "vis" Instanzen installiert sind.

apollon77

@SBorg Die Fragfe war auch eher allgemein und rethorisch gemeint weil viele Leute das tun (und mit 1.5.x getan haben und so ...) ... ;-))

apollon77

@e-i-k-e sagte in [Aufruf] js-controller 2.0 Beta Test:

Mein Multihost System läuft jetzt komplett auf 2.0.9. Objekte und neuerdings auch Files laufen auf redis.

Wie waren die Meldungen bei den "iobroker setup custom"? War das alles eindeutig und korrekt - vor allem auch wegen Master und Slave und so? Konntest Du nichts falsch machen oder gab es Punkte wo du bange hattest? Real user Feedback ist da cool.

Mir ist aufgefallen, das laut Anzeige 19 "vis" Instanzen installiert sind.
lol ... legst Du dazu bitte mal ein GitHub Issue im js-controller an? Muss ich ansehen. kann es stimmen wenn du alle Vis-Widget und Icons und so noch dazurechnest? also alles was mit vis beginnt? Wäre meine Vermutung

AlCalzone

@e-i-k-e sagte in [Aufruf] js-controller 2.0 Beta Test:

Egal ob root oder normaler user, auch der fixer brachte keine besserung.

Was war denn die Fehlermeldung wenn du das nicht mit sudo ausgeführt hast?

AlCalzone

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

also alles was mit vis beginnt? Wäre meine Vermutung

Wäre auch meine. Also Regex-Test mit /^vis./ anstatt /^vis\./

apollon77

@AlCalzone oder es ist in getInstances und damit unterschied wegen "Redis" oder so ...

watcherkb

bekomme folgende Fehlermeldung im Log:

host.iObroker	2019-09-25 12:50:19.577	error	Caught by controller[0]: .0: ../deps/uv/src/unix/poll.c:123: uv_poll_start: Assertion `!(((handle)->flags & (UV_HANDLE_CLOSING | UV_HANDLE_CLOSED)) != 0)' failed.

AlCalzone

@watcherkb Ich denke wir benötigen etwas mehr Kontext. Stürzt ein Adapter ab?

watcherkb

@AlCalzone sorry...hier nochmal detaillierter: ich habe ein Testsystem aufgesetzt und dort mein Backup vom Livesystem eingespielt. Alle Adapter bis auf den radar2 sind deaktiviert. Fehler kommt auch erst, wenn ich den radar2 Adapter starte. Vielleicht hat das ja auch mit dem eigentlich Update von js nichts zu tun.

host.iObroker	2019-09-25 13:20:01.382	info	Restart adapter system.adapter.radar2.0 because enabled
host.iObroker	2019-09-25 13:20:01.382	info	instance system.adapter.radar2.0 terminated with code NaN ()
host.iObroker	2019-09-25 13:20:01.381	warn	instance system.adapter.radar2.0 terminated due to SIGABRT
host.iObroker	2019-09-25 13:20:01.381	error	Caught by controller[0]: .0: ../deps/uv/src/unix/poll.c:123: uv_poll_start: Assertion `!(((handle)->flags & (UV_HANDLE_CLOSING | UV_HANDLE_CLOSED)) != 0)' failed.
radar2.0	2019-09-25 13:20:01.208	info	(2382) debug: radar2 received undefined objects and 1 states, with config devices,scandelay,arp_scan_cmd,btadapterid,printerdelay,debug,knownIPs,knownBTs,external,delayaway,delayuwz,numuwz,hcionly,l2
radar2.0	2019-09-25 13:20:01.148	info	(2382) starting. Version 1.2.0 in /opt/iobroker/node_modules/iobroker.radar2, node: v10.16.3
radar2.0	2019-09-25 13:20:00.793	debug	(2382) States connected to redis: 127.0.0.1:6379
radar2.0	2019-09-25 13:20:00.787	debug	(2382) statesDB connected
radar2.0	2019-09-25 13:20:00.784	debug	(2382) Objects connected to redis: 127.0.0.1:9001
radar2.0	2019-09-25 13:20:00.782	debug	(2382) Redis States: Use Redis connection: 127.0.0.1:6379
radar2.0	2019-09-25 13:20:00.780	debug	(2382) objectDB connected
radar2.0	2019-09-25 13:20:00.731	debug	(2382) Redis Objects: Use Redis connection: 127.0.0.1:9001
host.iObroker	2019-09-25 13:20:00.059	info	instance system.adapter.radar2.0 started with pid 2382
host.iObroker	2019-09-25 13:20:00.037	info	"system.adapter.radar2.0" enabled
host.iObroker	2019-09-25 13:20:00.036	info	object change system.adapter.radar2.0 (from: system.adapter.admin.0)

SBorg

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

@SBorg Nein. Aber damit habe ich die Möglichkeit, diese Option von npm auszuschalten.

Danke, dachte schon bin blind. Im Alter weiß man ja nie... ^^

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

@SBorg Die Fragfe war auch eher allgemein und rethorisch gemeint weil viele Leute das tun (und mit 1.5.x getan haben und so ...) ... ;-))

Alles gut ...und ich teste gerne.
Jetzt müsste man nur noch wissen woran es liegt

e-i-k-e

@apollon77

Ich muss gestehen, dass mein English nicht das Beste ist und ich deswegen übersetzen musste. Danach waren mir die Meldungen klar.

Die erste Frage war glaube ich: " Es wurde automatisch erkannt das dieser Host ein Slave ist, ist das korrekt? Y/N (oder so ähnlich).
Dies wurde mir auch auf dem Master so angezeigt. Vieleicht wäre es einfacher zu fragen, ob dieser Host ein Master oder Slave ist.

Zu Vis, Jackpot!
Sind genau 19 Instanzen die mit Vis anfangen Zudem fehlen die Icon ("iobroker update all" wurde natürlich ausgeführt).

e-i-k-e

@AlCalzone

npm install ioBroker/ioBroker.js-controller

pi@raspberrypi-slave:~ $ iobroker stop
pi@raspberrypi-slave:~ $ cd /opt/iobroker
pi@raspberrypi-slave:/opt/iobroker $ npm install ioBroker/ioBroker.js-controllernpm ERR! code EPERM
npm ERR! syscall spawn
npm ERR! errno EPERM
npm ERR! Error: spawn EPERM
npm ERR!     at ChildProcess.spawn (internal/child_process.js:366:11)
npm ERR!     at spawn (child_process.js:551:9)
npm ERR!     at execFile (child_process.js:221:15)
npm ERR!     at tryCatcher (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)
npm ERR!     at ret (eval at makeNodePromisifiedEval (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:16:23)
npm ERR!     at promiseRetry (/usr/lib/node_modules/npm/node_modules/pacote/lib/util/git.js:192:14)
npm ERR!     at /usr/lib/node_modules/npm/node_modules/promise-retry/index.js:29:24
npm ERR!  { Error: spawn EPERM
npm ERR!     at ChildProcess.spawn (internal/child_process.js:366:11)
npm ERR!     at spawn (child_process.js:551:9)
npm ERR!     at execFile (child_process.js:221:15)
npm ERR!     at tryCatcher (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)
npm ERR!     at ret (eval at makeNodePromisifiedEval (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:16:23)
npm ERR!     at promiseRetry (/usr/lib/node_modules/npm/node_modules/pacote/lib/util/git.js:192:14)
npm ERR!     at /usr/lib/node_modules/npm/node_modules/promise-retry/index.js:29:24
npm ERR!   cause:
npm ERR!    { Error: spawn EPERM
npm ERR!        at ChildProcess.spawn (internal/child_process.js:366:11)
npm ERR!        at spawn (child_process.js:551:9)
npm ERR!        at execFile (child_process.js:221:15)
npm ERR!        at tryCatcher (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)
npm ERR!        at ret (eval at makeNodePromisifiedEval (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:16:23)
npm ERR!        at promiseRetry (/usr/lib/node_modules/npm/node_modules/pacote/lib/util/git.js:192:14)
npm ERR!        at /usr/lib/node_modules/npm/node_modules/promise-retry/index.js:29:24 errno: 'EPERM', code: 'EPERM', syscall: 'spawn' },
npm ERR!   stack:
npm ERR!    'Error: spawn EPERM\n    at ChildProcess.spawn (internal/child_process.js:366:11)\n    at spawn (child_process.js:551:9)\n    at execFile (child_process.js:221:15)\n    at tryCatcher (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)\n    at ret (eval at makeNodePromisifiedEval (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:16:23)\n    at promiseRetry (/usr/lib/node_modules/npm/node_modules/pacote/lib/util/git.js:192:14)\n    at /usr/lib/node_modules/npm/node_modules/promise-retry/index.js:29:24',
npm ERR!   errno: 'EPERM',
npm ERR!   code: 'EPERM',
npm ERR!   syscall: 'spawn',
npm ERR!   parent: 'iobroker' }
npm ERR!
npm ERR! The operation was rejected by your operating system.
npm ERR! It is likely you do not have the permissions to access this file as the current user
npm ERR!
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/pi/.npm/_logs/2019-09-25T17_19_35_938Z-debug.log

sudo -H -u iobroker npm install ioBroker/ioBroker.js-controller

pi@raspberrypi-slave:/opt/iobroker $ sudo -H -u iobroker npm install ioBroBroker.js-controller

> iobroker.js-controller@2.0.9 preinstall /opt/iobroker/node_modules/iobro-controller
> node lib/preinstallCheck.js

NPM version: 6.11.3

> iobroker.js-controller@2.0.9 install /opt/iobroker/node_modules/iobrokerntroller
> node iobroker.js setup first

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.0.7 (node_modulvents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fse2.0.7: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":)
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: osx-temperature-sensor@1.0de_modules/osx-temperature-sensor):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for osxrature-sensor@1.0.4: wanted {"os":"darwin","arch":"any"} (current: {"os":","arch":"arm"})

+ iobroker.js-controller@2.0.9
updated 3 packages and audited 1656 packages in 87.662s
found 14 vulnerabilities (9 low, 5 high)
  run `npm audit fix` to fix them, or `npm audit` for details

e-i-k-e

Nach einem Neustart des Masters, blieben einige Adapter gelb/rot.
Erst nachdem ich einen manuellen Neustart der Adapter durchgeführt , wurden diese grün.

Anbei das log. iobroker.2019-09-25.log
Neustart Master ~19.00 Uhr
Neustart der gelb/roten Adapter: ~19.37Uhr

apollon77

@e-i-k-e ich denke, warum auch immer, das das nur ein Anzeigeproblem im Admin ist.

Zum verifizieren:
Nach dem Start wenn eine solche Instanz gelb ist:

„iobroker state get Adapter.0.info.connection“ aufrufen. Ist val auf true??
wenn ja bitte in Admin gehen und unter Objekte auch bis zu dem info.connection durchklicken. Steht da true?
jetzt auf Instanzen zurück ... wird jetzt grün angezeigt?

apollon77

@e-i-k-e Update all ??or upload all?? Letzteres wäre das korrekte

Zur Anzahl Instanzen; ich checke. Vllt hat es such was mit dem info connection zu tun

e-i-k-e

@apollon77 natürlich Upload all

apollon77

@e-i-k-e mach bitte nochmal und poste log. Alle hosts müssen laufen für das "uplaod all"!

apollon77

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

Kernel aktuell? Alle Updates installiert?

VBei libuv Fehler ist man recht "weit unten" ... Sollte mit controller eher nichts zu tun haben

apollon77

So Hey All,

später heute (informiere dann nochmal getrennt) kommt noch eine 2.0.10 mit kleineren Dingen und Optimierungen. Aber auch hier nichts größeres mehr dabei.

Der Stand zu den aus meiner Sicht hier "offenen "Themen:

iqontrol tut generell, gibt noch paar Kleinigkeiten, aber da ist der Dev dran. Aktuell nichts was der controller direkt verursachen sollte
radar2 wirft aktuell einen Fehler, aber auch das liegt aktuell daran wie der Adapter mit einer js-controller Bibliothek umgeht. Auch hier gibts ein Issue beim Adapter. Ich hoffe Frank hat bald Zeit reinzschauen
Ich habe viel rumgetestet aber konnte weder das "19 vis Instanzen"-Anzeigeproblem noch die "Instanzen werden gelb/rot im Admin angezeigt obwohl grün". Habe jetzt in meinem Testumfeld aber auch kein Multihost.

Vor allem zu letztem Punkt:
Bitte nochmal Admin per "Shift-Reload" bzw Forced Reload bzw Browser-Cache löschen neu laden. Ich kann mir gerade nur vorstellen das das ein "Timing Issue" irgendwie ist. Hier auch mal die Browser-Konsole checken. Da müssten Meldungen wie "Subscribe system.adapter." und "Subscribe.info.connection" kommen. Wenn nicht stimmt ggf was nicht. Ich denke das ggf der Admin der zwar zuerst startet dann einen Datenstand hat dr angezeigt wird wenn die seite geladen istm, aber ggf gibts zwischen "Mit den Daten die Seite anzeigen" und "ab jetzt aktualisierungen empfangen" einen kleinen gap und Adater die in der Zeit fertig geworden sind haben dann alte Daten oder sowas. Und das "Info.connection" wird meistens nur einmalig gesendet.
Zu dem "19 bis instanzen" hab ich aktuell eher keine Idee ... Aber auch hier bitte mal Force reload.

Oder gibts noch andere Themen (ausser dem npm install Thema mit rechten was eigentlich off-topic ist )

arteck

@apollon77 ich galub du hast alles erwähnt...

NEWS

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

Support us

1.2k
Online

30.4k
Users

76.5k
Topics

1.2m
Posts

NEWS

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

Support us

1.2kOnline

30.4kUsers

76.5kTopics

1.2mPosts

1.2k
Online

30.4k
Users

76.5k
Topics

1.2m
Posts