js-controller 4.0.x jetzt für alle User im STABLE!

[apollon77]

FAQ

Informationen zu pot. angezeigten Meldungen und Logs

(info) "Sets unsupported"

In MutliHost-Umgebungen wo noch nicht alle Hosts aktualisiert sind arbeitet eine Optimierung in einem Kompatibilitätsmodus. In diesem wird ggf vom js-controller und von Adaptern beim Start einmalig die Meldung "Sets unsupported" im Loglevel "info" geloggt. Diese verschwindet wenn alle Hosts auf js-controller 4.0+ sind.

(warn) Object XXX is invalid: obj.common.min/max has an invalid type!

Dies ist eine neue Prüfung, wie oben bereits erwähnt, welche prüft das der Minimum bzw Maximum Wert eines Objekts auch eine Zahl ist. Wenn diese Meldung kommt dann diese bitte per Issue an den Adapter-Entwickler weitergeben, das dies im Adapter behoben wird.

"Ignoring Directory "benchmark.files" because officially not created as meta ob ject. Please remove directory!"

Wenn bei der Inatallation des js-controller diese Meldung kommt:

The following notifications happened during sync:
- Ignoring Directory "benchmark.files" because officially not created as meta ob ject. Please remove directory!

Bitte ein iob upload all ausführen. Falls Einträge von Adaptern enthalten sein sollten die nicht mehr installiert sind, dann können diese Dateien manuell gelöscht werden.

TypeError: Cannot read property 'warn' of undefined

Falls der iobroker nicht mehr startet und im /var/log/syslog die untenstehende Fehlermeldung enthalten ist dann ist die backup Konfigurtation fehlerhaft.

/opt/iobroker/node_modules/@iobroker/db-base/lib/inMemFileDB.js:187
             this.log.warn(
                      ^
 TypeError: Cannot read property 'warn' of undefined
     at ObjectsInMemoryServer.initBackupDir (/opt/iobroker/node_modules/@iobroker/db-base/lib/inMemFileDB.js:187:22)

Bitte in /opt/iobroker/iobroker-data/iobroker.json im Bereich backup beo objects und states schauen das der Wert "period" eine Zahl in Minuten ist. Standard ist 120. Falls hier ein Wert über 10.000 drin steht so ist dieser warum auch immer falsch eingetragen und muss bitte korrigiert werden. Danach tut alles wieder.

Warning: Accessing non-existent property '...' of module exports inside circular dependency

Wenn beim Ausführen von CLI Befehlen oder im ioBroker Log Meldungen wie die nachstehenden angezeigt werden so liegt dies an einer alten version der Library "mogodb" im System. Diese Meldungen kommen nicht vom js-controller Upgrade sondern von der Nutzung von Node.js 14+ und dieser Library. Diese wurde vom node-red Adapter ggf. installiert.

(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

Wenn ein Update des node-red Adapters (bzw Uninstall falls nicht benötigt) nicht hilft dann bitte mit npm list mongodb (im iobroker Verzeichnis /opt/iobroker) rausfinden wo es herkommt. Falls etwas von "extranous" steht dann einfach per npm uninstall mongodb (im iobroker Verzeichnis /opt/iobroker) löschen.

Eine Backitup Instanz wird automatisch erstellt

Dies passiert weil Backitup für Neuinstallationen ein Standardadapter ist. Der kleine Nebeneffekt ist, das, wenn noch keine Backitup Instanz existiert ABER der Adapter-Code auf einem Host installiert ist, dann dort eine Instanz angelegt wird. Wer das nicht will kann diese manuell wieder entfernen und dann aber am besten auch den Adapter deinstallieren. Dann passiert dies nicht noch einmal.

Infos zum Thema "Rebuilds bei Node.js Aktualisierungen"

Generell gilt das Node.js Updates wie unter https://forum.iobroker.net/topic/44566/how-to-node-js-für-iobroker-richtig-updaten-2021-edition beschrieben funktionieren. Der js-controller 4.0 führt nur die automatisierten Rebuilds etwas anders aus als die 3.3.

In der neuen Version versuchen wir zuerst generell alle Module neu zu erstellen. Das sollte alle Probleme auf einen Schlag lösen. Falls das (und ja da kann es Gründe geben) nicht funktioniert ist der zweite Versuch das wirklich betroffene NPM-Paket zu identifizieren (also z.B. direkt "serialport" o.ä.) und dieses neu zu kompilieren. Das hat deutlich weniger Nebeneffekte wie die bisherigen Versuche.

Aktuell sind zwei Module bekannt die leider eine manuelle Korrekt benötigen (wir haben es bei den Modulen gemeldet, sodass sich das in Zukunft löst). Dazu dann die Meldungen im Log befolgen.

FAQ zur DB Umstellung File -> JSONL

Ich nutze Redis. Betrifft mich das?

Wenn Du für beide Datenbanken einen Redis einsetzt dann nicht. Es ist nur relevant wenn eine oder beide DBs "File" sind.

Was ist denn so besser an der "JSONL"-Datenbank anstelle "File"?

Von der Funktionalität ist alles identisch! Die beiden Datenbanken unterscheiden sich nur darin wie die Daten gespeichert werden.

Die File-DB schreibt hier alles in einem großen JSON-File regelmäßig - bei Objekten sind dies schnell mal 20MB. Dies kann durchaus viel I/O verursachen und ist vor allem bei SD-Karten-Basierten Systemen nicht optimal, weil es die Karte sehr belastet. Aber auch für SSDs ist dies nicht optimal. Zusätzlich besteht das Problem das ein Absturz beim Schreiben dazu führt das das ganze File defekt ist. ioBroker greift in diesen Fällen auf ein Backup-File zurück.

JSONL arbeitet hier anders. Änderungen werden erst einmal nur an die Datei angehangen und - nur wenn nötig - wird dann das File "komprimiert" und so neu geschrieben. Dies erfolgt aber viel seltener als bei der File-DB.
Für JSONL hat es @AlCalzone mal folgendermaßen zusammengefasst:
JSONL ist resistenter. Ein kaputtes Byte in der DB macht nicht alles kaputt und ein Absturz beim Schreibvorgang sorgt nur dafür, dass die ausstehenden Änderungen verloren gehen, nicht alles.
JSONL schont die SD-Karte durch weniger und kleinere Schreibvorgänge (nur wenn nötig).
JSONL braucht zumindest phasenweise etwas mehr Platz (die DB ist bis auf Kompaktierungsvorgänge append-only)
JSONL braucht etwas länger, wenn viele Objekte in kurzer Zeit geschrieben werden sollen (wobei meine letzten Tests nur noch Unterschiede im Rahmen der Standardabweichung ergeben haben)

Wir denken das das neue Datenbank-Handling mehr Vorteile hat - vor allem für SD-Karten- und SSD-basierte Systeme.

Was bedeutet es das die Datenbank jetzt jsonl ist?

Im Normalfall bedeutet hies für den täglichen Betrieb nichts. Auch die Umstellung erfolg vollautomatisch im Rahmen des js-controller Updates.
Ein iob status wird nach der Installation anstelle "file" jetzt "jsonl" anzeigen. Das wars auch schon. Backups über BackItUp oder iob backup und auch restores funktionieren weiterhin ohne Änderungen.

WICHTIG: Durch die automatische Datenbankumstellung ist ein direkter Downgrade oder Backup Restore eines mit 4.0 erstellten Backups nur noch auf js-controller 3.3.x möglich! Für andere Downgrade Optionen bitte im nächsten Eintrag lesen. Ein Downgrade mit Redis als Datenbank ist problemlos weiterhin möglich!

Die Datenfiles im iobroker-data Verzeichnis haben jetzt .jsonl am Ende und nicht mehr .json. Die letzten "file DB .json"-Files werden umbenannt und liegen noch im Verzeichnis mit der Endung ".migrated".

Kann man die Einstellungen der JSONL ändern?

Ja, auch die JSONL Datenbank hat einige Einstellungen (wie das "writeFileInterval" der File-DB früher, welches bei jsonl nicht genutzt wird). Üblicherweise muss da niemand Hand anlegen, weil die Defaults von uns bereits optimiert wurden.

Wer dennoch schauen will finden unter https://github.com/ioBroker/ioBroker.js-controller/blob/master/packages/controller/conf/iobroker-dist.json#L53-L71 (Objects) bzw https://github.com/ioBroker/ioBroker.js-controller/blob/master/packages/controller/conf/iobroker-dist.json#L99-L117 die jeweiligen Default-Werte. Anpassungen können einfach in Eurer iobroker.json manuell gemacht werden.

Wie kann ich doch auf js-controller 3.2 oder kleiner downgraden wenn "jsonl" der DB Typ ist?

js-controller Versionen kleiner als 3.3.x hatten die nötigen Dateien für eine "jsonl" Datenbank nicht an Board. Daher ist ein direkter Downgrade nicht möglich weil dann die Daten nicht lesbar sind!

Daher muss ZUERST (!!) unter js-controller 4.0 die Datenbank manuell zurück auf "file" migriert werden. Dies erfolgt per iob setup custom und dort bei der Abfrage des DB Typs file angeben. Alle weiteren Fragen beantworten und dann die Migration abwarten. Danach zeigt iob statuswieder "file" an. Dann kann ein Backup für den Restore in einer kleineren Version erstellt werden oder ein Downgrade via npm i iobroker.js-controller@version (Vorher ins ioBroker Verzeichnis wechseln!) auf die gewünschte Version erfolgen.

FAQ zu Redis "Sets" Optimierungen

Für Redis-basierte Systeme bringt der js-controller 4.0 einige Optimierungen mit. Eine davon nutzt spezielle interne Datenstrukturen, die konsistent initialisiert werden müssen. Aufgrund einiger Edge Cases wird diese Optimierung daher automatisch nur für Single-Host Redis-Systeme genutzt. Wer auch im Multi-Host-Umfeld mit Redis für Objekte von den Optimierungen profitieren möchte kann diese manuell aktivieren. VORAB müssen aber alle Hosts auf js-controller 4.0 sein und soweit alles gut sein das es keinen partiellen Downgrade mehr gibt.

Dann können die Optimierungen über iob object activateSets aktiviert werden, nachdem ALLE Hosts beendet wurden. So wird sichergestellt das die Datenstrukturen konsistent initialisiert werden können. Danach können alle Hosts wieder gestartet werden. Eine Deaktivierung der Optimierungen ist per iob object deactivateSets ebenso möglich.

[apollon77]

Und bevor einer der Beta-Tester frag: Es ist immer noch die 4.0.15 geblieben. Wer die also hat braucht kein weiteres Update.

Aber: bei Fragen zu Versionen <4.0.15 bitte den Beta Thread nutzen!

[cash]

@apollon77 Puh dann bin ich leider raus. Ich habe nur Admi 5.2.1 installiert. Um höher zu kommen braucht man js-controller 3.2..22 oder höher. Habe dort nur 3.2.21.

Generell sollte man erst erst auf die 3.2.22 gehen dann Admi-Update und dann auf js-contoller 4.0.15?

[mrjeschke]

@apollon77
Ich gehe davon aus , das ich im Info-Adapter die Anzeige

v16.14.0 (Die Version v16.x von Node.js wird derzeit nicht vollständig unterstützt. - Empfohlene Version v14.19.0)

ignorieren kann?
Sonst läuft alles super.

[apollon77]

@cash Naja es spricht nichts dagegen den controller zu aktualisieren und dann auf der Kommandozeile den Admin zu aktualisieren und erst dann alles zu starten

Der Weg von 3.2 auf 4.0 müsste recht problemlos gehen, über 3.3 wäre "sicherer" weil du ein backup machen kannst was dann im Restore direkt geht - aber wenn DU in der FAQ liesst steht da wie Du auch auf eine 3.2 zurückkommen kannst ....

[apollon77]

@maik-0 Ja, die Meldung muss da mal weg. Legst Du bitte mal bei info ein GitHub Issue an?

[mrjeschke]

@apollon77
Ist erledigt.

[Thomas Braun]

@apollon77

In Anbetracht der Tatsache, dass nodeJS12 am 30.04.22 sein End Of Life erreicht würde ich noch deutlicher auf eine aktuellere Installation hinweisen.
Wenn man eh in größerem Umfang am System schrauben will/muss... Dann kann man nodeJS auch gleich in Angriff nehmen.

[apollon77]

@thomas-braun Naja deswegen ist ja oben drin das die EMpfehlung Node.JS 14 ist ... da gabs auch nen eigenen Thread zu ... ich verlinke den mal noch

[Muchul]

Melde gehorsamst: update durchgeführt.
Null Probleme, läuft.

[cash]

noch 2 Fragen bevor ich es mache: darf ich iobroker fix bei einer Docker Installation (buanet) machen? Im Fehlerfall soll man eine Datei editieren? Wie mache ich das unter Linux?

Ach ja und funktioniert danach noch der Zugriff über die Cloud über die Pro-Lizenz?

[apollon77]

@cash sagte in js-controller 4.0.x jetzt für alle User im STABLE!:

noch 2 Fragen bevor ich es mache: darf ich iobroker fix bei einer Docker Installation (buanet) machen?

@andre ?

Im Fehlerfall soll man eine Datei editieren? Wie mache ich das unter Linux?

Ich nutze vi oder nano als Editor ... Weiss nicht was bei dir drauf ist. geht an der Kommandozeile.

Ach ja und funktioniert danach noch der Zugriff über die Cloud über die Pro-Lizenz?

Der js-controller hat damit nichts zu tun. Also ja, sollte ohne Änderungen gehen

[oFbEQnpoLKKl6mbY5e13]

@apollon77 @cash

Ich bin zwar nicht @andre, aber aus eigener Erfahrung kann ich sagen: mehrfach benutzt und als funktionierend bestätigt.

[Michael Schmitt]

@apollon77
Hi,
wie werde ich diese Meldungen los? Kommen nach dem update

2022-02-25 22:31:24.720 - warn: deconz.0 (12037) Object Groups.9.xy is invalid: Default value has to be stringified but received type "object"
2022-02-25 22:31:24.721 - warn: deconz.0 (12037) This object will not be created in future versions. Please report this to the developer.
2022-02-25 22:31:28.989 - warn: deconz.0 (12037) Object Groups.9.xy is invalid: Default value has to be stringified but received type "object"
2022-02-25 22:31:28.990 - warn: deconz.0 (12037) This object will not be created in future versions. Please report this to the developer.

[apollon77]

@michael-schmitt Indem Du schaust ob es beim Adapter schon ein Issue dazu gibt und sonst eins anlegst - und sonst kannst Du das Errorlevel der Instanz (Admin - Expertenmodus - Instanzen) auf error setzen

[apollon77]

Es scheint wohl auch systeminfo (Auch @frankjoke wie km200) inkompatibel zu sein. Habe ich im Forum oben hinzugefügt. Fix ist der gleiche wiee bei km200 beschrieben

[mickym]

@apollon77 sagte in js-controller 4.0.x jetzt für alle User im STABLE!:

Node-Red muss auf Verson 2.4.2 aktualisiert sein, da der Adapter sonst nicht funktioniert

Ich werde auf diese Version nicht aktualisieren, da ich mir bereits mit @jwiesel die neueste github Version installiert hatte, die endlich ein paar issues und vor allen die aktuelle Version von Node Red der Version 2.x enthält.

Insofern finde ich diese Version 2.4.2 - die wahrscheinlich noch die NodeRed Version 1.x enthält eher unglücklich und auch nicht zeitlich abgestimmt. Hätte man mit dem JS in Stable nicht noch warten können, bis @jwiesel seine Version mit der neuesten NR Version kompatibel gemacht hätte, anstelle die alte NR Adapter Version vom August 2021 zu aktualisieren?

Ich habe den admin heute aktualisiert - werde aber das System bzw. JS 4.x erst installieren, wenn eine neue NR Adapter version verfügbar ist, die eine aktuelle NR Version und die Kompatibilität zum JS 4.x herstellt.

Ich verstehe manchmal nicht, warum man manchmal so schnell die Adapter in stable überführt ohne diese Abhängigkeiten besser zu koordinieren.

Ich hoffe jedenfalls, dass man mit JS 3.3 solange arbeiten kann, bis die von @jwiesel NR adapter version offiziell mit JS 4.x arbeiten kann. Eine Rückbau auf die alte NR Version ist für mich jedenfalls keine Alternative.

[David G.]

Erfolgreich gewechselt.
Bisher keine Probleme festgestellt.

[babl]

Update war auch erfolgreich, bisher keine Probleme festgestellt

[Schimi]

edit

fehlaalarm.... hätte genauer gucken sollen

edit2
Hier nochmal der ursprübngliche Post... als ich ihn editiert habe waren noch keine antworten da... aber damit ein suchender was findet mache ich es nochmal neu

Seit dem update kann ich nicht mehr zwischen "stable" und "beta" umschalten?
Oder ist es woanders hingekommen und ich finde es nicht?