[SLZB-06M] TCP bug: Sensors drop after 20s - Support ignores logs and suggests return for functional hardware

[anonymous66va]

What happened?

I am reporting a critical TCP instability with the SLZB-06M (EFR32MG21). I have spent several days providing detailed technical feedback and debug logs to SMLIGHT official support, but they have completely ignored my analysis. Despite my evidence showing NCP stack timeouts and ASH fatal errors, their only response was: "I would recommend returning this device."

Here is a clear example from my logs showing the 20-second drop behavior:
[30/12/2025, 16:48:15] z2m: Successfully configured '0xa4c138f5dc8e542f'
[30/12/2025, 16:48:35] z2m: Device '0xa4c138f5dc8e542f' left the network
The device is an Innr Smart E27 bulb. As you can see, it leaves the network exactly 20 seconds after a successful configuration without any manual intervention.

pairing_issue_log.txt

I want to be clear: the hardware is COMPLETELY FUNCTIONAL. I have identical sensors already paired that work perfectly. However, any new sensor (even the same model) joins the network and then leaves/drops after exactly 20 seconds. This is a clear firmware/driver bug in TCP socket management or the 'ember' stack, not a hardware failure. Suggesting a return for a functional device is an unacceptable way to handle a professional technical report.

What did you expect to happen?

New sensors should join the network and stay connected permanently, just like the identical models already present in my mesh. The TCP connection between Zigbee2MQTT and the SLZB-06M should remain stable without triggering NCP timeouts or ASH fatal errors. I expect a professional technical investigation into the debug logs to identify and fix this firmware or driver-level bug, instead of being told to return a perfectly functional device.

How to reproduce it (minimal and precise)

Connect an SLZB-06M coordinator in TCP/Ethernet mode (PoE or LAN).
Configure Zigbee2MQTT to use the ember adapter driver.
Ensure a mesh with existing devices is already running (e.g., on Channel 15).
Try to pair a new Zigbee sensor, even if it is the exact same model as others already working in the network.
Observe that the new sensor successfully completes the initial join, but consistently leaves the network or drops the connection after exactly 20 seconds.
Verify the debug logs to see NCP timeouts and ASH_NCP_FATAL_ERROR messages triggered during this specific phase.

Zigbee2MQTT version

2.7.1

Adapter firmware version

7.4.5 [GA]

Adapter

SMLIGHT SLZB-06M (EFR32MG21) - TCP/Ethernet mode using the 'ember' driver

Setup

Home Assistant Add-on running on Raspberry Pi 4 (using Home Assistant OS). Kernel/Machine info: 6.12.47-haos-raspi - arm64 Hardware details: Cortex-A72 (x4) CPU, 3788 MB RAM

Device database.db entry

No response

Debug log

[02/01/2026, 17:18:59] zh:controller: Interview for '0xa4c138ceeed862e3' started
[02/01/2026, 17:18:59] z2m: Device '0xa4c138ceeed862e3' joined
[02/01/2026, 17:19:00] zh:controller: Succesfully interviewed '0xa4c138ceeed862e3'
[02/01/2026, 17:19:00] z2m: Successfully interviewed '0xa4c138ceeed862e3', device has successfully been paired
[02/01/2026, 17:19:20] z2m: Device '0xa4c138ceeed862e3' left the network
[02/01/2026, 17:19:24] zh:controller: Interview for '0xa4c138ceeed862e3' started
[02/01/2026, 17:19:25] zh:controller: Succesfully interviewed '0xa4c138ceeed862e3'
[02/01/2026, 17:19:25] z2m: Successfully interviewed '0xa4c138ceeed862e3', device has successfully been paired
[02/01/2026, 17:19:46] z2m: Device '0xa4c138ceeed862e3' left the network

Notes

I have contacted SMLIGHT official support multiple times regarding this issue (Support Case/Ticket ID: ticket #9364 ]), providing them with full debug logs and a detailed analysis. Unfortunately, I have only received generic, scripted responses. Despite my evidence pointing to a systematic TCP stack timeout, their only solution was: "I would recommend returning this device," without even reviewing the technical data provided.

I want to emphasize that this is NOT a hardware failure. The unit is fully functional, as identical sensors already in the mesh work perfectly. The issue is strictly related to the pairing/interview process of new devices over TCP, which triggers a consistent 20-second drop loop. I am opening this issue here to get a proper technical review, as the manufacturer's support has refused to escalate this to their engineers.

[anonymous66va]

UPDATE - Further Testing: Hardware vs. Software isolation

I have performed a crucial test to isolate the issue. I configured a second SLZB-06M unit as a Zigbee Router instead of a Coordinator.

Results in Router Mode:

Stability: The device is perfectly stable and stays online without any drops.

Interview: The pairing and interview process completed successfully (green checkmark).

Firmware: Running version 7.4.5 [GA] (20250102).

Technical Conclusion: This test proves that the hardware (radio chip, antenna, Ethernet port) is fully functional. The "20-second drop" issue is strictly limited to the device acting as a Coordinator using the ember driver during the pairing/interview of new end-devices.

This rules out a hardware failure and points directly to a bug in the coordinator's firmware stack or the driver logic when managing the network's trust center/pairing phase.

[chris-1243]

Have you tried to update the firmware of your adapter? 7.4.5 is not the latest.

https://github.com/Nerivec/silabs-firmware-builder/releases/tag/v2025.6.2

[anonymous66va]

Hi @chris-1243, thank you. I want to be more precise about the firmware history:

I originally started with the latest firmware release, and this 20-second drop issue was present from the very beginning. I only performed the downgrade to 7.4.5 [GA] because SMLIGHT support insisted it was a mandatory troubleshooting step, but as I suspected, it changed nothing.

The bug exists regardless of the firmware version I've tried so far, including the latest ones. I will now re-flash to the specific build you linked (v2025.6.2) to ensure a clean state and I will report back shortly. Thank you for your help in investigating this.

[anonymous66va]

Update: I flashed the firmware version you suggested (8.2.2.0), but the issue persists exactly as before.

As you can see from the logs below, the device (Innr RF 271 T) is successfully interviewed and configured, but it leaves the network automatically after exactly 20-21 seconds.

[20:20:32] z2m: Successfully configured '0xa4c138f5dc8e542f'
[20:20:52] z2m: Device '0xa4c138f5dc8e542f' left the network

This is happening with multiple devices. Since I am using the SLZB-06M in TCP mode, could this be a timeout or a keep-alive issue in the zigbee-herdsman stack when dealing with the new ember driver?

[chris-1243]

Could you share a debug log of the pairing until the device leaves the network.
Debug log is always stored in a file. When done, set the log back to info.

Also, when pairing your bulb is it close to the coordinator or at its final location. Do you set permit join to all or do you choose a specific device/coordinator?

Since I am using the SLZB-06M in TCP mode, could this be a timeout or a keep-alive issue in the zigbee-herdsman stack when dealing with the new ember driver?

Many users use TCP based coordinator with ember without troubles. I do not think this is the problem.
On the other hand, there is a long discussion regarding the SLZB06 family and connection issue

[anonymous66va]

Hi @chris-1243,

I have performed a fresh flash of the 8.2.2.0 (GA build 436) firmware as requested and repeated the tests. Unfortunately, the behavior remains identical: the devices are kicked out of the network exactly 25 seconds after joining.

Crucial Update - Existing Devices Breaking: The issue is much broader than just new devices. I am seeing this with the TS0601 _TZE200_bjawzodf (Tuya Temperature & Humidity sensor). The most alarming part: even existing sensors that were working perfectly for months are now failing. If I change the battery on an old sensor, it tries to re-join the network, but it gets stuck in the same 25-second loop and is kicked out.

I currently have 4 or 5 of these sensors already in the network that are working, but any "fresh" security handshake (new pairing OR re-pairing after power loss/battery change) is failing.

Observations: The log shows a successful interview and configuration for the Innr bulb (0xa4c138f5dc8e542f). However, precisely 25 seconds later, it leaves the network. The timing is 100% consistent across different devices (Innr bulbs and Tuya sensors).

Here is the log showing the join/leave cycles:

[2026-01-03 11:43:01] info: zh:ember: Adapter version info: {"ezsp":18,"revision":"8.2.2 [GA]","build":436}

// --- EXAMPLE: INNR BULB JOIN AND DROP ---
[2026-01-03 11:44:50] debug: zh:controller: Device '0xa4c138f5dc8e542f' joined
[2026-01-03 11:44:50] info: z2m: Starting interview of '0xa4c138f5dc8e542f'
[2026-01-03 11:44:52] info: z2m: Successfully interviewed '0xa4c138f5dc8e542f', device has successfully been paired
[2026-01-03 11:44:52] info: z2m: Successfully configured '0xa4c138f5dc8e542f'

// --- THE DROP (Exactly 25 seconds later) ---
[2026-01-03 11:45:15] debug: zh:controller: Device leave is from unknown or already deleted device '0xa4c138f5dc8e542f'
[2026-01-03 11:45:15] info: z2m: Device '0xa4c138f5dc8e542f' left the network

This confirms the issue is systematic and affects the Trust Center key establishment logic in the ember driver. It's effectively preventing any device from (re)joining the network securely.

Is there any specific adapter configuration I can test to increase the KEY_ESTABLISHMENT_TIMEOUT or a similar parameter?"

EDIT:
I also tested the following configuration to see if it would mitigate the timeout, but with no success:

adapter:
wait_for_tc_connect: true

The devices (Innr bulb and Tuya TS0601) still keep joining and leaving in an endless loop. The log shows the leave event repeating at every time a pairing is attempted. This confirms that the issue is not just a simple timing delay but a fundamental failure in the security handshake with the ember adapter."

[chris-1243]

There have been some minor changes in ember in latest Z2M version (2.7.2), could you try to update?

Also, would you share a full debug log in order to see what is going on?

I will try to reproduce this behavior on a test network.

@Nerivec My apologizes to ping you directly. Do you have any idea what could go wrong. Any tweak in ember or in Z2M in general we may apply to solve this?

[anonymous66va]

Hi @chris-1243, thank you for the feedback.

To answer your points and provide the latest data:

Z2M Version: I can confirm I am already running Zigbee2MQTT 2.7.2 (as shown in the first line of my previous log).

Join via Router (New Test): Following my previous post, I tried pairing the Innr bulb through a known-good router (a smart plug). The result is the same: it completes the interview but gets kicked out after exactly 25 seconds.

Full Log: I am attaching the full debug log file to this comment so you and @Nerivec can see the entire startup sequence and the multiple failed pairing attempts.

It really seems that any device requiring a fresh Trust Center exchange (new pairing or re-join after power loss) is being rejected by the ember driver after the 25-second timeout, regardless of the path (direct or via router).

Looking forward to your and @Nerivec's thoughts on this.

log.txt

[Nerivec]

I see a few misconceptions:

• Testing router vs coordinator firmware would confirm the hardware is functional but that's it, it would not point to a coordinator firmware bug, at least not without much deeper testing (the two are completely different).
• TCP socket instability could cause ASH_NCP_FATAL_ERROR or similar, but I don't see any in latest log.
• The ember stack (Z2M side) is not involved in the device verification process, that's entirely done by the coordinator (NCP), Z2M only allows/disallows joins and does the interview (gathering data from the device).
• TCP socket would have no bearing on a device leaving on its own.

First step: remove this device from your network, and never use it again.

Repeater Matrimoniale (0x04cd15fffe0c438d): TS0207_repeater - Tuya Repeater (Router)

Cf: https://www.zigbee2mqtt.io/devices/TS0207_repeater.html#warning

This kind of issue (join loop) is usually because the key exchange does not go well, which results in the device leaving, however this requires a sniff to confirm (Z2M appears to show as confirmed in latest log, but would need a sniff to be sure).
But, with the presence of the above Tuya repeater (which is the equivalent of a blackhole), all bets are off....
Once removed, restart Z2M, and let the network settle (12-24h). Then retry joins, and report back.

[anonymous66va]

Hi @chris-1243 and @Nerivec,

Quick update: I have successfully removed the Tuya repeater (0x04cd15fffe0c438d). It was removed cleanly from the Z2M device list and I have physically unplugged it.

I also restarted Zigbee2MQTT. As suggested, I am now letting the network settle and I will not attempt any joins for the next 24 hours. I will report back tomorrow with the results.

Thank you both for the great support so far!

[anonymous66va]

Hi @Nerivec,

I'm providing an update and more technical evidence regarding the connection drops on the SLZB-06M using the ember driver.

Environment cleanup (Crucial): Following the previous troubleshooting steps, I have now completely removed the Tuya repeater (specifically the TS0207_repeater model) from the network. All tests described below were conducted in a clean, point-to-point environment with devices attempting to connect directly to the SLZB-06M coordinator.

1. Device Comparison & Observations:

   Success: A Moes Dimmer (TS0601) was re-paired successfully and remains stable.

   Failure: Both an Innr Smart Bulb (RF 271 T) and a Tuya Temp/Hum Sensor (TS0601 _TZE200_bjawzodf) exhibit the same failure pattern. They complete the interview and configuration, but leave the network exactly 19-20 seconds after the "Successfully configured" message.

2. ASH Layer Analysis: The logs during the failed pairing of the "chatty" devices (bulb and sensor) show a massive asymmetry in ASH flow control, which doesn't happen with the simpler Moes dimmer:

   ACK frames: RX=2, TX=531

   Retry frames: RX=22, TX=2

The driver is flooded with Timer expired waiting for ACK errors right after the configuration phase:

[2026-01-04 11:36:04] debug: zh:ember:uart:ash: Timer expired waiting for ACK for frmTx=2
[2026-01-04 11:36:04] debug: zh:ember:uart:ash: ---> [FRAME type=DATA frmTx=2 frmRx=2](ackRx=2) RE-TX
...
[2026-01-04 11:38:38] info: zh:ember:uart:ash: ACK frames : RX=2, TX=531

3. Attempted Workarounds: I tried to adjust the serial settings in configuration.yaml (increasing command_timeout to 5000ms and adding an adapter_delay of 100ms), but the 20-second drop persists.

It seems that when the traffic volume increases, the ASH-over-TCP synchronization fails. This likely causes the Trust Center to force a "Leave" command because the security handshake or final network steering bits aren't acknowledged in time.

I am attaching the full log.txt for your analysis.

log.txt

[Nerivec]

• ASH can piggyback ACKs on DATA frames and tx/rx would be different depending on the device (since interview processes can be very different), also is affected by the devices that would e.g. announce the join, and of course the rest of the network traffic. In short, large/small discrepancies are entirely expected.
• I only see two ACK timer expiry in your log, and they both are retried successfully.
• command_timeout doesn't exist https://www.zigbee2mqtt.io/guide/configuration/all-settings.html
• adapter_delay is only used by deconz driver https://www.zigbee2mqtt.io/guide/configuration/adapter-settings.html#advanced-configuration
• Good networks of over 150 devices can execute several simultaneous OTA updates, which is by far the largest spammer, so no problem there as far as ASH is concerned.

In any case, real problems with ASH layer would be catastrophic since it would take down the entire communication with the network, which is not the case here.

[2026-01-04 11:38:06] debug: 	zh:ember:ezsp: ezspTrustCenterJoinHandler: newNodeId=30182 newNodeEui64=0xa4c138f5dc8e542f status=STANDARD_SECURITY_UNSECURED_JOIN policyDecision=USE_PRECONFIGURED_KEY parentOfNewNodeId=0
...
[2026-01-04 11:38:06] info: 	zh:controller: Interview for '0xa4c138f5dc8e542f' started
...
[2026-01-04 11:38:07] info: 	z2m: Successfully interviewed '0xa4c138f5dc8e542f', device has successfully been paired
[2026-01-04 11:38:07] info: 	z2m: Device '0xa4c138f5dc8e542f' is supported, identified as: Innr Smart E27 filament LED globe light bulb (RF 271 T)
[2026-01-04 11:38:07] info: 	z2m: Configuring '0xa4c138f5dc8e542f'
...
[2026-01-04 11:38:07] info: 	z2m: Successfully configured '0xa4c138f5dc8e542f'
...
[2026-01-04 11:38:07] debug: 	zh:ember:ezsp: ezspZigbeeKeyEstablishmentHandler: partner=0xa4c138f5dc8e542f status=TC_RESPONDED_TO_KEY_REQUEST
[2026-01-04 11:38:07] debug: 	zh:ember:ezsp: ezspZigbeeKeyEstablishmentHandler: partner=0xa4c138f5dc8e542f status=TC_REQUESTER_VERIFY_KEY_SUCCESS
...
[2026-01-04 11:38:09] debug: 	z2m: Received Zigbee message from '0xa4c138f5dc8e542f', type 'readResponse', cluster 'genOnOff', data '{"onOff":1}' from endpoint 1 with groupID 0
...
[2026-01-04 11:38:12] debug: 	zh:ember:ezsp: ezspIncomingRouteRecordHandler: source=30182 sourceEui=0xa4c138f5dc8e542f lastHopLqi=168 lastHopRssi=-69 relayCount=0 relayList=
...
[2026-01-04 11:38:27] debug: 	zh:ember:ezsp: ezspTrustCenterJoinHandler: newNodeId=30182 newNodeEui64=0xa4c138f5dc8e542f status=DEVICE_LEFT policyDecision=NO_ACTION parentOfNewNodeId=65535

As far as I can see (same pattern as above block holds for most cases), the device joins successfully, does the interview successfully, exchanges a few messages, and then leaves.

Have you tried permit joining on a specific nearby router instead of coordinator/all?

If that still does not work, I suggest you flash one of your adapter-router back to coordinator (temporarily), so you can sniff the join-leave behavior. We need to see what's happening on the network that Z2M is not able to see.
https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html#with-emberznet-and-husbzb-1-adapters

[hirtema]

@anonymous66va i also have a SLZB-06M, fortunatelly any of your problems so far, but here are two thoughts you might also consider in hunting down your problem:

1.) what is the setting of the "socket processing option" down in the SLZB-06M "Z2M / ZHA" menu? Maybe turning this to "on" can help if it's still off. This should reduce overhead in the SLZB's network socket to serial converter. And of course prefer LAN over wifi connection to rule out any network related topics that may add additional problems.

2.) you wrote you flashed firmware based on SDK 8.2.2.0, that should be development revision "20251204" in the built-in OTA radio update menu of the SLZB-06M. I also tried this firmware some time ago, but for me it had problems and so i reverted back to the latest stable firmware based on SDK 8.0.2. (stable revision "20250220" in the radio OTA update dialog), which is rock-solid for my network.

When having 2.) i also saw ASH "problems" in the logs, it looked like the radio didn't answer any more after Z2M issued two route requests in the same second (based on log timestamp), then the timeout watchdog got angry and initiated restart.

When looking at your logs i didn't see the problem i saw in my logs so far, but maybe you can keep that firmware topic in mind.

[anonymous66va]

Hi @Nerivec and @Irtema,

I have an important update. I followed @Irtema's suggestion and enabled the "Socket processing option" on my SLZB-06M.

Technical Results:

ASH Layer Stability: The transport layer is now much cleaner. Looking at the logs, the ACK asymmetry is gone, and there are no more "Timer expired" errors. The TCP tunnel is now performing correctly.

The "20-second drop" persists: Despite the stable communication, the network "bouncer" is still kicking out devices. I tested multiple devices with the same result:

    Innr Smart Bulb (RF 271 T): Successfully interviewed at 17:04:47 -> Forced to leave at 17:05:07.

    Tuya Temp/Hum Sensor (TS0601 _TZE200_bjawzodf): Same 20-second deterministic drop.

    Xiaomi/Lumi sensors: Also showing erratic behavior during the join phase.

Conclusion: Since the ASH transport issues are now resolved but the devices are still being expelled exactly 20 seconds after a successful interview, this confirms the issue is logical and resides within the SDK 8.2.2.0 Trust Center/Security handshake.

The coordinator seems to fail the final Link Key exchange validation and issues a forced "Network Leave" command. This matches @Irtema's experience where reverting to the 8.0.2 stable SDK resolved similar ASH/stability issues.

However, I am staying on this DEV firmware to help you investigate why this SDK version is failing with strict Zigbee 3.0 devices while older devices (like my Moes Dimmer) manage to stay connected.

I am attaching the new log (with Socket Processing ON) for your analysis.

log.txt

POST UPDATE

have further evidence to share. I enabled the "Socket processing option" as suggested, and I am also providing the internal logs from the SLZB-06M to rule out hardware or network-level issues.

1. Observations from the Coordinator System Log: The logs show that the SLZB-06M hardware is operating perfectly at the system level. The Ethernet connection is stable, and there are no reboots or socket crashes during the tests. However, a low-level EZSP glitch was noted at boot: EZSP frame < 4 bytes!.
   Plaintext

[04.01.2026 15:51:16] setup | Starting firmware: v3.1.3
[04.01.2026 15:51:19] Network | Network up
[04.01.2026 15:51:19] SocketServer | [EFR32MG21] Starting packet mode server on port: 6638
[04.01.2026 15:51:19] SocketServer | [EFR32MG21] EZSP frame < 4 bytes!
[04.01.2026 16:51:24] EventSender | [_handleNewClient] new client: 10.0.0.122
[04.01.2026 16:51:39] SocketServer | [EFR32MG21] New client, id: 0
[04.01.2026 17:13:50] internet state | Heap: 3100

2. Pairing Test Results (Socket Processing ON):

   ASH Layer: The transport layer is now significantly cleaner. The ACK asymmetry I reported earlier is gone, and the TCP tunnel is performing correctly without "Timer expired" errors.

   The "20-second drop" persists: Despite the stable communication, the devices are still being kicked out exactly 20 seconds after the successful interview.

    Innr Smart Bulb (RF 271 T): Interview OK (17:04:47) -> Forced Leave (17:05:07).
   
    Tuya Temp/Hum Sensor (TS0601): Same deterministic 20s drop.
   
    Xiaomi/Lumi sensors: Also showing erratic behavior during the join phase.
   

Technical Conclusion: The SLZB-06M hardware and its Ethernet-to-Serial bridge are stable. Since the ASH transport issues are resolved but the 20-second drop remains identical across multiple brands (Innr, Tuya, Xiaomi), this points directly to a logical failure within the SDK 8.2.2.0 Trust Center/Security handshake.

It seems the coordinator (or the driver) fails to validate the final Link Key exchange, triggering a forced "Network Leave" command. I am staying on this DEV firmware to assist with further debugging of this specific SDK regression.