Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

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

[liv-in-sky]

@thomas-braun

auf jeden fall vielen dank für deine hilfe

habe deinen werkzeugkasten gelesen , wie ich auf einen anderen user umstelle

da steht nicht viel - nur die gruppe sudo muss da sein ?

[Thomas Braun]

@liv-in-sky
Im Grunde ja. Das Paket sudo muss halt installiert sein.
Der iobroker ist bei mir in den Gruppen drin:

pi@chet:~ $ sudo -u iobroker groups
iobroker tty dialout audio video plugdev bluetooth redis gpio i2c
pi@chet:~ $

Ein Standarduser mit leicht erweiterten Rechten dann so:

pi@chet:~ $ groups
pi adm dialout cdrom sudo audio video plugdev games users input netdev gpio i2c spi iobroker
pi@chet:~ $

[liv-in-sky]

@asgothian

@Homoran

auch euch beiden - vielen dank für die hilfe

der serial port ist eher seltsam - ich kann den zigbee stick nur in einen bestimmten usb port stecken, dann findet er den texas instruments - aber nach vielleicht einer minute geht das licht des sticks aus - es findet sich auch kein /dev/ttyusb0 oder sowas

[Thomas Braun]

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

kein /dev/ttyusb0 oder sowas

Schau unter

ls -l /dev/serial/by-id

nach dem DeviceLink

[Homoran]

@thomas-braun
@liv-in-sky
mir ist da noch ein möglicher Stolperstein gekommen.
Armbian hat aufgeräumt, anscheinend weil sie es auch nicht mehr schaffen alles zu pflegen, und die Bullseye Version, mit der ich das Image für dich gebaut hatte, begrüsst beim Einloggen mit "no enduser support"

Da kannst du zwar nichts gegen, machen, ein apt update/grade hat auch was getan, aber ich weiß nicht, ob es noch empfehlenswert ist so etwas zu nehmen.

Allerdings gibt es auch keine mir bekannten Alternativen.
Was bei Buster im Begrüßungsscreen steht weiß ich icht.
Die Ubuntu Versionen gäbe es auch noch

[Thomas Braun]

@homoran
Finde ich nicht schlimm. Beim Start von Raspberry Bullseye steht ja auch, dass es keinerlei Gewährleistung auf irgendwas gibt.

[liv-in-sky]

@thomas-braun hatte ich - da kommt

ls -l /dev/serial/by-id
ls: cannot access '/dev/serial/by-id': No such file or directory

ist nach einer min weg - manchmal:

lsusb
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 004: ID 0451:16a8 Texas Instruments, Inc.
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[Thomas Braun]

@liv-in-sky
Das ist dann vermutlich eher ein Hardware/Firmware-Problem bei dem Stick.

[liv-in-sky]

@homoran

ich lasse es so