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.

[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

[matata86]

https://xzg.xyzroe.cc/

Have you tried this firmware?
What are your experiences?
Is it possible to upgrade while keeping the devices paired in Z2M?

[habitats-tech]

Yes running this FW version since it came out. Very reliable as I have coordinators running non-stop since it came out.

[habitats-tech]

Yes updating the FW does not require re-pairing if memory serves me well.

[habitats-tech]

When updating anything zigbee, if changes do not affect the IEEE address and the type of FW stack (e.g. zstack or ember), you are good to go.

[marcinsu]

I don't see any problems with this software. It seems to me that if someone has a P7 chip, there is no point in buying UGZ-01 (because SLZB P7 is probably the same and only a change of FW is enough).

[habitats-tech]

A few more points for Z2M networks in general.

Try channel 26 with all the different devices you have. In my experience this benefits Tuya devices as for some reason they do not miss reporting schedule as frequently. I have extensively tried channels 25, etc. but always Tuya for some reason randomly lose their reporting schedule (some take days before they suddenly start reporting again). This does not happen (missing the reporting schedule frequently) on channel 26.

Additionally set your coordinator to signal strength 8-12. As low as possible, as it benefits wireless signal congestion. I have routers almost 10m away from coordinator (set at 12 signal strength), and they communicate with no issues.

[Sortberg]

Do you have any indication of the signal strength? Or is it your own experience? Doesn't the 'map' get weaker if it doesn't send on 20?

[janstadt]

So i am running dev26 with the most recent zigbee firmware and i went through today and repaired everything. It worked for a few hours and then i noticed some of my automations not firing and come to find that all the door sensors (xiaomi mijia ones mostly) were unavailable. I tested out channel 26 and 25, no difference, things still just become unknown in HASS (im not running the smlight integration). I just dropped the transmit power down to 12 from 20 and we will see how that goes, but man oh man is this frustrating. Going back to channel 25 with transmit power of 12. I went around and repaired the goofed up door sensors. Im gonna just wait and see how things go for a while. Gotta leave the devices and coordinator alone cuz its hard to know what changes are affecting things.

[tomtom13]

my 2 pennies here. I've been running on channel 25 for very long time and never had problem with 2.4G wifi interference. I live in a detached house and everybody around me sit on channel 1 (including me) for wifi 2.4G. Only problem is that damn dongle crashing.

[habitats-tech]

Do you have any indication of the signal strength? Or is it your own experience? Doesn't the 'map' get weaker if it doesn't send on 20?

Focusing on battery devices, a high LQI value does not guarantee better operation of the device. Obviously this also depends on the quality of the device, but in my experience a well behaved device even with an LQI of 3 operates flawlessly.

When the coordinator was on 20 a lot more router devices were connecting with the end result being congestion. When set to 12 the network became more efficient with less devices connecting to the coordinator. To my experience the less devices connecting to the coordinator the better. Again based on my experience avoid connecting battery operated devices directly to the coordinator, they can destabilise the zigbee network. The above are for larger networks, but if you can follow best design practices even on a small network you can benefit long term. You never know when you become rich to afford a larger zigbee network. 😊

[habitats-tech]

Snapshot of the coordinator connections with transmit power at 12. Closest router is 2m and furthest router is 12m.

[Sortberg]

This evening it has been running without issues since 7/1. Then this error appeared, as you can see in the log... What kind of error is this?
FFS....................................................................................

z2m - 11-1-2025-486e6e9b_zigbee2mqtt_2025-01-11T21-46-54.430Z.log
SLZB06P7 - Crash.txt

[habitats-tech]

This is a zigbee socket error. For some reason communication to the socket times out. I have found this error common when using ember (SLZB06M) coordinators, but you are using zstack.

[Tarik2142]

It looks like the network connection was lost for a while. This is some network error.

[doff-1]

So I've been following this thread after I had some stability issues.
during the development of this thread I downgraded my SLZB-06M to 2.3.6 and reconnected the SLZB integration in Home Assistant via IP instead of mDNS.
Since that I haven't really had any issues.
Logging in to the device now I notice a slowdown of the web interface, but everything is still up and running.

To sum it up:
SLZB-06M in coordinator mode
Connected and powered by PoE
108 zigbee devices on the network
Core: 2.3.6
Radio: 20231030
ZHA (NOT z2m)
Home Assistant SLZB addon configured with IP

currently device uptime is 39days and 21hrs
Z2M/ZHA uptime is 2 days, because of recent HA updates.

Btw. Which radio firmware is recommended for ZHA?

[sphings79]

Today my switch deactivated the Port of the SLZB-06:

Blocked by Spanning Tree Protocol to prevent a network loop. This port will be automatically re-enabled when the loop is no longer detected.

There is only the stick connected to that port.

---

EDIT: Im on DEV29

[Tarik2142]

For this to happen you need to connect the device simultaneously via ethernet and wifi but the device only uses one interface at a time

[ausycb]

I found this thread after having issues with SLZB-06P7 with ZHA. ZIGBEE network basically stays up for ~3 hours and then becomes unresponsive, with the continuous connect attempt thereafter. Restarting ZIGBEE from the SMLight dashboard immediately gets everything working again for the next few hours. I have only 47 devices connected, most of them Hue lights. Support did not respond to my support request. I have changed back to my cheapo old TUYA ethernet hub which I flashed with EZSP and will see how it compares.

[tomtom13]

SLZB is superior to any Tuya on any front. My Tuya comments are based on dealing with hundreds of devices. I hope your Tuya lasts, not everything fails. I suggest you try to get things working with SLZB, a safer bet longer term.

With the exception of slzb crashing frequently and requiring manual intervention from the admin.

[techie-dreamer]

I found this thread after having issues with SLZB-06P7 with ZHA. ZIGBEE network basically stays up for ~3 hours and then becomes unresponsive, with the continuous connect attempt thereafter. Restarting ZIGBEE from the SMLight dashboard immediately gets everything working again for the next few hours. I have only 47 devices connected, most of them Hue lights. Support did not respond to my support request. I have changed back to my cheapo old TUYA ethernet hub which I flashed with EZSP and will see how it compares.

This is what I had (although it could be up to 24 hours of stability).

Here what I did to troubleshoot:

1. Settings -> AddOns -> Zigbee2MQTT
2. Log tab
3. Downloaded the log file for last 24 hours
4. Paste into Google Sheets & counted number of rows by device name (data -> columns)
5. This identified my temperature sensors were sending multiple readings a second.

Actions:

1. Removed the batteries from all 'chatty' devices (7 temp sensors)
2. Immediately the zigbee network was more stable & didnt crash

I've tried to adjust the update frequency of the sensors but nothing seems to 'take' with the units.
So for now, I'll leave them offline.

I appreciate you use ZHA but hopefully similar exists on that integration (pulling logs)

[habitats-tech]

SLZB is superior to any Tuya on any front. My Tuya comments are based on dealing with hundreds of devices. I hope your Tuya lasts, not everything fails. I suggest you try to get things working with SLZB, a safer bet longer term.

With the exception of slzb crashing frequently and requiring manual intervention from the admin.

This issue was fixed 3 weeks ago and hopefully will not come back to haunt us again.

[ausycb]

EZSP (Tuya device) coordinator has been solid for the last 24 hours. So definitely something that the SLZB is not handling.

[ausycb]

Update here - so Tuya still running without issue. Might switch back to SLZB and so how long it lasts. FWIW I migrated to SLZB originally using the ZHA migrate radio / backup and install option.

[MSL-DA]

+140 devices, Zigbee firmware https://github.com/darkxst/silabs-firmware-builder/releases/tag/20250107

[sphings79]

My UZG-01 arrived today, setting up was easy.
Updated the FW to the latest Beta.
Exchanging the SLZB-06 was also easy. Just stopped Z2M, changed the Z2M config and startet Z2M again.
All devices are working. No repair needed. No need to change the IEEE
Will test with my 80+ devices now ...

[sphings79]

Sooooooooooooooooooo few days ago, a slzb-06p10 arrived. I've used the advice of @sphings79 and the switch over was painless. Now the 6p10 version - it crashed only after 8 hours, while "bare 6" lasts few days. Soooo I guess I'm stuck for the time being with waiting for UZG. And yes, I've updated the firmware to newest version, I've disabled the updates, I've disabled the reporting of debug data to manufacturer etc etc. It's still "pretty bad".

What makes this whole ordeal worse is that from time to time, the 6p10 switches to usb only mode. Not fun.

You could try to flash it with the UZG FW and try again.

[sphings79]

Update: Everything is still fine, so my wife is happy :)
I looked at the logs and exported the last 10.000 lines.
I created a piviot table and had a look wich devices were most chatty.
Most "chatty" devices were the Paulmann bulbs and two newly added tuya plugs (other model then the ones i already had).

Perhaps someone can help me what to set under z2m to get the paulmann bulbs more silent?
The Payload they send every 30 to 60 seconds looks like this:

[2025-01-20 12:52:01] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/WZ Deckenlampe 1v6', payload '{"brightness":152,"color":{"x":0.4341,"y":0.4031},"color_mode":"color_temp","color_temp":329,"color_temp_startup":370,"effect":null,"last_seen":"2025-01-20T12:52:01+01:00","linkquality":116,"power_on_behavior":"previous","state":"OFF"}'
[2025-01-20 12:53:03] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/WZ Deckenlampe 1v6', payload '{"brightness":152,"color":{"x":0.4341,"y":0.4031},"color_mode":"color_temp","color_temp":329,"color_temp_startup":370,"effect":null,"last_seen":"2025-01-20T12:53:03+01:00","linkquality":116,"power_on_behavior":"previous","state":"OFF"}'
[2025-01-20 12:54:04] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/WZ Deckenlampe 1v6', payload '{"brightness":152,"color":{"x":0.4341,"y":0.4031},"color_mode":"color_temp","color_temp":329,"color_temp_startup":370,"effect":null,"last_seen":"2025-01-20T12:54:04+01:00","linkquality":120,"power_on_behavior":"previous","state":"OFF"}'
[2025-01-20 12:54:47] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/WZ Deckenlampe 1v6', payload '{"brightness":152,"color":{"x":0.4341,"y":0.4031},"color_mode":"color_temp","color_temp":329,"color_temp_startup":370,"effect":null,"last_seen":"2025-01-20T12:54:47+01:00","linkquality":120,"power_on_behavior":"previous","state":"OFF"}'
[2025-01-20 12:55:06] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/WZ Deckenlampe 1v6', payload '{"brightness":152,"color":{"x":0.4341,"y":0.4031},"color_mode":"color_temp","color_temp":329,"color_temp_startup":370,"effect":null,"last_seen":"2025-01-20T12:55:06+01:00","linkquality":116,"power_on_behavior":"previous","state":"OFF"}'

Here is my piviot table if someone is interested in:
Device | COUNTA von Device
0x94b216fffe50493e | 3
0xa4c138195b016da6 | 2
4er Schalter Arbeitszimmer | 1
Arbeitszimmer Dauerstrom Fenster | 21
Arbeitszimmer Fenster rechts links | 302
Arbeitszimmer Fenster rechts rechts | 342
Arbeitszimmer Präsenzmelder | 218
Bad Keller H&T | 14
Bad Keller Repeater | 99
bridge/event | 4
Briefkastenklappe | 4
Coordinator | 5
Dachboden Deko Repeater | 99
CHILD Schreibtisch | 248
Flur 1.OG Bewegungsmelder | 51
Flur 1.OG Deckenlampe | 344
Flur EG Bewegungsmelder | 133
Flur EG Deckenlampe | 180
flur_1.og | 57
Haustür Wassermelder | 5
Hue Dimmer | 15
HWR Einfahrt | 95
HWR Vibrationssensor links | 5
HWR Vibrationssensor rechts | 3
HWR Wassermelder | 4
Küche LED Arbeitsplatte Mikrowelle | 102
Küche LED Arbeitsplatte Spüle | 30
Kühlschrank | 255
Kühlschrank HWR | 258
CHILD 4er Lichtschalter Tür | 2
CHILD Deckenlampe 1v4 | 57
CHILD Deckenlampe 1v4/availability | 2
CHILD Deckenlampe 2v4 | 93
CHILD Deckenlampe 3v4 | 45
CHILD Deckenlampe 3v4/availability | 2
CHILD Deckenlampe 4v4 | 97
CHILD PC | 286
CHILDTV | 251
Netzwerkkeller Fenster | 3
Netzwerkkeller H&T | 24
Partykeller H&T | 18
Repeater Nebenraum | 132
Schlafzimmer Bett links | 249
Schlafzimmer Deckenlampe 1v4 | 208
Schlafzimmer Deckenlampe 2v4 | 207
Schlafzimmer Deckenlampe 2v4/availability | 2
Schlafzimmer Deckenlampe 3v4 | 208
Schlafzimmer Deckenlampe 4v4 | 207
Schlafzimmer Hue Aura | 22
Schlafzimmer Lichterschlauch TV | 88
sz_deckenlampe | 3
CHILD Deckenlampe 1v3 | 335
CHILD Deckenlampe 2v3 | 337
CHILD Deckenlampe 3v3 | 354
CHILD Flamingo | 24
CHILD Lichtschalter Tür | 26
CHILD Lichtschalter Tür/action | 4
CHILD_deckenlampe | 39
Teststecker | 250
Treppenhaus Haustür Bewegungsmelder | 43
Waschkeller H&T | 22
Waschkeller Hintertür | 4
Waschkeller Hintertür Vibrationssensor | 4
Wohnzimmer hinter Gardine Carport | 21
Wohnzimmer hinter Gardine Straße | 21
Wohnzimmer Kugel Sofa Küche | 21
Wohnzimmer LED Stripe hinter Sofa | 22
Wohnzimmer Sofa Kugel Carport | 21
Wohnzimmer Vitrine Finn | 47
Wohnzimmer Vitrine Küche | 42
WZ 4er Lichtschalter Tür | 51
WZ 4er Lichtschalter Tür/action | 15
WZ Deckenlampe 1v6 | 343
WZ Deckenlampe 2v6 | 342
WZ Deckenlampe 3v6 | 341
WZ Deckenlampe 4v6 | 342
WZ Deckenlampe 5v6 | 343
WZ Deckenlampe 6v6 | 342
wz_deckenlampe | 103
XMAS Carport | 248
XMAS Garage | 271
XMAS HWR | 262
XMAS Terasse | 255

[tomtom13]

Sooooooooooooooooooo few days ago, a slzb-06p10 arrived. I've used the advice of @sphings79 and the switch over was painless. Now the 6p10 version - it crashed only after 8 hours, while "bare 6" lasts few days. Soooo I guess I'm stuck for the time being with waiting for UZG. And yes, I've updated the firmware to newest version, I've disabled the updates, I've disabled the reporting of debug data to manufacturer etc etc. It's still "pretty bad".
What makes this whole ordeal worse is that from time to time, the 6p10 switches to usb only mode. Not fun.

You could try to flash it with the UZG FW and try again.

I shall try it (if it's possible) when I'll get few spare hours. Some pointer would be appreciated (like where to get UZG firmware from etc). IF that will work properly we'll know that at least hardware works OK. But we all know "it's all about the software" and I don't care that much about funky features like vpn etc, while I really really care about stability and performance.

[sphings79]

Sooooooooooooooooooo few days ago, a slzb-06p10 arrived. I've used the advice of @sphings79 and the switch over was painless. Now the 6p10 version - it crashed only after 8 hours, while "bare 6" lasts few days. Soooo I guess I'm stuck for the time being with waiting for UZG. And yes, I've updated the firmware to newest version, I've disabled the updates, I've disabled the reporting of debug data to manufacturer etc etc. It's still "pretty bad".
What makes this whole ordeal worse is that from time to time, the 6p10 switches to usb only mode. Not fun.

You could try to flash it with the UZG FW and try again.

I shall try it (if it's possible) when I'll get few spare hours. Some pointer would be appreciated (like where to get UZG firmware from etc). IF that will work properly we'll know that at least hardware works OK. But we all know "it's all about the software" and I don't care that much about funky features like vpn etc, while I really really care about stability and performance.

You can use the webinstaller. Just connect you SLZB via USB and got to https://xzg.xyzroe.cc/install/
And here is a link to the supported devices: https://xzg.xyzroe.cc/features/#supported-devices

[sphings79]

5 days, everything still fine with uzg

[Sortberg]

Hello. I just want to share my experience regarding the SLZB-06P7. Since January 7, I’ve been running with core version v2.6.8.dev26 and zigbee firmware 20240716. I’ve uninstalled my addon in Home Assistant and disabled the web interface when zigbee2mqtt is running. Since making these changes, I haven’t experienced my network going down. Previously, my network would crash daily, and all my devices became unavailable in zigbee2mqtt. I also had difficulty getting zigbee2mqtt to connect to the coordinator when starting the addon. Now, they connect to each other right away. One thing to be aware of is that some devices, especially Tuya, spam the network a lot, which can cause it to crash. For the first time in 5 months, my network is finally stable :)

[kevdogg]

I know this thread has been busy lately and although it's really evolved in the direction, I really love the testing going on with the UZG (which mine is currently sitting in a box since I just received it). I have an SLZB-06P7 running v2.6.8.dev28 with Radio 20240716. I described my setup previously a few weeks ago. I don't have any devices connected to this machine - no m2qtt, no devices, no HA integration. My uptime is now 15 days. I think the GUI issue has basically been solved by the dev26/28 releases. I'm going to add the z2mqtt and then just let this sit idle. As described above, the problem with the device freezing is likely due to zigbee "chatty" devices and I'm aware many in this forum have discussed putting together a list however I can see it being really hard to debug if you have many many devices connected to discover what exactly is going on. There isn't an equivalent of an "htop" that can be run on this device is there? Just curious. Anyway, I've really enjoyed this thread, keep the testing going!!

[tomtom13]

? wait, what ?
Mate, c'mon. So: when people report driving their cars report that at highway speed (large zigbee networks) their cars spontaneously lock up getting them stranded on the side of the road waiting for the road side assistance (me having to power down and up the device), you say I have my car on the drive way, without engine on just on battery maintainer (nothing, not even z2m connected) is the same ?
Sorry I had to go to that stupid analogy, but there was no other way to clearly demonstrate how polar opposite the scenarios were, and your test doesn't prove anything.

[techie-dreamer]

I know this thread has been busy lately and although it's really evolved in the direction, I really love the testing going on with the UZG (which mine is currently sitting in a box since I just received it). I have an SLZB-06P7 running v2.6.8.dev28 with Radio 20240716. I described my setup previously a few weeks ago. I don't have any devices connected to this machine - no m2qtt, no devices, no HA integration. My uptime is now 15 days. I think the GUI issue has basically been solved by the dev26/28 releases. I'm going to add the z2mqtt and then just let this sit idle. As described above, the problem with the device freezing is likely due to zigbee "chatty" devices and I'm aware many in this forum have discussed putting together a list however I can see it being really hard to debug if you have many many devices connected to discover what exactly is going on. There isn't an equivalent of an "htop" that can be run on this device is there? Just curious. Anyway, I've really enjoyed this thread, keep the testing going!!

You can take a log from z2mqtt (HA > Settings > AddOns > z2mqtt > Log tab) then download last 10k entries. Import that into google sheets, data to columns using ' as delimiter and create a pivot table. I'm not great at spreadsheets but pretty simple to create a count of device names, so you can see chatty devices. The issue is, why is it crashing with chattty devices? As I add more to my network, it's going to be very tricky to determine what's a chatty device (don't add) & whats not.

[alienatedsec]

@tomtom13 My GUI on SLZB-06 was freezing regularly before being updated to the latest dev26.

I used the source below to download firmware as my device seems to have issues with GUI's OTA downloads.
https://smlight.tech/flasher/#SLZB-06

[tomtom13]

I know this thread has been busy lately and although it's really evolved in the direction, I really love the testing going on with the UZG (which mine is currently sitting in a box since I just received it). I have an SLZB-06P7 running v2.6.8.dev28 with Radio 20240716. I described my setup previously a few weeks ago. I don't have any devices connected to this machine - no m2qtt, no devices, no HA integration. My uptime is now 15 days. I think the GUI issue has basically been solved by the dev26/28 releases. I'm going to add the z2mqtt and then just let this sit idle. As described above, the problem with the device freezing is likely due to zigbee "chatty" devices and I'm aware many in this forum have discussed putting together a list however I can see it being really hard to debug if you have many many devices connected to discover what exactly is going on. There isn't an equivalent of an "htop" that can be run on this device is there? Just curious. Anyway, I've really enjoyed this thread, keep the testing going!!

You can take a log from z2mqtt (HA > Settings > AddOns > z2mqtt > Log tab) then download last 10k entries. Import that into google sheets, data to columns using ' as delimiter and create a pivot table. I'm not great at spreadsheets but pretty simple to create a count of device names, so you can see chatty devices. The issue is, why is it crashing with chattty devices? As I add more to my network, it's going to be very tricky to determine what's a chatty device (don't add) & whats not.

Hey, I'm not having a jab at you specifically, OP was a bit weird but I honestly think that we need to stop giving the manufacturers free passes or creating excuses for them: If you had an ethernet switch or wifi access point that would crash when you start downloading large files close to the line speed / wifi saturation limit ... one would be fuming with anger, how come we are OK with zigbee coordinator not being able to comply with simple specification requirement? IT doesn't matter if there are thousand of devices that are pumping a message every second - if the network is slow as slug, great, the coordinator shall not crash or network shall not destabilise.

[andregoncalvespires]

I understand the frustration of being impacted by devices that do not meet the basic requirements. But in the case of the SLZB06-M, which is what I use, I don't see much difference in supporting devices that send a lot of messages compared to the Sonoff Dongle-e, for example.

I have 6 mmwave and 2 Tuya energy meters that generated/generated spam and had the same problems every time these devices were on the same network and I added more than 80 devices. The Z2m was very slow and many impacts were felt on the ZigBee network.

I started to have peace of mind when, at first, I divided the networks separating these devices from the others, and then, when I updated the mmwave firmware eliminating the distance reporting.

Today I have 92 devices on the network coordinated by the SLZB06-M. I had some problems with the Core versions with updates above 2.3.6. In dev version 2.6.26 I started to have stability and went 24 days without rebooting.

Therefore, I believe that the dongle is very functional, and that manufacturers should pay attention to delivering devices that meet certain requirements, such as not sending so many messages simultaneously. In the past, there was a warning on the page of devices supported by zigbee2MQTT, and the user would be aware of the risk when choosing.

I installed version 2.7.0. I hope it will be stable in the long term.

[fti7]

FYI: v2.7.0 is out

[techie-dreamer]

@matata86 "Improved Network Communication: A new Zigbee packet processing mode has been implemented. It groups all ZNP(ZSTACK), EMBER or EZSP packets and processes them at once (previously, only individual bytes were processed). "

Is this expected to help a network of 'chatty devices' which seems to be the failure point for my SLZB06 crashing at the moment (removing these device batteries has made it instantly more stable) as per here

[traffiqq]

@techie-dreamer Well, i don't have more informations on that.
The problem seems to be that the devices are to chatty and congest the zigbee network itself. Grouping that garbage after the coordinator received the data would not help improve the network situation.

The question remains if the problem is to many messages on the network or the handling of the messages on the coordinator. If its the problem is the coordinator maybe the option helps, time to try it out i suppose.

[tomtom13]

The problem seems to be that the devices are to chatty and congest the zigbee network itself. Grouping that garbage after the coordinator received the data would not help improve the network situation.

Not sure if you realise that, however zigbee messages are sent as a whole, not segmented. It doesn't matter how congested the network is, messages are being received one by one. If messages was interrupted mid flight it gets resent. This is why there is an "medium access negotiation" going on, "guard intervals", "re-transmit backoff randomisation" and on and on and on.
Sooooo, there is no need to process anything. Problem is that they have very dumb buffer management, and they push stuff down the TCP pipe as quickly as they can rather than allowing the message to come in completely before copying it to tcp write buffer. That leads to messages not being TCP packet aligned, if a packet gets dropped it should be resent by ESP32 (as per TCP spec), but who knows how that part is doing in reality on esp. Personally I would implement this as an UDP datagrams, allowing messages to get in out of sync, but who am I to judge.

[traffiqq]

Not sure if you realise that, however zigbee messages are sent as a whole

Well, depends on the message size:

Message Fragmentation is a process where a large message – too large to send in one APS packet – is broken down and transmitted as smaller fragments. The fragments of the larger message are then reassembled by the receiving device.

I am just starting my journey in debugging this because my network started failing a few weeks ago.
As of now i am unable to pinpoint the exact cause of the problem. Maybe it is my coordinator or a problem in the mesh itself ( aka some funny device ). I hope the logs contains something useful once the network collapses again.

they have very dumb buffer management
I didn't look into the firmware but maybe that can be fixed.

[tomtom13]

Well, depends on the message size:

That messages you are referring to are part of segmented transfer - which almost exclusively are binary file uploads (firmware upgrade) ... I don't see people complaining here about firmware updates failing, but just a normal network imploding on it self when a stupid light bulb sends back it's illumination status along with power socket reporting current power consumption.

[tomtom13]

2.7.0 - less than 3 hours and 6p10 collapsed on it self.

When trying to manually start Z2M it wasn't able to connect back to the coordinator:

While 6p10 web interface was working properly AND there was no error reported.

What I think at this point is that z2m has a problem. It will crash on some message that it's not supposed to receive (that's a bit bad)
Then the 6p10 just has a socket dangling (can be seen as "yes one client is still connected" in the gui, while z2m is just dead, stoped and all tcp link shall be closed by now)

Switching back to "bare 6" with 2.7.0. We'll see how long this one lasts.

[tomtom13]

I can add something to way that this is error occurred: After reviewing the logs and data received, the error in Z2M happened at 4:48, however as network was slowly collapsing - the last data was sent from temp sensor at 5:19. This is indicates to me more of a slow corruption than an instant crash.

[kevdogg]

Has anyone flashed the uzg firmware on the slzb06? I just received a uzb last weekend and I think the hardware is equivalent to a slzb06p7.

…

On Tue, Jan 21, 2025 at 1:47 PM sphings79 ***@***.***> wrote: 5 days, everything still fine with uzg — Reply to this email directly, view it on GitHub <#21157 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABH75V7NXRQPVQ7QZ767ONT2L2P3JAVCNFSM6AAAAABCWKS5AKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJQG4YTSMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[techie-dreamer]

Has anyone flashed the uzg firmware on the slzb06? I just received a uzb last weekend and I think the hardware is equivalent to a slzb06p7.
…
On Tue, Jan 21, 2025 at 1:47 PM sphings79 @.> wrote: 5 days, everything still fine with uzg — Reply to this email directly, view it on GitHub <#21157 (reply in thread)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABH75V7NXRQPVQ7QZ767ONT2L2P3JAVCNFSM6AAAAABCWKS5AKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJQG4YTSMQ . You are receiving this because you were mentioned.Message ID: @.>

No but interested in results & if there is any device re-pairing needed

[tomtom13]

zigbee chip is the same on slzb06p7 and UZG-01 - !!! HOWEVER !!! just because few chips are the same, it doesn't make the same hardware. Alto ESP is pretty flexible, I would be weary of just flashing random firmware left and right.

[ausycb]

Same issues with 2.7.1. back to my old Tuya hub

[traffiqq]

FYI:

I noticed a funny package in the logs:

That device sends the same package 6 times at the exact same time and it does that every 5 Minutes.
I set Debounce to 1 for that device and for now the stick seems stable.

[sphings79]

That won’t reduce the Zigbee network traffic.
Debounce is on the Z2M side.

[traffiqq]

Yes, that thought occurred to me too. Can't hurt tho.

[Vabis1010]

How do you debounce a device. Got two tuya devices with this problem?