Test js-controller v2.0.x (GitHub)
-
@apollon77
keine Panik, wenn ich den compact modus disable, läuft ja alles und das ist in ein paar Sekunden umgestellt
-
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 -
@Jan1 Liegt nicht direkt an der 2.0.6 ... ist ein "Timing" thema. fix kommt in 2.0.7
-
@opossum vis upload vor der 1.2.1 war kaputt. Bitte 1.2.1 aus latest installieren
-
Hallo,
@opossum vis upload vor der 1.2.1 war kaputt. Bitte 1.2.1 aus latest installieren
das war es, nun funktioniert das. Danke @apollon77, dann werde meine vis umstellen.
Gruß
Egbert -
@Jan1 Kannst du bitte BLE v0.9.1 probieren?
-
@AlCalzone @Jan1 bitte warte mal noch :-)) Ich würde gern das Du die alte nochmal mit der 2.0.7 vom controller testet :-)) geht das? Ich finalisiere den jetzt
-
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
