SLZB-06 große Probleme mit IEEE Adresse und Netzwerk

Blueleader72 · 21. März 2025 um 17:12

Ich bin heute auf den SLZB-06 umgestiegen und es hat Anfang alles bestens geklappt.
Angebunden ist er über POE

Als ich später ein neues Gerät anlernen wollte, stellte ich fest, dass die IEEE Adresse nicht mehr die gleiche war die ich eingestellt hatte. Also IEEE neu geschrieben und neu gestartet.

Seit dem habe ich Probleme.
Die grüne LED am Coordinator leuchtet nicht mehr. Trotzdem sind Geräte teilweise erreichbar.
Wenn ich die Benutzer IEEE auslese bekomme ich fast bei jedem Klick eine von 3 IEEE Adressen angezeigt wovon eine die richtige ist.
Die anderen 2 sind nicht die Werksadresse.

Habe dann wie in der Anleitung beschrieben einen kompletten Shut down des Hauses gemacht.

Die User IEEE ist jetzt unknown, Geräte trotzdem teilweise ansprechbar. Andere Lampen blinken teilweise unregelmäßig.

Bin kurz davor das Teil in die Tonne zu schmeißen.

Core FW ist v2.7.1
Zigbee FW ist 20221226

Bin für jeden Tip dankbar!

Arbeite im Moment nur vom Handy aus bis mein PC wieder funktioniert.

manfred52 · 21. März 2025 um 18:15

HI, bei meinem Stick ist folgende Firmware drauf:
Zigbee: 20240710
Core: v2.8.2.dev3
Ich hatte heute einen andere versucht und die hat wohl einen Fegler gehabt. Wenn Du direkt in dem Stick eingeloggt bist kannst Du jederzeit eine andere Firmware installieren. Eventuell mal den Stick dann nach dem Update neu booten und überprüfen was für ein Pegel bei mqtt angezeigt wird, der ist nämlich sehr wichtig damit alles funktioniert. Ich hoffe ich konnte ein wenig helfen, bei mir läuft der ohne Probleme und bei meinem sohn auch.

Blueleader72 · 21. März 2025 um 18:25

Ich hatte diese Versionen nicht installiert da es “DEV” Versionen sind.

Habe jetzt aber beides upgedatet.
Ich finde den Pegel allerdings nicht. Wo genau sollte der sein?

Das Problem mit der IEEE Adresse besteht nach wie vor.

Habe langsam die Vermutung das Teil ist defekt.

manfred52 · 21. März 2025 um 18:45

OK, mit dem Pegel das war wohl mein Fehler. Ich hatte das gestern bei einer Installation das der Pegel von dem Gerät was darüber connected war schlecht war. Den Stick selber hab ich nichts gefunden. Die IEEE Adresse hab ich nur die genommen die im Stick drin ist, da ich bei der Umstellung auf Nummer sicher gehen wollte und alles neu angelernt hab. Ich würde erst mal die Firmware flashen und dann in der Nähe einen Sensor oder irgendwetwas versuchen zu connecten. Sollte ja auch bei HA in den Geräten auftauchen, sonst ist wirklich der Stick defekt.

Blueleader72 · 22. März 2025 um 08:43

Zunächst mal Danke für Deine Hilfe!

Das interessante ist, dass die Zigbee-Geräte großteils erreichbar sind, allerdings mit teilweise extremen Lags.
Laut Zigbee2MQTT in HA passt die IEEE vom Stick.
Dürfte dann wahrscheinlich ein Fehler vom WEB-Interface sein?

Allerdings habe ich haufenweise Fehler im Z2M Protokoll:

[19:28:07] INFO: Preparing to start...
[19:28:07] INFO: Socat not enabled
[19:28:08] INFO: Starting Zigbee2MQTT...
Starting Zigbee2MQTT without watchdog.
[2025-03-21 19:28:12] error: 	zh:zstack:znp: Error while parsing to ZpiObject 'TypeError: Cannot read properties of undefined (reading 'execute')'
[2025-03-21 19:28:12] error: 	zh:zstack:znp: Error while parsing to ZpiObject 'TypeError: Cannot read properties of undefined (reading 'execute')'
[2025-03-21 19:28:12] error: 	zh:zstack:znp: Error while parsing to ZpiObject 'TypeError: Cannot read properties of undefined (reading 'execute')'
[2025-03-21 19:28:12] error: 	zh:zstack:znp: Error while parsing to ZpiObject 'TypeError: Cannot read properties of undefined (reading 'execute')'
[2025-03-21 19:28:12] error: 	zh:zstack:znp: Error while parsing to ZpiObject 'TypeError: Cannot read properties of undefined (reading 'execute')'
[2025-03-21 19:28:27] error: 	z2m: Failed to configure 'PC-Monitore ', attempt 1 (Error: ZCL command 0xa4c138c9924b0982/1 haElectricalMeasurement.configReport([{"attribute":"rmsVoltage","minimumReportInterval":5,"maximumReportInterval":3600,"reportableChange":5}], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')
    at Endpoint.checkStatus (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:349:28)
    at Endpoint.zclCommand (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:954:26)
    at processTicksAndRejections (node:internal/process/task_queues:105:5)
    at Endpoint.configureReporting (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:686:9)
    at Object.rmsVoltage (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/lib/reporting.ts:219:5)
    at configure (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/devices/tuya.ts:6189:13)
    at Object.configure (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/index.ts:357:21)
    at Configure.configure (/app/lib/extension/configure.ts:124:13)
    at EventEmitter.wrappedCallback (/app/lib/eventBus.ts:204:17))
[2025-03-21 19:28:27] error: 	z2m: Failed to configure 'Plug WZ', attempt 1 (Error: ZCL command 0xa4c1386ebb97524b/1 haElectricalMeasurement.configReport([{"attribute":"rmsVoltage","minimumReportInterval":5,"maximumReportInterval":3600,"reportableChange":5}], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')
    at Endpoint.checkStatus (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:349:28)
    at Endpoint.zclCommand (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:954:26)
    at processTicksAndRejections (node:internal/process/task_queues:105:5)
    at Endpoint.configureReporting (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:686:9)
    at Object.rmsVoltage (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/lib/reporting.ts:219:5)
    at configure (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/devices/tuya.ts:6189:13)
    at Object.configure (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/index.ts:357:21)
    at Configure.configure (/app/lib/extension/configure.ts:124:13)
    at EventEmitter.wrappedCallback (/app/lib/eventBus.ts:204:17))
[2025-03-21 19:28:28] error: 	z2m: Failed to configure 'PC-Monitore ', attempt 2 (Error: ZCL command 0xa4c138c9924b0982/1 haElectricalMeasurement.configReport([{"attribute":"rmsVoltage","minimumReportInterval":5,"maximumReportInterval":3600,"reportableChange":5}], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')
    at Endpoint.checkStatus (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:349:28)
    at Endpoint.zclCommand (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:954:26)
    at processTicksAndRejections (node:internal/process/task_queues:105:5)
    at Endpoint.configureReporting (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:686:9)
    at Object.rmsVoltage (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/lib/reporting.ts:219:5)
    at configure (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/devices/tuya.ts:6189:13)
    at Object.configure (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/index.ts:357:21)
    at Configure.configure (/app/lib/extension/configure.ts:124:13)
    at EventEmitter.wrappedCallback (/app/lib/eventBus.ts:204:17))
[2025-03-21 19:28:32] error: 	z2m: Failed to configure 'PC-Monitore ', attempt 3 (Error: ZCL command 0xa4c138c9924b0982/1 haElectricalMeasurement.configReport([{"attribute":"rmsVoltage","minimumReportInterval":5,"maximumReportInterval":3600,"reportableChange":5}], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')
    at Endpoint.checkStatus (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:349:28)
    at Endpoint.zclCommand (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:954:26)
    at processTicksAndRejections (node:internal/process/task_queues:105:5)
    at Endpoint.configureReporting (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:686:9)
    at Object.rmsVoltage (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/lib/reporting.ts:219:5)
    at configure (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/devices/tuya.ts:6189:13)
    at Object.configure (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/index.ts:357:21)
    at Configure.configure (/app/lib/extension/configure.ts:124:13)
    at EventEmitter.wrappedCallback (/app/lib/eventBus.ts:204:17))
[2025-03-21 19:28:41] error: 	z2m: Failed to configure 'Plug WZ', attempt 2 (Error: Bind 0xa4c1386ebb97524b/1 seMetering from '0x00212effff096cee/1' failed (AREQ - ZDO - bindRsp after 10000ms)
    at Object.start (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/utils/waitress.ts:67:23)
    at func (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:423:47)
    at processTicksAndRejections (node:internal/process/task_queues:105:5)
    at Queue.execute (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/utils/queue.ts:36:20)
    at ZStackAdapter.sendZdoInternal (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:428:43)
    at ZStackAdapter.sendZdo (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:305:16)
    at Endpoint.bind (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:562:30)
    at Object.bind (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/lib/reporting.ts:42:9)
    at configure (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/devices/tuya.ts:6188:13)
    at Object.configure (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/index.ts:357:21))
[2025-03-21 19:28:47] error: 	z2m: Failed to configure 'Plug WZ', attempt 3 (Error: ZCL command 0xa4c1386ebb97524b/1 haElectricalMeasurement.configReport([{"attribute":"rmsVoltage","minimumReportInterval":5,"maximumReportInterval":3600,"reportableChange":5}], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')
    at Endpoint.checkStatus (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:349:28)
    at Endpoint.zclCommand (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:954:26)
    at processTicksAndRejections (node:internal/process/task_queues:105:5)
    at Endpoint.configureReporting (/app/node_modules/.pnpm/zigbee-herdsman@3.2.7/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:686:9)
    at Object.rmsVoltage (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/lib/reporting.ts:219:5)
    at configure (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/devices/tuya.ts:6189:13)
    at Object.configure (/app/node_modules/.pnpm/zigbee-herdsman-converters@23.2.0/node_modules/zigbee-herdsman-converters/src/index.ts:357:21)
    at Configure.configure (/app/lib/extension/configure.ts:124:13)
    at EventEmitter.wrappedCallback (/app/lib/eventBus.ts:204:17))
[2025-03-21 19:30:03] error: 	zh:controller:device: Handling of poll check-in from 0x0015bc00310221a4 failed (ZCL command 0x0015bc00310221a4/35 genPollCtrl.checkinRsp({"startFastPolling":false,"fastPollTimeout":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false,"sendPolicy":"immediate"}) failed (Timeout - 47159 - 35 - 53 - 32 - 11 after 10000ms))
[2025-03-21 19:30:52] error: 	zh:controller:device: Read response to 0xa4c138bb637ca9f0 failed (ZCL command 0xa4c138bb637ca9f0/1 genTime.readRsp({"localTime":795900635}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":1,"srcEndpoint":1,"reservedBits":0,"transactionSequenceNumber":41,"writeUndiv":false}) failed (SRSP - AF - dataRequest after 6000ms))
[2025-03-21 19:31:04] error: 	zh:controller:device: Handling of poll check-in from 0x0015bc003101e700 failed (ZCL command 0x0015bc003101e700/35 genPollCtrl.checkinRsp({"startFastPolling":false,"fastPollTimeout":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false,"sendPolicy":"immediate"}) failed (Timeout - 48094 - 35 - 70 - 32 - 11 after 10000ms))
[2025-03-21 19:33:48] error: 	zh:controller:device: Handling of poll check-in from 0x0015bc003101e700 failed (ZCL command 0x0015bc003101e700/35 genPollCtrl.checkinRsp({"startFastPolling":false,"fastPollTimeout":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false,"sendPolicy":"immediate"}) failed (Timeout - 48094 - 35 - 132 - 32 - 11 after 10000ms))
[2025-03-21 19:41:46] error: 	zh:controller:device: Handling of poll check-in from 0x0015bc00310221a4 failed (ZCL command 0x0015bc00310221a4/35 genPollCtrl.checkinRsp({"startFastPolling":false,"fastPollTimeout":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false,"sendPolicy":"immediate"}) failed (Timeout - 47159 - 35 - 50 - 32 - 11 after 10000ms))

Wollte jetzt testweise mal das Gerät “Plug WZ” neu anlernen was damit endete, das das Gerät jetzt auss Z2M verschwunden ist.

Edit:
Es lässt sich kein Gerät anlernen. Nicht mal eines, das noch nie angelernt war.
Dafür sind jetzt die Fehlermeldungen im Protokoll fast alle weg und die grüne LED am Coordinator leuchtet jetzt.

Edit 2:
Kann es sein, dass der SLZB-06 Probleme mit der Anzahl der Geräte hat?
Der Conbee II hatte jedenfalls keine Probleme.

Derzeit siht das Mesh so aus:
Router: 114
Endgerät: 79

Nachdem das Netzwerk gestern noch Großteils ging, ist es heute Tot.

Das Protokoll liefert für alle Geräte den gleichen Fehler:

[2025-03-22 09:38:34] error: 	z2m: Publish 'set' 'state' to 'OG Vorratskammer Deckenleuchte' failed: 'Error: ZCL command 0x00158d0002cbbdb7/1 genOnOff.off({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Timeout - 53738 - 1 - 8 - 6 - 11 after 10000ms)'

Thermometer liefern aber aktuelle Werte.
Neustart aller System hat mal nichts gebracht.

by HarryP: Zusammenführung Doppelpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)

Jim_OS · 22. März 2025 um 11:51

Nö das sollte eigentlich kein Problem sein.

Auch wenn ich noch nie einen Wechsel von Conbee auf SLZB-06 gemacht habe, aber was ich mich frage: Warum hast Du da mit irgendwelchen IEEE Adressen “herumhantiert” und bei dem SLZB-06 (versucht) irgendwelche anderen IEEE zu nutzen? Ja ich weiß das bei der Z2M Doku steht:

When migrating from one stick to another it is important that the new stick uses the same ieee address as the old stick. Some devices lookup the coordinator by its ieee address, this fails when the ieee address of the coordinator changes.

Aber in der Z2M steht auch das Du, wenn Du einen Wechsel zwischen Dongle mit unterschiedlichen Chipsätzen machst, alle Zigbee Geräte eh wieder neu anlernen musst. D.h. mal eben beim SLZB-06 nur die alte IEEE Adresse eintragen und schon funktioniert Z2M wie bisher, funktioniert eh nicht. Die alte IEEE Adresse hätte Dir nur etwas gebracht wenn Du z.B. von einem Sonoff Dongle-P - also mit CC2652P - zu dem SLZB-06 - ebenfall mit CC2652P - gewechselt hättest.

Was Da bei Dir jetzt alles wo und wie “verbogen” ist kann ich Dir auch nicht sagen, aber bei den ganz unterschiedlichen Problemen die da jetzt bei Dir auftauchen und weil Du - wie schon gesagt - eh alle Zigbee Geräte neu anlernen müsstest, würde es jetzt vermutlich Sinn machen mit Z2M noch einmal kompl. neu zu beginnen.

Anm.: Ich benutze zwar auch einen SLZB-06 und habe damals den Wechsel darauf von einem Sonoff Dongle-P gemacht, aber von Conbee und Conbee —> SLZB-06, habe ich keine Ahnung.

Edit: Deinen weiteren, neuen Beitrag zu dem Thema habe ich jetzt erst gesehen/-lesen.

VG JIm

Blueleader72 · 23. März 2025 um 09:10

Das wurde mir so von Leuten gesagt, die ebenfalls von einem Conbee II umgestiegen sind. Und auch Simon sagt es in seinem Video.

Leider hat das neu Anlernen nicht den gewünschten Erfolg.
Habe jetzt 168 Geräte neu angelernt und es ist die gleiche Problematik wie davor.
Außerdem merke ich dass ab ca 150 Geräten das Anlernen nur noch sehr schwierig durchzuführen ist da man mehrmals probieren muss damit es überhaupt startet.
Aber auch wenn ein Gerät erfolgreich angelernt wurde heißt es nicht dass es funktioniert.

Ich komme leider immer mehr zu der Erkenntnis, dass der SLZB-06 für mich eine große Fehlanschaffung war.
Der alte Conbee II hat das alles besser gemanaged.

Vielleicht hätte ich besser zum Nachfolger Conbee III wechseln sollen.

manfred52 · 23. März 2025 um 09:24

Ich nochmal. Bei dem Umstieg, ich bin vom Sonoff Dongel umgestiegen und als zweites war noch der SkyConnect in Betrieb. Das war alles ein wenig unübersichtlich, deshalb bin ich auf den SLZB-06 umgestiegen. Mit den IEEE Adressen hab ich einfach nur die vom Werk eingestellte gelassen und die Geräte neu angelernt. Das ging relativ Problemlos, manche Geräte müssen erst komplett resettet werden, was bei einigen wie Aqara nicht so einfach ist. Da muss man so etwa 15-20 Sekunden den Paring - Button drücken dann sind die komplett resettet. Für mich gibt es keine bessere Lösung als den SLZB-06 da man den dezentral platzieren kann und das ist in einem älteren Haus mit dicken Wänden wichtig. Wenn dann noch 1 oder 2 Repeater dazukommen funktioniert das richtig gut.

Jim_OS · 23. März 2025 um 10:35

Moin

Hm ok und die Leute hatten dann, bei dem von Dir beschriebenen Ablauf, keine Probleme? Irgendwelche Videos schaue ich eigentlich gar nicht und somit weiß ich nicht was in irgendwelchen Video dazu gesagt und gezeigt wird. Ich kann mich aber auch nicht daran erinnern mal über ein Video “gestolpert” zu sein in dem es um eine Migration von Conbee zu SLZB-06 ging. Aber wie gesagt Videos sind nicht so mein Ding.

M.W. wäre der von Dir geschilderte Ablauf mit dem ändern der IEEE in dem Fall nur in Verbindung mit einem vorher genutzten Dongel mit CC26xx Chipt korrekt. Wobei dann da bei Deinem Ablauf auch das Thema Z2M Backup wohl noch fehlt.

Wenn Du von einem anderen Chip aus - also z.B. von einem Conbee Dongle der ja vermutlich einen anderen Chip nutzt - zu dem SLZB-06 wechselst und dann einfach bei dem SLZB-06 die alte IEEE des Combee einträgst, dann scheint Z2M, bzw. das Zigbee Mesh, zwar erst noch zu funktionieren, weil Z2M halt “denkt” das nur der Dongle mit einem CC26xx Chip gegen einen anderen Dongle mit CC26xx Chip getauscht wurde und ansonsten alles gleich geblieben ist, aber spätestens wenn es dann um das anlernen von Geräten geht ist Schicht im Schacht, weil die kompl. Z2M Konfiguration auf den alten Dongle (Conbee) ausgelegt ist und Z2M z.B. ganz andere Treiber (deconz) statt z.B. zstack wie für den CC26xx Chip nutzt. D.h. das kann so dann gar nicht funktionieren.

Aber wie schon gesagt habe ich keine Ahnung von Conbee und den möglichen Migrationswegen zu einem SLZB-06 mit Z2M. Wenn das andere User so gemacht und Dir das so gesagt haben und das so auch in irgendwelchen Videos gezeigt wird, dann scheint es da ja ggf. irgendeine Möglichkeit nur per IEEE Übernahme zu geben.

VG JIm

Blueleader72 · 23. März 2025 um 11:00

Nur leider gibt es trotz neuem Anlernen die gleichen Probleme

Oder kann man da auch noch was falsch machen?

Jim_OS · 23. März 2025 um 11:46

Etwas falsch machen eigentlich nicht, aber aufgrund Deiner aktuell geschilderten “Anlernprobleme” und den verschiedenen Dingen die Du vorher bei den Versuchen mit der IEEE gemacht hast, hängen einzelne Geräte jetzt vermutlich noch in dem alten, aber jetzt nicht mehr existierenden Zigbee Mesh fest. Ich vermute, eben weil Du ja nur die IEEE Adresse übertragen hast und es dann z.B. und u.a. zu dem Problem kam das dann irgendwelche verschiedene IEEE Adressen aufgetaucht sind, sodass jetzt einzelne Zigbee Geräte erst noch extra resettet werden müssen. Aber das hängt halt auch davon ab was vorher wo und wie gemacht wurde, oder eben auch nicht.

Mal eine Beispiel das jetzt nicht unbedingt etwas mit der Migration von Donglen zu tun hat. Wenn man ein Zigbee Gerät bei Z2M z.B. von einer Z2M Instanz zu einer anderen Z2M Instanz umziehen wollte, dann sollte man das Gerät erst bei der ersten Z2M Instanz löschen (nicht das löschen erzwingen auswählen), denn durch das normale löschen wird das Zigbee Gerät dann eigenlich auch noch resettet und die alte Konfiguration für irgendeine vorherigen Zigbee Installation (incl. IEEE) ist dann auch weg. D.h. entfernt man das Zigbee Gerät vorher nicht aus der einen Zigbee Instanz sind evtl. Probleme vorprogrammiert.

Was jetzt bei Dir genau das Problem ist, oder die Probleme sind, kann ich Dir leider auch nicht sagen. Auch kann ich Dir keinen Ratschlag geben bzw. Vorschlag machen wie Du jetzt am besten weiter vorgehst. Was eben auch daran liegt das ich keinen Ahnung von Conbee und natürlich auch nicht von Deinem bisherigen Zigbee Mesh habe.

Was das Thema max. Anzahl von Zigbee Geräten berifft siehe z.B. hier:

github.com

Koenkk/Z-Stack-firmware/blob/4e888d3310eaf24c19699b00a29e24d512e49e8c/coordinator/README.md#overiew

# Z-Stack coordinator firmwares
This directory contains various Z-Stack coordinator firmwares.

## Overiew
<table>
  <tr>
    <td><b>Z-Stack</b></td>
    <td><b>Device</b></td>
    <td><b>Zigbee</b></td>
    <td><b>Direct children</b></td>
    <td><b>Routes</b></td>
    <td><b>Notes</b></td>
  </tr>
  <tr>
    <td rowspan="2">Z-Stack_Home_1.2 (default)</td>
    <td>CC2531</td>
    <td>1.2 HA</td>
    <td>20</td>
    <td>30/0</td>
    <td></td>

This file has been truncated. show original

VG Jim

Blueleader72 · 23. März 2025 um 12:11

Danke Dir mal für Deine ausführlichen Antworten!

Wenn ich das richtig verstehe, dann war das also komplett sinnlos alles neu anzulernen da ich die Geräte nicht einzeln gelöscht habe sondern einfach das ganze Verzeichnis am HA-Server?

Aber es muss ja trotzdem möglich sein die Geräte sauber neu anzulernen.
Was ist wenn mir die Installation abschmiert? Dann hab ich ja auch keine Oberfläche mehr um die Geräte zu löschen.

Ich mach mir gerne die Arbeit nochmal alles anzulernen aber dazu müsste ich wissen was genau ich machen muss um das Ganze sauber zu machen.
Ich wusste eigentlich nicht, dass die Zigbeegeräte selbst beim erneuten anlernen alte Informationen speichern.

manfred52 · 23. März 2025 um 12:20

Da gibt es im Verzeichnis zigbee2mqtt eine Backupdatei die macht Probleme, aber das wurde in dem Video was Du erwähnt hast auch erklärt. Ich hab das bei meiner Migration auch gelöscht und dann neu angelernt.

Jim_OS · 23. März 2025 um 12:43

Nein so hatte ich das eigentlich nicht geschrieben und auch nicht gemeint. Beim neu anlernen werden keine alte Informationen gespeichert, sondern ggf. abgerufen. Weil diese entweder noch auf dem Zigbee Gerät gespeichert sind, oder irgendwie von Z2M oder dem Dongle geliefert werden. Die Zigbee Mesh Informationen werden halt nicht nur bei Z2M oder dem Dongle gespeichert, sondern auch noch bei/in jedem Zigbee Gerät. D.h. jedes Zigbee Gerät “kennt” quasi den Mesh Aufbau, weiß welche Routen es gibt und welche es davon benutzen kann, oder schon benutzt hat usw. Wenn man dann das Zigbee Mesh manuell “umstrickt” - z.B. durch einen Dongle-Wechsel - und die vorhandenen Daten aus dem Zigbee Gerät nicht gelöscht hat, kann es eben zu unterschiedlichen Problemen kommen. Z.B. - was Du ja u.a. auch erwähnt hast - das sich ein Zigbee Gerät nicht (mehr) anlernen lässt.

Aber das sind jetzt alles eher grundlegende Dinge, die Dir jetzt bei Deinen Problemen auch nicht wirklich helfen. Wie schon gesagt habe ich leider auch keinen Ratschlag für Dich wie Du jetzt in Deiner Situation am besten weiter vorgehst.

Ich an Deiner Stelle würde jetzt (zwangsweise) vermutlich noch einmal kompl. bei Null beginnen. D.h. Z2M incl. Z2M Ordner kompl. bei HA löschen. Im Anschluss den HA Host kompl. neu booten. Auch den SLZB-06 würde ich sicherheitshalber mal resetten. Dann Z2M neu installieren und dann würde ich damit beginnen erst einmal die wichtigsten Zigbee Geräte neu anzulernen, beginnend mit den Routern. Geräte die beim anlernen ggf. herumzicken würde ich erst einmal außen vor lassen. Während dieses Anlernprozesses würde ich zwischendurch auch immer mal wieder eine Pause einlegen und z.B. HA neu starten, oder sogar auch den HA Host neu booten. Danach würde ich immer erst einmal schauen wie das bis dahin aufgebaute Zigbee Mesh sich verhält und ob es hoffentlich auch problemlos funktioniert. So würde ich mich dann Schritt für Schritt weiter vorarbeiten und mich dann erst am Ende mit den Zigbee Geräten befassen die ggf. herumzicken.

Ja das ist total mühsam und zeitaufwändig, aber so würde ich halt vorgehen. Ob so eine Vorgehensweise für Dich überhaupt irgendwie in Frage kommt, eben weil dann alles was Du bisher für und mit Zigbee gemacht hast tot und weg ist, musst Du natürlich selber beurteilen und entscheiden und eine Garantie das es dann im Anschluss keinerlei Probleme mehr gibt gibt es natürlich auch nicht.

Für diesen Fall haben eigentlich alle Zigbee Geräte noch die Möglichkeit ein Reset manuell auszulösen

PS: Das Du langsam ziemlich frustriert sein dürftest ist auch klar, sprich ging mir an Deiner Stelle dann wohl auch so.

Edit: Therotisch denkbar wäre natürlich auch noch ein altes HA Backup einzuspielen und dann erst wieder den Conbee Dongle zu benutzen, aber ich befürchte das das jetzt auch nichts mehr bringt, weil jetzt durch die bisher versuchten und durchgeführten Änderungen bei Z2M und den Zigbee Geräten, ein irgendwie per HA Restore rückgängig machen auch nicht mehr möglich ist. D.h. nach einem HA Restore würden Dich mit Z2M und dann wieder dem Conbee Dongle, ähnliche Probleme bei den Zigbee Geräten und dem Mesh erwarten.

Edit 2: Der hier unter Punkt 2 beschiebene Punkt war mir z.B. so auch nicht bekannt, bzw. habe ich das damals - als ich von dem Sonoff Dongle-P (CC26xx Chip) zu dem SLZB-06 (ebenfalls CC26xx Chip) gewechselt habe - so glaube ich auch nicht gemacht.

Aber auch die Schritte 1 bis 4 und zwar in der Reihenfolge, spielen vermutlich/halt auch eine Rolle was das Verhalten der Zigbee Geräte bei dem Dongle Wechsel betrifft.

VG Jim

Blueleader72 · 23. März 2025 um 13:38

Jim_OS:

Ich an Deiner Stelle würde jetzt (zwangsweise) vermutlich noch einmal kompl. bei Null beginnen. D.h. Z2M incl. Z2M Ordner kompl. bei HA löschen. Im Anschluss den HA Host kompl. neu booten. Auch den SLZB-06 würde ich sicherheitshalber mal resetten. Dann Z2M neu installieren und dann würde ich damit beginnen erst einmal die wichtigsten Zigbee Geräte neu anzulernen, beginnend mit den Routern. Geräte die beim anlernen ggf. herumzicken würde ich erst einmal außen vor lassen. Während dieses Anlernprozesses würde ich zwischendurch auch immer mal wieder eine Pause einlegen und z.B. HA neu starten, oder sogar auch den HA Host neu booten. Danach würde ich immer erst einmal schauen wie das bis dahin aufgebaute Zigbee Mesh sich verhält und ob es hoffentlich auch problemlos funktioniert. So würde ich mich dann Schritt für Schritt weiter vorarbeiten und mich dann erst am Ende mit den Zigbee Geräten befassen die ggf. herumzicken.

Ja das ist total mühsam und zeitaufwändig, aber so würde ich halt vorgehen. Ob so eine Vorgehensweise für Dich überhaupt irgendwie in Frage kommt, eben weil dann alles was Du bisher für und mit Zigbee gemacht hast tot und weg ist, musst Du natürlich selber beurteilen und entscheiden und eine Garantie das es dann im Anschluss keinerlei Probleme mehr gibt gibt es natürlich auch nicht.

Das ist, fast, genau das was ich gestern gemacht habe.

Coordinator zurückgesetzt
Alle Dateien aus dem config\zigbee2mqtt\ Ordner gelöscht
HA neu gestartet (Z2M war komplett leer)
Erst alle Steckdosen und Aktoren radial angelernt damit das Grundmesh steht
Lampen angelernt
Endgeräte angelernt
Dabei gab es aber schon teilweise Probleme dass ich Geräte mehrfach anlernen musste bzw. dass Geräte plötzlich verschwunden waren obwohl ich sie definitiv erfolgreich angelernt hatte.

Ausserdem gab es immer wieder Meldungen die ich beim alten Coordinator so nicht gesehen hätte.
Das löst dann auch kein gutes Gefühl aus wenn das schon beim Anlernen so kommt.

Ein paar konnte ich am Handy erfassen:
Das kam öfter, aber da es nicht rot ist sollte es nicht all zu tragisch sein denke ich.

Auch das kam ein paar mal, ließ sich aber immer durch erneutes Anlernen lösen.

…

Manch mal bekam ich auch eine so lange Fehlermeldung dass ich sie gar nicht komplett erfassen konnte.
Aber auch diese Geräte ließen sich nach dem Löschen irgend wann anlernen.

Und im späteren Verlauf begannen dann schon erfolgreich angelernte Geräte Meldungen nach diesem Schema zu erzeugen:

Viele Dinge funktionieren zwar aber Schalter und Leuchten sind teilweise unbrauchbar (lange Reaktion, keine Reaktion)
Geräte lassen sich nicht anlernen, nicht mal am Coordinator.
Manche lassen sich plötzlich anlernen die es gestern noch nicht taten.
Ich habe fast nicht geschlafen und würde am liebsten jedes einzelne Gerät mit dem Vorschlaghammer ablernen

Nein aber im Ernst, wie soll ich zu dem Netzwerk vertrauen aufbauen?

Jim_OS · 23. März 2025 um 14:16

Das es beim anlernen ggf. Probleme geben kann, kann aber auch noch andere Gründe haben. Mal abgesehen davon das es immer mal wieder irgendwelche “zickigen” Geräte gibt die ggf. nur am Coordinator selber angelernt werden können, oder die sich z.B. weigern eine einmal bestehende Route zu verlassen, auch wenn bei der der LQI-Wert inzwischen ggf. total schlecht ist usw., spielen in Deinem Fall eben ggf. auch noch irgendwelche alten Konfigurationen bei/in den Zigbee Geräten eine Rolle.

Auch ist es ja so das ein Zigbee Mesh nicht direkt nach dem anlernen von Geräten perfekt steht und funktioniert, sondern das Mesh muss sich erst einmal selbstständig aufbauen und optimieren und das kann und sollte man auch nicht versuchen großartig zu beeinflussen. D.h. gerade wenn man - so wie Du jetzt - sehr viele Zigbee Gerät neu bei dem Mesh anlernt, kann das gut und gerne Stunden oder sogar Tage dauern bis sich alle Zigbee Geräte in dem Mesh ihre Routen gesucht und aufgebaut haben und ein Gerät das sich ggf. noch problemlos anlernen lies macht ggf. am nächsten Tag irgendwelche Zicken. Eben weil sich zwischenzeitlich irgendwelche Routen geändert haben. D.h. rund 200 Zigbee Geräte wie bei Dir wieder neu anlernen zu müssen ist keine Sache von ein paar Stunden, sondern eher von ein paar Tagen und zwischendurch kann es immer mal wieder Rückschläge geben, in der Form das Z2M neue Fehler ausspuckt.

Ich musste z.B. vor einer Weile und weil ich hier für einen User etwas testen wollte, meine Zigbee Geräte auch alle neu anlernen. Auch wenn es bei mir nur um rund 40 Zigbee Geräte geht. Ich hatte den Fehler gemacht bei meiner HA + Z2M Testinstallation mal den alten Sonoff Dongle mit seiner alten Konfiguration einzubinden, ohne daran zu denken das das auch Auswirkungen auf das bestehende Z2M Mesh per SLZB-06 und die Zigbee Geräte haben könnte. Auch da war das Ende vom Lied das keine der beiden Z2M Installationen noch korrekt war und funktioniert hat und es ein heilloses Durcheinander gab. Auch da musste ich mich, obwohl ich bei meinem Produktiv-HA-System dann am Ende ein Vollbackup eingespielt hatte um die Probleme wieder in den Griff zu bekommen, im Anschluss noch mit allen möglichen Problemen - incl. dem scheinbar nicht anlernen können von Geräten - herumschlagen. Der “Spaß” hat mich dann auch rund einen 1/2 Tag gekostet.

Klar das Du jetzt auch irgendwie unter Zeitdruck bist und das Vertrauen zu dem Zigbee Mesh verlierst, aber wie gesagt braucht das alles leider viel Zeit und geht auch nur Step bei Step. Auch hast Du jetzt in der Situation ja eh keine Alternative mehr, außer den erwähnten Vorschlaghammer.

VG Jim

Blueleader72 · 23. März 2025 um 14:54

Danke!
Das beruhigt mich.

Ich hatte gerade beim Pausieren im Garten einen ähnlichen Gedankengang.
Mein Netzwerk ist über Monate hinweg gewachsen. Wahrscheinlich ist der Coordinator einfach bei der Menge in kurzer Zeit überfordert.

Und Deine Erklärung deckt sich genau mit der Tatsache, dass Geräte sich später anlernen lassen obwohl sie das davor verweigert hatten.

Also werde ich mal abwarten und schauen wie sich das entwickelt.

Habe noch einen größeren Schwachpunkt entfernt, nämlich die WLAN-AP der Shelly die teilweise noch aktiv waren.

Jetzt sieht mein Kanalprofil auch gleich viel besser aus.

Das sollte auch etwas helfen denke ich.

Jim_OS · 23. März 2025 um 15:32

Auch das ist möglich. Der von Dir beschriebene Ablauf

ist vom Ablauf her auch richtig und mach aus meiner Sicht so auch Sinn, aber jedes Gerät kennt beim anlernen ja auch erst nur eine einzige Route, nämlich die über die es angelernt wurde. Erst danach “erfährt” es wie der Mesh Aufbau aussieht und sucht sich ggf. auch noch andere Routen zusammen. Wenn dann zwischenzeitlich aber schon wieder x neue, aktive Zigbee Geräte angelernt werden oder wurden, ergeben sich ja auch schon wieder y neue Routen und all das muss irgendwie aufeinander abgestimmt werden. Das kostet halt Zeit und leider kann man als User nicht erkennen was jetzt im Hintergrund im Mesh alles gerade so passiert. Auch die Z2M Karte (hier mal meine aktuelle nur mit den Routern)
Z2M_Karte
hilft da leider nicht weiter weil:
a) Das nur eine Momentaufnahme ist.
b) Dort Dinge angezeigt werden die nicht korrekt sind. D.h. die LQI-Werte stimmen ggf. nicht, oder es werden z.B. Geräte ganz ohne Verbindundslinie angezeigt, obwohl das Gerät problemlos funktioniert.
c) Es beim aufrufen der Z2M Karte auch zu Fehlermeldungen kommen kann das Daten - z.B. LQI-Werte - von einem Gerät nicht abgerufen werden können.

Daher muss und sollte man einem Zigbee Mesh und das können hier viele User sicherlich so bestätigen, immer erst einmal Zeit geben (1 - 2 Tage) bis es sich hoffentlich “eingespielt” hat. Und wie schon gesagt würde ich in Deinem Fall, bei dem es um rund 200 Geräte geht, die Problemfälle erst einmal außen vor lassen und mich an denen dann erst in ein paar Stunden später, oder ggf. auch erst am nächsen Tag oder so, erneut versuchen. Das ein Gerät ggf. mehrere Anläufe braucht bis es sich dann endgültig in das Mesh integrieren lässt und es eine stabile und fehlerfreie Verbindung gibt, ist jetzt auch nicht so außergewöhnlich.

VG Jim