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

[apollon77]

Hallo ioBroker-Community,

nach längerer Entwicklungszeit kommt heute der neue js-controller 4.0 (Releasename "Isabelle") für alle User ins Stable Repository (sollte im laufe des Abends bei allen auftauchen). Dieser Artikel enthält alle wichtigen Infos zu diesem Release und im zweiten Post eine kleine FAQ.
Ich bedanke mich bei allen fleißigen Testern der Community während der Beta Phase!

Node.js Versions-Anforderungen
In diesem Release entfällt Node.js 10.x, welches seit April letztem Jahr nicht mehr gepflegt wird. Node.js 16.x ist dazugekommen. Die unterstützten Node.js Versionen sind damit: 12.x, 14.x und 16.x. Die empfohlene Node.js Version für ioBroker heben wir mit diesem Release auf 14.x an (siehe auch https://forum.iobroker.net/topic/49480/node-js-10-x-ist-tot-es-lebe-node-js-14). Node.js 16.x wird mit js-controller 4.0 nun auch mit npm 7 bzw. 8 unterstützt.
Bitte beachtet weiterhin bei Node.js Updates die Anleitung im Forum unter https://forum.iobroker.net/topic/44566/how-to-node-js-für-iobroker-richtig-updaten-2021-edition . Infos ebenso hier in der FAQ hier im Thread.

Informationen zur Version
Neben einigen Optimierungen und Verbesserungen stand der Haupt-Fokus dieser Version auf Performance-Verbesserungen. Ein paar neue Features sind aber ebenfalls hinzugekommen. Auch daran den Wildwuchs in der Umsetzung einiger Adapter etwas einzugrenzen wurde weiter gearbeitet, was ggf. zu neuen Log-Meldungen für bestimmte Fälle führt. Bitte unterstützt hier wieder und legt bei den relevanten Adaptern im GitHub Issues an, damit diese Dinge gefixt werden können.

Mit dem js-controller 4.0 wird intern die Datenbank von "file" auf "jsonl" umgestellt. Dies geschieht bei der Installation automatisch ohne weitere Aktionen, wenn file genutzt wird. Weitere Details dazu sieht in der FAQ (Post #2)! Nach erfolgter Migration erscheint beim nächsten Öffnen (oder Reloads falls offen) des Admin5 auch eine Information dazu:

Für Redis Installationen haben wir ein Problem entdeckt, welches von der betriebssystem-Konfiguration von dem Host abhängt wo der Redis-Server drauf läuft. Wer also Redis als Datenbank nutzt bitte unter https://forum.iobroker.net/topic/52976/wichtiger-hinweis-für-redis-installationen nachsehen und sein System prüfen und potentiell beheben.

Detailliertere Informationen zu allen Änderungen und Features findet Ihr weiter unten und im Changelog.

In Summe sind in dieser Version wieder über 120 Änderungen in über 450 commits eingeflossen. Dafür bedanke mich diesmal wieder besonders bei foxriver76, AlCalzone und natürlich Bluefox und auch ein paar weiteren Entwicklern für die aktive Mitarbeit an dieser Version!

Der js-controller 4.0 ist generell kompatibel mit allen bestehenden ioBroker-Systemen. Ein Update von der 2.0/2.1/2.2/3.x ist problemlos möglich. Wir empfehlen allerings vor dem Update auf die 4.0 idealerweise ein Update auf die 3.3.x durchzuführen, da ein Downgrade nach einem erfolgten Update nur auf eine 3.3.x möglich ist (siehe FAQ)! Nur die Node.js Version muss weiterhin mindestens 12.x sein, wie oben bereits ausgeführt.

Aktuell ist nur node-red <2.4.2 inkompatibel, aber es gibt noch einige Versions-Empfehlungen weiter unten.

---

Installation

---

VOR der Installation

Wie bei jedem Test dieser Art: Bitte macht ein Backup! iobroker backup bzw. kopieren des iobroker-data Verzeichnisses reichen an sich aus. Bitte nicht das node_modules Verzeichnis einfach kopieren, da sonst symbolische Links kaputt gehen können, was zu größeren Problemen danach führt. Eine alte 3.3.x-Version des js-controller kann im Notfall einfach wieder per npm install iobroker.js-controller@version ("version" durch die gewünschte Versionsnummer ersetzen, vorher ins ioBroker Verzeichnis wechseln cd /opt/iobroker) installiert werden und sollte alles wieder herstellen.

Für die User, welche die experimentelle JSONL-Datenbank bereits einsetzen, ändert sich nichts - ausser das dieser Datenbank-Typ nun die offizielle ist

Nötige Adapter-Aktualisierungen

Aktuell sind drei Adapter bekannt, welche aktualisiert werden müssen bzw. sollten:

• Backitup sollte auf 2.3.3+ aktualisiert sein, damit vor allem Restores mit js-controller 4 sauber funktionieren
• Admin sollte auf 5.3.1+ aktualisiert sein, damit alle Settings für den js-controller 4 korrekt editiert werden können
• Node-Red muss auf Verson 2.4.2 aktualisiert sein, da der Adapter sonst nicht funktioniert
• km200 (see https://github.com/frankjoke/ioBroker.km200/issues/69 Fix is described in https://forum.iobroker.net/post/760260
• systeminformation Am Ende der gleiche wie wie direkt oben drüber bei km200

Am besten dennoch VOR dem js-controller Update alle verfügbaren Adapter-Updates prüfen und alle Updates installieren, die im Changelog auf Optimierungen oder Anpassungen für den js-controller 4.0 hinweisen.

Es werden aber, wie oben ausgeführt, einige Adapter ggf. Warnungen ins Log schreiben - und ggf kommen ein paar neue dazu, welche aber primär bei Objektanlagen interessant sind und weniger im Betrieb "nerven". Meldungen die vor dem Upgrade im Log waren sind jetzt auch noch da.
Bitte zuerst versuchen die gemeldeten Objekt-IDs via Admin zu löschen und den Adapter neu zu starten. Wenn die Meldungen danach nicht weg sein sollten ist aktuell die einzige Option das Loglevel der betroffenen Instanz auf "Warning" zu setzen - aber erst nachdem die Logs idealerweise in einem GitHub-Issue beim entsprechendem Adapter gemeldet wurden!

Achtung: MASTER-Systeme Reihenfolgen beachten!

Bei einem Multi-Host-System, welches auf js-controller 2.2 oder 3.x läuft, ist es beim Update auf Version 4.0 empfohlen, zuerst das Master-System zu aktualisieren. Der Master muss dann wieder gestartet werden. Die Slaves werden danach aktualisiert!

Bei Updates von Master/Slave-Systemen mit js-controller 1.5 oder früher auf die 4.0 müssen zwingend zuerst die Slaves und der Master als letztes aktualisiert werden. Beim Slave Update muss der alte Master aber noch laufen. Die Slaves bleiben nach dem Update offline und können sich nicht zum Master verbinden und werden erst wieder funktionieren wenn auch der Master auf die 4.0 aktualisiert wurde!

Windows

Aus der Community kommt von @sigi234 eine Anleitung für ein Windows Update https://forum.iobroker.net/topic/51574/windows-installation-update

Für alle "alten manuellen" Installationen gilt

• iobroker update
• ioBroker muss gestoppt sein.
• Vor dem Update bitte prüfen das keine Prozesse mehr laufen
• iobroker upgrade self
• ioBroker starten

Linux

ACHTUNG: Wer von einer kleineren js-controller Version als 3.2 kommt, sollte direkt per npm installieren und NICHT per iob uograde self!!

• iobroker update (Repository aktualisieren)
• iobroker stop
• prüfen das keine Prozesse (Adapter, Backups) mehr laufen (ps auxww|grep io und auch ps auxww|grep backup ). Es passiert manchmal das trotz dem Stoppen noch Zombies zurückbleiben
• iobroker fix (Alle Rechte im Dateisystem, Linux-Pakete u.ä. aktualisieren)
• iobroker upgrade self (Ausführung des Updates)
• iobroker start

Die Installation wird - wenn Sie von einem 2.x/3.x-System aus erfolgt - einige Warnungen/Fehler loggen. Wenn diese aussehen wie im folgenden Bild gezeigt (GET/SET-UNSUPPOTED bzw LUA script load error), ist dies erwartet und ok!

Update js-controller from @3.3.22 to @4.0.15
npm install iobroker.js-controller@4.0.15 --loglevel error --unsafe-perm --prefix "/opt/iobroker" (System call)
Server Objects 127.0.0.1:37942 Error from InMemDB: Error: GET-UNSUPPORTED for namespace cfg.: Data=["meta.objects.features.useSets"]
Server Objects 127.0.0.1:37942 Error from InMemDB: Error: GET-UNSUPPORTED for namespace cfg.: Data=["meta.objects.protocolVersion"]
Server States 127.0.0.1:60678 Error from InMemDB: Error: GET-UNSUPPORTED for namespace meta.: Data=["meta.states.protocolVersion"]
Server States 127.0.0.1:60680 Error from InMemDB: Error: PSUBSCRIBE-UNSUPPORTED for namespace meta.: Data=["meta.*"]
Server Objects 127.0.0.1:37942 Error from InMemDB: Error: Unknown LUA script load
Server Objects 127.0.0.1:37942 Error from InMemDB: Error: Unknown LUA script load
Server Objects 127.0.0.1:37942 Error from InMemDB: Error: Unknown LUA script load
Server Objects 127.0.0.1:37942 Error from InMemDB: Error: SET-UNSUPPORTED for namespace cfg.: Data=["meta.objects.features.useSets",{"type":"Buffer","data":[49]}]
Server Objects 127.0.0.1:37942 Error from InMemDB: Error: multi NOT SUPPORTED
Server Objects 127.0.0.1:37942 Error from InMemDB: Error: sadd NOT SUPPORTED
Server Objects 127.0.0.1:37942 Error from InMemDB: Error: exec NOT SUPPORTED
Server Objects 127.0.0.1:37942 Error from InMemDB: Error: multi NOT SUPPORTED
Server Objects 127.0.0.1:37942 Error from InMemDB: Error: sadd NOT SUPPORTED
Server Objects 127.0.0.1:37942 Error from InMemDB: Error: exec NOT SUPPORTED

Wichtig: Falls es bei Updates von js-controller 3.2.x bei update oder upgrade einen Fehler gibt "No connection to database" dann bitte nochmals versuchen und wenn es wieder passiert folgende Schritte ausführen:

• Editiere /opt/iobroker/iobroker-data/iobroker.json
• Unter objects und states gibt es jeweils ein ' "connectTimeout": 2000,`
• Zahl ändern auf 5000
• Neu versuchen
• Der Wert kann so bleiben weil er eh beim js-controller 4 der neue Standardwert ist

Bei Fehlern:
Wenn bei der Installation Fehler wegen fehlender Zugriffsrechte auftreten, am besten den Installation-Fixer (iobroker fix wer schon einen js-controller 2.x oder höher hat, alternativ weiterhin manuell via curl -sL https://iobroker.net/fix.sh | bash -) nutzen und die Installation wiederholen.
Falls es auch danach noch Fehler gibt, bitte die Installation erneut mittels sudo -H -u iobroker npm install iobroker.js-controller versuchen. Bitte berichtet solche Fälle hier im Thread.

Die Installation kann ggf. Warnungen ausspucken über potentiell "deprecated" NPM Module oder Compiler-Warnungen oder (bei optionalen Paketen auch -Fehler) anzeigen (z.B, unix_dgram, serialport, pam_authentication und ggf andere). Hier gilt wie immer: Ignorieren
Ebenso eine Aufforderung "npm audit fix" auszuführen kann ignoriert werden!

NACH der Installation

Nach der Installation sollte der ioBroker automatisch wieder starten. Falls doch nicht bitte mittels iobroker start starten.

Wenn alles klappt merkt Ihr ausser der höheren Versionsnummer in der Host-Ansicht im Admin keinen Unterschied. Alles funktioniert weiterhin wie vorher. Alle Adapterinstanzen starten und funktionieren. Wenn das so ist hat alles geklappt.

Falls im Log Warn-Meldungen auftauchen mit dem Hinweis diese an den Entwickler zu senden, dann bitte schauen welcher Adapter es ist und entsprechend dort Issues bitte anlegen!

Wie bereits gesagt, viele Änderungen fanden hinter den Kulissen statt.

BREAKING CHANGES

• Support for Node.js 10 is dropped! Supported are Node.js 12.x, 14.x and 16.x
• CLI command iob update --updateable changed to iob update --updatable
• CLI command iob update http://download.iobroker.net/sources-dist.json is not supported anymore
• CLI command iob rebuild adaptername is no longer supported because of the new way of automatic rebuilds and some unwanted side effects
• CLI command iob state get <id> will no longer handle binary state values (which was never really working before). We added iob state getBinary <id> <encoding> as new way.
• Ensure that on a backup-restore the same adapters and adapter versions are restored as existing on backup time. Also check js-controller version and error on mismatch (is allowed to be forced accepted by --force parameter for restore)
• The "file" database will be automatically converted into JSONL and the database types that use "file" are adjusted to "jsonl" on installation (and backup restore). This means that a rollback of js-controller is only possible to 3.3 after 4.0 was installed! Rollback to former versions require a manual migration to "file" DB before the downgrade! (COMMUNICATION, TESTFOKUS)

Hier für Interessierte als Spoiler noch alle weiteren Änderungen als Zusammenfassung:

Spoiler

Features

• (bluefox) Added complexity rules for user passwords: New created passwords need to follow the following rules (TODO ADMIN UI INFO ISSUE):
  • minimum length is 8
  • contains at least one digit
  • contains at least one lower case letter
  • contains at least one upper case letter
• (foxriver76) Introduce option "--custom" when deleting instances or adapter to also clean up relevant custom entries from all objects (TODO ADMIN ISSUE ADD CHECKBOX!, TESTFOKUS)
• (foxriver76) Added new host objects to provide Node.js version and PID
• (foxriver76) Updated the Linux capabilities on js-controller start when a Node.js version change was detected (and initial on first run)
• (AlCalzone/foxriver76) Further optimize strategy for required Node.js module rebuilds. We first try to run rebuild in root package and if still packages are left (or it fails) we try to rebuild the really affected modules alone. Should give better results then former strategy (TESTFOKUS)
• (bluefox) Added support for configuring multiple repositories (TODO LINK+INFO FLAG)
• (Apollon77) Streamline logging configuration for all available transports: A set Loglevel in config means that this loglevel is pinned for the transport for all cases. An Empty/not set level ("Default" in Admin) means that logging is dynamic and can be adjusted per Instance controller or loglevel state on the fly.
• (foxriver76) Added installedFrom info to adapter start log line when not installed from npm normally

Optimizations and Fixes

• (Apollon77/foxriver76) Improve performance of object deletions (also when deleting instances or adapters) significantly (file-db 4x faster, jsonl-db 14x faster, redis 360x% !! faster)
• (foxriver76/Apollon77) Improve performance for redis object searches by up to 2,5x by using lookup structures for object types and custom object properties. This optimization is only active for single host redis systems automatically, but can be activated for multihost redis systems too after all hosts are (and stay!) on js-controller 4.0! (TODO DOCS)
• (foxriver76/Apollon77) Improve performance for object searches in general by limiting search namespaces to the relevant ones automatically
• (foxriver76) Improve handling of backup restores when custom hostnames were used (especially relevant for Docker usage)
• (foxriver76) Optimize backup to make sure invalid user-generated JSONs do not prevent backups from being considered valid
• (foxriver76/klein0r) Improved CLI help
• (foxriver76) Preserve changed instance names also when updating adapter (name was reset before)
• (foxriver76) stop adapters on Windows prior update to prevent EBUSY
• (foxriver76) Prevent crashes for uploads with invalid adapter installations
• (bluefox) Removed news from instance/adapter objects on install/update because taken from repository in Admin5 (TODO CHECK ADMIN4 EFFECTS)
• (AlCalzone) Removed extraneous "npm install" inside adapter directory
• (foxriver76/AlCalzone) reduce JSONL compression frequency to reduce I/O (relevant when experimental JSONL database modules are used)
• (foxriver76) prevent uploading js-controller (creating system.adapter.js-controller object) and remove existing cases on setup first
• (foxriver76) prevent crash when multihost password is invalid and multihost active
• (bluefox/foxriver76) bigger internal refactorings in cli commands (TESTFOKUS)
• (foxriver76) made logging of not fulfilled adapter dependencies more user-friendly
• (foxriver76) Check user and group assignments and remove unknown users from groups (could have happened in earlier versions) in setup first
• (foxriver76) Prevent crash on adapter install/update if version string in repo is invalid
• (AlCalzone) Update and optimize JSONL database integration and configuration options
• (foxriver76) make sure that settings for file/jsonl DB in configfile are also respected
• (foxriver76) Update seq integration for logging
• (foxriver76) If logging can not be initialized because of a fatal error do not start js-controller
• (foxriver76) Prevent start of a debug session for an instance that is already running
• (Apollon77) Fix an edge case for file db which could lead to main and backup file being broken in strange situations with multiple crashes in a row
• (foxriver76) make sure that admin, backitup and discovery instances are created when update of controller happens if installed and no instance exists
• (Apollon77) Optimize Stop Handling to prevent errors
• (Apollon77) Optimize Adapter process initialization to prevent edge case errors
• (foxriver76) Optimize meta object sync
• (Apollon77) make sure to really end CLI process when they should end in error cases
• (Apollon77) catch error when streaming data to stdout and this is closed already
• (Apollon77) Optimize some special cases on adapter start
• (AlCalzone) Prevent issues when backup interval is configured with invalid values
• (AlCalzone) Prevent db-file-locking issues for jsonl database; the connectTimeout for databases is now minimum 5s (overrides lower values from configuration)
• (foxriver76) allow instance deletion when executed from an other host
• (foxriver76) stop the database before executing upgrade self; Will be effective for all upgrades >4.0.5
• (Apollon77/foxriver76) Optimize database initialization and destroys
• (Apollon77) Update winston-syslog to prevent errors
• (Apollon77, foxriver76, bluefox, AlCalzone) Several fixes and refactorings to prevent potential crash cases reported by Sentry and other sources

Developer relevant DEPRECATIONS/WARNINGS

• js-controller is no longer installable from GitHub because is now a monorepo. Use @dev tag on npm to get the nightly build of master js-controller!
• log info when setState is used for an object of type file - use setBinaryState instead!
• log info when default value of an object is invalid (e.g. does not match object type)
• log info when common.states is used and not an object (deprecate String usage)
• log info when common.min/common.max exists on non numbers and contain invalid values/types
• add get/setForeignBinaryState methods as copy from get/setBinaryState allow adapter to migrate; get/setBinaryState will be changed in 4.1 to be "non Foreign"
• Enhanced object checks: adapter need to have a name as string
• Decline calls for getForeignObjects with non string pattern (was pot. crashing before)
• adapter.tools is deprecated and replaced by a shim. Use methods in adapter class or adapter-core instead or open issues if you need more internal functions
  The object view definition "custom/state" is now removed from js-controller after being replaced by "system/custom" in js-controller 3.3. All relevant adapters are updated (COMMUNICATION)
• remove all Fifo Methods from adapter.js because deprecated since 1.x
• remove adapter.objects.* methods because deprecated since 2.x

Developer relevant new Features

• (jogibear9988) Add new "unload-safe" promise based "adapter.delay" method to delay further code execution, but still make sure code do not continue after unload was called. This method can not be used inside the "unload" method itself!
• (jogibear9988/AlCalzone/foxriver76/Apollon77) Revamp adapter.*Timeout and adapter.*Interval methods to be "unload-safe" and also clear missing timeouts without warnings for more developer convenience! The methods to set a timeout or interval can not be used inside the "unload" method itself!
• (foxriver76) Allow to set "null" for common.states and not log error for object (also for extend)
• (AlCalzone) Introduce new methods in tools for Node.js module management: installNodeModule, uninstallNodeModule (TODO Issues adapter that use npm install -> Move))
• (bluefox) Add license management functionality to host. Adapters can use adapter.getSuitableLicenses to get available relevant licenses (TODO DOCS)
• (AlCalzone) Switch NPM relevant handling to library pak to be more flexible for the future which package manager we want to use. Important: There are still parts that rely on npm for now!
• (bluefox) Also report docker info when sending diag data
• (foxriver76) Add server time to getHostInfo message
• (foxriver76) For multihost clusters with js-controller 4.0+ the hosts automatically determine a "primary" host that can be used js-controller internally (right now, preparation for future topics)
• (Apollon77) Add database types to crash data reported to sentry

Developer relevant Optimizations and Fixes

• (foxriver76) fixed permissionError on setBinaryState
• (foxriver76) preserve "native" content for instanceObjects when updating the objects on adapter start
• (Apollon77/foxriver76) Limit the search scope for object types host, adapter, instance, instanceStats, enum, script, group, user, config to the relevant namespaces when no search start/end is provided to speedup these calls in general
• (foxriver76) Optimize deleteDevice/deleteChannel methods to just delete all objects the relevant device/channel
• (foxriver76) Removed some magic path lookups to be compatible to npm 7/8. Appname of controller is now always "iobroker" ("ioBroker" in dev cases)
• (foxriver76) Also use Sentry (if enabled/allowed) in CLI commands whenever database is initialized to report crashes from CLI if they happen
• (foxriver76) Introduce a database protocol version number to allow detection of the available database features in multihost environments
• (bluefox) Prevent issues when using adapter.addChannelToEnum because of missing callback
• (foxriver76) make sure autoSubscribe works as expected in all cases
• (Apollon77) Correctly return null when a session is expired
• general dependency updates
• code style optimizations and streamline code
  

---

Wie Fehler melden?

---

Wer sich unsicher ist, ob ein Fehler vorliegt, sollte am besten hier im Thread das Problem beschreiben. So können wir alle versuchen, das Problem nachzuvollziehen und ggf. einzugrenzen.

Bitte checkt auch die "Known issues Liste" (zweiter Post) mit den Dingen die aktuell während dem Beta-Test bekannt sind und bis zum Release noch angepasst werden.

Sobald ein Fehler auftritt der in einer Fehlermeldung oder einen Crash mit Fehlerdetails im Log oder auf Kommandozeile endet, dann dazu am besten direkt ein GitHub-Issue im js-controller Projekt öffnen und zusätzlich hier im Thread posten. Je detaillierter die Angaben im Issue sind (genaue Fehlermeldungen/Logs, Infos zur OS- und Node.js-Umgebung sowie genaue Schritte zur Reproduktion des Problems), umso schneller können wir Fehler einkreisen und beheben.

Wir wünschen allen viel Spaß mit der neuen Version des js-controller.

Ingo

sunshower2 created this issue in frankjoke/ioBroker.km200

closed km200 läuft unter Controller 4.0 bei mir nicht mehr #69

[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