js-controller 4.0 jetzt im BETA/LATEST!
-
Vielen Dank. Nach mehrmaliger Neuinstallation funktioniert der Adapter wieder. Da hat's irgendwo anscheinend gehakelt.
-
@amg_666 sagte in js-controller 4.0 jetzt im BETA/LATEST!:
1.11.8 auf allen Shellys
bei den H&T dürfte das wieder zurückgezogen worden sein. mir wurde wieder die 1.11.7 angeboten. hatte auch bei 2 von 10 WLAN aussetzer. nach ca 10min keine verbindung mehr...
zurück auf 1.11.7 keine aussetzer mehr. -
So,
gerade problemlos upgrade meiner drei Produktiv iob installeátionen von 4.0.8 --> 4.0.12 gemacht.
Master läuft auf Proxmox, CPU nur kurz beim starten etwas erhöht, RAM nahezu unverändert:
rote linie zeigt den neustart.
Lediglich bei einem Slave bin ich etwas verwundert über das verhalten. Hier gab es zwar den BackitUp Adapter allerdings ohne Instanz. Die wurde mir 4.0.12 von alleine wieder angelegt.... ist das so gewollt?
pi@pi-iobroker:~ $ iob update Used repository: Beta (latest) Adapter "admin" : 5.3.0 , installed 5.3.0 Adapter "backitup" : 2.3.3 , installed 2.3.0 [Updatable] Adapter "discovery" : 2.7.5 , installed 2.7.5 Controller "js-controller": 4.0.12 , installed 4.0.8 [Updatable] Adapter "modbus" : 3.4.17 , installed 3.4.17 Adapter "net-tools" : 0.1.7 , installed 0.1.7 Adapter "rpi2" : 1.3.2 , installed 1.3.1 [Updatable] Adapter "smartmeter" : 3.2.1 , installed 3.2.1 Adapter "tr-064" : 4.2.15 , installed 4.2.15 pi@pi-iobroker:~ $ iob upgrade self Update js-controller from @4.0.8 to @4.0.12 Stopped Objects DB Stopped States DB NPM version: 6.14.16 Installing iobroker.js-controller@4.0.12... (System call) > iobroker.js-controller@4.0.12 preinstall /opt/iobroker/node_modules/iobroker.js-controller > node lib/preinstallCheck.js NPM version: 6.14.16 > iobroker.js-controller@4.0.12 install /opt/iobroker/node_modules/iobroker.js-controller > node iobroker.js setup first object _design/system updated host.pi-iobroker create instance backitup host.pi-iobroker object system.adapter.backitup.0.alive created host.pi-iobroker object system.adapter.backitup.0.connected created host.pi-iobroker object system.adapter.backitup.0.compactMode created host.pi-iobroker object system.adapter.backitup.0.cpu created host.pi-iobroker object system.adapter.backitup.0.cputime created host.pi-iobroker object system.adapter.backitup.0.memHeapUsed created host.pi-iobroker object system.adapter.backitup.0.memHeapTotal created host.pi-iobroker object system.adapter.backitup.0.memRss created host.pi-iobroker object system.adapter.backitup.0.uptime created host.pi-iobroker object system.adapter.backitup.0.inputCount created host.pi-iobroker object system.adapter.backitup.0.outputCount created host.pi-iobroker object system.adapter.backitup.0.eventLoopLag created host.pi-iobroker object system.adapter.backitup.0.sigKill created host.pi-iobroker object system.adapter.backitup.0.logLevel created host.pi-iobroker object backitup.0.info created host.pi-iobroker object backitup.0.info.latestBackup created host.pi-iobroker object backitup.0.info.ccuNextTime created host.pi-iobroker object backitup.0.info.iobrokerNextTime created host.pi-iobroker object backitup.0.history created host.pi-iobroker object backitup.0.history.html created host.pi-iobroker object backitup.0.history.json created host.pi-iobroker object backitup.0.history.ccuLastTime created host.pi-iobroker object backitup.0.history.iobrokerLastTime created host.pi-iobroker object backitup.0.history.ccuSuccess created host.pi-iobroker object backitup.0.history.iobrokerSuccess created host.pi-iobroker object backitup.0.oneClick created host.pi-iobroker object backitup.0.oneClick.ccu created host.pi-iobroker object backitup.0.oneClick.iobroker created host.pi-iobroker object backitup.0.output created host.pi-iobroker object backitup.0.output.line created host.pi-iobroker Set default value of backitup.0.info.ccuNextTime: none host.pi-iobroker Set default value of backitup.0.info.iobrokerNextTime: none host.pi-iobroker Set default value of backitup.0.history.html: No backups yet host.pi-iobroker Set default value of backitup.0.history.json: [] host.pi-iobroker Set default value of backitup.0.history.ccuLastTime: No backups yet host.pi-iobroker Set default value of backitup.0.history.iobrokerLastTime: No backups yet host.pi-iobroker Set default value of backitup.0.history.ccuSuccess: false host.pi-iobroker Set default value of backitup.0.history.iobrokerSuccess: false host.pi-iobroker Set default value of backitup.0.oneClick.ccu: false host.pi-iobroker Set default value of backitup.0.oneClick.iobroker: false host.pi-iobroker Set default value of backitup.0.output.line: host.pi-iobroker object system.adapter.backitup.0 created { -
@wendy2702 sagte in js-controller 4.0 jetzt im BETA/LATEST!:
Lediglich bei einem Slave bin ich etwas verwundert über das verhalten. Hier gab es zwar den BackitUp Adapter allerdings ohne Instanz. Die wurde mir 4.0.12 von alleine wieder angelegt.... ist das so gewollt?
Ja, aber nur wenn dein System gar keine backitup Instanz hat. Wenn du kein Backitup willst bitte komplett deinstallieren
-
@apollon77 sagte in js-controller 4.0 jetzt im BETA/LATEST!:
@dolomiti Hm ... mach mal bitte im ioBroker dir ein
npm list mongodbWas kommt da raus?schlippe@ioBroker-Test:/opt/iobroker$ npm list mongodb [sudo] password for schlippe: iobroker.inst@1.1.2 /opt/iobroker `-- mongodb@3.2.7 extraneous npm ERR! extraneous: mongodb@3.2.7 /opt/iobroker/node_modules/mongodbHabe Node-Red deinstalliert und der Fehler kommt immer noch.
schlippe@ioBroker-Test:/opt/iobroker$ iobroker status (node:2218) Warning: Accessing non-existent property 'count' of module exports inside circular dependency (Use `node --trace-warnings ...` to show where the warning was created) (node:2218) Warning: Accessing non-existent property 'findOne' of module exports inside circular dependency (node:2218) Warning: Accessing non-existent property 'remove' of module exports inside circular dependency (node:2218) Warning: Accessing non-existent property 'updateOne' of module exports inside circular dependency iobroker is running on this host. Objects type: jsonl States type: jsonl schlippe@ioBroker-Test:/opt/iobroker$Vielleicht ist es langsam mal an der Zeit mein Testsystem sauber mit nem Backup neu aufzusetzten, in der Hoffnung, dass dann die mongodb-Fehler weg sind.
-
@dolomiti dann lösche es, danach sollte es funktionieren
npm uninstall mongodb -
-
@dolomiti Jupp. Ich verstehe nur nicht warum er diese alte Version installiert. Im Adapter steht https://github.com/ioBroker/ioBroker.node-red/blob/master/package.json#L30
-
@apollon77
Habe jetzt Node-Red nochmal neu installiert. Jetzt ist die Ausgabe wohl wie zu erwarten. Bei bei meinem 2. Testsystem, einem RasPi, sieht es auch so ausschlippe@ioBroker-Test:/opt/iobroker$ npm list mongodb [sudo] password for schlippe: iobroker.inst@1.1.2 /opt/iobroker `-- iobroker.node-red@2.4.2 `-- mongodb@3.7.3Da das Problem erst nach dem Update vom js-Controller aufgetreten ist, hatte ich das damit in Zusammenhang gebracht.
Danke für die Hilfe
Dolomiti
-
Hallo, ich habe folgende Konfiguration:
- ioBroker als Docker Container (buanet), aktuelles Image
- NPM v6.14.16
- Node.js v14.19.0
Das Update auf den js-Controller 4 lief soweit (nach "iob fix") ohne Probleme durch und auch sonst läuft alles einwandfrei. Eine Sache ist mir aber aufgefallen: Während die "states.jsonl" regelmäßig komprimiert wird und eine Größe zwischen 1 und 10MB hat, wurde die Datei "objects.jsonl" immer größer und hatte mittlerweile (bei meinem recht kleinen System) 200 MB erreicht. Einige Experimente mit dem Parameter "auto-compress size factor" brachten keine Änderung. Erst nachdem ich eine "Fake-Umstellung" von json- auf Redis-DB mit "iob setup custom" durchgeführt hatte, wurde die "objects.jsonl" auf nun ca. 7 MB komprimiert.
Mit "Fake-Umstellung" meine ich das Starten der Migration auf Redis, die dann aber automatisch abgebrochen wird, da keine Redis-DB gefunden wird.Das Log zeigt keine Auffälligkeiten, die ich mit dem "Problem" in Verbindung bringen könnte.
Meine Frage ist nun: Ist das Beschriebene überhaupt ein Problem oder das erwartete Verhalten und habe nur ich diesen Effekt?
Grüße, Marc
-
@marc-berg sagte in js-controller 4.0 jetzt im BETA/LATEST!:
wurde die Datei "objects.jsonl" immer größer und hatte mittlerweile (bei meinem recht kleinen System) 200 MB erreicht
Kannst du mir noch ein paar Eckdaten geben? Wie viele States/ Objekte hast du? Kannst du mir einmal eine solche (große) Datei schicken (und die states.jsonl zum Vergleich)? Als zip sollte die sich gut komprimieren lassen - ich geb dir nen Upload-Link.
-
Ist es eigentlich generell so, das nach der Migration die jsonl Dateien größer sind als die alten json Dateien?
Können eigentlich alle Dateien die *.migrated heißen weg?
Achso, ich habe 42 aktive Adapter mit 20.030 Datenpunkten.
-
-
@jb_sullivan Naja "Files größer" ist relativ. Wenn Du oben in der FAQ liesst wie JSONL funktioniert sind sie ausser direkt nach der Komprimierung immer größer weil halt neue Daten wieder angehängt werden.
Ja die ".migrated" können weg, sind nur quasi ne Art "mini Backup" von dem zeitpunkt der jsonl umstellung
-
Hallo nochmals an alle fleißigen Beta Nutzer!
In den nächsten Stunden kommt der js-controller 4.0.14 ins Beta/Latest Repo, welcher die Version ist, mit der wir im Laufe der kommenden Woche auch nach Stable wollen (Daumen drücken).
Also bitte nochmal alle installieren und checken bitte ... Voraussichtlich heute Abend geht auch noch eine Admin Notification an alle raus die Beta haben und noch nicht den neuesten js-controller
4.0.14 (2022-02-19)
- (Apollon77) Additional optimizations for setup process and DB defaults
- (foxriver76) also log a message on force restore if it accepts a js-controller version mismatch
- (foxriver76) Fix seq instance detection to add correct meta data to logs in all cases
- (Apollon77) Add database types to crashes reported to sentry
- (foxriver76) Add JSONL as default for new installations
Ingo
-
@apollon77 Update von 4.0.12 auf 4.0.14 lief unauffällig durch.
Update js-controller from @4.0.12 to @4.0.14 [downloadPacket] stoppedList cannot be used if stopping of databases is requested Stopped Objects DB Stopped States DB NPM version: 6.14.16 Installing iobroker.js-controller@4.0.14... (System call) > iobroker.js-controller@4.0.14 preinstall /opt/iobroker/node_modules/iobroker.js-controller > node lib/preinstallCheck.js NPM version: 6.14.16 > iobroker.js-controller@4.0.14 install /opt/iobroker/node_modules/iobroker.js-controller > node iobroker.js setup first Successfully migrated 18706 objects to Redis Sets object _design/system updated { "defaultPrivate": "-----BEGIN RSA PRIVATE KEY-----\r\n\r\n-----END RSA PRIVATE KEY-----\r\n", "defaultPublic": "-----BEGIN CERTIFICATE-----\r\n\r\n-----END CERTIFICATE-----\r\n" } Update certificate defaultPrivate The object "system.certificates" was updated successfully. Update certificate defaultPublic The object "system.certificates" was updated successfully. + iobroker.js-controller@4.0.14 updated 14 packages in 36.912s 74 packages are looking for funding run `npm fund` for details -
@apollon77 Update auf 4.014 verlief ohne Probleme.
-
auch bei mir 4.0.14 ohne Probleme
jsonl hat den diskwrite von ca. 125k auf 25k gesenkt!
-
Läuft ohne Mucken:
echad@chet:~ $ iobroker upgrade self Update js-controller from @4.0.12 to @4.0.14 [downloadPacket] stoppedList cannot be used if stopping of databases is requested Stopped Objects DB Stopped States DB NPM version: 8.4.1 Installing iobroker.js-controller@4.0.14... (System call) changed 21 packages in 48s 53 packages are looking for funding run `npm fund` for details echad@chet:~ $ iobroker start -
ist zwar OT aber eine kurze Frage. Ich wollte brav das update als nicht root machen. Da hätte ich dann aber nach jedem Schritt das root passwort eingeben müssen.
Hat mein Benutzer zu wenig Rechte?
