Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[tugsi]

@thomas-braun Das ist meine Antwort, sind die Errors alle so ok? Ich weiss das mit dem coffee ist alt, aber irgendwie wirkt das so viele...

pi@raspberrypi:~ $ cd /opt/iobroker/ && npm ls | grep zigbee
├─┬ iobroker.zigbee@1.7.6 (github:ioBroker/ioBroker.zigbee#eea83037ea5f0cd3020a9e16154c6980c70f492f)
│ ├─┬ zigbee-herdsman@0.14.49
│ └─┬ zigbee-herdsman-converters@14.0.608
│   └── zigbee-herdsman@0.14.49 deduped
npm ERR! extraneous: @abandonware/noble@1.9.2-5 /opt/iobroker/node_modules/@abandonware/noble
npm ERR! extraneous: @apollon/frankjoke-myadapter@1.2.5 /opt/iobroker/node_modules/@apollon/frankjoke-myadapter
npm ERR! extraneous: @types/request@2.48.3 /opt/iobroker/node_modules/@types/request
npm ERR! extraneous: iobroker.admin /opt/iobroker/node_modules/iobroker.admin
npm ERR! error in /opt/iobroker/node_modules/iobroker.admin: ENOENT: no such file or directory, open '/opt/iobroker/node_modules/iobroker.admin/package.json'
npm ERR! extraneous: areq@0.2.0 /opt/iobroker/node_modules/areq
npm ERR! extraneous: better-queue@3.8.10 /opt/iobroker/node_modules/better-queue
npm ERR! extraneous: cc-znp@0.5.0 /opt/iobroker/node_modules/cc-znp
npm ERR! extraneous: chai@4.2.0 /opt/iobroker/node_modules/chai
npm ERR! extraneous: coffee-compiler@0.3.2 /opt/iobroker/node_modules/coffee-compiler
npm ERR! extraneous: coffee-script@1.12.7 /opt/iobroker/node_modules/coffee-script
npm ERR! extraneous: fsevents@2.1.2 /opt/iobroker/node_modules/fsevents
npm ERR! extraneous: mdns-discovery@0.2.6 /opt/iobroker/node_modules/mdns-discovery
npm ERR! extraneous: netmask@1.0.6 /opt/iobroker/node_modules/netmask
npm ERR! extraneous: node-pre-gyp@0.12.0 /opt/iobroker/node_modules/node-pre-gyp
npm ERR! extraneous: node-ssdp@3.3.0 /opt/iobroker/node_modules/node-ssdp
npm ERR! extraneous: objectbox@0.3.0 /opt/iobroker/node_modules/objectbox
npm ERR! extraneous: osx-temperature-sensor@1.0.4 /opt/iobroker/node_modules/osx-temperature-sensor
npm ERR! extraneous: ping@0.2.2 /opt/iobroker/node_modules/ping
npm ERR! extraneous: proving@0.1.0 /opt/iobroker/node_modules/proving
npm ERR! extraneous: queue@6.0.1 /opt/iobroker/node_modules/queue
npm ERR! extraneous: suncalc2@1.8.1 /opt/iobroker/node_modules/suncalc2
npm ERR! extraneous: typescript@3.7.2 /opt/iobroker/node_modules/typescript
npm ERR! extraneous: virtual-tsc@0.4.6 /opt/iobroker/node_modules/virtual-tsc
npm ERR! extraneous: vm2@3.8.4 /opt/iobroker/node_modules/vm2
npm ERR! extraneous: wake_on_lan@1.0.0 /opt/iobroker/node_modules/wake_on_lan
npm ERR! extraneous: xpc-connection@0.1.4 /opt/iobroker/node_modules/xpc-connection
npm ERR! extraneous: zcl-packet@0.2.4 /opt/iobroker/node_modules/zcl-packet
npm ERR! extraneous: zstack-constants@0.2.0 /opt/iobroker/node_modules/zstack-constants
npm ERR! extraneous: zwave-js@7.2.3 /opt/iobroker/node_modules/zwave-js
npm ERR! peer dep missing: @zwave-js/core@>=10.0.0, required by @zwave-js/log-transport-json@3.0.0
npm ERR! peer dep missing: @zwave-js/shared@>=10.0.0, required by @zwave-js/log-transport-json@3.0.0

[Thomas Braun]

@tugsi sagte in Zigbee Neustart bei Firmwareupdatesüberprüfung:

sind die Errors alle so ok?

Errors sind grundsätzlich nie okay, sonst wäre es Warnings und keine Errors.

Insbesondere der sieht komisch aus:

npm ERR! error in /opt/iobroker/node_modules/iobroker.admin

Installier den admin nochmal drüber. Und bring deine nodejs-Installation auf Stand 16, du bist da offenbar noch mit was altem unterwegs.

[tugsi]

@thomas-braun sagte in Zigbee Neustart bei Firmwareupdatesüberprüfung:

Errors sind grundsätzlich nie okay, sonst wäre es Warnings und keine Errors.

Es gibt aber auch Errors, die man getrost ignorieren kann, deswegen meine Frage ;)

[Thomas Braun]

@tugsi sagte in Zigbee Neustart bei Firmwareupdatesüberprüfung:

Es gibt aber auch Errors, die man getrost ignorieren kann,

Erzähl mir mehr...
Nein, Errors schaut man sich an und fixt sie, damit die Fehler ausgemerzt werden.

[tugsi]

@thomas-braun sagte in Zigbee Neustart bei Firmwareupdatesüberprüfung:

Installier den admin nochmal drüber. Und bring deine nodejs-Installation auf Stand 16, du bist da offenbar noch mit was altem unterwegs.

Ich denke der fehlende admin kommt weil dies im Multihost ein Slave ist?
Nodejs auf 16, heißt aber auch, dass ich dann beim Master auf 16 gehen sollte oder? Gibt es denn dann auch so eine Reihenfolge wie beim JS-Controller, erst Master dann Slave?

Zum Thema beseitigen der Errors, habe gerade mal geschaut, das liegt daran, dass unter node_modules Pakete liegen, die nicht in der package.json gelistet sind.
Der Befehl

rm -rf node_modules

würde alle löschen und mit

npm install

die benötigten erneut installieren.
Kannst das bestätigen oder eher anders vorgehen (abgesehen von V16 updaten)?
Auf 16 mache ich nicht mehr heute, da brauche ich Ruhe und Zeit, wenn mal was nicht so rundläuft, also was für das Wochenende :-)

[Thomas Braun]

@tugsi sagte in Zigbee Neustart bei Firmwareupdatesüberprüfung:

Gibt es denn dann auch so eine Reihenfolge wie beim JS-Controller, erst Master dann Slave?

Da du die beiden Systeme eh währenddessen runterfährst: Kein Problem der Reihenfolge.

[Thomas Braun]

@tugsi sagte in Zigbee Neustart bei Firmwareupdatesüberprüfung:

dass unter node_modules Pakete liegen, die nicht in der package.json gelistet sind.

Das sollte eigentlich nicht der Fall sein. Zusätzliches Zeug ist i.d. R. unter dem javascript-Adapter zu finden.

[David G.]

Ich habe auch die 1.7.6 drauf.
Habe die Tage noch ein paar Firmwareupdates eingespielt.

├── iobroker.zigbee@1.7.6 (git+ssh://git@github.com/ioBroker/ioBroker.zigbee.git#6e5ff46b6464c71c20f8fe099c0600b3cca68c07)

[tugsi]

@thomas-braun sagte in Zigbee Neustart bei Firmwareupdatesüberprüfung:

Das sollte eigentlich nicht der Fall sein. Zusätzliches Zeug ist i.d. R. unter dem javascript-Adapter zu finden.

Ich hab mir das gerade mal angeschaut und ich habe einen Verdacht, dass ich damals wohl schlampig gearbeitet hatte. Kann mich nicht mehr so recht dran erinnern, aber ich hatte zuerst ioBroker auf den Pi, dann wurde das alles zu knapp da und bin umgezogen auf Docker als Master und den Pi als Slave, eventuell habe ich keine reine Neuinstallation da gemacht oder zum testen noch was anderes zusätzlich, dann als Slave eingebunden und alles lief und never change a running System ... so gelassen.
Ist ja auch an meinem Touchscreen dran und das damals einzurichten war auch alles nicht simpel...
Hab da Leichen im Keller :laughing:
Vieleicht wirklich mal ein guter Anlass alles mal auf den aktuellsten Stand zu ziehen und den Raspberry neu aufzusetzen. Muss nur gerade den Pi alles zusammensuchen wegen dem Monitor, manchmal ist einiges Try&Error, weil man nicht das passende im Netz findet und am Ende des Tages freust Dich und bist froh, aber machst keine Doku für später.... (Kenn ich von der Arbeit, bin SPS-Programmierer... und Doku ist das langweiligste was es gibt, aber man ärgert sich später immer wieder, dass man es nicht sofort getan hat)

[Thomas Braun]

@tugsi sagte in Zigbee Neustart bei Firmwareupdatesüberprüfung:

Muss nur gerade den Pi alles zusammensuchen wegen dem Monitor

Was für ein Monitor?
ssh und go...

[tugsi]

@thomas-braun sagte in Zigbee Neustart bei Firmwareupdatesüberprüfung:

ssh und go...

ssh ist kein Problem, das war irgendwas mit der Auflösung und der Config für X... wie gesagt, kein Hexenwerk, muss aber nochmal die Dinge zusammensuchen und wenn ich damit anfange, sollte es auch in einem Rutsch gemacht werden, ansonsten habe ich hier eine Frau die sich a) fragt, warum ich wieder so lange am Laptop sitze und b) warum ihr doch mittlerweile geliebter Screen nix anzeigt

Aber vielleicht kannst Du mir das beantworten, auch wenn der Thread hier gerade abdriftet.
Muss ich den Slave erstmal beim Master abmelden, bevor ich den dann neu aufsetze oder?

[Thomas Braun]

@tugsi sagte in Zigbee Neustart bei Firmwareupdatesüberprüfung:

das war irgendwas mit der Auflösung und der Config für X.

Was für ein X? Man lässt da kein X laufen.

[tugsi]

@thomas-braun sagte in Zigbee Neustart bei Firmwareupdatesüberprüfung:

Was für ein X? Man lässt da kein X laufen.

Das mag Deine Sichtweise sein.
Ich habe auf den Pi ein X laufen, weil das meinen Monitor als Visualisierung befeuert und da der zentral liegt, läuft darauf ein ioBroker im Slavemodus mit Zigbee und ZWave.
Mir wäre neu, dass man auf einem Pi mit ioBroker nichts anderes laufen lassen darf, zumal wie gesagt es ein Slavesystem ist. Mir erstellt sich nicht der Sinn, warum ich extra für meine Visualisierung einen extra Rechner und somit Stromfresser hinsetzen muss.

[arteck]

@tugsi @david-g

leute .. nur weil ihr die Version 1.7.6 drauf habt heisst es nicht das diese aktuell ist..
ich mach täglich ein update auf GIT der Version 1.7.6 ..

also GIT Version installieren JETZT und nochmal schauen..bitte

[tugsi]

@arteck Keep calm, ich habe das schon verstanden, ich komm doch selber aus der Programmierecke, auch wenn es Automatisierung ist, aber man macht nicht immer für kleine Zwischenschritte sofort eine Versionsänderung.
Ich hatte Deine Bitte für eine Neuinstallation über GIT befolgt und hatte ja das gleiche Problem, deswegen kam meine Nachfrage, ob es so richtig war mit der Installation...

Aber jetzt weiß ich ja, wo ich nachschauen muss, ob er es genommen hat, ich sehe ja Deine Versionsänderungen von herdsman und schaue bei Github welche Du in der package.json gepackt hast.
Gerade upgedatet und nachgeschaut, das aktuelle von Dir drauf:

cd /opt/iobroker/ && npm ls | grep zigbee
├─┬ iobroker.zigbee@1.7.6 (github:ioBroker/ioBroker.zigbee#4e4143cee5b8affa73b2b1e1ed6f9fb91201f078)
│ ├─┬ zigbee-herdsman@0.14.51
│ └─┬ zigbee-herdsman-converters@14.0.610
│   └── zigbee-herdsman@0.14.51 deduped

Aber Problem besteht immer noch:

2022-09-01 08:06:06.531 - info: zigbee.0 (8913) Failed to check if update available for '0x540f57fffe3f5cde' (No image available for imageType '5634')
2022-09-01 08:06:06.607 - info: zigbee.0 (8913) Failed to check if update available for '0x94deb8fffe4c0e07' (No image available for imageType '5634')
2022-09-01 08:06:34.439 - info: zigbee.0 (8913) Failed to check if update available for '0x14b457fffeca020d' (Device didn't respond to OTA request)
2022-09-01 08:06:34.446 - error: zigbee.0 (8913) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
2022-09-01 08:06:34.447 - error: zigbee.0 (8913) unhandled promise rejection: Timeout - 63764 - 1 - null - 25 - 1 after 30000ms
2022-09-01 08:06:34.449 - error: zigbee.0 (8913) Error: Timeout - 63764 - 1 - null - 25 - 1 after 30000ms
at Timeout._onTimeout (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/waitress.ts:64:35)
at listOnTimeout (internal/timers.js:557:17)
at processTimers (internal/timers.js:500:7)
2022-09-01 08:06:34.450 - error: zigbee.0 (8913) Timeout - 63764 - 1 - null - 25 - 1 after 30000ms
2022-09-01 08:06:34.470 - info: zigbee.0 (8913) cleaned everything up...
2022-09-01 08:06:34.819 - info: zigbee.0 (8913) Zigbee: disabling joining new devices.
2022-09-01 08:06:34.846 - info: zigbee.0 (8913) Failed to check if update available for '0x14b457fffe91707c' (Device didn't respond to OTA request)
2022-09-01 08:06:34.972 - info: zigbee.0 (8913) terminating
2022-09-01 08:06:34.975 - warn: zigbee.0 (8913) Terminated (UNCAUGHT_EXCEPTION): Without reason
2022-09-01 08:06:36.082 - error: host.raspberrypi Caught by controller[0]: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
2022-09-01 08:06:36.084 - error: host.raspberrypi Caught by controller[1]: Error: Timeout - 63764 - 1 - null - 25 - 1 after 30000ms
2022-09-01 08:06:36.091 - error: host.raspberrypi Caught by controller[1]: at Timeout._onTimeout (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/waitress.ts:64:35)
2022-09-01 08:06:36.093 - error: host.raspberrypi Caught by controller[1]: at listOnTimeout (internal/timers.js:557:17)
2022-09-01 08:06:36.093 - error: host.raspberrypi Caught by controller[1]: at processTimers (internal/timers.js:500:7)
2022-09-01 08:06:36.095 - error: host.raspberrypi instance system.adapter.zigbee.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
2022-09-01 08:06:36.096 - info: host.raspberrypi Restart adapter system.adapter.zigbee.0 because enabled

[Asgothian]

@tugsi Um dem weiter nachzugehen musst du heraus finden welches Gerät betroffen ist.

Dazu bitte die Geräte durch nutzen des Ein/Ausschalt Icons auf der Kachel deaktivieren bevor du den Firmware check machst. Deaktivierte Geräte werden im Firmwarecheck ignoriert.

Zur Nutzung musst du die Geräte im Nachgang natürlich wieder aktivieren.

A.

[tugsi]

@asgothian
Danke, ich habe den Übeltäter gefunden.
Bin hingegangen und habe erstmal alle OTA-fähigen Geräte deaktiviert und da lief er durch.
Dann bin ich hingegangen und habe jede Gerätegruppe nach und nach zugeschaltet und geschaut was passiert.
Der Absturz passiert immer, wenn der IKEA Styrbar-Schalter aktiv ist (https://www.zigbee2mqtt.io/devices/E2001_E2002.html), deaktiviere ich, dann läuft der Firmwarecheck ohne Probleme durch.
Ok, jetzt weiß ich das und kann den für den Fall deaktivieren, aber ist ja nicht Sinn.
Soll ich bei Github ein Issue dafür aufmachen?

[arteck]

@tugsi hast den mal gedrückt während der OTA prozess lief. also aufwecken.. ?

wenn ja und es immer noch knallt dann bitte ein issue aufmachen

[tugsi]

@arteck Ist egal, auch wenn ich in aufwecke vorher und auch während des Checks, hängt er sich auf.
Mir ist nur dabei aufgefallen, dass er den Check macht, da ich den Schalter während dessen mehrfach geschaltet habe und wohlmöglich wenn der Check eine Rückmeldung bekommt, erst dann crashed der Adapter.

Issue ist gemacht: https://github.com/ioBroker/ioBroker.zigbee/issues/1518

[tugsi]

Hab noch einen aktuelleren Styrbar (mit silbernen Deckel) ausprobiert, wenn ich den anmelde und OTA ausprobiere, funktioniert alles normal, er checked und sagt, dass es keine neue Firmware gibt (date code: 20200708
build: 1.0.024), aber der alte Styrbar hat dieselben Daten.
Also vermute ich, dass es an den Schalter selber liegt, dass der Adapter crashed.
Also wäre Interessant, ob andere mit dem älteren Modell (weißer Schalterdeckel), ebenso Probleme haben.