NEWS
Test js-controller v2.0.x (GitHub)
-
@apollon77
Der compact mode läuft mit Version 2.0.6 nicht mehr. Der admin restartet ständig.
hier mal ein Log:
-
Hallo,
erst mal danke für die schnelle Antwort.@Dr-Bakterius sagte in [Aufruf] js-controller 2.0 Beta Test:
Wenn man das direkt auf dem ioBroker-Rechner machen möchte, gehören die Dateien nach
/opt/iobroker/iobroker-data/files/vis.0habe ich kopiert:
Aber sie werden mir im Auswahldialog leider nicht angezeigt:
Irgend etwas ist noch nicht korrekt bei mir. Klicke ich auf den Uploadbutton, dann kommt bei mir folgendes:
Ich kann von dort auch hochladen, aber in der Auswahl sieht das dann so aus:
Dabei stehen die Rechte der Dateien wie folgt:
Sorry, wenn ich nerve.
Gruß
Egbert@opossum vis upload vor der 1.2.1 war kaputt. Bitte 1.2.1 aus latest installieren
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
-
-
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
-
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
@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. -
@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
-
@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
-
@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
Support us
741
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge