NEWS
js-controller 4.0 jetzt im BETA/LATEST!
-
@apollon77 Nene da stimmte was temporär nicht. Die iob VM hat 4 von 16 GB. Der ganze Server mit allen VM/LXC läuft nie über 45% RAM. Die iob VM im Monatsmittel hängt bei 3,5 von den zugewiesenen 4 GB rum. Noch nie hatte ich eine Warnung bei >80% der VM. Klar kann ich der VM mal mehr geben, wird dann sicher auch verwendet, aber war bisher nie nötig und nach reboot ja auch nicht mehr. Auch frühere iob restarts mit file und JSONL kamen nicht an die Grenzen.
Irgendwas ist da vorhin beim Update von 4.0.7 mächtig schief gegangen. -
Ab sofort steht die Beta 2.3.0 des Backitup Adapter zur Verfügung.
Hier gab es für den js-controller einige größere Änderungen beim iobroker-restore.Es wäre super, wenn hier die Tester des js-controllers dies mit testen und bei Fehlern bitte melden könnten.
Voraussetzung für einen Test des Restores ist js-controller größer 4.0.6, da alle Anpassungen in kleineren 4er Versionen noch nicht enthalten sind.Auch Versionen von js-controller 3.3.x werden weiter unterstützt.
Alle Änderungen findet Ihr im Backitup Thread.
-
@simatec
ich hab den aktuellen js-controller drauf (4.0.8) und backitup 2.3.0 grade installiert.
intel nuc mit proxmox debian als Master und einen abgesetzten pi3b (auch mit 4.0.8)Das lief alles fehlerfrei durch, aber ich habe ein backup manuell angestartet (über Adminoberfläche) und das "hängt", keine Ahnung was da "undefined" ist.
Started iobroker ... [DEBUG] [iobroker] - host.iobroker 17009 states saved [DEBUG] [iobroker] - host.iobroker 19191 objects saved [DEBUG] [iobroker] - Backup created: /opt/iobroker/backups/iobroker_2022_02_11-14_06_44_backupiobroker.tar.gz [DEBUG] [iobroker] - done [DEBUG] [historyDB] - compress from historyDB started ... [ERROR] [historyDB] - Backitup cannot found source "undefined" for compress!
-
@amg_666 Bitte poste das im backitup Thread sonst werden hier die Themen vermischt.
Es geht hier nur um den Restore des iobrokers in Verbindung mit dem js-controller 4 -
@apollon77 Keine Ahnung ob es am JS 4.0.7 liegt aber ich habe ja vorhin einen Slave neu installiert und da ist ja dann der Discovery Adapter bei. Den wollte ich jetzt wieder löschen vom Master aus.
Im Log:
2022-02-11 15:50:07.082 - info: host.iobroker instance system.adapter.dwd.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) 2022-02-11 15:50:09.570 - info: host.iobroker iobroker del discovery.0 2022-02-11 15:50:10.934 - info: host.iobroker iobroker Delete instance "discovery.0" 2022-02-11 15:50:11.216 - info: host.iobroker iobroker host.iobroker Counted 5 states of discovery.0 2022-02-11 15:50:11.280 - info: host.iobroker iobroker host.iobroker Counted 15 states of system.adapter.discovery.0 2022-02-11 15:50:11.319 - info: host.iobroker iobroker host.iobroker Counted 5 states (io.discovery.0.*) from states 2022-02-11 15:50:11.338 - info: linux-control.0 (28537) getting data from VIS-OG (192.168.178.215:22) 2022-02-11 15:50:11.435 - info: host.iobroker iobroker host.iobroker Counted 15 states (system.adapter.discovery.0.*) from states 2022-02-11 15:50:13.091 - info: host.iobroker iobroker host.iobroker Counted 1 objects of discovery.0 2022-02-11 15:50:13.091 - info: host.iobroker iobroker host.iobroker Deleting 21 object(s). 2022-02-11 15:50:13.241 - info: host.iobroker iobroker host.iobroker Deleting 20 state(s). 2022-02-11 15:50:14.378 - info: host.iobroker iobroker exit 0
In den Objekten:
Im Admin:
Jetzt mal versucht wenn ich auf den Slave Filter wobei ich dann in einen loop laufe:
Wenn ich das bestätige:
Kommt das:
Wenn ich dann hier auf Schließen klicke kommt wieder das:
Den Hinweis das er nicht deinstalliert werden kann weil Nettools ihn benötigt gab es beim ersten mal nicht.
JS Problem, Adapter oder Admin?
-
@wendy2702 Lies mal den Changelog zur 4.0.8... Da wurde genau das gefixt ... also wenn es darum geht einen discovery auf nem anderen Host zu löschen.
Die Meldung mit "nettools braucht ihn" sollte an sich immer kommen... bzw hier die gilt ggf das "Host spezifisch"
EDIT: @foxriver76 hat schon festgestellt das da noch was nicht korrekt ist ... fix kommt in die 4.0.9
-
Also bei mir kommt dieser NPM nicht-gefunden-package.json Fehler immer noch, mit ws 4.0.8
-
@jobe451 Update: Das Problem ist offenbar vielmehr, dass ich den ws selber nicht ugedated kriege auf 4.0.8... Was kann man da machen? Wie kann man den update erzwingen?
-
@jobe451 Du hast recht ... dann installiere es via
cd /opt/iobroker
undnpm i iobroker.js-controller@4.0.8 --production
-
@apollon77 sagte in js-controller 4.0 jetzt im BETA/LATEST!:
@e-i-k-e Danke, Hast nen Bug gefunden. Wird in der 4.0.8 gefixt
Mit 4.0.8 kann ich nun die Adapter löschen.
Danke! -
habe jetzt gerade das update von 4.0.5 auf 4.0.8 gemacht
was ich aber nun nicht verstehe, was ist damit gemeint?The following notifications happened during sync: - Ignoring Directory "userdata.0" because officially not created as meta object. Please remove directory!
-
@crunchip
0_userdata.0
vsuserdata.0
-
@foxriver76 ok und wo sollte ich userdata.0 finden
-
@crunchip Entweder in deinen Objekten oder vllt auch hier: /opt/iobroker/iobroker-data/files/userdata.0
-
@diginix ich hab schon nach userdata suchen lassen, findet aber nichts
-
@crunchip der Ordner heißt meiner Meinung nach falsch.. hast du ihn selbst erstellt? Auf meinem System heißt er korrekt
0_userdata.0
-
..@foxriver76 sagte in js-controller 4.0 jetzt im BETA/LATEST!:
hast du ihn selbst erstellt?
na eben nicht, deshalb war meine Eingangsfrage
aber @dignix hatte recht, ist tatsächlich in diesem Pfad, ein Ordner vom 19.05.2020
wo liegt dann
0_userdata.0
, doch auch im selben Pfad? -
@foxriver76 Der Punkt ist doch immer die nächste Ebene. Ist doch bei den Instanzen auch so, dass .0 der Unterorder der ersten Instanz ist.
Das Bild passt bei @crunchip. Sieht bei mir auch so aus.
-
@diginix Ja das Objekt passt, aber der Ordner auf dem File System passt nicht, wie im letzten Post bereits erwähnt.
Bzw. gibt es villt den korrekten Ordner zusätzlich zum falschen
-
@crunchip Zeig doch mal ein Screenshot vom Admin "Reiter Dateien"