js-controller 2.0

Hallo ioBroker-Community,

passend zum Erreichen der 30.000 aktive Installationen Marke vor ein paar Tagen möchten wir Euch nun gern den neuen js-controller 2.0 vorstellen. Dieser ist ab sofort im Latest Repository und auf npm verfügbar.

In einem internen Test und einen sehr umfangreichen Beta-Test in der Community haben wir dieses große Update des js-controllers bereits sehr intensiv getestet. Großer Dank geht an @Arteck, @sigi234, @SBorg, @opossum, @e-s, @e-i-k-e, @Yetiberg, @Jan1, @Einstein67, @Dr. Bakterius und viele andere mehr. Das war eine super Zusammenarbeit!

Es sind vor allem "unter der Haube" einige grundlegende Änderungen eingeflossen, die den Wechsel auf eine neue Hauptrelease-Nummer rechtfertigen. Mehr dazu weiter unten.

Der js-controller 2.0 ist generell kompatibel mit allen bestehenden ioBroker-Systemen. Es kann von jeder früheren Version auf die Version 2.0 aktualisiert werden. Einzig die Node.js Version muss vor dem Update mindestens auf 8.x, besser noch auf 10.x angehoben werden! Für Node.js 12 ist es aber noch etwas zu früh, da hier immer noch einige Adapter nicht kompatibel sind.

Weiterhin wird der ioBroke-Eigene-Dateibereich (im Normalfall bisher unter /iobroker-data/files/...) nun strikter behandelt und manuell oder per Skript (fs.write) dort direkt abgelegte/hinkopierte Dateien sind ggf. nicht mehr in Visualisierungen anzeigbar! Skripte müssen angepasst werden (Nutzung von writeFile) bzw. die Dateien müssen in offiziell definierte Adpater-Basisverzeichnisse (z.B. vis.0, iqontrol.meta u.ä.) abgelegt werden. Nutzt am besten auch die offiziellen Uploader via Vis oder iqontrol, damit diese Dateien korrekt registriert sind. Diese Änderung wurde auch zur Erhöhung der Sicherheit umgesetzt! Der positive Nebeneffekt ist auch das die Files dann mit im Backup landen, was bisher nicht gegeben war!

Installation

Vor der Installation Wie bei jedem Update dieser Art: Bitte macht ein Backup! iobroker backup, bzw. kopieren des iobroker-data Verzeichnisses reichen an sich im Zweifel auch aus (ioBroker vorher stoppen natürlich). Bitte nicht das node_modules Verzeichnis einfach kopieren, da sonst symbolische Links kaputt gehen können, was zu größeren Problemen danach führt.

Nötige Adapter-Aktualisierungen

Die folgenden Adapter müssen auf die genannten Minimalversionsnummern aktualisiert werden, da diese sonst nicht mit dem js-controller 2.0 funktionieren. Diese Updates am besten vorher ausführen, weil alle genannten Versionen auch mit den alten js-controller Versionen funktionieren.

  • simple-api 2.1.2 or higher
  • email 1.0.5 or higher
  • pushover 1.1.1 or higher
  • hue 1.2.4 or higher
  • node-red 1.10.1 or higher
  • vis 1.2.1 or higher
  • iqontrol 0.2.6 or higher
  • socketio 2.1.2 or higher
  • radar2 1.0.9 (GitHub version 1.2.0 muss manuell angepasst werden, siehe FAQ!)
  • broadlink2 (siehe FAQ)

ACHTUNG: SLAVE-SYSTEME ZUERST!

Bei einem Multi-Host-System ist es beim Update auf Version 2.0 sehr wichtig, die Slave-Systeme zuerst zu aktualisieren. Der Master wird als letztes aktualisiert!

Wenn diese Reihenfolge nicht eingehalten wird können sich die Slave-Systeme nicht mit dem master verbinden und das Update muss manuell ausgeführt werden (Details dazu siehe FAQ Post).

Windows

Auf Systemen, die mit dem neuen Windows Installer eingerichtet wurden, darf der js-controller nicht mir npm aktualisiert werden. Es wird eine neue Version des Windows Installers geben, die das Update des js-controllers mit wenigen Mausklicks ermöglicht. Wir updaten dazu hier im Thread.

Für alle "alten manuellen" Installationen gilt der gleiche ioBroker-eigene iobroker upgrade self Befehl wie sonst auch.

Linux

Wie üblich wird das Update per iobroker upgrade self ausgeführt.

Bei Fehlern: Wenn bei der Linux-Installation Fehler wegen fehlender Zugriffsrechte auftreten, am besten den Installation-Fixer nutzen und die Installation wiederholen.

curl -sL https://iobroker.net/fix.sh | bash -

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.

Nach der Installation

Nach der Installation den ioBroker wieder starten (z.B. mittels iobroker start).

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. Die großen Änderungen sind alle "Unter der Haube" versteckt.

Dazu, was Euch jetzt die ganzen Neuerungen bringen, findet Ihr weiter unten in diesem Text Informationen. Neue Funktionen als Basis für Weiterentwicklungen wurden behutsam integriert und einige bestehende Probleme gezielt behoben.

Mit iobroker help wird eine Liste der möglichen Kommandozeilen-Kommandos angezeigt, die mit Version 2.0 um einige Befehle länger geworden ist.

Was hat sich geändert, was besonders ansehen/testen?

Eine der größeren Änderungen ist, dass die ioBroker-eigenen States- und Objects-Datenbanken vollständig neu geschrieben wurden. Im ioBroker-System wird zur Kommunikation jetzt ein TCP-basiertes und mit Redis-kompatibles Protokoll verwendet. Vor allem "Reconnection from DB"-Fehler sollten dadurch jetzt der Vergangenheit angehören. Auf Basis dieser Änderungen planen wir für die Zukunft noch einige interessante Neuerungen.

Durch diese Änderung steht jetzt in Logs teilweise "connected to redis" obwohl Ihr gar keinen Redis nutzt. Ihr könnt allerdings weiterhin am Port erkennen wenn es die ioBroker-eigene Datenbank ist (normalerweise Ports 9000 und 9001). Erste Tests haben gezeigt das die CPU Belastung der Adapter-Prozesse und des js-controller geringer ist als in der alten Version, da das neue Protokoll deutlich schlanker ist. Es ist weiterhin flexibler und robuster - so lange die Netzwerkverbindung nicht abreißt. Aber selbst in solch einem Fall sollte ein automatischer Reconnect stattfinden und, wenn der Abbruch nich zu lang ist, alle Änderungen aus der Zeit ohne Verbindungen nochmals gesendet werden. Also falls Ihr in der Vergangenheit von "Reconnect to DB" Meldungen und Effekten geplagt wart ist Euer Bericht für uns sehr interessannt.

Ebenso der berühmt berüchtigte "Error 7", welcher im Log erscheint wenn ein Adapterprozess bereits läuft, aber ein neuer gestartet werden soll wurde verbessert. Wenn ein neuer Prozess gestartet werden soll, sollten sich nun ggf noch laufende Prozesse automatisch selbst beenden und eine einmalige Meldung im Log erzeugen.

Wie bereits gesagt, viele Änderungen fanden hinter den Kulissen statt. Hier für Interessierte als Spoiler eine Zusammenfassung:

2.0 - Release Bella

Breaking changes

Minimum requirement for js-controller 2.0 is node.js 8.x Files in iobroker-data/files are only supported in officially registered directories New user features

  • Add Compact Mode and compact groups (Technology Preview)
  • Add build-in Alias handling for Objects/States (Technology Preview)
  • Add support to also use Redis for Objects and Files
  • Add Redis sentinel support
  • Allow dynamic change of Loglevel for adapter instance and js-controller hosts processes
  • Add optional migration for State and/or Objects values when using setup custom
  • Add monitoring for event-Loop-Lag as host and adapter objects
  • Add possibility to validate backup files
  • Support command „iobroker logs“
  • Support command „cert create“
  • Remember installation location for reinstallations
  • Use Remembered installation location for automatic adapter installs
  • Log Process-ID for all adapter log messages
  • Enhance some CLI commands like iobroker status
  • New adapter developer features

Streamline redis vs file States handling which was different also before controller 2.0:

  • not set states will always return null now
  • States will set to null completely (not only value) when they expire
  • States will also be published to onChanged handlers when states are in Redis
  • Add adapter.supportsFeature('NAME') method to check if a certain feature exists. #244
  • Ability to define secured objects in io-pack access only via own adapter and admin. #287
  • Added getObjectView and getObjectViewAsync on adapter object
  • Added getObjectList and getObjectListAsync on adapter object
  • Allow the deletion of multiple objects with wildcard
  • setObject/setObjectNotExists now also sets default value of state after object creation
  • Allow getPort to check for the port optionally on a certain host/IP

Further changes

  • Rewrite InMem databases (States & Objects) to TCP (redis compatible) protocol and deprecate socket.io version; will be removed approx. in v2.1
  • Add adapter handling to prevent "error 7" (adapters will stop themself as soon as PID is not as expected)
  • Upgrade all dependencies
  • Don't chmod 777 after controller upgrade
  • Refactoring of many CLI commands
  • Add possibility to return zip file as a link and not as base64
  • Standardize error codes
  • Root should always npm install with --unsafe-perm
  • Enable gzip to read repositories
  • Read hash of sources.json online before downloading the whole file
  • Add some information about user-agent
  • Verify the version of node.js by start of the instance
  • Hide cmd window on windows
  • Include certificate creation in setup first
  • Suppress warning by npm install
  • Allow optional dependencies being installed
  • Optimize setup custom command and add more user guidance
  • Add Feature overview to README
  • Forward upload console outputs from slave to master
  • Make sure to upload and upgrade all relevant objects on installations and updates of adapters
  • Always upgrade instance objects after successful installs or upgrades
  • Optimize adapter start processes, especially when combined with needed automatic installations of adapters
  • After 2 installation tries with "last-installedFrom" use the installedVersion field to try to install from npm
  • Hhosts now ignore object changes when the affected instances is still in installQueue
  • Code refactoring and optimizations in various places
  • Randomize Certificate Serial numbers
  • delay parallel start of scheduled instances to prevent system overload scenarios (same rules asd for adapterstart, basically 4s delay)

Bugfixes

  • Log scheduled restarts as info only (fixes #315)
  • Fixed #340 to maintain restartSchedule on updates
  • Fixed a bug where it was possible to set "ack" to any value via cli
  • Enable ESLint and fix most issues
  • Optimize multi host upload
  • Restart stopped adapters at the end of the upload and not before to make sure to not have two adapter restarts on upgrade cases
  • Enhance checks for failed installations in cli and controller
  • Also update adapter instance statistic objects when no instanceObejcts are defined
  • ".alive" state values are only checked on adapter start if ack=true to allow to start a process if not running
  • Fix for mutlihost detection
  • Fix backup of states
  • Make sure also VIS global CSS is included in backup and restored
  • Many more fixes in various places

Weitere Details zu den Änderungen und Bugfixes ist im Changelog einzusehen.

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.

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, Info zur verwendeten DB-Konstellation (file(file, file/redis, redis/redis ...), Infos zur OS- und Node.js-Umgebung sowie genaue Schritte zur Reproduktion des Problems), umso schneller können wir Fehler einkreisen und beheben.

Überblick über einige der neuen Features

1.Compact Modus und Compact Gruppen

Eines der großen Vorteile von ioBroker ist, dass jeder Adapter als eigener Prozess ausgeführt wird. Das macht das System sehr stabil - bei Problemen betreffen diese nur den einen Adapter und nicht das ganze System. Andererseits benötigt dieser Ansatz allerdings auch etwas mehr RAM. Für Systeme mit wenig verfügbarem RAM (z.B. Raspi Nano oder Raspi 1 mit 512MB RAM), die oft als Slave-Systeme eingesetzt werden, ist die Anzahl der Adapter damit limitiert.

Der Compact Modus löst dieses Problem dadurch, dass mehrere Adapter zusammen in einem Prozess laufen und damit der RAM-Bedarf deutlich geringer ist (es werden etwa 20-30MB je Adapter-Instanz eingespart). Dies geht aber zu Lasten der Stabilität, da ein fehlerhafter Adapter auch alle anderen Adapter im gleichen Prozess betrifft und diese sich ggf. ebenfalls neu starten.

Adapter-Instanzen können dazu, um das Risiko etwas zu verteilen, in mehrere Gruppen aufgeteilt werden. Jede Gruppe startet einen eigenen Prozess, in dem dann alle Instanzen dieser Gruppe ausgeführt werden. Die Gruppe 0 ist speziell. Hier Mitglied zu sein bedeutet, dass der betreffende Adapter im Haupt-js-controller-Prozess ausgeführt wird. Dies ergibt die größte RAM-Ersparnis - allerdings auch das größte Risiko, da ein fehlerhafter Adapter den js-controller negativ beeinflussen kann. Als Standard werden Instanzen in der Gruppe 1 ausgeführt, wenn der Compact Modus für die entsprechende Instanz aktiviert wird.

Ob ein Adapter den Compact Modus unterstützt, hängt vom jeweiligen Adapter ab. Diese Information wird künftig noch in der Adapterliste aufgenommen. Aktuell werden nur Adapter die als daemon ausgeführt werden auch im Compact Modus gestartet (also keine scheduled-Adapter). Auch wenn der Adapter generell den Compact-Mode unterstützt muss die Nutzung pro Instanz einzeln aktiviert werden!

Zur Zeit gibt es zur Konfiguration des Compact Modus noch keine Unterstützung im Admin. Die Konfiguration erfolgt per Kommandozeilen-Aufruf. Die wichtigsten Kommandos sind:

iobroker compact enable zum generellen Aktivieren des Compact Modus für den aktuellen js-controller Host. ioBroker muss danach neu gestartet werden, damit die Änderung aktiv wird.

iobroker list instances zeigt zusätzliche jetzt auch den Status des Compact Modus der Adapterinstanzen an.

iobroker compact <adaptername>.<instanz> status zeigt den Compact Modus Status der Instanz an.

iobroker compact <adaptername>.<instanz> enable 1 aktiviert die Ausführung im Compact Modus in Gruppe „1“. Nur der Adapter wird dabei neu gestartet. Diese Konfiguration kann bei laufendem ioBroker erfolgen.

Falls es Probleme gibt (z.B. ein Adapter läuft nicht mehr sauber oder bleibt "hängen" beim Stoppen), dann bitte ein Issue beim Adapter öffnen. Ansonsten bitte hier im Thread posten, damit wir sehen, woran es liegt.

2. Installations-Quelle von Adaptern wird gespeichert

ioBroker-Adapter werden im Normalfall aus dem Latest- oder Stable-Repository von npm installiert. Falls ein Adapter auf einen anderen Host verschoben wird oder das System neu installiert werden muss, wird versucht die gleiche Version wieder von npm zu installieren. Im Normalfall klappt das auch. Falls ein Adapter allerdings testweise von GitHub installiert wurde, ist dieser Stand bzw. diese Version ggf. nicht auf npm verfügbar. Damit kann die gleiche Version nicht automatisch neu installiert werden. Dies ändert sich nun.

Für alle neuen Adapterinstallationen nach dem Update merkt sich ioBroker den genauen GitHub-Stand einer Custom-Installation und kann diesen Stand dann wieder nachinstallieren.

Auch an der Adapterinstallation selbst, dem Upload und ähnlichem wurde einiges überarbeitet und optimiert. Es wurden einige Sonderfälle behoben, wo teile der upload-Logik nicht korrekt ausgeführt wurden. Auch hier helfen eure Tests.

3. Redis-Unterstützung nun auch für Objekte und Files

Standardmäßig werden Objekte und Zustände in einer ioBroker-eigenen Speicher-Datenbank verwaltet und in JSON-Dateien gespeichert. Mit dieser eigenen Lösung wird keine weitere Software benötigt.

Seit einiger Zeit ist es bereits möglich, Zustände alternativ in einer optimierten Redis-Datenbank zu speichern. Ab einiger gewissen Anzahl an Zustandsänderungen pro Sekunde kann durch den Einsatz von Redis die Gesamtsystemlast zurückgehen bzw. auf mehrere Systeme verteilt werden. Redis bringt allerdings auch einen Mehraufwand mit, da diese Software installiert, verwaltet und gesichert werden will, damit es bei Updates oder im Problemfall nicht zu einem Datenverlust kommt.

Mit js-controller 2.0 erlaubt ioBroker nun auch Objekte und die Dateien, die aktuell auf dem Master-System im Dateisystem abgelegt sind, in der Redis-Datenbank zu verwalten.

Wichtig: Vor allem die Verlagerung von Dateien in die Datenbank kann dazu führen, dass diese recht groß werden kann (gern mehrere hundert MB). Da Redis alle Daten immer im RAM hält, ist diese Option nur für Systeme geeignet, die genügend RAM-Ressourcen zur Verfügung haben. Ebenso die CPU Belastung wird bei einem redis/redis System höher sein weil Daten anders verarbeitet werden müssen.

Die Verlagerung von Dateien in die Datenbank führt zu einer deutlich größeren Flexibilität. Aufgrund dieser Änderung gibt es quasi keine lokalen Daten im Dateisystem mehr. In Summe wird die Redis-Datenbank zur zentralen Datenhaltung des ioBroker-Systems, da sie sämtliche Daten beinhaltet. Alle js-controller und Adapter verbinden sich dann mit dieser zentralen Datenbank.

Mit dem js-controller 2.x kann sogar eine Redis-Sentinel Installation zur Steigerung der Systemverfügbarkeit genutzt werden (quasi ein Redis-HA-Cluster). Das ist eine erste Grundlage für die Bereitstellung eines hochverfügbaren ioBroker-Systems, das Ausfälle einzelner Serverkomponenten kompensieren kann. Diese Option sollte man allerdings aktuell nur austesten wenn man weiss was man tut 😉 Dazu in späteren Updates mehr.

Mit dem Einzug der verschiedenen Speichermöglichkeiten für Dateien, Objects und States wurde der Befehl iobroker setup custom überarbeitet. Zum einen zeigt er mehr Informationen an. Zusätzlich ist er jetzt aber auch in der Lage, bei einem Wechsel der Datenhaltung die Daten in alle Richtungen zu migrieren. So ist ein Wechsel jederzeit möglich.

4. "Alias"-Feature

Einer der Vorteile von ioBroker ist, dass es sehr viele Adapter gibt. Allerdings hat sich herausgestellt, das jeder Adapter z.B. je nach angebundenen Systemen durchaus individuelle Strukturen bezüglich der Ablage der bereitgestellten Datenpunkte implementiert. Dies bringt vor allem bei eigenen Skripten aber auch bei Visualisierungs- und den Cloud/iot-Adaptern gewisse Herausforderungen mit sich. Beim Austausch von Geräten zwischen verschiedenen Herstellern muss man so gelegentlich aufgrund der Änderungen bei den Datenpunkten Skripte anpassen. Visualisierungsadapter und der iot-Adapter versuchen z.B. anhand der Rollen von Datenpunkten den Typ von Geräten zu erkennen, um diese korrekt anzuzeigen bzw. an Amazon bzw. Google zu melden. Dabei stehen die Adapter manchmal auf verlorenem Posten, weil bestimmte Adapter Informationen zu Rollen u.ä. gar nicht liefern können - vor allem MQTT, modbus u.ä. sind hier betroffen.

Das Alias Feature, das direkt im js-controller verankert ist, stellt den neuen Namespace "alias.0" für Objekte zur Verfügung. Das Feature erlaubt es, Geräte mit einer stabilen Struktur und sauberen Rollen anzulegen. Das erfolgt jetzt zuerst manuell, später auch z.B. mittels des kommenden "Devices"-Adapters, der sich gerade in Entwicklung befindet.

Auch dieses Feature hat noch keine vollständige Unterstützung im Admin, was allerdings noch kommen wird.

Nach der Definition des Alias-Objects kann im neuen Bereich common.alias die ID des Quellobjekts im jeweiligen Adapter definiert werden. Ab dann werden alle Daten in beide Richtungen zwischen den Objekten synchronisiert. Zusätzlich kann interessanterweise eine read und write Funktion definiert werden, um einfache Umrechnungen vorzunehmen (z.B. Wh <--> kWh).

Weitere (technische) Details haben wir unter Alias Information in der js-controller README veröffentlicht.