SLZB 06 verliert Verbindung

Albi54 · 9. August 2026 um 06:52

moin zusammen,
habe vor 3 Wochen Zigbee2MQTT umgestellt auf einen SLZB-06 Adapter.
Alles wunderbar, er sitzt jetzt in der Mitte des Hauses und alle Gräte laufen.
Mein Problem, 1 bis 2 mal pro Woche verliert er die Verbindun zum Rechner, einmal
Power aus und ein und alles läuft wieder.
Was mache ich falsch oder was kann ich änder?
Danke

tinob · 9. August 2026 um 11:29

Es wäre Hilfreich ein Log vom Mosquitto Broker mit dem Fehler zu bekommen.

Schorsch · 9. August 2026 um 12:44

Ist der SLZB per LAN-Kabel angeschlossen?
WLAN ist suboptimal.
Hat der SLZB eine feste IP im Router?

Albi54 · 9. August 2026 um 12:49

ja er ist über einen Unifi Switch angeschlossen und über einen seperaten Injector. Die IP in Unifi ist fest zugeteilt worden.

Albi54 · 9. August 2026 um 12:52

was genau was ist kann ich dir nicht sagen, hab mal Teil kopiert

[2026-08-09 14:48:49] debug: 	zh:zstack:unpi:parser: <-- [254,1,100,1,0,100]
[2026-08-09 14:48:49] debug: 	zh:zstack:unpi:parser: --- parseNext [254,1,100,1,0,100]
[2026-08-09 14:48:49] debug: 	zh:zstack:unpi:parser: --> parsed 1 - 3 - 4 - 1 - [0] - 100
[2026-08-09 14:48:49] debug: 	zh:zstack:znp: <-- SRSP: AF - dataRequest - {"status":0}
[2026-08-09 14:48:49] debug: 	zh:zstack:unpi:parser: --- parseNext []
[2026-08-09 14:48:49] debug: 	zh:zstack:unpi:parser: <-- [254,3,68,128,26,1,44,240]
[2026-08-09 14:48:49] debug: 	zh:zstack:unpi:parser: --- parseNext [254,3,68,128,26,1,44,240]
[2026-08-09 14:48:49] debug: 	zh:zstack:unpi:parser: --> parsed 3 - 2 - 4 - 128 - [26,1,44] - 240
[2026-08-09 14:48:49] debug: 	zh:zstack:znp: <-- AREQ: AF - dataConfirm - {"status":26,"endpoint":1,"transid":44}
[2026-08-09 14:48:49] debug: 	zh:zstack:unpi:parser: --- parseNext []
[2026-08-09 14:48:49] debug: 	zh:zstack: Data confirm error (0xa4c138fd3135681b:229,26,4)
[2026-08-09 14:48:49] debug: 	zh:controller:endpoint: Error: ZCL command 0xa4c138fd3135681b/1 genOnOff.off({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Data request failed with error: 'MAC_NO_RESOURCES' (0x1a))
    at ZStackAdapter.sendZclFrameToEndpointInternal (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:572:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
    at async ZStackAdapter.sendZclFrameToEndpointInternal (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:590:24)
    at async ZStackAdapter.sendZclFrameToEndpointInternal (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:590:24)
    at async ZStackAdapter.sendZclFrameToEndpointInternal (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:590:24)
    at async ZStackAdapter.sendZclFrameToEndpointInternal (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:590:24)
    at async <anonymous> (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:472:20)
    at async Queue.execute (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/utils/queue.ts:38:20)
    at async ZStackAdapter.sendZclFrameToEndpoint (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:470:16)
    at async Request.send (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/controller/helpers/request.ts:86:25)
[2026-08-09 14:48:49] error: 	z2m: Publish 'set' 'state' to 'Ladung Kirsten Dell' failed: 'Error: ZCL command 0xa4c138fd3135681b/1 genOnOff.off({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Data request failed with error: 'MAC_NO_RESOURCES' (0x1a))'
[2026-08-09 14:48:49] debug: 	z2m: Error: ZCL command 0xa4c138fd3135681b/1 genOnOff.off({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Data request failed with error: 'MAC_NO_RESOURCES' (0x1a))
    at ZStackAdapter.sendZclFrameToEndpointInternal (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:572:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
    at async ZStackAdapter.sendZclFrameToEndpointInternal (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:590:24)
    at async ZStackAdapter.sendZclFrameToEndpointInternal (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:590:24)
    at async ZStackAdapter.sendZclFrameToEndpointInternal (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:590:24)
    at async ZStackAdapter.sendZclFrameToEndpointInternal (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:590:24)
    at async <anonymous> (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:472:20)
    at async Queue.execute (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/utils/queue.ts:38:20)
    at async ZStackAdapter.sendZclFrameToEndpoint (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:470:16)
    at async Request.send (/app/node_modules/.pnpm/zigbee-herdsman@10.8.0/node_modules/zigbee-herdsman/src/controller/helpers/request.ts:86:25)
[2026-08-09 14:48:50] debug: 	zh:zstack:unpi:parser: <-- [254,3,68,128,205,1,43,32]
[2026-08-09 14:48:50] debug: 	zh:zstack:unpi:parser: --- parseNext [254,3,68,128,205,1,43,32]
[2026-08-09 14:48:50] debug: 	zh:zstack:unpi:parser: --> parsed 3 - 2 - 4 - 128 - [205,1,43] - 32
[2026-08-09 14:48:50] debug: 	zh:zstack:znp: <-- AREQ: AF - dataConfirm - {"status":205,"endpoint":1,"transid":43}
[2026-08-09 14:48:50] debug: 	zh:zstack:unpi:parser: --- parseNext []
[2026-08-09 14:48:50] debug: 	zh:zstack: Data confirm error (0xa4c138af866b8b28:44454,205,0)
[2026-08-09 14:48:50] debug: 	zh:zstack: Wait 2000ms
[2026-08-09 14:48:52] debug: 	zh:zstack: sendZclFrameToEndpointInternal 0xa4c138af866b8b28:44454/1 (0,1,3)
[2026-08-09 14:48:52] debug: 	zh:zstack:znp: --> SREQ: AF - dataRequest - {"dstaddr":44454,"destendpoint":1,"srcendpoint":1,"clusterid":61184,"transid":45,"options":0,"radius":30,"len":5,"data":{"type":"Buffer","data":[16,6,11,2,0]}}
[2026-08-09 14:48:52] debug: 	zh:zstack:unpi:writer: --> frame [254,15,36,1,166,173,1,1,0,239,45,0,30,5,16,6,11,2,0,231]
[2026-08-09 14:48:52] debug: 	zh:zstack:unpi:parser: <-- [254,1,100,1,0,100]
[2026-08-09 14:48:52] debug: 	zh:zstack:unpi:parser: --- parseNext [254,1,100,1,0,100]
[2026-08-09 14:48:52] debug: 	zh:zstack:unpi:parser: --> parsed 1 - 3 - 4 - 1 - [0] - 100
[2026-08-09 14:48:52] debug: 	zh:zstack:znp: <-- SRSP: AF - dataRequest - {"status":0}
[2026-08-09 14:48:52] debug: 	zh:zstack:unpi:parser: --- parseNext []
[2026-08-09 14:48:53] debug: 	zh:zstack:unpi:parser: <-- [254,3,68,128,205,1,45,38]
[2026-08-09 14:48:53] debug: 	zh:zstack:unpi:parser: --- parseNext [254,3,68,128,205,1,45,38]
[2026-08-09 14:48:53] debug: 	zh:zstack:unpi:parser: --> parsed 3 - 2 - 4 - 128 - [205,1,45] - 38
[2026-08-09 14:48:53] debug: 	zh:zstack:znp: <-- AREQ: AF - dataConfirm - {"status":205,"endpoint":1,"transid":45}
[2026-08-09 14:48:53] debug: 	zh:zstack:unpi:parser: --- parseNext []
[2026-08-09 14:48:53] debug: 	zh:zstack: Data confirm error (0xa4c138af866b8b28:44454,205,1)
[2026-08-09 14:48:53] debug: 	zh:zstack: Discovering route to 44454
[2026-08-09 14:48:53] debug: 	zh:zstack:znp: --> SREQ: ZDO - extRouteDisc - {"dstAddr":44454,"options":0,"radius":30}
[2026-08-09 14:48:53] debug: 	zh:zstack:unpi:writer: --> frame [254,4,37,69,166,173,0,30,113]
[2026-08-09 14:48:53] debug: 	zh:zstack:unpi:parser: <-- [254,1,101,69,0,33]
[2026-08-09 14:48:53] debug: 	zh:zstack:unpi:parser: --- parseNext [254,1,101,69,0,33]
[2026-08-09 14:48:53] debug: 	zh:zstack:unpi:parser: --> parsed 1 - 3 - 5 - 69 - [0] - 33
[2026-08-09 14:48:53] debug: 	zh:zstack:znp: <-- SRSP: ZDO - extRouteDisc
[2026-08-09 14:48:53] debug: 	zh:zstack:unpi:parser: --- parseNext []
[2026-08-09 14:48:56] debug: 	zh:zstack: sendZclFrameToEndpointInternal 0xa4c138af866b8b28:44454/1 (0,2,3)
[2026-08-09 14:48:56] debug: 	zh:zstack:znp: --> SREQ: AF - dataRequest - {"dstaddr":44454,"destendpoint":1,"srcendpoint":1,"clusterid":61184,"transid":46,"options":0,"radius":30,"len":5,"data":{"type":"Buffer","data":[16,6,11,2,0]}}
[2026-08-09 14:48:56] debug: 	zh:zstack:unpi:writer: --> frame [254,15,36,1,166,173,1,1,0,239,46,0,30,5,16,6,11,2,0,228]
[2026-08-09 14:48:56] debug: 	zh:zstack:unpi:parser: <-- [254,1,100,1,0,100]
[2026-08-09 14:48:56] debug: 	zh:zstack:unpi:parser: --- parseNext [254,1,100,1,0,100]
[2026-08-09 14:48:56] debug: 	zh:zstack:unpi:parser: --> parsed 1 - 3 - 4 - 1 - [0] - 100
[2026-08-09 14:48:56] debug: 	zh:zstack:znp: <-- SRSP: AF - dataRequest - {"status":0}
[2026-08-09 14:48:56] debug: 	zh:zstack:unpi:parser: --- parseNext []
[2026-08-09 14:48:57] debug: 	zh:controller:endpoint: ZCL command 0x70b3d52b6008086c/1 haElectricalMeasurement.read(["rmsVoltage","rmsCurrent","activePower"], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false})
[2026-08-09 14:48:57] debug: 	zh:zstack: sendZclFrameToEndpointInternal 0x70b3d52b6008086c:60384/1 (0,0,4)
[2026-08-09 14:48:57] debug: 	zh:zstack:znp: --> SREQ: AF - dataRequest - {"dstaddr":60384,"destendpoint":1,"srcendpoint":1,"clusterid":2820,"transid":47,"options":0,"radius":30,"len":9,"data":{"type":"Buffer","data":[16,72,0,5,5,8,5,11,5]}}
[2026-08-09 14:48:57] debug: 	zh:zstack:unpi:writer: --> frame [254,19,36,1,224,235,1,1,4,11,47,0,30,9,16,72,0,5,5,8,5,11,5,81]
[2026-08-09 14:48:57] debug: 	zh:zstack:unpi:parser: <-- [254,1,100,1,0,100]
[2026-08-09 14:48:57] debug: 	zh:zstack:unpi:parser: --- parseNext [254,1,100,1,0,100]
[2026-08-09 14:48:57] debug: 	zh:zstack:unpi:parser: --> parsed 1 - 3 - 4 - 1 - [0] - 100
[2026-08-09 14:48:57] debug: 	zh:zstack:znp: <-- SRSP: AF - dataRequest - {"status":0}
[2026-08-09 14:48:57] debug: 	zh:zstack:unpi:parser: --- parseNext []
[2026-08-09 14:48:58] debug: 	zh:zstack:unpi:parser: <-- [254,3,68,128,205,1,46,37]
[2026-08-09 14:48:58] debug: 	zh:zstack:unpi:parser: --- parseNext [254,3,68,128,205,1,46,37]
[2026-08-09 14:48:58] debug: 	zh:zstack:unpi:parser: --> parsed 3 - 2 - 4 - 128 - [205,1,46] - 37
[2026-08-09 14:48:58] debug: 	zh:zstack:znp: <-- AREQ: AF - dataConfirm - {"status":205,"endpoint":1,"transid":46}
[2026-08-09 14:48:58] debug: 	zh:zstack:unpi:parser: --- parseNext []
[2026-08-09 14:48:58] debug: 	zh:zstack: Data confirm error (0xa4c138af866b8b28:44454,205,2)
[2026-08-09 14:48:58] debug: 	zh:zstack: Request network address of '0xa4c138af866b8b28'
[2026-08-09 14:48:58] debug: 	zh:zstack:unpi:writer: --> frame [254,10,37,0,40,139,107,134,175,56,193,164,0,0,147]
[2026-08-09 14:48:58] debug: 	zh:zstack:unpi:parser: <-- [254,1,101,0,0,100]
[2026-08-09 14:48:58] debug: 	zh:zstack:unpi:parser: --- parseNext [254,1,101,0,0,100]
[2026-08-09 14:48:58] debug: 	zh:zstack:unpi:parser: --> parsed 1 - 3 - 5 - 0 - [0] - 100

Schorsch · 9. August 2026 um 13:02

Um den POE-Injector als Fehlerquelle auszuschließen, könntest du den SLZB mal für 1 Woche per USB mit Energie versorgen.

Hast du das Log mal na eine KI gesendet, oder magst du die nicht?

Hier die Analyse von Gimini:

Im Log-Auszug liegen zwei konkrete Fehlergründe vor. Der Hauptfehler beim Ausschaltbefehl (genOnOff.off) für das Gerät „Ladung Kirsten Dell“ (0xa4c138fd3135681b) ist:

Data request failed with error: 'MAC_NO_RESOURCES' (0x1a)

Ebenfalls treten bei weiteren Datenpaketen Fehler mit dem Status 205 (0xCD / NWK_NO_ROUTE) auf.

1. Was bedeutet `MAC_NO_RESOURCES (0x1a)`?

Dieser Fehler wird direkt vom Texas Instruments Zigbee-Chip (CC2652P im SLZB-06) zurückgemeldet und bedeutet: Der Puffer für ausstehende Nachrichten an Endgeräte (Child-Devices) ist voll.

Ursachen:

Verbindungsproblem zu einem Batteriegerät: Der Koordinator möchte ein Datenpaket an ein schlafendes Endgerät senden (oder an ein Gerät, das nicht mehr erreichbar ist). Der Koordinator speichert das Paket in seiner internen Tabelle, bis sich das Gerät aufweckt. Meldet sich das Gerät nicht, läuft diese Tabelle voll.
Überlastung des Koordinators / Reconnecting-Loops: Wenn mehrere Geräte gleichzeitig die Verbindung verlieren oder gestört sind, läuft der Puffer für Indirect Transmissions voll.

2. Was bedeutet Status `205` (`NWK_NO_ROUTE`)?

Das Log zeigt bei der Adresse 0xa4c138af866b8b28 mehrfach den Status 205. Das bedeutet, dass der Koordinator im Mesh-Netzwerk keinen gültigen Routing-Pfad mehr zu diesem Gerät findet und eine Routenerkennung (extRouteDisc) startet, die fehlschlägt.

Ursachen und Lösungen

1. Das betroffene Gerät („Ladung Kirsten Dell“) neustarten / neu koppeln

Das Gerät 0xa4c138fd3135681b stromlos machen (ausstecken bzw. Batterie für 10 Sekunden entnehmen).
Sollte es danach weiterhin den Fehler werfen, das Gerät kurz aus Zigbee2MQTT entfernen und am Zielort neu anlernen.

2. Sendeleistung (Transmit Power) des SLZB-06 anpassen

Ein zu stark eingestellter SLZB-06 (z. B. auf maximalen 20 dBm) führt oft dazu, dass Endgeräte den Koordinator zwar perfekt „hören“, ihre eigenen kleinen Antennen die Antwort aber nicht mehr zurück zum Koordinator senden können (asymmetrisches Link-Budget).

In der Weboberfläche des SLZB-06 unter Zigbee Settings die Transmit Power (TX Power) auf 9 dBm bis maximal 14 dBm reduzieren.

3. Zigbee-Kanal und WLAN-Überlappung prüfen

Sehr häufig entstehen gestaute MAC-Puffer durch Funkstörungen durch 2,4 GHz WLAN:

Empfohlen: Zigbee-Kanal 11, 15, 20 oder 25.
Wenn das Haus-WLAN auf Kanal 1, 6 oder 11 läuft, den Zigbee-Kanal so wählen, dass er im Frequenzbereich dazwischen liegt (z. B. Zigbee Ch. 15 bei WLAN Ch. 1, oder Zigbee Ch. 25 bei WLAN Ch. 11).

4. Router-Anzahl im Mesh erhöhen

Der Fehler tritt auf, wenn zu viele Geräte direkt am Koordinator hängen anstatt über netzbetriebene Zigbee-Router (z. B. Hue-Lampen, Zigbee-Steckdosen).

Ein paar dauerhaft am Strom hängende Steckdosen im Haus verteilt entlasten den Speicher des SLZB-06 komplett, da diese die Datenpuffer für schlafende Geräte übernehmen.

Albi54 · 9. August 2026 um 13:43

so, Ladung Kirsten Dell erst mal gelöscht und entfernt
Andere Stromversorgung eingebaut.
2 zusätzliche Router eingebaut
Leistung auf 14 DB in der yaml von zigbee geändert
jetzt warten wir mal ab
Danke dir

Schorsch · 9. August 2026 um 13:56

Das waren jetzt aber viele Sachen auf einmal.
Evtl. wäre gar nicht alles nötig gewesen. Dein Wunsch ist wahrscheinlich, möglichst schnell einen störungsfeien Betrieb zu erreichen - kann ich auch verstehen.

Eine Notlösung wäre noch folgende:

in HA den sensor.zigbee2mqtt_bridge_state überwachen und bei Status getrennt einen SmartPlug, an dem die Stromversorgung des SLZB hängt, aus- und nach einigen Sekunden wieder einschalten. Oder präventiv, jede Nacht um 4:00 Uhr schalten.
Das darf dann natürlich kein Zigbee-SmartPlug sein.
Besser ist natürlich, den Fehler zu finden

Albi54 · 9. August 2026 um 16:01

moin,
ja das hatte ich schon, was war der Erfolg es stieg morgens um 8 Uhr aus, deshalb wird der Fehler gesucht

Albi54 · 10. August 2026 um 05:36

was ich noch festgestellt habe jetzt, wenn es Probleme gibt sind die Endgeräte weiterhin online nur die Router gehen in offline
aber alle

Schorsch · 10. August 2026 um 07:25

Moin,

Das ist ein entscheidender Hinweis!

Dass ausschließlich alle Zigbee-Router zeitgleich offline gehen, während die batteriebetriebenen Endgeräte asl online angezeigt werden, schließt ein physisches Ausfallproblem des SLZB-06 oder der Stromversorgung praktisch aus.

Das Fehlerbild weist auf ein Z-Stack Routing-Table Overflow im Zigbee-Netzwerk hin.

Batteriegeräte schlafen (Deep Sleep):
Batteriebetriebene Endgeräte senden nicht dauerhaft Signale. Zigbee2MQTT markiert sie erst nach Stunden oder Tagen als offline (je nach Availability-Timeout). Dass sie als „online“ angezeigt werden, ist meist nur der letzte bekannte Status in Z2M – tatsächlich sind auch sie vom Netz abgeschnitten, sobald sie aufwachen.
Es handelt sich wahrscheinlich um einen Soft-Lockup des Zigbee-Stacks (Mesh-Crash), nicht um ein Verbindungsproblem des Adapters zum LAN.

Das Absenken der Sendeleistung (TX Power) auf ~10 dBm sowie ein Firmware-Update des Zigbee-Moduls beheben dieses Phänomen in fast allen Fällen dauerhaft.

Ist die Firmware bei dir aktuell?

Und nochmal der Hinweis auf die Notlösung.

Albi54 · 10. August 2026 um 07:50

moin,
der Stick ist aktuell und die Sendeleistung hab ich gestern auf 14 gesenkt, mal schauen ob das passt sonst gehe ich mal auf 10. Jetzt noch Frage wegen dem Kanal im Zigbee, wenn ich ihn von 11 auf 25 ändere, muss ich dann alle Geräte neu anlernen?? Hab jetzt mal wlan auf 6 geschoben!
Dank

Schorsch · 10. August 2026 um 13:03

Ja und nein!

Die richtige Reihenfolge ist entscheidend, damit deine Automationen nicht kaputtgehen:

Geräte NICHT löschen: Lösche die vorhandenen Geräte vor dem Kanalwechsel auf keinen Fall aus Z2M.
Kanal ändern: Ändere den Kanal in der Z2M-Konfiguration (configuration.yaml von Z2M) und starte das Add-on neu.
Anlernen aktivieren: Aktiviere in Z2M „Beitritt erlauben“. Evtl. wiederholen, wenn es für viele Geräte länger als 4,25 min dauert.
Neu pairen: Versetze deine Endgeräte nacheinander in den Pairing-Modus.

Der entscheidende Vorteil:
Z2M erkennt die Geräte beim erneuten Anlernen anhand ihrer MAC-Adresse (IEEE-Adresse) wieder. Der friendly_name sowie alle Entity-IDs in Home Assistant bleiben exakt erhalten. Die bestehenden Automationen funktionieren danach nahtlos weiter.

Die beste mir bekannte Kanalwahl ist WLAN auf 1 und Zigbee auf 25.
Kanal 26 wird von einigen Zigbee-Geräten nicht problemlos unterstützt.

Albi54 · 10. August 2026 um 14:22

ist es richtig

homeassistant:
enabled: true
advanced:
network_key:
- 100
- 13
- 30
- 189…
- jetzt steht kein Kanal drin und da muss dann 25 rein

tinob · 10. August 2026 um 15:06

Ganz ehrlich, ich würde versuchen zuletzt den Zigbee Kanal zu ändern, spiele lieber mit dem Wlan Kanal rum, Wlan Geräte verzeihen dir viel leichter den Wechsel als Zigbee Endgeräte.

Der Stick sagt dir die Empfohlenen Config.

Am Stick direkt kannst du den Kanal ändern, aber wie gesagt, es wäre das letzte was ich tun würde.

Wenn dein Zigbee-Netz auf Kanal 11 läuft, solltest du deinen WLAN-Router im 2,4-GHz-Band auf WLAN-Kanal 6 oder 11 einstellen, um die Überschneidung zu minimieren.

Schorsch · 10. August 2026 um 15:31

Das sieht nicht richtig aus.
Es muss schon channel: davor stehen.

Es geht auch in den Einstellungen von zigbee2mqtt unter Einstellungen.

Das ist allerdings die Handy-Ansicht, da ich unterwegs bin.

tinob · 10. August 2026 um 15:38

Dee Kanal wird am SLZB-06 Stick eingestellt

Schorsch · 10. August 2026 um 15:41

Kannst du das bitte näher beschreiben?
Es liest sich so, als ob am SLZB-06 DIP-Schalter wären, was natürlich nicht der Fall ist.

EDIT: Ahh, jetzt habe ich es erst gesehen. Du meinst im Web-Interface vom Stick. Ok, so habe ich es noch nicht gemacht.

tinob · 10. August 2026 um 15:49

Der SLZB hat ein Webserver und wird über die Oberfläche eingestellt und meine Bilder sind da her.

Albi54 · 10. August 2026 um 17:06

genau da habe ich auch andere Einstellungen und das update vorgenommen. Was mich wundert wenn die Probleme mit Zigbee auftretten und ich den Stick via Webserver boote bleiben die Probleme bestehen. Ziehe und stecke ich ihn neu dann läuft alles wieder hoch…habe feste IP beim Router für den Stick und beim Stick selbst alle Daten eingetragen.