NEWS
Test js-controller v2.0.x (GitHub)
-
@Jan1 Ich hätte mindestesn eine Meldung "compact geht nicht daher starte ich normal" erwartet und dann sollte der start direkt erfolgen und ein pot. gestarteter compact sollte sich beenden.
@apollon77
so hab noch mal die 0.9.0 drauf und den compact modus aktiviert, jetzt waren plötzlich viele Fehler im Log
War ne blöde Idee noch mal auf 0.9.0 zurück zu gehen, jetzt startet der BLE Adapter nicht mehr. Bin gerade am reparieren.
Läuft wieder nach dem der Fixer drüber ist
-
@SBorg den git clone Fehler hatte Arteck auch mal plötzlich. Ursache muss irgendwo bei npm liegen. Aber gut zu wissen das das andere Kommando tat.
Node-red release ich dann heute Abend.
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg den git clone Fehler hatte Arteck auch mal plötzlich. Ursache muss irgendwo bei npm liegen...
Zumindest habe ich ihn jetzt permanent. Ohne "sudo -H..." lässt sich nichts mehr installieren. Die Fehlermeldung seitens npm scheint mir aber auch irreführend. Ich habe ja alle Rechte im tmp-Verzeichnis und spaßeshalber ein chmod 777 darauf bringt keinerlei Besserung. Ev. bringt ja ein neues npm-Release Besserung ;)
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
Auf Systemen, die mit dem neuen Windows Installer eingerichtet wurden, darf der js-controller nicht mir npm aktualisiert werden. Es wird eine neue Version des Windows Installers geben, die das Update des js-controllers mit wenigen Mausklicks ermöglicht. Wir updaten dazu hier im Thread.
[Edit: Defekte Links entfernt. 24.09.19, stabilostick]
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg den git clone Fehler hatte Arteck auch mal plötzlich. Ursache muss irgendwo bei npm liegen...
Zumindest habe ich ihn jetzt permanent. Ohne "sudo -H..." lässt sich nichts mehr installieren. Die Fehlermeldung seitens npm scheint mir aber auch irreführend. Ich habe ja alle Rechte im tmp-Verzeichnis und spaßeshalber ein chmod 777 darauf bringt keinerlei Besserung. Ev. bringt ja ein neues npm-Release Besserung ;)
-
@AlCalzone Mehrmals, dürfte aber nix bringen, da NPM meckert, dass er im /[User-Verzeichnis]/.npm/_cacache/tmp/git-clone... das Verzeichnis zum DL nicht anlegen kann. Mit NPM 6.4.1 ging es noch, erst mit dem Update auf 6.11.3 trat es bei mir auf. NPM selbst verriet ja noch, dass es bei älteren Versionen durchaus zu Fehlern in den Userrechten kam. Der vorgeschlagene Fix fruchtet aber auch nicht.
Ist zumindest kein Problem vom Broker/JS-Controller.LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@AlCalzone Mehrmals, dürfte aber nix bringen, da NPM meckert, dass er im /[User-Verzeichnis]/.npm/_cacache/tmp/git-clone... das Verzeichnis zum DL nicht anlegen kann. Mit NPM 6.4.1 ging es noch, erst mit dem Update auf 6.11.3 trat es bei mir auf. NPM selbst verriet ja noch, dass es bei älteren Versionen durchaus zu Fehlern in den Userrechten kam. Der vorgeschlagene Fix fruchtet aber auch nicht.
Ist zumindest kein Problem vom Broker/JS-Controller.@SBorg Ich sehe üblicherweise die Fehler, dass
npmals non-root ausgeführt wird (wie es sein sollte), aber versucht in/root/.npmzu schreiben. Das kommt meiner Erfahrung nach daher, dass die Rechte im Zielordner falsch sind undnpmdaher auf das falsche Cache-Verzeichnis zugreifen will. -
Sooooooo ... Auf GitHub haben wir jetzt die 2.0.7 vom js-controller.
Änderungen und Test-Bitten:
- Ich habe nochmal am Fallback-Handling bei Adaptern mit "kaputtem" Compact-Mode gearbeitet. Bitte mit der "alten" BLE Version nochmal testen :-) Danach die neue gern auch
- In einigen Fällen konnten in den File-DB-Strukturen Fehler entstehen die dann dazugefhrt haben das Files nicht angezeigt wurden, Diese werden nun beim lesen behoben.
- Slaves sollten jetzt Disconnects (von der Objects-DB!) besser erkennen und ggf in 30s Intervallen neu versuchen. @e-i-k-e Schaunochmal wie sich die Slaves jetzt verhalten wenn der Master weg ist. AM besten die Slaves zuerst auf 2.0.7, dann starten und dann den Master ... Ein Log wäre wieder interessant
Danke @apollon77.
Habe das komplette System auf 2.0.7 aktualisiert.
Leider werden die Adapter auch mit dieser Version erst grün, wenn ich die Slave neustarte.
Was mir allerdings gefällt, die Slave Geräte behalten Ihren letzten GPIO (RPI Adapter) Status. (glaube ich ;))Anbei der log vom Slave. iobroker.2019-09-23.log
Neustart Master: 18:45 Uhr
Neustart Slave: 18:52 UhrUnabhängig davon werden mit im log vom Master folgenden warn angezeigt.
admin.2 2019-09-23 18:46:36.260 info (1343) starting. Version 3.6.5 in /opt/iobroker/node_modules/iobroker.admin, node: v10.16.3 Error 2019-09-23 18:46:32.940 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.939 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.936 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.934 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.919 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.917 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.906 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.904 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.900 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.898 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.895 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f host.ioBroker-Rock 2019-09-23 18:46:32.380 info instance system.adapter.admin.2 started with pid 1343 host.ioBroker-Rock 2019-09-23 18:46:32.330 warn Multihost discovery server: service started on 0.0.0.0:50005 -
Danke @apollon77.
Habe das komplette System auf 2.0.7 aktualisiert.
Leider werden die Adapter auch mit dieser Version erst grün, wenn ich die Slave neustarte.
Was mir allerdings gefällt, die Slave Geräte behalten Ihren letzten GPIO (RPI Adapter) Status. (glaube ich ;))Anbei der log vom Slave. iobroker.2019-09-23.log
Neustart Master: 18:45 Uhr
Neustart Slave: 18:52 UhrUnabhängig davon werden mit im log vom Master folgenden warn angezeigt.
admin.2 2019-09-23 18:46:36.260 info (1343) starting. Version 3.6.5 in /opt/iobroker/node_modules/iobroker.admin, node: v10.16.3 Error 2019-09-23 18:46:32.940 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.939 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.936 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.934 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.919 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.917 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.906 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.904 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.900 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.898 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f Error 2019-09-23 18:46:32.895 warn from InMemDB: Error: Unknown Script 47ca5e051ba19850d94c45a1fc8725ff04ae868f host.ioBroker-Rock 2019-09-23 18:46:32.380 info instance system.adapter.admin.2 started with pid 1343 host.ioBroker-Rock 2019-09-23 18:46:32.330 warn Multihost discovery server: service started on 0.0.0.0:50005 -
@AlCalzone Mehrmals, dürfte aber nix bringen, da NPM meckert, dass er im /[User-Verzeichnis]/.npm/_cacache/tmp/git-clone... das Verzeichnis zum DL nicht anlegen kann. Mit NPM 6.4.1 ging es noch, erst mit dem Update auf 6.11.3 trat es bei mir auf. NPM selbst verriet ja noch, dass es bei älteren Versionen durchaus zu Fehlern in den Userrechten kam. Der vorgeschlagene Fix fruchtet aber auch nicht.
Ist zumindest kein Problem vom Broker/JS-Controller.@SBorg Kannst du mal probieren, den Eigentümer im ioBroker-Ordner zu korrigieren?
sudo chown -R iobroker /opt/iobrokerDas sollte der Fixer eigentlich machen, aber vielleicht stimmt da ja doch was nicht.
Warum `sudo` böse ist: https://forum.iobroker.net/post/17109
-
@e-i-k-e hast du hier mal das volle Master log? Kommen sie auch wenn du Admin neu startest?
Anbei das log vom Master.
Könntest du dir bitte auch die Uhrzeit ~1.15 Uhr anschauen. Ich habe seit einigen Tagen Probleme mit meinem ioBroker, dieser hängt sich mehrmals täglich auf. Ich wäre dir sehr dankbar.
Den Admin habe ich nicht neugestartet. Kann ich aber gerne testen.
-
Auf GitHub gibt es jetzt die 2.0.8 . Ich habe nochmal das Stoppen und Restarting angeschaut und überarbeitet.
Ich habe mal mit meinem Redis/Redis Testsystem getestet und einen Redis restart hat es gut weggesteckt@e-i-k-e Kannst bitte das Slave Thema nochnal checken ... bin gespannt auf die Logs. Das "unknown Skript" kann ich mir eher nicht erklären. States und Objects sind "file" oder Objects in Redis?
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
Anbei das log vom Master.
Könntest du dir bitte auch die Uhrzeit ~1.15 Uhr anschauen. Ich habe seit einigen Tagen Probleme mit meinem ioBroker, dieser hängt sich mehrmals täglich auf. Ich wäre dir sehr dankbar.
Den Admin habe ich nicht neugestartet. Kann ich aber gerne testen.
-
Auf GitHub gibt es jetzt die 2.0.8 . Ich habe nochmal das Stoppen und Restarting angeschaut und überarbeitet.
Ich habe mal mit meinem Redis/Redis Testsystem getestet und einen Redis restart hat es gut weggesteckt@e-i-k-e Kannst bitte das Slave Thema nochnal checken ... bin gespannt auf die Logs. Das "unknown Skript" kann ich mir eher nicht erklären. States und Objects sind "file" oder Objects in Redis?
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
Auf GitHub gibt es jetzt die 2.0.8
Läuft.:grinning:
-
Auf GitHub gibt es jetzt die 2.0.8 . Ich habe nochmal das Stoppen und Restarting angeschaut und überarbeitet.
Ich habe mal mit meinem Redis/Redis Testsystem getestet und einen Redis restart hat es gut weggesteckt@e-i-k-e Kannst bitte das Slave Thema nochnal checken ... bin gespannt auf die Logs. Das "unknown Skript" kann ich mir eher nicht erklären. States und Objects sind "file" oder Objects in Redis?
Das sieht sehr gut aus, alle Adapter der Slave sind grün:+1:
Bei mir sind die Objects in Redis.Anbei das log vom:
Master: iobroker.2019-09-24.log
Slave: iobroker.2019-09-24.logNeustart Master: ~00:07Uhr
Neustart Slave: ~00:14 Uhr -
Das sieht sehr gut aus, alle Adapter der Slave sind grün:+1:
Bei mir sind die Objects in Redis.Anbei das log vom:
Master: iobroker.2019-09-24.log
Slave: iobroker.2019-09-24.logNeustart Master: ~00:07Uhr
Neustart Slave: ~00:14 Uhr -
@e-i-k-e Was passiert denn 1:15? Bringt /var/log/syslog irgendwas zu dem Zeitpunkt? Sieht wie ein Reboot aus ... kann RAM kram sein, kann schlechte Stromversorgung sein oder sowas
Eigentlich nichts geplantes. Der Absturz passiert auch zu anderen Uhrzeiten. :confused:
Anbei mal das syslog, ich selbst kann da nicht viel mit anfangen. syslogN8 und bis morgen. ;)
-
Das sieht sehr gut aus, alle Adapter der Slave sind grün:+1:
Bei mir sind die Objects in Redis.Anbei das log vom:
Master: iobroker.2019-09-24.log
Slave: iobroker.2019-09-24.logNeustart Master: ~00:07Uhr
Neustart Slave: ~00:14 Uhr -
Eigentlich nichts geplantes. Der Absturz passiert auch zu anderen Uhrzeiten. :confused:
Anbei mal das syslog, ich selbst kann da nicht viel mit anfangen. syslogN8 und bis morgen. ;)
@e-i-k-e hast du syslog auch von davor? Das 0:17 s geübt für Zeit gewesen zu sein Die Dieuhr hatte beim restart. Würde dann aber auf 6:XX aktualisiert. Daher denke ichbdad der Crash eher da ist.
Um 6:2x macht das System meistens Daily Aufgaben und so und dadurch kann last entstehen.
Was ist für ein Netzteil dran (wird gerade off topic für diesen Thread) ;-)
-
@SBorg Kannst du mal probieren, den Eigentümer im ioBroker-Ordner zu korrigieren?
sudo chown -R iobroker /opt/iobrokerDas sollte der Fixer eigentlich machen, aber vielleicht stimmt da ja doch was nicht.
@AlCalzone sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg Kannst du mal probieren, den Eigentümer im ioBroker-Ordner zu korrigieren?
sudo chown -R iobroker /opt/iobrokerDas sollte der Fixer eigentlich machen, aber vielleicht stimmt da ja doch was nicht.
Hatte mal
ls -lR|grep -v iobroker|awk {'print $3'} > result.txtausgeführt, danach in der TXT Leerzeilen gelöscht = leere Datei, also keine Datei die nicht iobroker gehört. Aber man weiß ja nie, also noch mal chown ausgeführt, bleibt dabei:Als User ausgeführt:
npm 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:313:11) npm ERR! at exports.spawn (child_process.js:508:9) npm ERR! at exports.execFile (child_process.js:218:15) npm ERR! at tryCatcher (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23) npm ERR! at ret (eval at makeNodePromisifiedEval (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:16:23) npm ERR! at promiseRetry (/usr/local/lib/node_modules/npm/node_modules/pacote/lib/util/git.js:192:14) npm ERR! at /usr/local/lib/node_modules/npm/node_modules/promise-retry/index.js:29:24 npm ERR! at <anonymous> npm ERR! { Error: spawn EPERM npm ERR! at ChildProcess.spawn (internal/child_process.js:313:11) npm ERR! at exports.spawn (child_process.js:508:9) npm ERR! at exports.execFile (child_process.js:218:15) npm ERR! at tryCatcher (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23) npm ERR! at ret (eval at makeNodePromisifiedEval (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:16:23) npm ERR! at promiseRetry (/usr/local/lib/node_modules/npm/node_modules/pacote/lib/util/git.js:192:14) npm ERR! at /usr/local/lib/node_modules/npm/node_modules/promise-retry/index.js:29:24 npm ERR! at <anonymous> npm ERR! cause: { Error: spawn EPERM npm ERR! at ChildProcess.spawn (internal/child_process.js:313:11) npm ERR! at exports.spawn (child_process.js:508:9) npm ERR! at exports.execFile (child_process.js:218:15) npm ERR! at tryCatcher (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23) npm ERR! at ret (eval at makeNodePromisifiedEval (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:16:23) npm ERR! at promiseRetry (/usr/local/lib/node_modules/npm/node_modules/pacote/lib/util/git.js:192:14) npm ERR! at /usr/local/lib/node_modules/npm/node_modules/promise-retry/index.js:29:24 npm ERR! at <anonymous> errno: 'EPERM', code: 'EPERM', syscall: 'spawn' }, npm ERR! stack: 'Error: spawn EPERM\n at ChildProcess.spawn (internal/child_process.js:313:11)\n at exports.spawn (child_process.js:508:9)\n at exports.execFile (child_process.js:218:15)\n at tryCatcher (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)\n at ret (eval at makeNodePromisifiedEval (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:16:23)\n at promiseRetry (/usr/local/lib/node_modules/npm/node_modules/pacote/lib/util/git.js:192:14)\n at /usr/local/lib/node_modules/npm/node_modules/promise-retry/index.js:29:24\n at <anonymous>', 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/xxx/.npm/_logs/2019-09-23T19_16_22_629Z-debug.logNochmals npm neu installiert und alle Rechte unter /usr/local/lib/node-modules... kontrolliert, alles iO.
Als root ausgeführt:
siehe oben, "git clone..."-ErrorNur die Version mit "sudo -H..." funktioniert. Im Moment bin ich mit meinem Latein erst mal am Ende, weiß echt nicht mehr was das NPM-Update da verhunzt hat. Wenn ich der Einzige bin/bleibe, was soll's? Es läuft sonst alles und über "Umweg" kriege ich es installiert.
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation
Support us
594
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge