Tester für Zigbee Adapter 2.0.x gesucht

[arteck]

so für alle bei den die 2.0.3 Probleme verursacht... bitte die 2.0.4 installieren...

wenns läuft ERSTMAL auf der 2.0.3 bleiben... bis auf weiteres

[dimaiv]

@asgothian
Habe heute Nachmittag noch mal deine Testversion installiert mit ZHC 23.4.0 , hat wieder nicht funktioniert. Nach 2 Stunden mit 14 Geräten keine Funktion mehr... CPU Last über 100%...

[Asgothian]

@dimaiv Das ist seltsam - bei mir läuft sie stabil ohne Effekte. Du hast direkt von meinem Fork dem Branch 1.11 installiert ?

[dimaiv]

@asgothian sagte in Tester für Zigbee Adapter 2.0.x gesucht:

@dimaiv Das ist seltsam - bei mir läuft sie stabil ohne Effekte. Du hast direkt von meinem Fork dem Branch 1.11 installiert ?

Ja, direkt.

Jetzt läuft 2.0.4. überall über Nacht. Morgen werde ich deine Testversion noch mal wo anders testen.

[Asgothian]

@dimaiv Seltsam. Tu mir mal bitte einen gefallen:
Patch mal das shouldConfigure so das es

• ins Log schreibt wenn es aufgerufen wird
• immer direkt ein false zurück liefert, so das keine Konfiguration gestartet wird.

Und dann lass den Adapter nochmal laufen. Ich vermute das sich da irgend etwas aufschaukeln könnte. Ansonsten hab ich in diesem issue bei Koenkk nachgefragt, aber er steht auch auf dem Schlauch.

Ein anderer Test wäre folgender : Installier von diesem Branch: https://github.com/asgothian/ioBroker.zigbee/tarball/2.0.5ZHC21. Das ist der identische Code zum branch 1.11, nur mit der dependency auf ZHC21.38.0

A.

[dimaiv]

@asgothian
Die 2.0.5ZHC21 läuft seit 3 Stunden stabil an 2 Orten.

[Asgothian]

@dimaiv Danke. Lassen wir die mal länger laufen - und schauen wir mal ob Koenkk einen Vorschlag macht wo ich suchen kann

A.

[dimaiv]

@asgothian
Beim ZHC23.x könnte man schon nach 20 Minuten sehen wo die CPU Last hin geht...

[Asgothian]

@dimaiv An 2 Orten heisst auf 2 unterschiedlichen ioBrokern, sprich Du könntest eine davon zum Mitschreiben nutzen ? Dann würde ich gesondertes Logging einbauen und eine Doku machen wie du zhc austauschen kannst ohne neu zu installieren.

Sofern du sagst das könntest Du probieren, natürlich. nur.Bei mir bringt es nix, die ZHC23 läuft bei mir seit 2 Tagen ohne Auffälligkeiten

A.

[dimaiv]

@asgothian
Ja, ich würde gerne es so machen.

[Asgothian]

@dimaiv Ich brauch leider noch etwas für die logging version - musste mich heute um was anderes erst kümmern. Ich denke morgen kann ich 2 Versionen (identisch ausser Herdsman-converters) bereitstellen

A.

[Shadowhunter23]

@Asgothian
Heute hatte ich das wieder mit einer anderen Instanz ( Zigbee Instanz 2 ). Einige Jahre lief das ohne Probleme. Jetzt mit der 2.0.x ist zweimal doch schon oft...
Firmware neu Flaschen hilft aber ist nicht wirklich gut wenn auf einmal das Netz nicht mehr geht.

Im Einsatz ist immer Koordinator:
https://github.com/codm/cc2652p2-tcp-zigbee

@shadowhunter23 sagte in Tester für Zigbee Adapter 2.0.x gesucht:
@asgothian

Kann man zu dieser Meldung was sagen? War auch schon in der 2.0.2 so.

zigbee.3
2025-03-07 15:30:07.937	error	Failed to open the network: Error: --> 'SREQ: AF - dataRequestExt - {"dstaddrmode":2,"dstaddr":"0x000000000000fffd","destendpoint":242,"dstpanid":0,"srcendpoint":242,"clusterid":33,"transid":1,"options":0,"radius":30,"len":6,"data":{"type":"Buffer","data":[25,2,2,10,0,0]}}' failed with status '(0x11: BUFFER_FULL)' (expected '(0x00: SUCCESS)') at /opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:258:27 at processTicksAndRejections (node:internal/process/task_queues:95:5) at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:36:20) at ZStackAdapter.dataRequestExtended (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:1100:9) at /opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:746:13 at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:36:20) at ZStackAdapter.sendZclFrameToAll (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:744:16) at GreenPower.permitJoin (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/greenPower.ts:277:13) at Controller.permitJoin (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/controller.ts:317:13) at ZigbeeController.permitJoin (/opt/iobroker/node_modules/iobroker.zigbee/lib/zigbeecontroller.js:668:13)

[Asgothian]

@shadowhunter23 sagte in Tester für Zigbee Adapter 2.0.x gesucht:

Heute hatte ich das wieder mit einer anderen Instanz ( Zigbee Instanz 2 ). Einige Jahre lief das ohne Probleme. Jetzt mit der 2.0.x ist zweimal doch schon oft...
Firmware neu Flaschen hilft aber ist nicht wirklich gut wenn auf einmal das Netz nicht mehr geht.

Da kann ich wenig zu sagen - ich fürchte das da entweder der Koordinator ein Problem hat oder es so starke Störungen geht das der aus dem Tritt kommt.

Jedenfalls kommt die Meldung nicht aus dem Zigbee-Adapter sondern aus dem zigbee-herdsman. Da setzen wir schon die aktuelle Version ein.

A.

[dimaiv]

@shadowhunter23
Firmware Version ?
Stromversorgung beim Coordinator stabil ? Was für Netzteil?
Beim Firmware flaschen wird nicht unbedingt NVRAM mit gelöscht.
Ich würde dir empfehlen ein mal NVRAM zu löschen.
Wichtig vorher sauber Zigbee Adapter runterfahren.
Beim wiederstarten länger warten.

[Asgothian]

@dimaiv Ok.. ich hab 2 Versionen gemacht. Beide werden das Log gross werden lassen.

Alle Ausgaben die ich brauche sind Warnungen mit ZHC...

https://github.com/asgothian/ioBroker.zigbee/tarball/2.0.5ZHC21_EL - die Version die ohne Probleme läuft
https://github.com/asgothian/ioBroker.zigbee/tarball/2.0.5ZHC23EL - die Version mit ZHC23

Wobei auch die 23EL bei mir ohne Probleme läuft - leider

A.

[Shadowhunter23]

@dimaiv sagte in Tester für Zigbee Adapter 2.0.x gesucht:

Firmware Version ?

20240710

Stromversorgung beim Coordinator stabil ? Was für Netzteil?

Steckernetzteil 5V; 1A was ich zum Koordinator dazu gekauft habe.
Bestellt habe ich im April 2022.

Ich würde dir empfehlen ein mal NVRAM zu löschen.

Dazu gibt in der Weboberfläche vom Koordinator keine Möglichkeit.
Reicht es wenn diese Einstellungen beim flashen gesetzt sind ( erase, write, verify )?
https://github.com/codm/cc2652p2-tcp-zigbee/blob/master/img/codm-cc265p2-tcp-zigstargw-update.png

[dimaiv]

@shadowhunter23
Auf deinem Screenshot links unter NVRAM -> Erase.

[Neuschwansteini]

@asgothian

die aktuelle 2.0.4 laeuft bei mir sehr stabil, und ich habe keine offline-Devices seitdem mehr.. was mich wundert, da frueher immer mal das ein oder andere offline ging..

Koennte natuerlich auch sein, dass das Umfeld weniger Stoerungen funkt.. ist aber auffaellig, dass es seit dem update so ruhig ist..

[bommel_030]

@neuschwansteini @Asgothian
Ich bin aktuell mit der 2.0.4 unterwegs, da die 2.0.3 >36h versucht hat alle Geräte zu konfigurieren und damit das Log geflutet hat.
Jetzt habe ich 2 Lampen (1x IKEA und 1x HUE) die monatelang problemlos liefen, seit der 2.0.4 aber immer mal wieder als available = false gekennzeichnet werden.
Was die Lampen zum Glück scheinbar nicht wissen, die lassen sich tadellos weiterhin per ioBroker schalten....

[Asgothian]

@bommel_030 sagte in Tester für Zigbee Adapter 2.0.x gesucht:

seit der 2.0.4 aber immer mal wieder als available = false gekennzeichnet werden.
Was die Lampen zum Glück scheinbar nicht wissen, die lassen sich tadellos weiterhin per ioBroker schalten....

Das liegt daran das die Lampen den 'ping request' vom Adapter nicht beantworten. Deswegen meldet der Adapter 'ich kann das Gerät nicht erreichen' und setzt es auf offline.
Zum steuern muss die Lampe ja nur den Befehl empfangen.Und wenn sie darauf meldet 'habs gemacht', dann wird sie auch wieder als 'online' gekennzeichnet.

Da kann derAdapter wenig tun Wer nicht antwortet ist selber schuld

A.