js-controller 4.0 jetzt im BETA/LATEST!

[sigi234]

@apollon77 sagte in js-controller 4.0 jetzt im BETA/LATEST!:

@sigi234 na dann halt doch noch ne .15

upps, das wollte ich nicht.

[SBorg]

@thisoft Bei 19 Paketen würden sich die Entwickler für eine Spende freuen

[Thisoft]

@sborg Achso, OK. Da stand ich auf der Leitung da guck ich mal in die Details wen von den 19 ich zu den Auserwählten zählen könnte

[AlCalzone]

@thisoft Das sind vermutlich dependencies von ioBroker. Ich denke vorher freuen sich die ioBroker-Entwickler über Unterstützung

[AlCalzone]

@marc-berg Rätsel gelöst:
Deine objects.json enthält 24550 Zeilen, unsere untere Grenze für automatisches Komprimieren liegt bei 25000.
Nach weiteren 450 Änderungen an Objekten wird dann auch komprimiert, vermutlich wurden diese bei deiner Fake-Umstellung zufälligerweise erreicht.

Falls du daran schrauben willst, wäre die Option sizeFactorMinimumSize die richtige - der Standardwert ist so gewählt, dass Installationen mit vielen Objekt-Änderungen nicht dauernd komprimieren, aber gleichzeitig die Datei nicht übertrieben groß wird.

[apollon77]

So, aus gegebenem Anlass muss ich leider doch noch eine 4.0.15 hinterherschieben. Da hatte sich ein alter Fehler wider eingeschlichen ...

4.0.15 (2022-02-20)

• (foxriver76) Make sure to stop adapters on windows or if needed for update (again)
• (Apollon77) optimize handling of set feature detection in error cases
• (foxriver76) Remove unneeded error logging

ACHTUNG
Ein Update von 4.0.14 auf 4.0.15 wird bei upgrade self eine Meldung ausgeben die ignoriert werden kann!!

Update js-controller from @4.0.14 to @4.0.15
[downloadPacket] stoppedList cannot be used if stopping of databases is requested

[JB_Sullivan]

Muss man sich eigentlich in irgend einer Form um diese Meldung kümmern, z.B. durch den npm audit fix? Schließlich wird ja da auch auf 6 kritische Schwachstellen hingewiesen.

found 169 vulnerabilities (18 low, 74 moderate, 71 high, 6 critical)
  run `npm audit fix` to fix them, or `npm audit` for details

EDIT: 4.0.15 ist einwandfrei installiert worden.

[Thomas Braun]

@jb_sullivan Würde ich die Finger von lassen.
Du kannst aber per

npm audit

schauen aus welchen Adaptern das stammt und dort dann ein Issue aufmachen, das die Dependencies hochgezogen werden.

[Marc Berg]

gelöscht

[Marc Berg]

@alcalzone sagte in js-controller 4.0 jetzt im BETA/LATEST!:

@marc-berg Rätsel gelöst:
Deine objects.json enthält 24550 Zeilen, unsere untere Grenze für automatisches Komprimieren liegt bei 25000.
Nach weiteren 450 Änderungen an Objekten wird dann auch komprimiert, vermutlich wurden diese bei deiner Fake-Umstellung zufälligerweise erreicht.

Falls du daran schrauben willst, wäre die Option sizeFactorMinimumSize die richtige - der Standardwert ist so gewählt, dass Installationen mit vielen Objekt-Änderungen nicht dauernd komprimieren, aber gleichzeitig die Datei nicht übertrieben groß wird.

Ah ja, das ergibt dann natürlich Sinn. Ich ging davon aus, dass die Einheit für diesen Faktor kByte ist, von Zeilen steht da nix. (aber von kByte auch nicht... )

Das probiere ich gleich mal aus, aber im Grunde reicht mir das Wissen, dass die Datei bei etwa 200MB nicht weiter wächst.

Danke!

Marc

[apollon77]

@jb_sullivan also wenn ihr wie es oben steht „iob fix“ ausführt dann sollte an sich die audit Meldung nie mehr kommen … nichts machen. Ignorieren

[AlCalzone]

@marc-berg sagte in js-controller 4.0 jetzt im BETA/LATEST!:

Ich ging davon aus, dass die Einheit für diesen Faktor kByte ist, von Zeilen steht da nix

Die Größe der jsonl-DB wird in Einträgen gezählt, wobei jeder als einzelne Zeile geschrieben wird. size ist die tatsächliche Anzahl der Einträge, uncompressed size ist ist die Anzahl der Einträge, die sich gerade in der Datei befinden.

[Marc Berg]

@alcalzone sagte in js-controller 4.0 jetzt im BETA/LATEST!:

Die Größe der jsonl-DB wird in Einträgen gezählt, wobei jeder als einzelne Zeile geschrieben wird. size ist die tatsächliche Anzahl der Einträge, uncompressed size ist ist die Anzahl der Einträge, die sich gerade in der Datei befinden.

Beim Herumspielen in den Host Base Settings habe ich noch ein paar kleine Fehlerchen entdeckt:

• Ändert man etwas an den Parametern "Size factor", "minimum size" etc., wird der Button "Save & Close" nicht aktiv. Man muss erst eine andere Option hin- und her ändern (z.B. "ignore read errors"), damit man speichern kann.

• Man darf den "Auto-compress size factor" auf 1 ändern. Abgesehen davon, dass eine "1" hier keinen Sinn ergibt, startet danach ioBroker nicht mehr, bis man den Wert in der "iobroker.json" wieder auf >1 ändert.

• Ändert man in der "Log"-Sektion den Parameter "Maximal size of one file", so wird dieser nach Speichern und erneut Öffnen nicht mehr angezeigt, wahrscheinlich, weil in der "iobroker.json" dann der Wert als String inkl. "MB" abgespeichert wird. Fraglich, ob die Änderung dann überhaupt zieht.

[AlCalzone]

@marc-berg Machst du bitte in Issue in https://github.com/ioBroker/ioBroker.admin auf, damit Bluefox das auch sieht?

Hier zur Vollständigkeit alle Checks der DB:

autoCompress
sizeFactor must be > 1
sizeFactorMinimumSize must be >= 0
intervalMs must be >= 10
intervalMinChanges must be >= 1

throttleFS
intervalMs must be >= 0
maxBufferedCommands must be >= 0

[Marty56]

Ich habe das Update auf 4.0.15 gemacht. iobroker startet ok.
Installationlog

Update js-controller from @4.0.14 to @4.0.15
[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.15... (System call)

> iobroker.js-controller@4.0.15 preinstall /opt/iobroker/node_modules/iobroker.js-controller
> node lib/preinstallCheck.js

NPM version: 6.14.16

> iobroker.js-controller@4.0.15 install /opt/iobroker/node_modules/iobroker.js-controller
> node iobroker.js setup first

Successfully migrated 7930 objects to Redis Sets
object _design/system updated

The following notifications happened during sync: 
- Ignoring Directory "cloud.admin" because officially not created as meta object. Please remove directory!
- Ignoring Directory "firetv.admin" because officially not created as meta object. Please remove directory!
- Ignoring Directory "proxmox" because officially not created as meta object. Please remove directory!
- Ignoring Directory "proxmox.admin" because officially not created as meta object. Please remove directory!
- Ignoring Directory "sayit.0" because officially not created as meta object. Please remove directory!
- Ignoring Directory "sayit.admin" because officially not created as meta object. Please remove directory!
- Ignoring Directory "sonos.admin" because officially not created as meta object. Please remove directory!

{
  "defaultPrivate": "-----BEGIN RSA PRIVATE KEY-----hier habe ich gekürzt---\r\n-----END RSA PRIVATE KEY-----\r\n",
  "defaultPublic": "-----BEGIN CERTIFICATE-----\r\nMIIDfjC hier habe ich gekürzt w==\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.15
removed 6 packages and updated 13 packages in 118.671s

143 packages are looking for funding
  run `npm fund` for details

Was mich wundert ist, dass er redis migrieren will. Benutze ich doch gar nicht.
Außerdem verstehe ich die Zertifikate nicht. Das hat der beim letzten Update nicht gemacht.

Soll ich die Directories, die als nicht created markiert wurden, manuell löschen?

[apollon77]

@marty56 sagte in js-controller 4.0 jetzt im BETA/LATEST!:

Was mich wundert ist, dass er redis migrieren will. Benutze ich doch gar nicht.

DU verstehst die Meldung falsch. Alles ok, ignorieren

Außerdem verstehe ich die Zertifikate nicht. Das hat der beim letzten Update nicht gemacht.

Sollte er auch haben. Bei einem controller Update werden die self-signed Certs aktualisiert.

Soll ich die Directories, die als nicht created markiert wurden, manuell löschen?

Siehe FAQ Post ... am Ende wenn die Adapter nicht mehr da sind, dann ja löschen. SOnst sollte es ein iob upload all beseitigen

[da_Woody]

@apollon77 sauber durchgelaufen!

[Feuersturm]

@apollon77 auch hier keine Probleme mit der neuen Version

[SBorg]

@apollon77 sagte in js-controller 4.0 jetzt im BETA/LATEST!:

@sborg ich kapiers net … :-((

Ich sowieso nicht ^^
... und die 15 lief eben kpl. ohne "Objects database error: connect ECONNREFUSED 127.0.0.1:9001" völlig problemlos durch

[apollon77]

@sborg Was auch sehr interessant ist