Test js-controller v2.0.x (GitHub)
-
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
- Ich habe nochmal am Fallback-Handling bei Adaptern mit "kaputtem" Compact-Mode gearbeitet. Bitte mit der "alten" BLE Version nochmal testen
-
@apollon77
jetzt läuft alles im compact mode wie es soll (mit BLE 0.9.0). Keine Fehler oder Warnungen im Log, ale Adapter lassen sich einzeln neu starten, ohne Auswirkung auf das System@AlCalzone
BLE 0.9.1 funktioniert nun auch im compact modus. -
@Jan1 sagte in [Aufruf] js-controller 2.0 Beta Test:
@apollon77
jetzt läuft alles im compact mode wie es soll (mit BLE 0.9.0). Keine Fehler oder Warnungen im Log, ale Adapter lassen sich einzeln neu starten, ohne Auswirkung auf das SystemHast Du mal noch ein Log von so einem 0.9.0 versuch?! Aber cool
-
@apollon77
nein, weil alles sauber war und keine Fehler oder Warnungen drin standen. Wenn Du willst, hau ich noch mal die 0.9.0 Version ndes BLE drauf. -
@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
-
Ok, sehe schon
alles ok. Ich fixe noch was ... grrrr -
@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
-
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]
-
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Ohne "sudo -H..." lässt sich nichts mehr installieren
Mal den Fixer ausgeführt?
-
@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. -
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 -
@e-i-k-e hast du hier mal das volle Master log? Kommen sie auch wenn du Admin neu startest?
-
@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.
-
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?
-
@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
-
-
Das sieht sehr gut aus, alle Adapter der Slave sind grün
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
