js-controller 3.3 jetzt im Beta
-
@foxriver76 sagte in js-controller 3.3 jetzt im Beta:
Ich schätze da wird zur Laufzeit kein neues Objekt erstellt oder es werden die States und Objekte gleichzeitig o. in falscher Reihenfolge gesetzt.
Das ist genau das worauf ich "zart" hinweisen wollte. Und noch mal der Hinweis: Ist mindestens beim Alexa2-Adapter genauso.
Issue mache ich auf.
-
@ofbeqnpolkkl6mby5e13 Danke.
Beim Alexa2 auch das Problem wenn ein neues Echo während Adapter Laufzeit hinzugefügt wird?
Da ist meines Wissens nach auch kein Issue existent derzeit.
-
@foxriver76 sagte in js-controller 3.3 jetzt im Beta:
@ofbeqnpolkkl6mby5e13 Danke.
Beim Alexa2 auch das Problem wenn ein neues Echo während Adapter Laufzeit hinzugefügt wird?
Genau. Das Szenario hatte ich weiter oben bereits beschrieben. Wenn man z. B. einen neuen Echo bei Amazon bestellt, dann fügt Amazon das Gerät bereits zum Kundenkonto hinzu, noch bevor es überhaupt geliefert wurde..
Da ist meines Wissens nach auch kein Issue existent derzeit.
Ich will es mal so sagen: ich habe bisher keines dazu eröffnet.
-
istim Javascript auch so wenn du ein neues script erstellst
-
@arteck da kommt es auf den User an oder was ist das konkrete Beispiel? Da alles asynchron läuft (ja user sind dort verwöhnt weil getState via Cache synchron läuft, ist aber bei set nicht möglich) darf man erst im cb/nach await etc den zugehörigen State setzen.
-
@foxriver76
Warum unterscheiden sich die folgenden Meldungen eigentlich:has to be stringified but received type "object" has to be type "string" but received type "object" -
@ofbeqnpolkkl6mby5e13 sagte in js-controller 3.3 jetzt im Beta:
has to be stringified but received type "object"Es wird ein Objekt erwartet, welches vorher in einen String konvertiert wurde (da DB nur Strings kennt, wenn wir selbst serialisieren kann es bei verschachtelten Objekten zu Datenverlust kommen). Das State Objekt hat also den Typ
object,jsonoderarray(aktuell auch nochfile). Es wurde ein nicht serialisiertes Objekt gesetzt.has to be type "string" but received type "object"Das state Objekt hat den Typ
string, aber es wurde ein Objekt gesetzt. -
@foxriver76
Danke! -
Es kommt die nächsten Stunden noch ein js-controller 3.3.22, in dem noch ein Fehler behoben wurde, weswegen Adapter in der Initialisierung hängen bleiben konnten. Betroffen war Sonos als Beispiel - sollte aber recht wenige betroffen haben.
-
@apollon77 Nur um es zu verstehen. Sind wenige betroffen weil wenige den Sonos Adapter nutzen oder weil es wieder nur unter bestimmen Konstellationen auftritt?
Habe am Wochenende erst 3.3.21 draufgemacht von vorher einer älteren 3.3.x. und ich nutze den Adapter nur starte ich ioBroker max. einmal die Woche wegen Backup NAS neu. Wenn man generell mit dem Adapter betroffen ist müsste ich das Update nochmal riskieren…
-
@cash sagte in js-controller 3.3 jetzt im Beta:
müsste ich das Update nochmal riskieren…
was riskiertst du mit dem update?
-
Sagen wir es so: Der Fehler war schon ... eeeeeeeeewig drin ... jetzt haben wir Ihn gefunden und daher gefixt ... Risiko ist also eher low und der Sonos Adapter hat vllt jetzt ein Problem weniger
(falls das überhaupt jemand mal gemerkt hat) -
@apollon77 Update und starten des Testsystems mit der 3.3.22 verlief ohne Probleme.
-
Jetzt hab ich mal nach Anleitung meinen Rock64 auch upgedatet und leider ging das bei mir voll in die Hose.
Node ist bei mir v12.22.6Ich habe
iobroker stop iobroker backup iobroker update iobroker upgrade selfausgeführt.
Ausgabe:pi@rock64:/opt/iobroker$ iobroker upgrade self Update js-controller from @3.3.15 to @3.3.22 NPM version: 6.14.15 npm install iobroker.js-controller@3.3.22 --loglevel error --unsafe-perm --prefix "/opt/iobroker" (System call) sharp: Installation error: Use with glibc 2.28 requires manual installation of libvips >= 8.10.6 ../src/common.cc:24:10: fatal error: vips/vips8: Datei oder Verzeichnis nicht gefunden #include <vips/vips8> ^~~~~~~~~~~~ compilation terminated. make: *** [sharp.target.mk:139: Release/obj.target/sharp/src/common.o] Fehler 1 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 5.10.63-rockchip64 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/sharp gyp ERR! node -v v12.22.6 gyp ERR! node-gyp -v v5.1.0 gyp ERR! not ok In file included from ../../nan/nan.h:58, from ../src/unix_dgram.cc:5: /home/iobroker/.cache/node-gyp/12.22.6/include/node/node.h:736:43: warning: cast between incompatible function types from ‘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.6/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/unix_dgram.cc:404:1: note: in expansion of macro ‘NODE_MODULE’ NODE_MODULE(unix_dgram, Initialize) ^~~~~~~~~~~Kann mir da jemand helfen?
Gruss Ralf
-
Welches Release? Ist das noch Stretch oder noch älter?
-
@thomas-braun
Hilf Dir das hier?pi@rock64:/opt/iobroker$ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"Ist jetzt mein System versaut, oder kann ich notfalls wieder auf den alten Stand?
Gruss Ralf -
-
@thomas-braun
Ok, hab ich ausgeführt:pi@rock64:/opt/iobroker$ apt policy libvips42 libvips-dev libvips42: Installiert: (keine) Installationskandidat: 8.7.4-1+deb10u1 Versionstabelle: 8.7.4-1+deb10u1 500 500 http://deb.debian.org/debian buster/main arm64 Packages libvips-dev: Installiert: (keine) Installationskandidat: 8.7.4-1+deb10u1 Versionstabelle: 8.7.4-1+deb10u1 500 500 http://deb.debian.org/debian buster/main arm64 Packages pi@rock64:/opt/iobroker$Ist das so ok?
Oder muss ich jetzt sagen apt install libvips42 libvips-dev?
Gruss Ralf -
@derrapf
Genau das.sudo apt install libvips-dev libvips42 -
@derrapf
Oh, ich sehe gerade, die Versionen dürften zu alt sein.
