js-controller 2.0 ab sofort im Latest Repo
-
@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 -
@ilovegym
vollkommen richtig, hatte ich bei mir aber auc und nach dem manuellen löschen lief das auch wieder über den Admin wie gewohnt. -
@ilovegym was sagt Admin denn beim löschen von Adaptern?
-
@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.. -
@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. -
@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?
-
@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.
-
@Yetiberg der $hostname$ ist Blödsinn und kommt von einem früheren bug bei Backup/restore. Den kannst du löschen.
-
@apollon77
wenn ich nur "edit.html" ohne Parameter aufrufe, bekomme ich denselben FehlerWo muss ich den LogLevel auf debug stellen?
-
Kurze Frage - liegt es am FullyAdapter oder an js-controller? Das Error Log tauch erst seit 2.0.x vom js-controller bei mir auf.
-
@ilovegym Installation Fixer genutzt?
-
@telekom0815 Sollte reichen unter system.adapter.web.0.loglevel ... kurz vor dem Aufruf. und danach zurücksetzen
-
@JB_Sullivan Installiere fully browser mal neu. Das ist irgendwie ein npm Modul nicht mehr da
-
@apollon77 sagte in js-controller 2.0 ab sofort im Latest Repo:
@ilovegym Installation Fixer genutzt?
Ja, keine Änderung..
-
@ilovegym Dann sollte aber nichts mehr verbogen sein.
-
@apollon77 Hmm ja, hoffentlich.
Export der Scripte geht immer noch nichtDenke dein Ansatz wegen den slaves hört sich vernünftig an..
