SLZB-06 freezing every few days

[Dinth]

Hi. Recently i have migrated from ZBDongle-P to SLZB-06 (powered over PoE) and while it works great when it works, every few days SLZB-06 is completely freezing and the whole mesh goes down.
Zigbee2MQTT log only shows this:

Zigbee2MQTT:warn  2024-02-02 09:00:01: Failed to ping 'Baby room uplight' (attempt 1/1, Read 0x0017880108aca49e/11 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - AF - dataRequest after 6000ms))
Zigbee2MQTT:warn  2024-02-02 09:00:12: Failed to ping 'Shed floodlight' (attempt 1/1, Read 0x04cd15fffeddcf9c/11 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - AF - dataRequest after 6000ms))
Zigbee2MQTT:warn  2024-02-02 09:00:23: Failed to ping 'Zigbee repeater first floor' (attempt 1/1, Read 0x00124b002447f894/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - AF - dataRequest after 6000ms))
Zigbee2MQTT:warn  2024-02-02 09:00:34: Failed to ping 'Private office CRT screen' (attempt 1/1, Read 0x0c4314fffef7a0e7/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - AF - dataRequest after 6000ms))
Zigbee2MQTT:warn  2024-02-02 09:00:45: Failed to ping 'Landing cabinets light 3' (attempt 1/1, Read 0x385b44fffe0c4a11/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - AF - dataRequest after 6000ms))
Zigbee2MQTT:warn  2024-02-02 09:00:56: Failed to ping 'Master bedroom light 2' (attempt 1/1, Read 0x842e14fffe125b08/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - AF - dataRequest after 6000ms))
Zigbee2MQTT:warn  2024-02-02 09:01:07: Failed to ping 'Zigbee repeater ground floor' (attempt 1/1, Read 0x00124b002447f8d4/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - AF - dataRequest after 6000ms))

If i now restart Z2M im getting:

[09:07:29] INFO: Preparing to start...
[09:07:29] INFO: Socat not enabled
[09:07:30] INFO: Starting Zigbee2MQTT...
Zigbee2MQTT:error 2024-02-02 09:07:52: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2024-02-02 09:07:52: Failed to start zigbee
Zigbee2MQTT:error 2024-02-02 09:07:52: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
Zigbee2MQTT:error 2024-02-02 09:07:52: Exiting...
Zigbee2MQTT:error 2024-02-02 09:07:52: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)
    at ZStackAdapter.start (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:103:27)
    at Controller.start (/app/node_modules/zigbee-herdsman/src/controller/controller.ts:132:29)
    at Zigbee.start (/app/lib/zigbee.ts:60:27)
    at Controller.start (/app/lib/controller.ts:106:27)
    at start (/app/index.js:107:5)

On the SLZB-06 side there's nothing suspicious - normal temperatures, everything seems to work except no connected client:

setup | start
L_Y,L_B | status: 1
ConfigHelper | load config
ConfigHelper | config open: Ok
setup | Config loaded
setup | Device type: SLZB-06
[ZBCHK] | Connection OK
Network | init
Network | EVENT_ETH_START
Network | EVENT_ETH_CONNECTED
Network | ETH init: OK
setup | Filesystem size: 3456
setup | Filesystem used: 368
setup | done
Network | [MDNS] Started
Network | EVENT_ETH_GOT_IP
Network | ETH MAC: D4:8A:FC:A1:DF:6F IPv4: 10.10.25.10 GW: 10.10.0.1 Speed: 100Mbps DNS1: 10.10.0.1 DNS2: 0.0.0.0
taskZB | [taskZB] Starting server on port: 6638
Network | fireNetworkUp
Web | Webserver started
time | time sync start
internet | connected
time | timezone: GMT0BST,M3.5.0/1,M10.5.0
time | Wednesday, January 31 2024 17:00:47
taskTimeSync | Heap: 1448
stats | Statistics sent
stats | Heap: 2436
Network | EVENT: 0
Network | EVENT: 2
Network | EVENT: 3
taskZB | New client
taskZB | Client disconnected
taskZB | New client
taskZB | Client disconnected
taskZB | New client
taskZB | Client disconnected
taskZB | New client
taskZB | Client disconnected
taskZB | New client
taskZB | Client disconnected
taskZB | New client
taskZB | Client disconnected
taskZB | New client
taskZB | Client disconnected
taskZB | New client
taskZB | Client disconnected
taskZB | New client
taskZB | Client disconnected
taskZB | New client
taskZB | Client disconnected
Network | EVENT: 0
Network | EVENT: 2
Network | EVENT: 3
Network | EVENT: 0
Network | EVENT: 2
Network | EVENT: 3
Network | EVENT: 0
Network | EVENT: 2
Network | EVENT: 3
Network | EVENT: 0
Network | EVENT: 2
Network | EVENT: 3
Network | EVENT: 0
Network | EVENT: 2
Network | EVENT: 3
Network | EVENT: 0
Network | EVENT: 2
Network | EVENT: 3
Network | EVENT: 0
Network | EVENT: 2
Network | EVENT: 3
taskZB | New client
Network | EVENT: 0
Network | EVENT: 2
Network | EVENT: 3
taskZB | Client disconnected
taskZB | New client
taskZB | Client disconnected
taskZB | New client
taskZB | Client disconnected
taskZB | New client
taskZB | Client disconnected
taskZB | New client
taskZB | Client disconnected
taskZB | New client
taskZB | Client disconnected
Network | EVENT: 0
Network | EVENT: 2
Network | EVENT: 3
taskZB | New client

Seems that Z2M is trying to connect but the connection drops.

My Z2M config is as follows:

data_path: /config/zigbee2mqtt
socat:
  enabled: false
  master: pty,raw,echo=0,link=/tmp/ttyZ2M,mode=777
  slave: tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5
  options: "-d -d"
  log: false
mqtt: {}
serial:
  port: tcp://10.10.25.10:6638
  baudrate: 115200
  adapter: zstack
  disable_led: false
advanced:
  transmit_power: 20

When this happens i need to completely restart ESP32 and Zigbee stack via the SLZB-06 web panel. SLZB-06 is running on the latest firmware v2.0.16 / 20230507

[Dinth]

It may be related to #18192

[Dabbadoeber]

I stumbled open this thread, since a couple of days I got the same problem.... hopefully there is a fix soon. For me only power cycling the stick will bring the network back.

[Dabbadoeber]

I have connected ZHA to the same dongle:
Socket connected: | Yes, 2 client
Trying to check if the problem occurs on Z2M and ZHA then i should be related to the SLZB-06 dongle.
Maybe power issues ?

i used this guide to do so:

https://smarthomescene.com/guides/how-to-use-zigbee2mqtt-and-zha-with-a-single-coordinator/

[Dabbadoeber]

Problem is defently with the SLZB-06 as Both ZHA and Z2m dont have a connection anymore.

[Dinth]

After a month of suffering pain of instable/dead Zigbee mesh i have a few things to add:

1. I have tried both PoE and USB-C power and there is no difference - so the problem doesnt seem to be related to power.
2. Approx 2 times in 3 its still not possible to connect to the Zigbee gateway after restarting it, so often i need to restart it a couple of times before Z2M/ZHA can connect to it.
3. I have tried to export radio to ZHA and the problem exists in ZHA but feels little bit different. In Z2M i am noticing errors and devices dropping off gradually before the adapter freezes, but i believe ZHA was running rock stable until the moment the adapter freezes.
4. SMLight support before they have stopped responding to my emails suggested that the problem may be in the adapter and/or Z2M not able to handle some of the errors in my Zigbee mesh. I have tried switching the power off for an hour from all the devices and i have removed some dodgy routers from my mesh. It may be a coincidence, but after each of those actions the adapter was indeed working for considerably longer before freezing. Unfortunately after a freeze and next restart of the adapter everything went back to normal, that means adapter freezing quite often.

[Dabbadoeber]

I am only using Busch jeager switch on my network, i have splitted the network in my House into 3 parts.
this is because the busch jeager cannot handle to much devices.
If the Coordinator becomes onresponsive the BJ ZLL Switch still work, that is, switches that i have "bind" are still operational.
accept that no information is send to Z2M/Home assitant
i still have a usb dongle think these SLZB-6 crap wil go on e-Bay /Markplaats.

[tomtom13]

It's funny how SMLight give that excuse, while whole internet doesn't seem to go down just because one person plugged in a dodgy router / server. When my light bulb burns down whole city doesn't loose electricity because of that.
From the whole thread and people interaction with their "support" I think they effed up, but they have the "rockstar programmers" that can do no wrong and they put blame on everything else and their marketing is now on charm offence.

[Dabbadoeber]

I have created a new Zigbee2mqtt container on my Qnap en moved over everything (configuration.yaml, coordinator.json)
Also downgrade the SLZB-6 to version v0.9.9
and started, until now it seems ok (hopefully it wil keep running)

[Dinth]

Could you please keep us updated? I will also try flashing it next time my adapter freezes, but maybe i am going to try coordinator firmware?

[Dinth]

Also have you flashed 0.9.9 via the UI?
I can flash the older 2.0.17, but when trying 0.9.9 im getting OTA write error.

[Dabbadoeber]

i did flash it trough the ota.

I thought i had it running for a while, but in the night it stopped again.......
I only have 13 devices on this network, I just finished pairing them all to a USB SONOFF Zigbee 3.0 USB Dongle Plus-P.
I don’t like this because its running in a docker container on a Qnap nas, I don’t know if the link to port: /dev/ttyUSB0 will remain after reboot or something.
The pairing only took me about 1 hour.
Did save the database and configuration.yaml (only for the devices) and used this on the new network.
I didn’t had to remove cover or anything to pair the switches again.
So it was the most convenient way to go for me.
Did order a Zigstart UZG so maybe this will be better.

For now No more SLZB-6 for me.

[Dabbadoeber]

I did the transition to the sonoff dongle, but still Z2M Freezes (but not as much, and restarting docker fixes it) , zo maybe it is Z2m After all, going back to : koenkk/zigbee2mqtt:1.34.0
see if this runs stable.

[Dinth]

What is your hardware? I've been googling the errors im seeing and i have seen one post somewhere where a person was suggesting that this may be due to low disk write/read speeds and that replacing his drive (where the Z2M container was running from) to SSD has fixed those issues.
Although this doesnt explain why ZHA is also affected...

[Dinth]

Just got SNZB-06M today which has a completely different Zigbee chip and will be testing it.

On the other hand, i found something what may be helpful with such faulty SNZB-06 as i had before - apparently it can be flashed with ESPHome and still run as a Zigbee coordinator (its actually burried on their wiki) but on a completely different firmware.

[Dinth]

And SNZM-06M is still experiencing the same issue, a different device on a different chip (TI one).

[Dabbadoeber]

Hi back after a whille, i downgrade Z2M to [1.34.0] it has been running for a week with out issues (sonoff dongle)
today i changed everything to a UZG-01 , where i Write the IEEE from the dongle onto the UZG-01.
so i dont need to pair al devices again.

Hardware @ the moment is a Qnap NAS TVS-H874X, so this should not be a problem i think
is is a hassle with usb though, so thats why i preffer a LAN Coordinator.

[Dabbadoeber]

Pfff 100 devices , i only have 13 on this nework , split my home in 3 diffrent networks because of issues with slow ZLL devices, to much zigbee traffic made them freeze.
maybe switch on debug log in Z2M too see wich devices spams the network

[ViggoGaming]

Hi back after a whille, i downgrade Z2M to [1.34.0] it has been running for a week with out issues (sonoff dongle)

today i changed everything to a UZG-01 , where i Write the IEEE from the dongle onto the UZG-01.

so i dont need to pair al devices again.

Hardware @ the moment is a Qnap NAS TVS-H874X, so this should not be a problem i think

is is a hassle with usb though, so thats why i preffer a LAN Coordinator.

Hey. Do you mind sharing how you downgraded Z2M to version 1.34.0?

[dbroome1978]

It might be fixed on the next release.
See
#21462 (comment)

[Dinth]

Thanks, it has crashed again for me today.
I dont think its actually caused by one of the devices chattering/Zigbee being overloaded - once it happens Z2M stops receiving any messages from the mesh.

[Dabbadoeber]

I am using docker (Container station) so i recreated the image, and instead of the :latest tag is used :1.34.0
must say after HASS update i had some trouble (could not communicate with MQTT server) but since i updated this everyhing has been quite stable

[mremedi2023]

Same here, my lan zigbee is down

[guzmanregueiro]

I have the same problem. Every 3/4 hours it freezes

[Dinth]

@mremedi2023 @guzmanregueiro Have you tried the latest firmware (20240710) ?

[guzmanregueiro]

Yes. And now 20240716

[mremedi2023]

Yes

[Matriciel]

Hi,
Where are you find the firmware ?

[nonamejuju]

I have the same problem here. The SLEB-06 was rock solid for the past few months, but now Z2mqtt can't connect to it every few days. A hard reboot of the dongle fix it. Dongle connected in Ethernet with USB power. Maybe a new update of Home assistant changed something ?

[Dinth]

Which versions are you using (particularly Z2M and firmware)?
I had the problem since i migrated to PoE coordinators (back in January), Z2M update to 1.39.0 made it much worse, and then the latest firmware 20240710 fixed it.
HA is most definetely not a problem here, it wouldnt cause your coordinator to freeze.

I remember seeing some comments in the past connecting this issue to a slow disk i/o on Z2M host, so send us your spec please

Also if nothing else helps, i also remember seeing some comments from user who fixed that issue by downgrading Z2M to a really old version (1.34 maybe?), but dont remember specifically which one

[nonamejuju]

For SLZB-06 :

• Core firmware version: v2.5.0
• Zigbee Coordinator Revision: 20240710

Zigbee2MQTT :

• Current version: 1.39.1-1

Home Assistant:

• Core 2024.8.2
• Supervisor 2024.08.0
• Operating System 13.1
• Frontend 20240809.0

Running on a BMAX B4 Plus Mini PC Intel N100 16GB 512GB SSD, with promox, the coordinator is behind an ethernet switch, and I'm running in parallel ZHA with a Sonoff ZBDongle-E connected directly in USB for the talky devices. I will investigate the logs and try different config and testing things and report back.

[Dinth]

ok, ssd this rules out slow disk i/o.
I would first try reverting Z2M back to 1.38

[foufoutos21]

I have two controllers SLZB-06 and I was quite happy with their performance for the last months.
Lately I have a lot of strange errors and freezes of the whole MQTT structure. I'm using 3 coordinators in a multistorey building as the only workable solution. One usb coordinator connected to Home assistant pc (a FUTRO thin client with 4GB ram and 256GB mSATA SSD) and the two SLZB-06 via POE LAN.
First observation was the broken web interface of the devices.
Then SSE errors during connection to the web interfaces, then noticed freeze of Z2M instances. Lately is not accessible at all and collapse of my Home automation system.
SLZB-06 are not reliable, are not stable and they are not offering any kind of support.
I have try any possible firmware available in their web flasher, any combination of zigbee firmware but in vain!

Zigbee2 MQTT version 1.39.1-1 Home Assistant Core 2024.8.2 on 13.1 OS
SLZB-06 with 0.99 and 2.5.0 /2.3.6 core frmware, unsure what zigbee firmware is running as I'm testing everything is available.
Frustrated and disappointed!
Any assistance is welcomed

[nonamejuju]

For SLZB-06 :

• Core firmware version: v2.5.0
• Zigbee Coordinator Revision: 20240710

Zigbee2MQTT :

• Current version: 1.39.1-1

Home Assistant:

• Core 2024.8.2
• Supervisor 2024.08.0
• Operating System 13.1
• Frontend 20240809.0

Running on a BMAX B4 Plus Mini PC Intel N100 16GB 512GB SSD, with promox, the coordinator is behind an ethernet switch, and I'm running in parallel ZHA with a Sonoff ZBDongle-E connected directly in USB for the talky devices. I will investigate the logs and try different config and testing things and report back.

All right after a month I don't have any problem.

I have moved it to another location, next to my Sonoff ZBDongle-E and Wi-Fi router. On paper, it's a worse location than the previous one (which was in the middle of the house), but there have been no more disconnections or freezes since. I also updated to the latest Z2MQTT version that was released. It's worth noting that the SLZB-06 is now connected directly to my main Wi-Fi router via Ethernet, instead of being behind a switch. Hope this help someone !

[mremedi2023]

Same here, I keep having problems, definitely Zigbee technology is not stable, much less user-friendly, with more than 70 devices, I am about to move everything to WiFi as I had before and without problems. El dom, 25 ago 2024 a la(s) 2:41 p.m., foufoutos21 ***@***.***) escribió:

…

I have two controllers SLZB-06 and I was quite happy with their performance for the last months. Lately I have a lot of strange errors and freezes of the whole MQTT structure. I'm using 3 coordinators in a multistorey building as the only workable solution. One usb coordinator connected to Home assistant pc (a FUTRO thin client with 4GB ram and 256GB mSATA SSD) and the two SLZB-06 via POE LAN. First observation was the broken web interface of the devices. Then SSE errors during connection to the web interfaces, then noticed freeze of Z2M instances. Lately is not accessible at all and collapse of my Home automation system. SLZB-06 are not reliable, are not stable and they are not offering any kind of support. I have try any possible firmware available in their web flasher, any combination of zigbee firmware but in vain! Zigbee2 MQTT version 1.39.1-1 Home Assistant Core 2024.8.2 on 13.1 OS SLZB-06 with 0.99 and 2.5.0 /2.3.6 core frmware, unsure what zigbee firmware is running as I'm testing everything is available. Frustrated and disappointed! Any assistance is welcomed — Reply to this email directly, view it on GitHub <#21157 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BENWU6TMBYDBYDFX4XQLVX3ZTIJLZAVCNFSM6AAAAABCWKS5AKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANBUGQYTIMY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[foufoutos21]

I can spot the culprit in my setup but my third coordinator is a usb sonoff stick with z2m same as others (1.39.1-1) and it's rock solid.
My next step is such controller in raspberry pi with POE or (maybe) I'll give a try to ZigStar UZG-01.

[Blackduke77]

Wonderful, I have been having the same issues, and from this thread, we are not going to get to the bottom of it. Has anyone tested a working alternative

[Blackduke77]

I am going to try and go back to firmware 20240315

[habitats-tech]

I have created 3 threads to document issues and findings pertaining to SLZB and UZG hubs, so we can all contribute from a single point of reference to the continuous improvement of zigbee2mqtt for the aforementioned hubs.

#26839 - ember SLZB
#26838 - zstack SLZB
#26840 - zstack UZG

[Feriman22]

I solved this by enabling "Allow multi-threaded socket connection" under "Z2M and ZHA".

Edit: Enabling this made things worse, so I had to disable it.

The real issue is probably one spamming device; in my case, it's a presence sensor. I will build my own from scratch.

Edit2: I removed the spammy device (presence sensor), but still the same issue.

[lejstef]

I'm using ZHA. Tested enabling "Allow multi-threaded socket connection", but that only made the problem worse. Started freezing multiple times per day.

[Feriman22]

I have some update from smlight:

There is a known problem with radio modules from Texas Instruments, its radio modules freeze at high load, usually the more load the sooner it will happen. This can happen both in an hour and in a week, depending on the amount of traffic.
This problem is present on absolutely all CC radio modules, which is why you can find so many messages about it. By the way, you can also find messages about the same problems with sonoff zbdongle-p, which only confirms that these radio modules have problems.
Most likely, the problem is software, but since this is a problem of the closed SDK of Texas Instruments, we can only wait for it to be solved by the manufacturer of the radio module.
There are two known solutions:

• Reduce traffic on the network
• Switch to EFR32 radio (M coodrinator versions)

[lavir]

In my case, I need to figure out where to send my family so that I can swap to EFR32 and repair all the sensors without my loved ones yelling at me 😂 Now 80 sensors, the rest of ≈60 are waiting when I solve this issue 🙁

[lavir]

Another thing that bothers me. Can interference from access points affect the connection in any way (I know that in general, yes, it can), and how can I check this myself? I have three Unifi AP. I tried everything, including changing the channel width and signal strength. No difference.

[techie-dreamer]

Another thing that bothers me. Can interference from access points affect the connection in any way (I know that in general, yes, it can), and how can I check this myself? I have three Unifi AP. I tried everything, including changing the channel width and signal strength. No difference.

We have 5 Unifi APs operating on 5Ghz & 2.4Ghz, no issues when the chatty devices are removed from the Zigbee network, it's rock solid.

[Mrsash2020]

I have the MR3 for 6 months now and its been a headache and a half.

Using channel 25 moved from a perfectly stable CC2652P7 for more than a year.

Crashes within 24 hours with the CC2674P10 chip. Originally dropped devices every few hours. Devices would show offline willy nilly etc. Had to reboot MR3/Zigbee/OS to get it working again. The updates to firmware/OS last few months did reduce the issue where it would crash within a few hours but now around 24 hours where my sanity is now being tested.

I was asked to start fresh which did not fix the issue by smlight. They sent me another MR3 which has the same issue.

As a last ditch attempt I even tried the EFR chip re-pairing everything which had weird issues of its own. I noticed devices falling off as I was adding them. What the?? Eventually after a few hours of my 60 odd devices being added some devices became unresponsive.

smlight have been good and helpful etc ..... they have asked me to send it back for a refund.
I was thinking of asking them to send me a MR1. Anyone know if this would work considering same chip as 06?

[tomtom13]

In my case, I need to figure out where to send my family so that I can swap to EFR32 and repair all the sensors without my loved ones yelling at me 😂 Now 80 sensors, the rest of ≈60 are waiting when I solve this issue 🙁

Actually I've got a simple suggestion - start a second instance of Z2M, and slowly one by one start migrating the device. Just remove in old instance, and then pair it in new one. That way you will not drag in any crap config along, and you will just copy&paste names across and you're golden.

[madCase1988]

Also, if this thread is a little bit older. I strugled today the whole day. Tried everything (all combinations of plug of stick, reboot, different firmware's and zigbee coordinator fw versions, Zigbee restart in all combinations , recover of backup, of the proxmox machine etc. etc. etc.
Zigbee2Mqtt was either starting and crashing after some time (timeout) or not starting (Error while starting zigbee Herdsman).

In the End and that is for all the people who still struggle after what I did above: TRY ALSO RESTARTING THE MQTT BROKER (after you did e.g. "zigbee restart" or unplugging SLZB from power.

I would recommend the follwoing:

• Stop zigbe2mqtt

• Unplug Stick from Power (wait 1-2 minute)

• Plug it in and wait 1-2 minutes allthough GUI is up already some time

• "Zigbee restart" in SLZB GUI

• stop mqtt broker

• start mqtt broker

• start zigbee2mqtt

[madCase1988]

also it can help when you come from backup: delete state.json in z2m folder before you start z2m

[tomtom13]

OK boys and girls, here is something that might be interesting to specifically SLZB users.

Backstory:
after very long time of using UZG I started having some issues, my netwrok have grown and got up to 197 devices. Few issues started showing up - recently I wanted to add some TRV's and those had a very hard time pairing. So I decided to take a gander and use SLZB06p10 since it should handle more devices. I HAD TO MIGRATE :( anyway, while re-paring everything to an old instance, I've notices that when I paired few of devices that are very chatty (update every 5 seconds) then issues started hitting me again. I moved all the devices to a separate network based on new instance. Issues NEWRLY vanished, but I started having devices dropping of randomly on old instance, some values never updating, some dimmer switches not even reporting properly.

So I started digging.

Turns out that my old instance of Z2M has about 230 devices in coordinator_backup.yaml - considering that originally there were 197 devices MINUS 9 devices moved to the separate instances, this looked fishy. Today over past few days I started something akin of "cleanup". I started removing zombie devices from coordinator_backup.yaml, and for "naughty devices" (one that don't update all the values, or randomly fall off) I started shifting those to new network -> shutdown old Z2M instance -> remove device data from coordinator_backup.yaml -> power OF coordinator -> 10s wait -> power on coordinator -> starts Z2M -> remove device from new instance -> pair it again to the old instance.

So far my results are good, values are updating properly, network is becoming more stable.

So to me it rakes of Z2M not being to well geared to keep crap out of it's config / internal DB.

What I would suggest is if you have a large network:
Get a second coordinator -> setup a second z2m instance and make it use second coordinator -> move device one by one to new instance.
Here is a caveat, I've noticed that when pairing a device in Z2M, and pairing it within last 2 minutes of "allow joining" sometimes interrogation may not finish properly and you end up with some "funnies" in your config / DB.

about p10 slzb, dissable everything, dhcp, mdns, auto update check, any funky feature you can. Just leave it as dumb coordinator.

[stadyGIT]

My Zigbee Network is stable since I disabled the smlight integration in Home assistant.

With integration enabled it take about one week when it get unstable with device no reaction. And the slzb interface was not reachable.

Disabled integration, restart everything and since month it is stable without issues.

I use

Z2m and a slzb06

[techie-dreamer]

My Zigbee Network is stable since I disabled the smlight integration in Home assistant.

With integration enabled it take about one week when it get unstable with device no reaction. And the slzb interface was not reachable.

Disabled integration, restart everything and since month it is stable without issues.

I use

Z2m and a slzb06

With respect, I've had a different experience on z2m & slzb06.
Never enabled the smlight integration, when it 'crashes' the Zigbee network is unresponsive but the slzb06 web interface is accesible via direct IP address. The common factor here is mine crashing is 'chatty devices' which seems to crash the zigbee chip on the co-ordinator. I think your issue maybe something else, perhaps co-ordinator firmware (is it up to date in web UI?) or a networking issue (overlapping IPs? physical cable failure?)

[stadyGIT]

My Zigbee Network is stable since I disabled the smlight integration in Home assistant.

With integration enabled it take about one week when it get unstable with device no reaction. And the slzb interface was not reachable.

Disabled integration, restart everything and since month it is stable without issues.

I use

Z2m and a slzb06

With respect, I've had a different experience on z2m & slzb06.

Never enabled the smlight integration, when it 'crashes' the Zigbee network is unresponsive but the slzb06 web interface is accesible via direct IP address. The common factor here is mine crashing is 'chatty devices' which seems to crash the zigbee chip on the co-ordinator. I think your issue maybe something else, perhaps co-ordinator firmware (is it up to date in web UI?) or a networking issue (overlapping IPs? physical cable failure?)

Everything is up to date (z2m, coordinator, etc.)
Just wanted to say, that maybe the integration of home assistant (if someone here use it) could be the problem. Since I disabled the smlight integration in home assistant my Zigbee network runs stable and smooth without issues. I have no chatty devices.
How I said, in my case the integration was the problem.

Slzb06 is connected over Poe on a unifi switch and network.

[techie-dreamer]

Hi all - so I think I've cracked it, after a week of testing, my Zigbee network hasn't crashed once. Before, it was going down every 24 hours on average - requiring a reboot of the co-ordinator.

The change was swapping the slzb06 (Zigbee CC2652P chipset) out for a slzb06m (Zigbee EFR32MG21 chipset) co-ordinator. smlight support (& many above) has said there was a known issue with CC2652P chipset crashing under high Zigbee traffic and they seem to be right. Nothing else on my network has changed - almost 90 devices, about 50% battery powered and the rest mains (routers).

Here's how I swapped:

1. Shut down z2mqtt from Home Assistant
2. Backup from zigbee2mqtt (or data) directory (this is to make a clean rollback if needed) - config, database etc.. in /homeassistant/zigbee2mqtt/
3. Logged in to web interface of slzb06 (Zigbee CC2652P chipset) & copied the IEEE address to a text file
4. Powered down the slzb06 (Zigbee CC2652P chipset)
5. Connected the slzb06m (Zigbee EFR32MG21 chipset) to network, did any firmware updates, set same IP address and wrote the IEEE address of previous adapter (not sure if this is 100% needed), set same static IP address as old controller
6. Opened and edited /homeassistant/zigbee2mqtt/configuration.yaml from adapter: zstack to adapter: ember
7. Restart z2mqtt and watch the logs (Settings -> AddOns) to ensure it starts up (** see note below)
8. Be patient for everything to come back up, power cycle devices who are relunctant - it took me about 12 hours for fully stability to return - presume it's the mesh remapping. I did NOT need to re-pair any devices.

** NOTE: Mine didn't start up first time, saying invalid backup file in the logs, so I renamed coordinator_backup.json to coordinator_backup.save.json and tried again (thanks to these instructions) and it came up fine.

Hope that helps someone and gives hope if you're almost giving up - as I was (my family were tearing hair out when the lights were 'broken again' :)

[WhimsySpoon]

The individual device settings are still there. They same to be part of state.json which I did not delete.

That confirms my suspicion that I lost all of mine because of my IP/settings conflict issue - thanks for checking.

I just checked by coordinator_backup.json and the IEEE is also different, but it's just being stored in a different format - I suspect little-endian byte order. Nothing to worry about, it's all good.

[WhimsySpoon]

Just wanted to provide a quick update for anyone who comes across this and is considering a similar migration.

I ran the Mg24 for about two weeks and it was flawless - no freezing at all. I wanted to buy a backup coordinator in case the Mg24 failed, and instead of getting another Mg24, I instead purchased the overpowered Mg26 for a small amount more. It took a week to arive from Ali Express, but I plugged it in, cloned the IEEE from the Mg24 and everything came right back online without any fuss.

For the first week or two, I did have some oddities with devices falling offline. I had to pop the coordinator into pairing mode and rejoin them and they started behaving again. I suspect this was due to them holding bad routes.

I also had an issue with a cheap AliExpress Tuya-based switch. It had a low battery and was reannouncing itself frequently. This (oddly) was causing the same three completely unrelated devices to keep falling off the network. As soon as I replaced the battery, everything was fine.

One final issue (I hope), I'm running Z2M as an Add-on/App in HAOS running on a VM on Proxmox. I've had a couple of issues whereby I've woken up in the morning to find the z2m app stopped, even with Watchdog enabled. Long story short, I was backing up the VM in Proxmox and for a split second at the start of the backup, the VM was effectively frozen. This caused a communications issue between the Mg26 and Z2M which the ember stack seems particularly sensitive to, and the addon gracefully shut down. I suspect the graceful shut down is what prevented the watchdog from bring it back to life.

I have since appied a bandwidth limit to the backup for that VM and created an automation to restart the addon should it be dead for more than 60 seconds (a watchdog watchdog). I didn't expect the bandwidth limit to have a positive effect, but so far the addon hasn't crashed and the automation hasn't run.

Overall, my LQIs have increased a lot and my network is rock solid now. Devices also react faster.

tl;dr: Mg24 and Mg26 are solid worthwhile upgrades over the CC chips.

[andrewjfreyer]

@WhimsySpoon or @techie-dreamer do either of you have availability turned on?

[WhimsySpoon]

@andrewjfreyer yep. I have mine configured fairly agressively, but I have yet to see any false-positives:

availability:
  enabled: true
  active:
    timeout: 20
    max_jitter: 120000
    pause_on_backoff_gt: 30
    backoff: true
  passive:
    timeout: 240

[techie-dreamer]

@WhimsySpoon or @techie-dreamer do either of you have availability turned on?

Yes availability on - no issues seem. Stable for over a month.
I have alerting when the zigbee network goes down (ie. a hardwired devices changes state to 'unavailable') and it's happened twice but minor blip, network still working & device came back up within minutes.

[tomtom13]

OK boys and girls, have anybody tried THREAD on EFR32MG26 and / or CC2674P10 ? Specifically, looking at how it behaves on SLZB ?

[zeratul021]

I am just setting up OTBR with my new SLZB-MR4U on TI chip. Will get back if I hat any issues.
(Running 50 device zigbee network on the SL chip. The TI chip has known problem when network gets overloaded that it crashes)

[kbonnel]

I know you are asking about the MG25 and P10, but in case you were curious, I am running Matter over Thread on my slzb-06p7 for almost a year and haven't had any real issues. I don't have an extensive matter/thread environment, a couple of apple tv 4ks as border routers, and a Aqara hub M2 with a Aqara Smart Lock U100. Kimo

…

On Fri, Feb 6, 2026 at 6:30 PM Tomasz Kusmierz ***@***.***> wrote: OK boys and girls, have anybody tried THREAD on EFR32MG26 and / or CC2674P10 ? Specifically, looking at how it behaves on SLZB ? — Reply to this email directly, view it on GitHub <#21157 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASASZ7CHTRKT22JRIBX7IAD4KU52DAVCNFSM6AAAAABCWKS5AKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZSGM3DSMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tomtom13]

I know you are asking about the MG25 and P10, but in case you were curious,

I am running Matter over Thread on my slzb-06p7 for almost a year and

haven't had any real issues.

I don't have an extensive matter/thread environment, a couple of apple tv

4ks as border routers, and a Aqara hub M2 with a Aqara Smart Lock U100.

Kimo

On Fri, Feb 6, 2026 at 6:30 PM Tomasz Kusmierz @.***>

wrote:

OK boys and girls, have anybody tried THREAD on EFR32MG26 and / or

CC2674P10 ? Specifically, looking at how it behaves on SLZB ?

—

Reply to this email directly, view it on GitHub

#21157 (comment),

or unsubscribe

https://github.com/notifications/unsubscribe-auth/ASASZ7CHTRKT22JRIBX7IAD4KU52DAVCNFSM6AAAAABCWKS5AKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZSGM3DSMQ

.

You are receiving this because you were mentioned.Message ID:

@.***>

Thanks bud! From my experience all CC device on 06, 06p7 and 06p10 have issues on z2m, so it's good to hear some good news on p7.
Are all your routers in "same network" for thread ? or running multiple meshes ?

[tomtom13]

OK, What is the max baud rate that people run for SLZB-06Mg26 (EFR32MG26) ? I'm pondering going with 460800. But would love some feedback before shifting 200 ish devices over.
ps. this is for box standard TCP ethernet connection.

[tomtom13]

Self reply, only were able to get 100k working.

[Feriman22]

I have news from SMLight support regarding this issue:

Hi Ferenc,

We have developed special firmware for the EFR32 radio modules that can send up to 200 reports per second, but we haven't had time to test it yet.

Kind regards, Support Team

[techie-dreamer]

Should be enough for even the biggest networks :)

[tomtom13]

OK boys and girls !
A bit of SUCCESS !!!

The SLZB-06Mg26 migration is done, and for 36 hours the network was rock solid as FFFFF !!! even devices that seemed sluggish, are now working perfectly and super fast. My oldest daughter had issues with her light switches being temperamental and slow - now it's instantaneous. She's very happy with the result :)

[techie-dreamer]

Excellent news - I have the same experience (about 2 weeks post migration now) - let's hope this is a long term solution :)

[tomtom13]

OK, bit of off-topic, I know I've been floating here and there an idea of shifting to thread............. well this is going a bit S*****.
I've found what was supposed to be a good choice for having ethernet connected thread border router - SMHUB nano. Looking at the spec, everything is there, it can run OTBR locally allowing HASS to add it ... at least this is what pretty youtube vids show to unsuspecting.
HOWEVER,
don't get into delusion based on pretty youtube videos that this is in anyway near being a product 😠 So to issues:
Ordered two units, thinking I will have a nice redundant setup. Boy, I was wrong. One of them is half cooked, doesn't want to show web interface at all (yes I know about possible port 3000). Unit takes about 10 minutes to bootup if you're lucky, sometimes 30 minutes. What adds insult to the injury is that BOTH units have exactly the same MAC address ... I mean what is it ? 1987 ? thinking nobody will notice that both devices have same MAC ? WTF ? But wait it get's better. You can't configure it to have static IP, only automatic (dhcp) - well all fun and games, but if DHCP assigns it an IP that it doesn't fancy, let's say static IP you reserver on your DHCP server - SMHUB will just ignore it and pick it's own address. I've only seen microsoft do this once with windows NT 4.0 so this really gives me a retro vibes.

So bottom line ATM is: not ready for prime time. We will need to wait, and knowin how long it takes for those to those things to mature - ping me circa 2028 whenever it's mature enough for prime time.

here is a screenshot from leases page, I just chopped of first three numbers from IP to keep ilusion of privacy, but we can see that unit smhub1 decided only ONCE to stick to assigned .223 IP static address ... otherwise those are all over the place and I'm slightly fed up with flushing spanning tree on my switch that is very angry with me connecting two devices with same MAC on the network (honestly I wouldn't mind if it allowed you to change interface MAC)

😠 😠 😠 😠 😠 😠 😠 😠 😠 😠 😠 😠 😠 😠 😠 😠 😠 😠 😠 😠 😠

[spacerunner5]

off topic indeed, but interesting.

however, there is no chance running 2 identical MAC addresses on the same (L2) network. Since the SMHub runs some sort of Linux, you could try changing the MAC address if you have root access to the machine.

[tomtom13]

off topic indeed, but interesting.

however, there is no chance running 2 identical MAC addresses on the same (L2) network. Since the SMHub runs some sort of Linux, you could try changing the MAC address if you have root access to the machine.

yes they do have page with "trouble shooting" on how to get a new mac address for their device ... but there are more problems. the dhclient seems to be configured in such a way that once you offer it a lease that it doesn't fancy it will run through your lease range until it's exhausted :/ and once it starts doing that it will never stop - even after reboot. Only way to fix it is to flash it with factory firmware and start setup from square 1 ........ really really frustrating.

I think that alto boys are trying, they are not trying hard enough to release a finished product.

Anyway, "mean while, back on zigbee farm" seems that 06-efr26 seems to be rock solid so far !

[spacerunner5]

I would definitely fix the duplicate MAC issue first. Duplicate MACs would instantly lead to a routing / switching conflict in the network: The device would eventually get an IP from DHCP but still has no access to the network. So it would try to re-lease, which would explain the many leases. Also, the DHCP server can only offer / assign static leases based on the MAC address. Same conflict.

Also note that after changing a MAC, the old ones still might be cached (learned) by switching equipment / arp tables. I would change both MACs and do a fresh start.

Also note that whatever work / fix you do on the boxes: Make sure only 1 is powered on, until you fixed the MAC issue.

[tomtom13]

I would definitely fix the duplicate MAC issue first. Duplicate MACs would instantly lead to a routing / switching conflict in the network: The device would eventually get an IP from DHCP but still has no access to the network. So it would try to re-lease, which would explain the many leases. Also, the DHCP server can only offer / assign static leases based on the MAC address. Same conflict.

Also note that after changing a MAC, the old ones still might be cached (learned) by switching equipment / arp tables. I would change both MACs and do a fresh start.

Also note that whatever work / fix you do on the boxes: Make sure only 1 is powered on, until you fixed the MAC issue.

Dude, I KNOW ! it was the first thing I fixed. But Still it's a pile of hot mess. Now both units are sitting powered off so their internal leases expire (12h) because those conflict with what my dhcp want's to give them... and even as a root I can't remove dhclient leases from device file system ...
Side note, their commands for writing environment variables rakes of broadcom dev toolkit that I've used in one workplace in the past and makes me want throw up - that's how great of an experience it was.

[andreas-bulling]

I have tried the migration but I see the following error in the log now:

[2026-02-18 13:11:52] info: 	zh:ember:ezsp: Received network/route error ROUTE_ERROR_MANY_TO_ONE_ROUTE_FAILURE for "65252".
[2026-02-18 13:12:58] info: 	zh:ember:ezsp: Received network/route error ROUTE_ERROR_MANY_TO_ONE_ROUTE_FAILURE for "45252".

I followed the instructions above but additionally also those in the link you shared (copying everything in the coordinator_backup.json except for the first two blocks etc)

The list of devices is empty.

Any ideas what's going wrong / what I have to do?

UPDATE
Nevermind. I rolled back to the proxmox snapshot that I had created before starting the migration. Did the same steps as before up to he point where I saw the error about the invalid backup file in the log. I, again, stopped the add-on but instead of copying anything manually I simply deleted the old coordinator_backup.json file (after creating a backup copy). Started the add-on up again in the expectation that this would create a new json file (that I would have to manually adapt) but, voila, suddenly all zigbee devices started popping up.

For those of you interested in how to setup Matter-over-Thread on your shiny new dongle, see
https://smlight.tech/manual/slzb-06/guide/thread-matter/

[WhimsySpoon]

I don't think those items in the log are relevant; I did my migration four days ago and I still see a few of those. If you copy/paste the five digit code into the Z2M devices list it'll tell you which one they are.

As I understand it, it just means your mesh is still rebuilding/routes are still being established. The important thing is that it's an info, not an error. Unless you are seeing vast amount of them, I wouldn't worry.

In terms of your empty device list, it sounds like what happened to me. Are you using the Home Assistant z2m add-on/app?

[andreas-bulling]

Thanks for your reply! But see above - suddenly it worked!

[Feriman22]

I have some news about this issue and solution it this GitHub issue:
#29116 (comment)