Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Homoran]

@liv-in-sky na dann

https://forum.iobroker.net/topic/32635/fehler-im-modul-sharp-libvips-fehlt/3?_=1642245231446

auch da wurde nur downgegradet

[Thomas Braun]

@liv-in-sky
Das hat mit der Grafikbibliothek libvips zu tun. Aber eigentlich sollte eine aktuelle Buster Version schon mit passender glibc daher kommen.

Zum Bau von canvas wird das auch benutzt. Dazu gibt es aber ein paar Threads hier.

[liv-in-sky]

@thomas-braun

könnte ich was machen ?

[Thomas Braun]

@liv-in-sky

apt policy libvips-dev

[liv-in-sky]

@thomas-braun sagte in Hilfe aus Karlsruhe und Umgebung:

apt policy libvips-dev

root@ioBroker-Rock64:~# apt policy libvips-dev
libvips-dev:
  Installed: (none)
  Candidate: 8.7.4-1+deb10u1
  Version table:
     8.7.4-1+deb10u1 500
        500 http://httpredir.debian.org/debian buster/main arm64 Packages
root@ioBroker-Rock64:~#

[Thomas Braun]

@liv-in-sky

Dann schaufel das Ding mal rein.

[liv-in-sky]

@thomas-braun

bin mir bei dir nie sicher, ob du handwerker oder IT-ler bist - mal wird gezimmert, mal geschaufelt und dann wieder upgedated und upgegraded

:-)

[Homoran]

@liv-in-sky sagte in Hilfe aus Karlsruhe und Umgebung:

mal wird gezimmert, mal geschaufelt und dann wieder upgedated und upgegraded

und ganz oft gehampelt

[Thomas Braun]

@homoran @liv-in-sky
Und gebügelt wird auch!

[liv-in-sky]

@thomas-braun

ja - user die root nutzen werden glatt-gebügelt :-)

[Thomas Braun]

@liv-in-sky Nee, die hampeln doch schon.
Vielleicht werden die aber abgebürstet.

[liv-in-sky]

@thomas-braun

muss dich nochmal fragen

nachdem ich die fehler irgendwie wegbekommen habe, war noch der zigbee adapter, der sich nicht löschen lies.

den habe ich dann auf version 1.0.0 gebracht und anschliessend auf die neuste version - danach konnte ich den adapter deinstallieren

leider habe ich dadurch neue meldungen erzeugt - die wieder nicht verschwinden, obwohl der adapter deinstalliert ist
hängt das mit dem root zusammen, besonders wenn ich die iobroker del ... commands ausführe

@Asgothian kennst du diese fehler bzw infos

Spoiler

../src/serialport.cpp: In function ‘Nan::NAN_METHOD_RETURN_TYPE Open(Nan::NAN_METHOD_ARGS_TYPE)’:

../src/serialport.cpp:78:69: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type] uv_queue_work(uv_default_loop(), req, EIO_Open, (uv_after_work_cb)EIO_AfterOpen); ^~~~~~~~~~~~~../src/serialport.cpp: In function ‘Nan::NAN_METHOD_RETURN_TYPE Update(Nan::NAN_METHOD_ARGS_TYPE)’:../src/serialport.cpp:135:71: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type] uv_queue_work(uv_default_loop(), req, EIO_Update, (uv_after_work_cb)EIO_AfterUpdate); ^~~~~~~~~~~~~~~

../src/serialport.cpp: In function ‘Nan::NAN_METHOD_RETURN_TYPE Close(Nan::NAN_METHOD_ARGS_TYPE)’:../src/serialport.cpp:175:70: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type] uv_queue_work(uv_default_loop(), req, EIO_Close, (uv_after_work_cb)EIO_AfterClose); ^~~~~~~~~~~~~~

../src/serialport.cpp: In function ‘Nan::NAN_METHOD_RETURN_TYPE Flush(Nan::NAN_METHOD_ARGS_TYPE)’:../src/serialport.cpp:215:70: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type] uv_queue_work(uv_default_loop(), req, EIO_Flush, (uv_after_work_cb)EIO_AfterFlush); ^~~~~~~~~~~~~~

../src/serialport.cpp: In function ‘Nan::NAN_METHOD_RETURN_TYPE Set(Nan::NAN_METHOD_ARGS_TYPE)’:../src/serialport.cpp:270:68: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type] uv_queue_work(uv_default_loop(), req, EIO_Set, (uv_after_work_cb)EIO_AfterSet); ^~~~~~~~~~~~

../src/serialport.cpp: In function ‘Nan::NAN_METHOD_RETURN_TYPE Get(Nan::NAN_METHOD_ARGS_TYPE)’:../src/serialport.cpp:314:68: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type] uv_queue_work(uv_default_loop(), req, EIO_Get, (uv_after_work_cb)EIO_AfterGet); ^~~~~~~~~~~~

../src/serialport.cpp: In function ‘void EIO_AfterGet(uv_work_t*)’:

../src/serialport.cpp:329:96: error: no matching function for call to ‘v8::Object::Set(v8::Local<v8::String>, Nan::imp::FactoryBase<v8::Boolean>::return_t)’ results->Set(Nan::New<v8::String>("cts").ToLocalChecked(), Nan::New<v8::Boolean>(data->cts)); ^In file included from /home/iobroker/.cache/node-gyp/14.18.3/include/node/node.h:67, from ../node_modules/nan/nan.h:58, from ../src/./serialport.h:6, from ../src/serialport.cpp:1:/home/iobroker/.cache/node-gyp/14.18.3/include/node/v8.h:3670:37: note: candidate: ‘v8::Maybe<bool> v8::Object::Set(v8::Local<v8::Context>, v8::Local<v8::Value>, v8::Local<v8::Value>)’ V8_WARN_UNUSED_RESULT Maybe<bool> Set(Local<Context> context, ^~~/home/iobroker/.cache/node-gyp/14.18.3/include/node/v8.h:3670:37: note: candidate expects 3 arguments, 2 provided/home/iobroker/.cache/node-gyp/14.18.3/include/node/v8.h:3673:37: note: candidate: ‘v8::Maybe<bool> v8::Object::Set(v8::Local<v8::Context>, uint32_t, v8::Local<v8::Value>)’ V8_WARN_UNUSED_RESULT Maybe<bool> Set(Local<Context> context, uint32_t index, ^~~/home/iobroker/.cache/node-gyp/14.18.3/include/node/v8.h:3673:37: note: candidate expects 3 arguments, 2 provided../src/serialport.cpp:330:96: error: no matching function for call to ‘v8::Object::Set(v8::Local<v8::String>, Nan::imp::FactoryBase<v8::Boolean>::return_t)’

[liv-in-sky]

@Asgothian

konnte die meldungen wieder wegbekommen - da waren noch shepard sachen im node_module ordner - es gab keinen iobroker.zigbee mehr

kann das sein, dass wenn im node_module ordner diese ordner existieren, diese fehler kommen können ?

[Thomas Braun]

@liv-in-sky Das sind Meldungen vom kompilieren des serialports.
NPM versucht immer wieder das zu bauen, wenn das noch nicht erfolgreich abgeschlossen wurde.

[liv-in-sky]

@thomas-braun die kamen ja durch den zigbee adapter- da der aber deinistalliert war, hat mich das verwundert, dass trotzdem die meldungen da waren

es war ja wieder die meldung mit dem /home/iobroker.....

jetzt weiß ich nicht, ob das erneute löschen des cache im home/iobroker verzeichnis oder das löschen der übergebliebenen zigbee ordner waren

aber jetzt sieht es so aus:

[liv-in-sky]

habe schon lange nicht mehr mit einem system gearbeitet, was so wenig adapter,scripte und dp hat - ist auf einmal schnell im browser - wenn ich meinen scripte tab im admin aufmache, gehe ich eine runde spazieren, bis das offen ist

[Thomas Braun]

@liv-in-sky sagte in Hilfe aus Karlsruhe und Umgebung:

die kamen ja durch den zigbee adapter

Jein. Das sind Überbleibsel vom zigbee-herdsman. Das ist ja eine Dependency des zigbee-Adapters.

[Asgothian]

@liv-in-sky
Die Meldungen kommen wenn die serialport Library neu übersetzt wird. Die können aus den Zigbee Bibliotheken kommen, aber auch aus anderen hardwarenahen Adaptern.

Am besten du schaust via npm List noch,Amal,nach ob der serialport von einem aktiven Adapter genutzt wird. Wenn nicht solltest du versuchen die zigbee Überreste in der folgenden Reihenfolge zu beseitigen:

Zigbee-Shepherd-converters
Zigbee-shepherd
Zigbee-herdsman
Zcl-packet

A.

[Homoran]

@asgothian können die Meldu gen auch kommen, eeil jetzt nichts dran hängt?

[Thomas Braun]

@homoran
Nein, wenn der serialport sauber gebaut wurde ist der auch ruhig wenn kein Gerät dranhängt.