js-controller 3.3 jetzt im STABLE!
-
Hallo ioBroker-Community,
nach einer recht langen Beta-Phase kommt heute der neue js-controller 3.3 (Releasename "Hannah") ins Stable Repository (sollte im Laufe des Abends bei allen auftauchen). Ein großer Dank geht an alle User die in der letzten Zeit diese Version bereits im Beta-Test getestet und Probleme und Fehler zur Behebung gemeldet haben und natürlich die Entwickler die Ihre Adapter wenn nötig angepasst haben!
Wichtig
Bei Fragen bitte zuerst im zweiten Post nachsehen ob das Thema ggf in einem anderen Forum Thread ausgelagert wurde um besser zu fokussieren.!Node.js Versions-Anforderungen
Die unterstützten Node.js Versionen bleiben in diesem Update gleich: 10.x, 12.x und auch 14.x werden offiziell unterstützt. Aufgrund der übergreifenden Adapter-Kompatibilität bleibt die empfohlene Node.js Version für ioBroker aktuell weiterhin auf 12.x. Falls jemand bereits mit Node.js 16.x arbeiten möchte, dann bitte im Moment AUSSCHLIESSLICH mit npm 6 !! (Bei npm 7 gibt es noch Probleme mit GitHub Installs bei einigen Adaptern)
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-editionInformationen zur Version
Die neue Version fokussiert sich neben Optimierungen, Bugfixes und einigen neuen Features vor allem weiter daran den Wildwuchs in der Umsetzung einiger Adapter etwas einzugrenzen. Im Zuge dieser neuen Checks wurden eine ganze Reihe Adapter aktualisiert - zu viele um hier alle zu nennen!
Bitte unterstützt hier weiter für ggf. noch übriggebliebene Adapter und legt bei den relevanten Adaptern im GitHub Issues an, damit diese Dinge gefixt werden können.Weiterhin zu Erwähnen ist diesmal, dass Adapter-Abhängigkeiten bei Updates besser berücksichtigt werden und das die Startreihenfolge von Adaptern nach Typ optimiert wird und auch mitbestimmen kann (mit Admin5). Detailliertere Informationen zu allen Änderungen und Features findet Ihr weiter unten und im Changelog.
In Summe sind in diese Version über 120 commits eingeflossen. Dafür bedenke mich diesmal 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 3.3 ist generell kompatibel mit allen bestehenden ioBroker-Systemen. Ein Update von der 2.0/2.1/2.2/3.x ist problemlos möglich. Nur die Node.js Version muss weiterhin mindestens 10.x sein, wie oben bereits ausgeführt. Wer überlegt die Node.js Version anzuheben bitte weiter unten im Abschnitt "Was ist zu testen" lesen
Installation
VOR der Installation
Wie bei jedem Test dieser Art: Bitte macht ein Backup!
iobroker backupbzw kopieren desiobroker-dataVerzeichnisses 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. Die alte Version des js-controller kann im Notfall einfach wieder pernpm install iobroker.js-controller@version(ausgeführt im ioBroker-Verzeichnis, z.B. /opt/iobroker) installiert werden und sollte alles wieder herstellen.Nötige Adapter-Aktualisierungen
Am besten 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 3.3 hinweisen.
Falls nach dem Update dennoch einzelne Adapter Info-Meldungen ins Log schreiben, 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!
Eine Liste der aktuell bekannten Adapter die noch Fehler ausgeben ist im zweiten Post gesammelt!
Achtung: Multihost-Systeme Reihenfolgen beachten!
Bei einem Multi-Host-System, welches auf js-controller 2.2, 3.1 oder 3.2 läuft, ist es beim Update auf Version 3.3 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 3.3 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 3.3 aktualisiert wurde!
Linux
iobroker update- ioBroker stoppen (
iobroker stop) - prüfen das keine Prozesse (Adapter, Backups) mehr laufen (
ps auxww|grep iound auchps auxww|grep backup). Es passiert manchmal das trotz dem Stoppen noch Zombies zurückbleiben - Wie üblich wird das Update dann per
iobroker upgrade selfausgeführt. - ioBroker starten (
iobroker start)
Wichtig: Falls es mit js.controller 3.2.x bei update oder upgrade einen Fehler gibt "No connection to database" dann bitte nochmals versuchen, wenn wieder passiert folgende Schritte ausführen:
- Editiere /opt/iobroker/iobroker-data/iobroker.json
- Unter objects und states gibt es ein ' "connectTimeout": 2000,`
- Zahl ändern in 5000 draus.
- Neu versuchen
- Nach dem Upgrade am besten den Wert wieder zurücketzen weil der js-controller 3.3 hier optimiert und länger wartet
Windows
Aus der Community kommt von @sigi234 eine Anleitung für ein Windows Update Update_Windows_ioBroker.pdf
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
Bei Fehlern:
Wenn bei der Installation Fehler wegen fehlender Zugriffsrechte auftreten, am besten den Installation-Fixer (iobroker fixwer schon einen js-controller 2.x oder höher hat, alternativ weiterhin manuell viacurl -sL https://iobroker.net/fix.sh | bash -) nutzen und die Installation wiederholen.
Falls es auch danach noch Fehler gibt, bitte die Installation erneut mittelssudo -H -u iobroker npm install iobroker.js-controllerversuchen. Bitte berichtet solche Fälle hier im Thread.NACH der Installation
Nach der Installation sollte der ioBroker automatisch wieder gestartet werden. Falls doch nicht bitte mittels
iobroker startstarten.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!
Was hat sich geändert, was besonders ansehen/beachten?
Neben einiger weiterer Bugfixes gibt es folgende Änderungen und Fixes zu erwähnen:
- generell siehe Changelog, speziell auch für Features
- Adapter-Instanzen starten nach den definierten Tiers
iobroker upgradebeachtet nun Adpater-Abhängigkeiten- backitup wird automatisch installiert bei neuen Installationen
- Einige Adapter werden Warnungen ausgeben wenn State-Werte gesetzt werden, da nun auch Datentypen und min/max-Werte geprüft werden. Bitte bei den Adapter-Repos melden
Speziell die Entwickler sollten bitte die genannten Deprecations und neuen Features anschauen und beachten.
Wie bereits gesagt, viele Änderungen fanden hinter den Kulissen statt. Hier für Interessierte als Spoiler eine Zusammenfassung:
Nach dem Update am besten prüfen, ob alles noch so funktioniert wie vorher auch. Das ist das wichtigste!
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, Infos zur OS- und Node.js-Umgebung sowie genaue Schritte zur Reproduktion des Problems), umso schneller können wir Fehler einkreisen und beheben.
-
Bekannte Adapter mit Fehlermeldungen
- deconz - Update geplant
- zigbee
- radar2
- wled - Update sollte die Tage kommen
- vedirect
- squeezboxrpc - fixed in 1.3.6
- synology
- enigma2
- web-speedy
- LaMetric
- kodi
- husq-automower
- smartcontrol
- shelly
- denon
Ausgelagerte Themen Threads!!
Thema "ack flag" Fehlermeldungen und "Was ist ack" und Readonly-States
https://forum.iobroker.net/topic/46771/wozu-ist-der-ack-flag-da
Thema Meldung zu falschem Datentyp
has wrong type "xxx" but has to be "yyy"https://forum.iobroker.net/topic/46776/meldungen-seit-controller-v3-3-zu-falschem-datentyp
-
Hallo,
nachdem der JS-Controller 3.3 seit heute im stable ist, habe ich auch ein Update gemacht. Seitdem habe ich natürlich auch massig Meldungen mit
has been written without ack-flag with valueim Log. Für einige Adapter (da müssen die Entwickler ran, steht ja oben), aber auch für viele Scripte, die ich seit Jahren laufen habe und hier im Forum und Internet zusammengesucht habe. Leider ist es so, dass einige der Scripte seit langer Zeit nicht mehr gepflegt wurden, aber bislang tadellos liefen. Ein Update seitens Entwickler/Programmierers wird es da nicht mehr geben. Von Javascript habe ich leider nicht zu viel Ahnung, aber würde es hinbekommen, wenn mir jemand sagt, wie Datenpunkte mit Ack-flag anstatt ohne geschrieben werden. Oder sollte ich einfach alle Datenpunkte auf writeable setzen und gut ist?
Fürs erste habe ich mal den Javascripte-Adapter und einige andere auf Loglevel error setzen müssen, da das Log ruck zuck mehrere MB enthielt, alles mit derartigen Meldungen. Aber das kann ja dauerhaft keine Lösung sein?!Gruss, Jürgen
-
@wildbill
Einfach bei den setState als 3. Übergabeparameter ein true oder false mit übergeben.setState(<der Datenpunkt>, <dein Wert>, true);Gruß
Dennis -
@idlebit Das schaue ich mir mal an, Danke.
Gruss, Jürgen -
@apollon77 Sorry das war aber nicht aus der Fehlermeldung zu erlesen, dass es sich um einen Read-Only State handelt.....
-
@idlebit Zeig mal die ganze Zeile des Logs ... du hast oben nur nen ausschnitt gepostet!
-
@apollon77 Das ist nicht mein Log!
-
Bitte nicht falsch verstehen! Ihr macht einen absolut super Job und wie schnell Fehler behoben werden und auf Github requests reagiert wird ist mega. ABER ich find es persönlich viel zu früh den js-controller 3.3 ins stable zu bringen.
Zumindest nicht ohne die Möglichkeit die wrong Type Meldungen mit einer Einstellung zu unterdrücken. Ich verstehe, dass ihr aufräumen wollt um den wildwuchs bei Adaptern in den Griff zu kriegen, aber da kann ja der normale User nichts für.
Ich zum Beispiel versuche meine logs super clean zu halten, da ich mir jede Info, Warnung und Error Meldung per Pushover schicken lasse und das hat bis jetzt hervorragend funktioniert, da ich selbst darauf achte, dass nichts unnötiges im log aufläuft. Jetzt mit dem js-controller 3.3 ist das unmöglich, da z.B. der WLED Adapter 100te von Meldungen rauswirft.
Gibt es die Möglichkeit, das Systemseitig zu unterdrücken OHNE das loglevel umzustellen. Wie gesagt, den normalen User interessiert es ja nicht ob irgend ein Wert mit dem falschenb Datentyp geschrieben wird, sondern nur die Entwickler!
-
@idlebit Na ok :-))
Laut Quellcode ist die einzige Stelle für den Teil so:
`${this.namespaceLog} Read-only state "${id}" has been written without ack-flag with value "${state.val}"` -
@apollon77 sagte in js-controller 3.3 jetzt im STABLE!:
@idlebit Na ok :-))
Laut Quellcode ist die einzige Stelle für den Teil so:
`${this.namespaceLog} Read-only state "${id}" has been written without ack-flag with value "${state.val}"`also das heisst, das readonly states eigentlich nur von adaptern erstellt und beschrieben werden sollen und wenn dann immer mit ack=true geschrieben werden soll.
wenn man in skripten eigene datenpunkte als readonly (warum auch immer) erstellt, dann muss man den ebenfalls mit ack=true beschreiben, da es ansonsten ein fehler gibt,
-
@fabian1 Ich kann dich verstehen, aber in meinen/unseren Augen ist es nicht zu früh. Wir haben jetzt ca. 3 Monate an den Adaptern gearbeitet und dabei über 80 Adapter aktualisiert welche Meldungen geworfen haben. Irgendwann ist auch mal ok und es muss weiter gehen.
Daher gab es auch eine Info-Adapter-Meldung dazu und so weiter.
Daher, falls noch noch einzelne Adapter übrig sind, bitte melden und Loglevel hochsetzen auf "warn". Das Logging der Meldungen erfolgt nur auf "info". Sollte sich also mit deinem "warn/error per pushover senden" nicht kollidieren.
EDIT: Für Wled sollte richtung Wochenende ein Update kommen (ml mindestens im Latest)
Wie gesagt, den normalen User interessiert es ja nicht ob irgend ein Wert mit dem falschenb Datentyp geschrieben wird, sondern nur die Entwickler!
Jain ... gibt auch genügend Fälle in Visus oder JavaScript wo User-Skripte komische und falsche Dinge tun.
-
@oliverio Exakt. Ein Read only state kann per definition nicht kontrolliert werden weil er nur einen Wert bereitstellt
Daher die Meldung. -
Hallo,
was bedeutet diese Meldung im Log ???State value to set for "tr-064.0.callmonitor.lastCall.callee" has to be type "number" but received type "string" -
bzw
fritzdect.0 2021-08-05 13:17:21.675 info (2739) State value to set for "fritzdect.0.DECT_099950270252.endperiod" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.674 info (2739) State value to set for "fritzdect.0.DECT_099950270252.boostactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.673 info (2739) State value to set for "fritzdect.0.DECT_099950270252.windowopenactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.579 info (2739) State value to set for "fritzdect.0.DECT_099950276783.endperiod" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.574 info (2739) State value to set for "fritzdect.0.DECT_099950276783.boostactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.573 info (2739) State value to set for "fritzdect.0.DECT_099950276783.windowopenactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.470 info (2739) State value to set for "fritzdect.0.DECT_099950696353.endperiod" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.468 info (2739) State value to set for "fritzdect.0.DECT_099950696353.boostactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.467 info (2739) State value to set for "fritzdect.0.DECT_099950696353.windowopenactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.393 info (2739) State value to set for "fritzdect.0.DECT_133560170728.endperiod" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.391 info (2739) State value to set for "fritzdect.0.DECT_133560170728.boostactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.390 info (2739) State value to set for "fritzdect.0.DECT_133560170728.windowopenactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.300 info (2739) State value to set for "fritzdect.0.DECT_133560175984.endperiod" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.298 info (2739) State value to set for "fritzdect.0.DECT_133560175984.boostactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.281 info (2739) State value to set for "fritzdect.0.DECT_133560175984.windowopenactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.135 info (2739) State value to set for "fritzdect.0.DECT_133560155800.endperiod" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.126 info (2739) State value to set for "fritzdect.0.DECT_133560155800.boostactiveendtime" has to be type "number" but received type "string" fritzdect.0 2021-08-05 13:17:21.124 info (2739) State value to set for "fritzdect.0.DECT_133560155800.windowopenactiveendtime" has to be type "number" but received type "string" -
@michael-schmitt Ja das hatte ich auch. Ist aber wie in der Anleitung beschrieben.
Ich habe die Datenpunkte alle gelöscht (des Callmonitors) und dann den Adapter neu gestartet und der Adapter hat die Objekte dann mit dem korrekten Typ angelegt.
Also zum Beispiel den Callmonitor.
Es geht Dir halt die Historie verloren. - Vielleicht auch nicht, aber ich habe nicht jeden Datenpunkt geprüft.
Also vielleicht hätte es auch getan, wenn ich nur den monierten Punkt gelöscht hätte. -
@mickym sagte in js-controller 3.3 jetzt im STABLE!:
Es geht Dir halt die Historie verloren.
Nur die Settings für History ... man kann es danach wieder aktivieren. Ja das ist leider blöd, aber aktuell leider so.
Die Alternative ist per Admin im Export-Modus das Objekt zu editierne und den Datentyp dort anzulassen. Für die mit History-Settings vllt schneller
-
@apollon77 sagte in js-controller 3.3 jetzt im STABLE!:
Jain ... gibt auch genügend Fälle in Visus oder JavaScript wo User-Skripte komische und falsche Dinge tun.
Jo so habe ich heute festgestellt, dass mein NodeRed Flow Strings in ein Zahlenobjekt geschrieben hat. Ich finde diese Meldungen auch als "Nicht-Adapter" Entwickler durchaus nützlich.
-
@michael-schmitt Die Meldung bedeutet das das Objekt definiert hat das es eine Nummer/Zahl ist, aber der Adapter hat eine Zeichenkette reingeschrieben ... Das kann ein Fehler sein weil das Objekt falsch ist oder nur ein Fall von -- Adapter schreibt "22" anstelle 22 -- rein
-
sind davon dann meine Blockly script betroffen ?
