js-controller 3.3 jetzt im STABLE!
-
@apollon77 said in js-controller 3.3 jetzt im STABLE!:
@pedder007 Es ist KEIN Adapter bekannt der mit dem neuen js.controller nicht tut oder kaputt geht. Das einzige was bei einigen Adaptern passiert ist, das pot "info-Logmeldungen" generiert werden - das kann ggf zu etwas mehr Last führen und ist im zweifelsfall unterdrückbar indem der Loglevel der Instanz auf "Warn" hochgesetzt wird.
Also damit ich das richtig verstehe, bevor ich jetzt dann am späten Nachmittag mit der Updateprozedur starte. Das einzige was mir als normaler User passieren kann ist, dass von Adaptern Fehler ins Log geschrieben werden und dass ich eigene Datenpunkte korrigieren muss, falls diese damals falsch angelegt wurden?
-
@apollon77 Läuft spitze, keine Probleme beim Update.
Danke euch allen.
-
@apollon77 sagte in js-controller 3.3 jetzt im STABLE!:
@jan1 Wie geschrieben wird das bei "Javascript" auf lange absehbare zeit nicht passieren. Es ist "Legacy" aber naja da ist zuviel schon da
Ich hatte es oben ja auch schon geschrieben, der Gedanke dahinter sind einheitlicher Systeme ohne Wildwuchs. Ok, da fallen eigene DPs unter Javascript etwas aus dem Rahmen weil die schon über den Blockly Block so angelegt wurden und das somit eben dumm gelaufen ist. Nur das dann noch zu begründen warum das OK ist und andere nicht, macht es auch nicht wirklich verständlicher für viele User.
-
@fabian1 sagte in js-controller 3.3 jetzt im STABLE!:
Vielleicht kann man für den MQTT Adapter eine ausnahme machen.
Mach ein GitHub issue im Admin, erkläre deinen hintergrund nochmal und wir sehen weiter
-
@jan1 sagte in js-controller 3.3 jetzt im STABLE!:
Nur das dann noch zu begründen warum das OK ist und andere nicht, macht es auch nicht wirklich verständlicher für viele User.
Ehrlich ... (Leider) gewinnt die Realität in den meisten Fällen dann doch immer. Und das ist so ein Fall. So gern wir es vllt ändern würden - wenn Du die Diksussion hier siehst werden wir den Teufel tun JavaScript.X anzufassen. Und das kann ich auch so ehrlich sagen. Auch in der Popup Meldung ist javascript.X explizit im Admin erwähnt. Und auch ich habe immer geschrieben das javascript.0 erlaubt ist.
Also : Ja die Empfehlung ist klar neue Datenpunkte in 0_userdata.0 einzustellen und darüber nachzudenken den Rest umzuziehen. Das ists aber auch schon
-
Hallo Gemeinde,
Hab dann doch noch was gefunden, bei dem ich nicht weiß wer der Schuldige ist.
hm-rpc.2 2021-08-08 21:25:21.883 error Cannot call setValue: XML-RPC fault: Failure hm-rpc.2 2021-08-08 21:25:21.881 error xmlrpc -> setValue ["NEQ1321750:1","LEVEL",0] FLOATBin jetzt mit allen Updates durch:
js-Controller 3.3.15
Admin 5.1.23
Rpc 1.14.43
JavaScript 5.2.8Das angemeckerte Device ist ein Homematic Rolladenaktor der zum Zeitpunkt des Logeintrags von einem Blockly runter gefahren wurde, was er auch brav gemacht hat.
-
@linedancer Das ist ein normaler Kommunikationsfehler seitens der CCU. Also eine Servicemeldung. Passiert immer mal wieder. Hat nichts mit dem Updates zu tun
-
Danke für die schnelle Rückmeldung, das beruhigt.
-
@apollon77
Vielen Dank! Habe wiedermal Bedenken gehabt durch dieses "große Update" und diese auch hier geäußerst. Nachdem nun für mich alles notwendige im Stable war, habe ich das Update/Upgrade durchgeführt und alles läuft ohne kleinstes Murren und Zucken auf js-controller 3.3 im admin 5!Vielen Dank, tolle Arbeit!
-
@linedancer Tip wäre mal die hm-rpc Instanz mit nem "Synce devices" neu zu starten
-
Habe jetzt wieder einen Anlauf gewagt und muss sagen, das sieht gegenüber des 1. Updates sehr gut aus. Es meckert nur noch 2 Adapter rum
Jetzt meckert bei mir nur noch der Adapter MiHome und der wichtigere SMA EM rum. Kann man das jetzt irgendwie so reparieren, das die Statistik nicht im Arsch ist?
mihome-vacuum.0 2021-08-11 08:10:30.470 info State value to set for "mihome-vacuum.0.info.water_box" has to be type "string" but received type "boolean"sma-em.0 2021-08-11 08:10:30.921 info State value to set for "sma-em.0.3004914003.pregardcounter" has to be type "state" but received type "number" -
@slowman sagte in js-controller 3.3 jetzt im STABLE!:
Kann man das jetzt irgendwie so reparieren, das die Statistik nicht im Arsch ist?
Es ist immer noch NUR eine Logzeile. Werte werden dennoch geschrieben ... alles gut
GitHub issues öffnen (bzw bei mihome-vacuum mal objekt löschen und adapter restarten) -
Das sagst du so in deinen jugendlichen Leichtsinn
Was passiert denn, wenn ich den kompletten Objektbaum vom SMA EM lösche und wieder erstellen lasse. Da ich ja die Daten an Grafana weiterreiche, dürfte doch meine Statistik nicht zerstört werden oder?
-
@slowman Naja wenn ein Objekt meckert lösche das eine Objekt ... und ja ggf musst du danach die Einstellungen für Historisierung neu machen
-
Habe jetzt noch ein paar Fehler drin, einige haben sich durch Löschen des Objektbaums erledigt. Aber nicht alle
Beim Hue Adapter bekomme ich absolut die Infomeldung nicht raus.
hue-extended.0 2021-08-15 10:07:06.718 info State value to set for "hue-extended.0.groups.000-all_lights.presence.state.presence" has to be type "string" but received type "boolean" hue-extended.0 2021-08-15 10:07:06.714 info State value to set for "hue-extended.0.sensors.053-küche_bwm.state.presence" has to be type "string" but received type "boolean" hue-extended.0 2021-08-15 10:10:09.303 info State value to set for "hue-extended.0.groups.000-all_lights.lightlevel.state.lightlevel" has to be type "string" but received type "number" hue-extended.0 2021-08-15 10:10:09.271 info State value to set for "hue-extended.0.sensors.221-hue_outdoor_light_sensor_2.state.lightlevel" has to be type "string" but received type "number" hue-extended.0 2021-08-15 10:10:09.271 info State value to set for "hue-extended.0.sensors.204-hue_ambient_light_sensor_6.state.lightlevel" has to be type "string" but received type "number"Staune das der Hue Extended Adapter Probleme macht, da ich sonst von keinen gelesen habe, das da nichts passt.
Kann man irgendwo selber in den Objektdaten dies verändern? -
@apollon77
Das Update ist durchgeführt. Vorher musste ich noch eineniobroker fixdurchführen.
Die Ausgabe des Updates:
peter@proxbroker:/opt/iobroker$ iobroker upgrade self Update js-controller from @3.2.16 to @3.3.15 NPM version: 6.14.14 npm install iobroker.js-controller@3.3.15 --loglevel error --unsafe-perm --prefix "/opt/iobroker" (System call) /bin/sh: 1: cmake: not found make: *** [config_deps.target.mk:13: /opt/iobroker/node_modules/cpu-features/deps/cpu_features/build/Makefile] Fehler 127 gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2 gyp ERR! stack at ChildProcess.onExit (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23) gyp ERR! stack at ChildProcess.emit (events.js:314:20) gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:276:12) gyp ERR! System Linux 4.19.0-17-amd64 gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild" gyp ERR! cwd /opt/iobroker/node_modules/cpu-features gyp ERR! node -v v12.22.5 gyp ERR! node-gyp -v v5.1.0 gyp ERR! not ok In file included from ../src/binding.cc:6: /home/iobroker/.cache/node-gyp/12.22.5/include/node/node.h:736:43: warning: cast between incompatible function types from ‘void (*)(Nan::ADDON_REGISTER_FUNCTION_ARGS_TYPE)’ {aka ‘void (*)(v8::Local<v8::Object>)’} to ‘node::addon_register_func’ {aka ‘void (*)(v8::Local<v8::Object>, v8::Local<v8::Value>, void*)’} [-Wcast-function-type] (node::addon_register_func) (regfunc), \ ^ /home/iobroker/.cache/node-gyp/12.22.5/include/node/node.h:770:3: note: in expansion of macro ‘NODE_MODULE_X’ NODE_MODULE_X(modname, regfunc, NULL, 0) // NOLINT (readability/null_usage) ^~~~~~~~~~~~~ ../src/binding.cc:2013:1: note: in expansion of macro ‘NODE_MODULE’ NODE_MODULE(sshcrypto, init) ^~~~~~~~~~~ Starting node restart.js peter@proxbroker:/opt/iobroker$Kann ich die Fehler ignorieren?
-
-
@thomas-braun
Danke.
OK, habe ich installiert.cmake: Installiert: (keine) Installationskandidat: 3.13.4-1 Versionstabelle: 3.13.4-1 500 500 http://deb.debian.org/debian buster/main amd64 Packages 500 http://ftp.de.debian.org/debian buster/main amd64 Packages peter@proxbroker:~$ sudo apt install cmake Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig Die folgenden zusätzlichen Pakete werden installiert: cmake-data libjsoncpp1 librhash0 Vorgeschlagene Pakete: cmake-doc ninja-build Die folgenden NEUEN Pakete werden installiert: cmake cmake-data libjsoncpp1 librhash0 0 aktualisiert, 4 neu installiert, 0 zu entfernen und 0 nicht aktualisiert. Es müssen 5.155 kB an Archiven heruntergeladen werden. Nach dieser Operation werden 25,8 MB Plattenplatz zusätzlich benutzt. Möchten Sie fortfahren? [J/n] Holen:1 http://deb.debian.org/debian buster/main amd64 cmake-data all 3.13.4-1 [1.476 kB] Holen:2 http://deb.debian.org/debian buster/main amd64 libjsoncpp1 amd64 1.7.4-3 [75,6 kB] Holen:3 http://deb.debian.org/debian buster/main amd64 librhash0 amd64 1.3.8-1 [122 kB] Holen:4 http://deb.debian.org/debian buster/main amd64 cmake amd64 3.13.4-1 [3.480 kB] Es wurden 5.155 kB in 0 s geholt (19,2 MB/s). Vormals nicht ausgewähltes Paket cmake-data wird gewählt. (Lese Datenbank ... 123005 Dateien und Verzeichnisse sind derzeit installiert.) Vorbereitung zum Entpacken von .../cmake-data_3.13.4-1_all.deb ... Entpacken von cmake-data (3.13.4-1) ... Vormals nicht ausgewähltes Paket libjsoncpp1:amd64 wird gewählt. Vorbereitung zum Entpacken von .../libjsoncpp1_1.7.4-3_amd64.deb ... Entpacken von libjsoncpp1:amd64 (1.7.4-3) ... Vormals nicht ausgewähltes Paket librhash0:amd64 wird gewählt. Vorbereitung zum Entpacken von .../librhash0_1.3.8-1_amd64.deb ... Entpacken von librhash0:amd64 (1.3.8-1) ... Vormals nicht ausgewähltes Paket cmake wird gewählt. Vorbereitung zum Entpacken von .../cmake_3.13.4-1_amd64.deb ... Entpacken von cmake (3.13.4-1) ... librhash0:amd64 (1.3.8-1) wird eingerichtet ... cmake-data (3.13.4-1) wird eingerichtet ... libjsoncpp1:amd64 (1.7.4-3) wird eingerichtet ... cmake (3.13.4-1) wird eingerichtet ... Trigger für man-db (2.8.5-2) werden verarbeitet ... Trigger für libc-bin (2.28-10) werden verarbeitet ... peter@proxbroker:~$Sollte ich nochmal iobroker upgraden? << Also erst zurück zum Snapshot und dann nochmal mit cmake
-
@peterfido
Dann versuch jetzt nochmal dein Glück. -
Habe ich. Ein paar Warnungen kommen noch.
peter@proxbroker:/opt/iobroker$ iobroker upgrade self Update js-controller from @3.2.16 to @3.3.15 NPM version: 6.14.14 npm install iobroker.js-controller@3.3.15 --loglevel error --unsafe-perm --prefix "/opt/iobroker" (System call) In file included from ../src/binding.cc:1: /home/iobroker/.cache/node-gyp/12.22.5/include/node/node.h:736:43: warning: cast between incompatible function types from ‘void (*)(Nan::ADDON_REGISTER_FUNCTION_ARGS_TYPE)’ {aka ‘void (*)(v8::Local<v8::Object>)’} to ‘node::addon_register_func’ {aka ‘void (*)(v8::Local<v8::Object>, v8::Local<v8::Value>, void*)’} [-Wcast-function-type] (node::addon_register_func) (regfunc), \ ^ /home/iobroker/.cache/node-gyp/12.22.5/include/node/node.h:770:3: note: in expansion of macro ‘NODE_MODULE_X’ NODE_MODULE_X(modname, regfunc, NULL, 0) // NOLINT (readability/null_usage) ^~~~~~~~~~~~~ ../src/binding.cc:153:1: note: in expansion of macro ‘NODE_MODULE’ NODE_MODULE(cpufeatures, init) ^~~~~~~~~~~ In file included from ../src/binding.cc:6: /home/iobroker/.cache/node-gyp/12.22.5/include/node/node.h:736:43: warning: cast between incompatible function types from ‘void (*)(Nan::ADDON_REGISTER_FUNCTION_ARGS_TYPE)’ {aka ‘void (*)(v8::Local<v8::Object>)’} to ‘node::addon_register_func’ {aka ‘void (*)(v8::Local<v8::Object>, v8::Local<v8::Value>, void*)’} [-Wcast-function-type] (node::addon_register_func) (regfunc), \ ^ /home/iobroker/.cache/node-gyp/12.22.5/include/node/node.h:770:3: note: in expansion of macro ‘NODE_MODULE_X’ NODE_MODULE_X(modname, regfunc, NULL, 0) // NOLINT (readability/null_usage) ^~~~~~~~~~~~~ ../src/binding.cc:2013:1: note: in expansion of macro ‘NODE_MODULE’ NODE_MODULE(sshcrypto, init) ^~~~~~~~~~~ Starting node restart.js peter@proxbroker:/opt/iobroker$
