js-controller 3.3 jetzt im Beta

[arteck]

istim Javascript auch so wenn du ein neues script erstellst

[foxriver76]

@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.

[oFbEQnpoLKKl6mbY5e13]

@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"

[foxriver76]

@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, json oder array (aktuell auch noch file). 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.

[oFbEQnpoLKKl6mbY5e13]

@foxriver76
Danke!

[apollon77]

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.

[cash]

@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…

[da_Woody]

@cash sagte in js-controller 3.3 jetzt im Beta:

müsste ich das Update nochmal riskieren…

was riskiertst du mit dem update?

[apollon77]

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)

[Feuersturm]

@apollon77 Update und starten des Testsystems mit der 3.3.22 verlief ohne Probleme.

[derrapf]

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.6

Ich habe

iobroker stop
iobroker backup
iobroker update
iobroker upgrade self

ausgefü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

[Thomas Braun]

@derrapf

Welches Release? Ist das noch Stretch oder noch älter?

[derrapf]

@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]

@derrapf

apt policy libvips42 libvips-dev

Wenn die fehlen, nachinstallieren.

[derrapf]

@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

[Thomas Braun]

@derrapf
Genau das.

sudo apt install libvips-dev libvips42

[Thomas Braun]

@derrapf
Oh, ich sehe gerade, die Versionen dürften zu alt sein.

[derrapf]

@derrapf Das scheint es gewesen zu sein
Ich habe

 apt-get install  libvips42 libvips-dev

gemacht. Das lief ohne Fehler
Danach habe ich noch mal den upgrade vom jscontroller gemacht und da kam nur die lapidare Meldung dass er uptodate wäre.

pi@rock64:/opt/iobroker$ iobroker upgrade self
Host    "rock64"         is up to date.

War's das quasi jetzt? Weil die Fehler am Anfang sahen ja dramatisch aus. Und jetzt kommt nur "is up to date" ?
Ich hätte jetzt erwartet dass die Installtionsrountinen nochmal ohne Fehler durchlaufen müssten...

Gruss Ralf

[derrapf]

@thomas-braun
Da haben wir gleichzeitig gepostet. Welche Versionen meinst Du?
Und was soll ich tun?
Gruss Ralf

[Thomas Braun]

@derrapf

iobroker status
iobroker update -i