NEWS
js-controller 2.0 ab sofort im Latest Repo
-
Moin
Habe gerade versucht meine Scripte zu exportieren.
Dort kommt folgende Fehlermeldung in einem grauen Fenster:File 2019-11-02-scripts.zip.zip not found
Script Engine 4.3.2
js-controller 2.0.39Welcher Adapter hat denn nun dran Schuld?
-
@Yetiberg
Mach das noch mal, weil beim Exportieren keine Files gesucht werden und die schon gar nicht *.zip.zip heißen. -
@apollon77
Web Adapter 2.4.8
Master/Slave System, wobei alles, bis auf den Radar2 Adapter, auf dem Master RockPro64 liegt. Bekomme mit einem aktuellen DEV Armbian Image kein Bluetooth zum laufen auf dem RockPro64. Aber das ist ein anderes Problem :-)
Das Problem besteht seit gestern als ich den Rasberry als Slave ins System eingebunden habe.
Beide Systeme haben file-file, nicht redis.@Jan1
Habe ich schon mehrfach versucht.Es ist ja nicht Lebenswichtig da bei einem Backup die Scripte ja mitgesichert werden. Aber seltsam ist es dennoch.
-
@Yetiberg Das Problem hat noch ein anderer User - wir können es aber nicht nachstellen :-( bei mir tuts.
Daher paar Fragen:
- Version Web Adapter?
- Master/Slave System oder Single Host?
@apollon77 hatte ich auch, jedoch ist es schon ne Weile her, als ich es versucht hatte. Probier ich dann mal mit aktuellem Stand.
Hab aber irgendwo gelesen, das es mit einem Browserwechsel funktionierte.Edit: Ein Zip Export, sowohl in Chrome/Opera/FF erfolgreich
-
@apollon77 der andere bin ich :-)
ich hab das exportieren der Scripts mit Firefox und Google Chrome versucht, den Cache gelöscht, reboot, etc.. mehr fällt mir nicht mehr ein.. die Datei wird anscheinend auch erst garnicht erzeugt.. und kann deshalb nicht runtergeladen werden... vielleicht ein Rechteproblem ??Meine Installation ist ziemlich alt und auch das löschen von Adaptern funktioniert nur per Hand, nicht aus dem Admin raus..
denke das ist auch sowas...Ich gehe heute mal ein paaar Admin-Versionen zurück und versuch es damit.. lass auch mal den Fixer drüber laufen.. schaden kanns nicht..
Aktuell Admin 3.6.10, Web 2.4.8, js-controller 2.0.39, javascript 4.3.2 (auch mit 4.3.3 das gleiche).
-
@apollon77 der andere bin ich :-)
ich hab das exportieren der Scripts mit Firefox und Google Chrome versucht, den Cache gelöscht, reboot, etc.. mehr fällt mir nicht mehr ein.. die Datei wird anscheinend auch erst garnicht erzeugt.. und kann deshalb nicht runtergeladen werden... vielleicht ein Rechteproblem ??Meine Installation ist ziemlich alt und auch das löschen von Adaptern funktioniert nur per Hand, nicht aus dem Admin raus..
denke das ist auch sowas...Ich gehe heute mal ein paaar Admin-Versionen zurück und versuch es damit.. lass auch mal den Fixer drüber laufen.. schaden kanns nicht..
Aktuell Admin 3.6.10, Web 2.4.8, js-controller 2.0.39, javascript 4.3.2 (auch mit 4.3.3 das gleiche).
@ilovegym sagte in js-controller 2.0 ab sofort im Latest Repo:
Meine Installation ist ziemlich alt und auch das löschen von Adaptern funktioniert nur per Hand
das Problem hab ich mit dem tr-64 Adapter, der lässt sich auch nicht entfernen
-
@ilovegym sagte in js-controller 2.0 ab sofort im Latest Repo:
Meine Installation ist ziemlich alt und auch das löschen von Adaptern funktioniert nur per Hand
das Problem hab ich mit dem tr-64 Adapter, der lässt sich auch nicht entfernen
-
@Jan1 manuell löschen geht, aber ist nicht im Sinne des Admin-Adapters :-)
Ausserdem muss da ein Fehler sein ;-) wer sucht, der findet auch einen :-) -
@Jan1 manuell löschen geht, aber ist nicht im Sinne des Admin-Adapters :-)
Ausserdem muss da ein Fehler sein ;-) wer sucht, der findet auch einen :-) -
@Jan1 manuell löschen geht, aber ist nicht im Sinne des Admin-Adapters :-)
Ausserdem muss da ein Fehler sein ;-) wer sucht, der findet auch einen :-) -
@Jan1 das hatte ich auch schon und wollte nicht.
hab gerade aus Spass nochmal über die Admin Oberfläche probiert und siehe da, er is nun weg.
In meinen Snapshots mal nachgesehen, mit js_controller .35 habe ich den tr64 entfernen wollen und umgestellt auf Community. Mittlerweile bin ich auf js-Controller.39 und jetzt ging es seltsamerweise. -
@apollon77 sagte in js-controller 2.0 ab sofort im Latest Repo:
@ilovegym was sagt Admin denn beim löschen von Adaptern?
der macht so, als wäre alles gut gelaufen, Error 0, und beendet sich. Keine Fehler im Log, aber der Adapter und das Verzeichnis ist anschließend immer noch da...
Anscheinend kann er das Verzeichnis nicht löschen.. bekommt aber auch kein Fehler.. ich hab das schon länger.. glaub seit dem Update von Node 6 of 8... jetzt mit 10.. immer noch.. denke da sind einfach sehr alte Berechtigungen verbogen.. -
@apollon77
Web Adapter 2.4.8
Master/Slave System, wobei alles, bis auf den Radar2 Adapter, auf dem Master RockPro64 liegt. Bekomme mit einem aktuellen DEV Armbian Image kein Bluetooth zum laufen auf dem RockPro64. Aber das ist ein anderes Problem :-)
Das Problem besteht seit gestern als ich den Rasberry als Slave ins System eingebunden habe.
Beide Systeme haben file-file, nicht redis.@Jan1
Habe ich schon mehrfach versucht.Es ist ja nicht Lebenswichtig da bei einem Backup die Scripte ja mitgesichert werden. Aber seltsam ist es dennoch.
@Yetiberg und auf dem Slave läuft nur ein Adapter? Admin, Web und JavaScript laufen alle auf dem Master?
Die einzige plausible Erklärung wäre wenn das „zip“ irgendwie auf einem anderen Host erzeugr werden würde. Dann würde er das falsche state lesen
-
Ich habe nochmal Code angeschaut wegen dem Export Problem und glaube die Ursache gefunden.
De JavaScript Adapter hat eine Liste der hosts und sucht sich daraus den ersten der aktiv ist raus. Der bekommt den Auftrag den Export zu machen und der speichert das dann in seinem eigenen Bereich. Dann wird die Download url erstellt und dem Browser übergeben. die url geht dann an den Admin Adapter in dem JavaScript gerade läuft. Der nimmt „seinen“ Host und versucht den Export zu lesen.
Na habt ihr ne Idee was passieren kann? ;-) und dass ist der Grund warum es nur manchmal bzw bei einigen Nicht tut ...
Auflösung: Der erste gefundene Host im JavaScript Adapter ist einfach ein anderer als der auf dem Admin läuft ;-(
Aber das kann man fixen.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
-
Ich habe nochmal Code angeschaut wegen dem Export Problem und glaube die Ursache gefunden.
De JavaScript Adapter hat eine Liste der hosts und sucht sich daraus den ersten der aktiv ist raus. Der bekommt den Auftrag den Export zu machen und der speichert das dann in seinem eigenen Bereich. Dann wird die Download url erstellt und dem Browser übergeben. die url geht dann an den Admin Adapter in dem JavaScript gerade läuft. Der nimmt „seinen“ Host und versucht den Export zu lesen.
Na habt ihr ne Idee was passieren kann? ;-) und dass ist der Grund warum es nur manchmal bzw bei einigen Nicht tut ...
Auflösung: Der erste gefundene Host im JavaScript Adapter ist einfach ein anderer als der auf dem Admin läuft ;-(
Aber das kann man fixen.@apollon77 kann ich aber so nicht bestätigen, da ich nur einen Master laufen habe und das gleiche Problem hatte.
umgestiegen von Proxmox auf Unraid
-
@apollon77 kann ich aber so nicht bestätigen, da ich nur einen Master laufen habe und das gleiche Problem hatte.
@crunchip in den Objekten wie viele System.host.* hast du?
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
-
@apollon77 einen,
system.host.IoBroker -
@apollon77
Auf dem Slave ist nur EIN Adapter. Radar2Bei mir wird System.host so angezeigt:
system.host.$hostname$
system.host.raspberrypi
system.host.rockpro64Ist der erste Eintrag denn so richtig?
Sieht komisch aus.
-
@apollon77
Auf dem Slave ist nur EIN Adapter. Radar2Bei mir wird System.host so angezeigt:
system.host.$hostname$
system.host.raspberrypi
system.host.rockpro64Ist der erste Eintrag denn so richtig?
Sieht komisch aus. -
@telekom0815 Ok, dann jetzt nächster Check. Wir bauen mal Logging in web-Adapter ein :-)
Bitte öffne /opt/iobroker/node_modules/iobroker.web/main.js in einem Editor.
Sucht dort nach der Zeile mit "adapter.getFile". Sollte nur einmal vorkommen und sieht grob aus wie https://github.com/ioBroker/ioBroker.web/blob/master/main.js#L1161vor der Zeile einfügen:
adapter.log.debug('GET FILE ' + id + ' / ' + (webByVersion[id] ? url.substring(versionPrefix.length + 1) : url) + ' for ' + (req.user ? 'system.user.' + req.user : settings.defaultUser));und danach:
adapter.log.debug('RESULT FILE ' + id + ' / ' + (webByVersion[id] ? url.substring(versionPrefix.length + 1) : url) + ': err=' + err + ' : ' + (buffer ? buffer.length : JSON.stringify(buffer)) + ' : ' + mimeType);Dann web-Adapter auf Loglevel "debug" stellen, damit Startet der neu. Dann nochmal abrufen und schick mal das log davon bitte.
@apollon77
wenn ich nur "edit.html" ohne Parameter aufrufe, bekomme ich denselben FehlerWo muss ich den LogLevel auf debug stellen?
738
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge