js-controller 2 jetzt für alle im Stable

[apollon77]

Hallo ioBroker-Community,

ioBroker wird mit inzwischen über 32.000 aktiven Installationen von immer mehr Smart-Home-Enthusiasten eingesetzt. Mit dem neuen js-controller 2, welcher ab sofort im Stable-Repository als Version 2.1 verfügbar ist, legen wir die Basis für die Zukunft.

In sehr umfangreichen Beta-Test und ca. 4 Wochen im Latest -Repository, mit großartiger Unterstützung durch die Community, wurde dieses große Update des js-controllers sehr intensiv getestet. Ich bedanke mich bei allen die in den Tests mitgewirkt und Feedback gegeben oder Bugs gemeldet haben. Das war eine super Zusammenarbeit!

Vor allem "unter der Haube" sind einige grundlegende Änderungen eingeflossen, die den Wechsel auf eine neue Hauptrelease-Nummer rechtfertigen.

Dieser Post enthält alle Informationen zur Installation und was hier zu beachten ist. Bitte lest Ihn sorgfältig durch. Der zweite Post enthält eine FAQ und der dritte Post Informationen zu ausgewählten neuen Features.

Zusammenfassung bzw. TL;DR

Um alle Details zu bekommen lest bitte den Post vollständig! Falls dies nicht gewünscht ist und ihr ganz genau, wisst was ihr tut, ist hier in Kurzform:

Linux:

• Mindestanforderung: Node.js 8.x, besser 10.x installieren! Prüfen mit node -v. Update nötig? -> Bitte im Text lesen!
• Reihenfolge: Slave-Systeme zuerst aktualisieren! Master zuletzt!
• iobroker update - Repository updaten und schauen ob Update angeboten wird!
• iobroker stop -ioBroker stoppen. Prüfen das keine Prozesse (auch ggf. Backups o.ä.) mehr laufen/hängen!
• iobroker upgrade self - Das eigentliche Update
• iobroker start - ioBroker wieder starten

Windows:

• Reihenfolge: Slave-Systeme zuerst aktualisieren! Master zuletzt!
• Den neuesten Windows Installer 2.x für ioBroker von https://www.iobroker.net/#de/download herunterladen und dort 'Update/Migration' auswählen.

Bei Fragen oder Problemen oder "Sich wundern über Dinge, die jetzt anders sind" bitte den Text lesen.

Was ist besonders zu beachten?

Der js-controller 2 ist generell kompatibel mit allen bestehenden ioBroker-Systemen. Es kann von jeder früheren Version auf die Version 2.1 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.x ist es aber noch etwas zu früh, da hier immer noch einige Adapter nicht kompatibel sind!
Falls ihr in diesem Zuge die Node.js-Version aktualisieren wollt, beachtet bitte die Informationen bzw. die Anleitung unter https://forum.iobroker.net/topic/22867/how-to-node-js-für-iobroker-richtig-updaten

Weiterhin wird der ioBroker-eigene Dateibereich (im Normalfall bisher unter <ioBroker-Verzeichnis>/iobroker-data/files/...) nun strikter behandelt. Manuell oder per Skript (fs.write) dort direkt abgelegte/hin kopierte Dateien sind ggf. nach dem Update 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 von Vis oder iqontrol, damit diese Dateien korrekt registriert sind. Diese Änderung wurde auch zur Erhöhung der Sicherheit umgesetzt! Der positive Nebeneffekt ist auch, dass die Files dann mit im Backup landen, was bisher nicht erfolgte!
Bei der Installation (oder nachträglich per iobroker file sync) werden die erlaubten Verzeichnisse geprüft und bisher nicht registrierte Dateien aufgenommen. Wer komplett eigene Verzeichnisse angelegt hat, bekommt dazu eine Fehlermeldung - diese werden nicht automatisch übernommen und müssen manuell korrekt kopiert werden. Siehe dazu auch die Informationen zum Ordner 0_userdata.0 im Post #3 in diesem Thread!

---

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 kaputtgehen können, was zu größeren Problemen danach führt.

Wenn das Update nicht angezeigt wird bitte im Admin unter "Adapter" oben auf das "Neu laden" Icon drücken oder iobroker updatean der Kommandozeile eingeben.

Nötige Adapter-Aktualisierungen

Die folgenden Adapter müssen auf die genannten Minimalversionsnummern aktualisiert werden, da diese sonst nicht mit dem js-controller 2.1 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 oder höher
• email 1.0.5 oder höher
• pushover 1.1.1 oder höher
• hue 1.2.4 oder höher
• node-red 1.10.1 oder höher
• vis 1.2.2 oder höher
• iqontrol 0.2.12 oder höher
• socketio 2.1.2 oder höher
• web 2.4.9 oder höher
• hqwidgets 1.1.3 oder höher
• ble v0.10.1 oder höher
• sonos 2.0.0 oder höher (Breaking change! Kein Webserver mehr enthalten!)
• radar2 1.0.9 (GitHub version 1.2.0 muss manuell angepasst werden, siehe FAQ!)
• broadlink2 2.0.2 oder höher (siehe auch FAQ)
• systeminfo 0.3.1 oder höher
• tr-064 (wenn noch soef Originalversion bei Fehlern community Version von GitHub (!!) installieren)
• mqtt-client 1.2.0 oder höher

Achtung: Slave-Systeme zuerst!

Bei einem Multi-Host-System ist es beim Update auf Version 2 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 dann manuell ausgeführt werden (Details dazu siehe FAQ).

Update ausführen

Linux

• ioBroker Repository aktualisieren (iobroker update) und schauen das die neue Version angeboten wird
• ioBroker stoppen (iobroker stop)
• Prüfen, dass keine Prozesse (Adapter, Backups) mehr laufen (ps auxww|grep io und auch ps auxww|grep backup). Es passiert manchmal, dass trotz dem Stoppen noch Zombie-Prozesse zurückbleiben. Diese müssen mit sudo kill beendet werden
• Wie üblich wird das Update dann per iobroker upgrade self ausgeführt.
• Wenn ihr von einem js-controller 1.5 updated ist es immer sinnvoll, nach den Installation-Fixer (siehe gleich unten) auszuführen, auch wenn es bei euch keine Permission-Fehler gab!
• ioBroker starten (iobroker start)

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

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

Falls auch danach noch Fehler auftreten, bitte die Installation erneut mittels cd /opt/iobroker && sudo -H -u iobroker npm install iobroker.js-controller@2.1.0 versuchen. Bitte berichtet solche Fälle hier im Thread.

Windows

Auf Systemen, die mit dem neuen Windows Installer eingerichtet wurden, darf der js-controller nicht mittels npm aktualisiert werden. Es gibt eine neue Version des Windows Installers, die das Update des js-controllers mit wenigen Mausklicks ermöglicht. Dazu den neuesten Windows Installer 2.x für ioBroker von https://www.iobroker.net/#de/download herunterladen und dort 'Update/Migration' auswählen.

Für alle "alten manuellen" Installationen gilt

• ioBroker-Service muss gestoppt sein.
• Vor dem Update bitte prüfen, dass keine Prozesse mehr laufen

und dann entweder

• iobroker upgrade self
• ioBroker-Service starten

oder

• Den neuesten Windows Installer 2.x für ioBroker von https://www.iobroker.net/#de/download herunterladen und dort 'Update/Migration' auswählen, um zur neuen Installation mir der Möglichkeit, mehrere Instanzen auf einem Rechner zu verwalten, zu wechseln.

NACH der Installation

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

Wenn alles klappt merkt ihr außer 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.

Was jetzt die ganzen Neuerungen bringen, haben wir weiter unten in diesem Text zusammengefasst. 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 um einige Befehle länger geworden ist.

---

Was hat sich denn geändert?

---

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 gar kein Redis im Einsatz ist. Man kann allerdings weiterhin am Port erkennen ob es die ioBroker-eigene Datenbank ist (normalerweise Ports 9000 und 9001) oder ein echter Redis genutzt wird (Port 6379). 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 nicht 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.

Erst nach ca. 90s ohne Verbindung zur Datenbank beenden sich Adapter und das System und ein automatischer Restart findet statt, wonach der js-controller wartet bis die Verbindung wieder da ist. Um ggf. Netzwerk-Effekte abzufangen gibt es alle 30s einen Restart des Controllers.

Ebenso wurde der berühmt berüchtigte "Error 7", welcher im Log erscheint, wenn ein Adapterprozess bereits läuft, aber ein neuer gestartet werden soll, 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:

Spoiler

2.0/2.1 - Release Bella/Christina

Breaking changes

• Minimum requirement for js-controller 2 is node.js 8.x
• Files in iobroker-data/files are only supported in officially registered directories AND when uploaded using ioBroker tools

New user features

• Introduced 0_userdata as home for user specific files, objects and states
• 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, creates new certificates with maximum 2 years runtime according to Apple requirements
• Support command iobroker cert view <name> with <name> defaults to "defaultPublic" to display certificate info
• Use Remembered installation location for automatic adapter installs
• Log Process-ID for all adapter log messages
• Enhance some CLI commands like iobroker status
• Arrays are now allowed as state values and working without "JSON.stringify"
• add method to synchronize file directories with file DB storage using iobroker file sync <id> and automatically execute on install or iobroker setup first

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)
• streamline reconnection handling and make more flexible (reconnedt delay to 5s with approx 20 tries) before shutting down the system
• iobroker upgrade all aktualisiert nicht mehr den Controller mit

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
• Fix upload of material adapter
• Many more fixes in various places
  

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

Im dritten Post dieses Threads stellen wir einige neue Features im Detail etwas "weniger technisch" vor.

---

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.

Falls ein Adapter nicht mehr korrekt funktioniert, bitte prüfen ob es für den Adapter ein Update gibt. Falls nicht, bitte auch hier im Thread gern melden oder beim Adapter ein Issue öffnen.

Ingo

[apollon77]

---

FAQ

---

In diesem Post werden wir als FAQ häufig gestellte Fragen, Antworten, Tipps und Tricks sammeln.

0. Das update wird mir nicht angezeigt
Nummer 0 weil es oben schon im Text steht
Bitte unter Adapter auf den "neu laden" Button drücken oder an der Kommandozeile iobroker update ausführen.

1. Euer Ernst, der Text oben ist ja mega lang... TL;DR

• Nodejs 8.x ist Mindestanforderung! Nodejs 10.x empfohlen.
• Bei Master/Slave-Systemen UNBEDINGT zuerst die Slaves und am Ende den Master aktualisieren.
• Dateien die selbst in iobroker-data/files in eigene Verzeichnisse kopiert wurden, werden ggf. nicht mehr gefunden. Bitte an offizielle Stellen hochladen, am besten per Vis Uploader o.ä. Der neue Platz für eigene Dateien ist 0_userdata.0, wenn man nicht vis.0 oder iqontrol.meta nutzen will. Falls Dateien in erlaubten Verzeichnissen reinkopiert wurden, so sollten diese nach der Installation (oder alternativ nach iobroker file sync) verfügbar sein.
• Es sollte nach dem Update alles so tun wie vorher.
• Wer ab sofort auch Objekte und Dateien im Redis ablegen will, muss sich mit den Anforderungen daran befassen (siehe Details bei der Feature-Beschreibung in Post #3)!
• iobroker upgrade self nutzen, es sei denn es wurde mit dem neuen Windows Installer installiert. Dann den neuesten herunterladen und damit updaten.

2. Ich bekomme nach dem Start von ioBroker einen Fehler im Log, dass pids.txt nicht geschrieben werden konnte. Was kann ich tun?

Der Fehler tritt auf wenn der Nutzer unter dem ioBroker gestartet wurde das genannte File nicht schreiben kann. Dies kann passieren wenn ioBroker aus Versehen als Root o.ä. gestartet wurde oder die Dateirechte dieser Datei verbogen sind. Die einfachste Abhilfe hier ist der Installation-Fixer (siehe oben im Text). Alternativ bitte die Datei einfach löschen wenn ioBroker nicht läuft und dann sollte sie beim nächsten Start korrekt angelegt werden.

3. Es ist irgendwie alles kaputt/ein wichtiger Adapter tut nicht. Wie komme ich wieder zurück auf die alte Version?

Zuerst einmal bitte alle Informationen sichern, im Forum posten bzw GitHub Issues anlegen, damit die Probleme behoben werden können. Die Version 2.1 ist die Basis der Zukunft und die 1.5 wird nicht mehr weiterentwickelt!

Zurück geht es mit diesen Schritten:

Linux

• ioBroker stoppen
• Falls Objects auf redis umgestellt wurden muss dies in jedem Fall zuerst rückgängig gemacht werden! iobroker setup custom und wieder umstellen auf die Alte Konfiguration. States im Redis funktionieren auch mit der 1.5
• Zur Sicherheit das iobroker-data Verzeichnis sichern bzw ein Backup ausführen
• Dann im ioBroker Verzeichnis (cd /opt/iobroker) das Kommando npm install iobroker.js-controller@1.5.14 ausführen. Falls es dabei auf Linux zu Fehlern kommt und nicht funktioniert bitte sudo -u iobroker -H npm install iobroker.js-controller@1.5.14 nutzen.
• ioBroker starten

Windows

• Über den Windows Dienstmanager den Dienst der neuen Instanz mit dem Namen "iobroker(<instanzname>)" stoppen. Startart auf "manuell" stellen.
• Dann beim Dienst der alten Instanz die Startart auf "Automatisch (Verzögerter Start)" einstellen und den Dienst starten.
• Die neue Instanz kann mit dem ioBroker Windows Installer gelöscht werden. Darauf achten, dass vor dem löschen keine Kommandozeilen-Fenster oder Dateien aus den Ordnern der neue Instanz geöffnet sind, da sonst das Löschen nicht vollständig erfolgen kann.

4. Ich habe trotz der Warnungen bei iobroker setup custom auf einem Slave auch Daten migriert und nun funktioniert nichts mehr. Was kann ich tun?

Bei der Migration wird ein Backup erstellt. Dieses ist auf dem Master-Host im backups-Verzeichnis gespeichert und hat am Ende des Namens "-migration" angehängt. Um den Datenstand von der Master-Migration wieder herzustellen muss dieses Backup mittels iobroker restore <Filename> wieder eingespielt werden.
Danach alle Slave-Hosts umstellen und am Ende auf dem Master ein iobroker upload all ausführen.

5. Ich habe Dateien in ein eigenes Verzeichnis in iobroker-data/files kopiert und jetzt werden diese nicht mehr angezeigt. Was kann ich tun?

Aus Sicherheitsgründen wird der ioBroker-eigene Storage jetzt etwas strikter behandelt. Nur offiziell in ioBroker definierte Verzeichnisse dürfen genutzt werden und nur offizielle Wege die Datei hochzuladen. Am besten die Upload-Tools von Adaptern wie vis oder iqontrol nutzen. Alternativ gibt es CLI-Kommandos.

Der neue Platz für ganz eigene Verzeichnisse ist dann 0_userdata.0 als Basisverzeichnis. Zum einmaligen hinzufügen eigener Dateien von früher - falls dies bei der Installation nicht funktioniert hat, ist das neue CLI Kommando iobroker file sync verfügbar. Für komplett eigene Verzeichnisse wird ein Fehler angezeigt, so dass man weiß was man tun muss.

6. Wie muss ich ein Skript was bisher in iobroker-data/files direkt geschrieben hat umbauen? Wie kann ich Dateien per JavaScript hochladen?

Das Skript sollte die writeFile Methode nutzen. Details auch https://forum.iobroker.net/post/307537 bzw https://forum.iobroker.net/post/310177

7. Broadlink2 funktioniert nicht mehr. Was kann ich tun?

Der Entwickler arbeitet an einem Update. Aktuell kann manuell durch eine Änderung die Funktion wiederhergestellt werden:
Im ioBroker-Verzeichnis in node_modules/@frankjoke/myAdapter ODER node_modules/iobroker.broadlink2/node_modules/@frankjoke/myAdapter liegt das File myAdapter.js. Dieses muss durch diese Version ( myAdapter.js ersetzt werden.

8. Ich nutze die GitHub-Version von Radar2 und die tut nicht mehr. Was kann ich tun?
Exakt das gleiche wie bei Broadlink in FAQ Punkt 7.

9. Uups, ich habe meinen Master zuerst aktualisiert und jetzt können sich die Slaves nicht mehr verbinden. Was nun?

Alles halb so wild, die Slaves müssen jetzt nur leicht anders aktualisiert werden:

• ioBroker stoppen, Backup machen
• Prüfen das keine Prozesse mehr laufen (ps auxww|grep io und ps auxww|grep backup)
• im ioBroker Verzeichnis npm install iobroker.js-controller@2.1.0 ausführen. Falls es dabei auf Linux zu Fehlern kommt und nicht funktioniert bitte sudo -u iobroker -H npm install iobroker.js-controller@2.1.0 nutzen.
• starten

10. Ich sehe nach dem Update im Log "Redis error:Error: Invalid Chunk: parse failed". Was muss ich tun?

Wenn diese Meldung kommt, waren vor dem Update von 1.5 auf 2.x entweder nicht alle Adapter beendet und einer lief noch, oder es wurde der Master zuerst aktualisiert und es existiert noch ein Slave auf 1.5. Es kann auch ein "iobroker backup" Prozess noch laufen und hängen geblieben sein.

Falls es ein Adapter oder Backup ist, diesen bitte manuell killen, damit sollten die Meldungen verschwinden. Dazu mit dem ps-Befehl den Prozess herausfinden und diesen dann per sudo kill -9 <prozessid> zwangsbeenden. Ist es der Slave, siehe FAQ Punkt 9.

11. Ich habe mit eigene Objekte angelegt und diese kann ich jetzt nicht mehr schalten
Dies kann passieren, wenn die Objektnamen zu stark von den erlaubten Zeichen abweichen. Das erste Zeichen muss a-z, A-Z, 0-9 oder _ sein. Die semantische Struktur ist danach wie bei den Adapter-States mit einem Punkt, einer Zahl, einem Punkt und dann eigenen Bezeichnungen und Strukturen. Beispiel: MeineObjekte.0.Büro.Licht

Für eigene Objekte und States existiert ab sofort 0_userdata.0 als Basis-Ordner. So muss niemand mehr kreativ eigene Strukturen anlegen. Wer bereits eigene Objektstrukturen hat und damit mit keinem Adapter kollidiert, kann diese natürlich weiterverwenden!

12. Ich habe 0_userdata.0 gelöscht, weil ich es nicht brauche. Es kommt aber mit jedem js-controller Update zurück. Ist das Absicht?
Ja ist es. Wir möchten 0_userdata.0 gern als neuen Standardplatz forcieren und haben uns dazu entschieden.

13. Ich finde den neuen alias.0 Ordner im Admin nicht. Wo ist er?
Um diesen zu sehen bevor man eigene Aliase angelegt hat, muss im Admin der Filter von "State" entfernt werden. Der Order ist vom Typ "meta". Sobald mindestens ein State enthalten ist, wird er auch mit dem Standardfilter im Admin angezeigt.

14: Wenn ich mit dem 2.1 Windows Installer migrieren will, sagt er, er kann keine admin.0 oder .1 Instanz finden.

Da hilft nur eines: Eine admin.0-Instanz installieren. Dazu bitte im bestehenden (=alten) ioBroker ein Kommandozeilenfenster öffnen und sich die admin-Instanzen auflisten lassen. Z.B.:

c:
cd c:\iobroker
iobroker list instances

Der Weg ist ENTWEDER, direkt einen admin.0 hinzuzufügen (siehe dazu den letzten Code Block hier im Punkt 14), ODER zuerst alle admin-Instanzen zu löschen. Dann fängt iobroker wieder mit .0 zu zählen an, wenn man neue hinzufügt. Falls irgendwelche besonderen Konfigs im Admin wie "Authentifizierung" oder "Zertifikate" aktiv sind, sind die im Nachgang wieder manuell anzuwenden. Kuckt also vor dem Fortfahren noch einmal in die Einstellungen der admin-Adapter.

Der ioBroker Server muss nicht gestoppt werden. Nachdem vorübergehend kein Admin installiert ist, machen wir ab jetzt alles in der Kommandozeile. Los geht es:

iobroker del admin <nummer eines admins>
iobroker list instances

Solange wiederholen, bis keine Admins mehr da sind.

Jetzt fügen wir einen admin.0 wieder hinzu. Beim folgenden Befehl kannt man die Portadresse so lassen oder anpassen:

iobroker add admin 0 --port 8081           [das ist der default Wert. Freien Port wählen.]
iobroker list instances

admin.0-Instanz auf dem Port da und aktiv ("+" davor)? Im Webbrowser aufrufen und testen! Wenn ok, dann jetzt das Update mit dem Windows Installer durchführen.

[apollon77]

---

Überblick über einige der neuen Features

---

1. 0_userdata.0 als offizieller Platz für eigene Dateien, Objekte und States

Eine oft gestellte Frage ist, wo man eigene Objekte und States unterbringen kann, oder auch wo eigene Grafiken für Visualisierungen abgelegt werden sollen.
Ab sofort existiert mit 0_userdata.0 ein Platz dafür. Ein Beispiel-State ist bereits angelegt, welcher problemlos gelöscht oder angepasst werden kann.

Wichtig Wer seine States bisher in javascript.X ablegt und das für die eigenen Bedürfnisse ausreicht, kann dies weiterhin ohne Probleme tun. Wer jedoch seine Skripte auf mehrere JavaScript-Instanzen verteilt möchte ggf. einen besseren Platz, wie 0_userdata.0, nutzen Ebenso eigene Ordner auf oberster Ebene (z.B. MeineObjekte.0.x) können weiterhin genutzt werden - so lange halt bis ein Adapter mit diesem Namen kommt ...

Dateien können über den vis-Uploader (ab Version >1.2.2) und die ioBroker-Kommandozeilen-Tools hochgeladen werden. Ein manuelles reinkopieren von Dateien in den Ordner funktionieren nicht mehr.
Alle Dateien und Objekte sind natürlich auch vom Backup enthalten.
Wer bisher eigene Dateien in vis.0 oder (per IQontrol Upload-Tool) iqontrol.meta gespeichert hat, kann das natürlich ebenfalls weiterhin nutzen.

2. 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!

Zurzeit 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 2 aktiviert die Ausführung im Compact Modus in Gruppe „2“. 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 prüfen können woran es liegt.

---

3. 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 ein Fehler der beim Upload beispielsweise von material für Probleme gesorgt hat ist behoben.

---

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

Standardmäßig werden Objekte und Zustände (States) in einer ioBroker-eigenen 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 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: Ausführliche Informationen zu Redis mit ioBroker (inklusive Infos WANN was für wen Sinn macht und was eher nicht!! Damit ihr wisst was ihr tut) findet ihr auch unter https://forum.iobroker.net/topic/26327/redis-in-iobroker-überblick

Wichtig: Vor allem die Verlagerung von Dateien in die Redis-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 ggf. leicht 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 weiß 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.

Wer Redis nutzen will sollte vorab prüfen ob Redis installiert ist und man verbinden kann (z.B. redis-clisollte eine Redis Shell geben).

Unter dem bereits weiter oben genannten Link https://forum.iobroker.net/topic/26327/redis-in-iobroker-überblick findet ihr eine Zusammenfassung zum Thema "Redis und ioBroker" und dieser Thread kann auch Informationsquelle oder erste Anlaufstelle bei Problemen sein.

---

5. "Alias"-Feature

ioBroker stellt mit seinen inzwischen über 300 Adaptern eine sehr breite Palette an Funktionen bereit. Allerdings hat sich herausgestellt, dass 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 Visualisierungen oder der Nutzung für die Cloud/IoT und Assistenten gewisse Herausforderungen mit sich.

Auch beim Austausch von Geräten zwischen verschiedenen Herstellern muss man so gelegentlich aufgrund der Änderungen bei den Datenpunkten seine 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 nun 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 bereitgestellt.

[sigi234]

@apollon77

Unter Windows aber noch nicht möglich?
Im Installer noch nicht drinnen.

[marcuskl]

Sollte das hier eigentlich nicht Vergangenheit sein ?

host.iobroker	2019-11-15 19:35:25.343	warn	instance system.adapter.radar2.0 already running with pid 2761
host.iobroker	2019-11-15 19:35:23.840	info	stopInstance system.adapter.radar2.0 killing pid 2761
host.iobroker	2019-11-15 19:35:22.840	info	stopInstance system.adapter.radar2.0 send kill signal
host.iobroker	2019-11-15 19:35:22.838	info	stopInstance system.adapter.radar2.0 (force=false, process=true)
host.iobroker	2019-11-15 19:35:22.837	info	"system.adapter.radar2.0" enabled
host.iobroker	2019-11-15 19:35:22.218	info	stopInstance system.adapter.radar2.0 killing pid 2761
host.iobroker	2019-11-15 19:35:21.217	info	stopInstance system.adapter.radar2.0 send kill signal
host.iobroker	2019-11-15 19:35:21.215	info	stopInstance system.adapter.radar2.0 (force=false, process=true)
host.iobroker	2019-11-15 19:35:21.212	info	"system.adapter.radar2.0" disabled

[apollon77]

@marcuskl es kann immer noch passieren das Prozesse „hängenbleiben“. Die Erkennung und Behandlung der Fälle sollten aber besser laufen. Für den minim Auszug fehlt mir jetzt ein bissl Kontext.

[marcuskl]

@apollon77 Was soll ich noch raussuchen ?

[apollon77]

Was hast du denn getan? Adapter restart im Admin oder wie? Läuft denn noch ein Radar2 Prozess mit de me genannten Prozess id?

Dann kill mal manuell. Mich wundert das der Radar2 im log nichts sagt ...

[crunchip]

@apollon77 habe ich auch immer wider mit dem radar2.
Heute z.b. nachdem ich iobroker gestoppt hatte und einen snapshot zurück spielte.

[marcuskl]

@apollon77 Ich habe was in der Adapterkonfiguration von radar geändert und danach startet der Adapter ja neu.
Prozesse finde ich nur eine Radar und de me nicht:

root@iobroker:~# ps -e
  PID TTY          TIME CMD
    1 ?        00:00:02 systemd
    2 ?        00:00:00 kthreadd
    3 ?        00:00:00 ksoftirqd/0
    5 ?        00:00:00 kworker/0:0H
    6 ?        00:00:00 kworker/u4:0
    7 ?        00:00:03 rcu_sched
    8 ?        00:00:00 rcu_bh
    9 ?        00:00:00 migration/0
   10 ?        00:00:00 lru-add-drain
   11 ?        00:00:00 watchdog/0
   12 ?        00:00:00 cpuhp/0
   13 ?        00:00:00 cpuhp/1
   14 ?        00:00:00 watchdog/1
   15 ?        00:00:00 migration/1
   16 ?        00:00:00 ksoftirqd/1
   18 ?        00:00:00 kworker/1:0H
   19 ?        00:00:00 kdevtmpfs
   20 ?        00:00:00 netns
   21 ?        00:00:00 khungtaskd
   22 ?        00:00:00 oom_reaper
   23 ?        00:00:00 writeback
   24 ?        00:00:00 kcompactd0
   26 ?        00:00:00 ksmd
   27 ?        00:00:00 khugepaged
   28 ?        00:00:00 crypto
   29 ?        00:00:00 kintegrityd
   30 ?        00:00:00 bioset
   31 ?        00:00:00 kblockd
   32 ?        00:00:00 devfreq_wq
   33 ?        00:00:00 watchdogd
   35 ?        00:00:00 kswapd0
   36 ?        00:00:00 vmstat
   48 ?        00:00:00 kthrotld
   49 ?        00:00:00 ipv6_addrconf
   84 ?        00:00:00 bioset
   85 ?        00:00:00 bioset
   86 ?        00:00:00 bioset
   87 ?        00:00:00 bioset
   88 ?        00:00:00 bioset
   89 ?        00:00:00 bioset
   90 ?        00:00:00 bioset
   91 ?        00:00:00 bioset
   92 ?        00:00:00 kworker/u4:1
   93 ?        00:00:00 ata_sff
   94 ?        00:00:00 scsi_eh_0
   95 ?        00:00:00 scsi_tmf_0
   96 ?        00:00:00 scsi_eh_1
   97 ?        00:00:00 scsi_tmf_1
   99 ?        00:00:00 bioset
  102 ?        00:00:00 scsi_eh_2
  103 ?        00:00:00 scsi_tmf_2
  104 ?        00:00:00 bioset
  364 ?        00:00:00 kworker/0:1H
  412 ?        00:00:00 jbd2/sda1-8
  413 ?        00:00:00 ext4-rsv-conver
  434 ?        00:00:00 kworker/1:1H
  442 ?        00:00:00 systemd-journal
  444 ?        00:00:00 kauditd
  468 ?        00:00:00 systemd-udevd
  490 ?        00:00:00 kworker/u5:1
  516 ?        00:00:00 ttm_swap
  613 ?        00:00:00 irqbalance
  614 ?        00:00:00 rsyslogd
  615 ?        00:00:00 bluetoothd
  617 ?        00:00:00 cron
  620 ?        00:00:00 dbus-daemon
  638 ?        00:00:00 systemd-logind
  639 ?        00:00:01 avahi-daemon
  643 ?        00:00:00 sshd
  650 ?        00:00:00 avahi-daemon
  651 tty1     00:00:00 agetty
  667 ?        00:00:00 systemd-timesyn
  674 ?        00:00:00 dhclient
 1953 ?        00:00:00 sshd
 1955 ?        00:00:00 systemd
 1956 ?        00:00:00 (sd-pam)
 1962 pts/0    00:00:00 bash
 2092 ?        00:07:00 iobroker.js-con
 2111 ?        00:01:51 io.admin.0
 2126 ?        00:01:30 io.javascript.0
 2141 ?        00:00:06 io.info.0
 2160 ?        00:01:14 io.iot.0
 2317 ?        00:00:07 io.lgtv.0
 2528 ?        00:00:06 io.web.0
 2547 ?        00:00:11 io.sonoff.0
 2562 ?        00:00:06 io.broadlink2.0
 2577 ?        00:00:09 io.telegram.0
 2607 ?        00:01:04 io.shelly.0
 2626 ?        00:00:29 io.tr-064.0
 2641 ?        00:00:05 io.sayit.0
 2656 ?        00:00:09 io.upnp.0
 2671 ?        00:00:09 io.simple-api.0
 2686 ?        00:00:07 io.tankerkoenig
 2697 ?        00:00:35 io.lovelace.0
 2712 ?        00:00:34 io.proxmox.0
 2727 ?        00:00:05 io.sayit.1
 2746 ?        00:00:07 io.tuya.0
 2761 ?        00:00:09 io.radar2.0
 2793 ?        00:00:13 io.chromecast.0
 2809 ?        00:00:08 io.influxdb.0
 2844 ?        00:00:07 io.sourceanalyt
 2863 ?        00:00:07 io.tankerkoenig
 2963 ?        00:00:01 kworker/1:0
 3284 ?        00:00:00 kworker/1:1
 3290 ?        00:00:00 hci0
 3291 ?        00:00:00 hci0
 3292 ?        00:00:00 kworker/u5:2
 3380 ?        00:00:00 sh <defunct>
 3465 ?        00:00:09 io.zigbee.0
 3476 ?        00:00:00 kworker/0:1
 3682 ?        00:00:00 sshd
 3688 pts/1    00:00:00 bash
 3721 ?        00:00:00 kworker/0:0
 3760 ?        00:00:00 kworker/u4:2
 3779 ?        00:00:00 kworker/0:2
 3786 pts/1    00:00:00 ps

[apollon77]

@marcuskl sagte in js-controller 2 jetzt für alle im Stable:

2761 ? 00:00:09 io.radar2.0

Da ist er aber

Kille den mal.

[apollon77]

Scheinbar ist das Stable File nicht aktualisiert worden ... komisch. Aber die 2.1.0 sollte bald bei allen nach und nach auftauchen.

[marcuskl]

@apollon77 ja das habe ich ja gesagt, ich finde nur diesen einen und nicht 2.
Ich habe diesen auch schon gekillt, hat aber nichts geändert, beim start von Radar wieder das selbe Problem.

[apollon77]

@marcuskl dann starte bitte Radar2 mal im loglevel silly und lass kurz laufen und restarte dann mal. Dann poste mal das log

[Chaot]

@apollon77 Habe jetzt das 2.1.0 Update gemacht.
Was mir schon bei 2.0.43 aufgefallen ist das der "Tuya" Adapter nicht mehr richtig arbeitet:

host.ioBroker	2019-11-15 21:18:54.422	info	"system.adapter.tuya.0" disabled
tuya.0	2019-11-15 21:18:27.143	error	(5662) 5303504684f3eb21724b: Error: connection timed out
host.ioBroker	2019-11-15 21:18:19.403	info	instance system.adapter.tuya.0 started with pid 5662

Aber ich habe noch keine Gelegenheit gehabt um den Fehler näher einzugrenzen.

[ilovegym]

@apollon77
Vielen Dank, läuft problemlos auf 5 Clients und dem Host. Konnte alle problemlos updaten, ohne Fehlermeldungen.
71 Instanzen ohne Probleme...

[apollon77]

@marcuskl ALso ich kann es auch bei mir mit dem radar2 nachstellen. Irgendwie hängt der beim beenden und reagiert nicht auf einen kill. Andere Adapter machen das wie Sie sollen. Leg bitte dazu mal ein issue beim Adapter an. Muss sich der Dev ansehen

[apollon77]

@Chaot Was genau ist denn der Fehler? Das "connection timed out"? Dann kann er keine Verbindung zu dem Gerät herstellen ... wüsste nicht was das mit dem controller zu tun hat.Mach ggf mal das Gerät Stromlos und restarte es

[Diginix]

Bei mir hing gerade der radar2 Adapter und ein Skripte welches auf das Objekt system.adapter.radar2.0.connected hört warf den Fehler dass das Objekt nicht existiert.

2019-11-15 21:24:00.014  - warn: javascript.0 (27906) getState "system.adapter.radar2.0.connected" not found (3)

Es ist zwar da war aber wertelos. Bis JS-Controller 1.5 waren alive und connected immer ausnahmslos entweder true oder fase, aber nicht leer. Und wieso sagt das Log not found obwohl das Objekt vorhanden ist?

Edit: Es gab einen Zombiprozess der mit pkill nicht zu töten war.

diginix@host:/opt/iobroker/log$ sudo pkill -f io.radar2.0
diginix@host:/opt/iobroker/log$ ps aux | grep radar
iobroker   457  0.0  2.1 824208 85064 ?        Sl   19:34   0:06 io.radar2.0

Nur mit kill -9 457 konnte ich ihn beenden.

[apollon77]

@Diginix alive und connected werden mit einem "expire" von glaube ca. 30s auf "true" gesetzt während der Adapter läuft. Normalerweise wird der Wert alle 15s neu gesetzt und damit bleibt er "true". Wenn Adapter gestoppt setzt der Controller auf false ohne expire.

Falls der Adapter jetzt hängenbleibt und damit der Wert "expired" wird der State auf null gesetzt und ist Wert-los ... genau das meckert JavaScript in dem Fall ggf an.

In controller 1.5 wurde bei einem expire (und file DB) nicht der State gelöscht sondern der Wert auf "null" (für dich dann auch false) gesetzt. Bei redis DB aber gelöscht wie jetzt. Mit js.controller 2 ziehen wir das gleich.