[Bug]: Ember adapter crashes with ASH_ERROR_TIMEOUTS when processing Schneider PowerTag R9M70 (ZGP)

[Automatisierer0]

What happened?

Zigbee2MQTT crashes consistently (after approx. 5-10 minutes) when a Schneider PowerTag R9M70 is active in the network. The crash is triggered by Green Power (ZGP) frames being proxied through a Philips Hue Smart Plug. The logs show ECONNRESET followed by HOST_FATAL_ERROR or ASH_ERROR_TIMEOUTS within the zigbee-herdsman EZSP/Ember stack, specifically when trying to set or update multicast table entries or configuration values.

[2026-06-15 01:54:52] error:     zh:ember:ezsp: ERROR Transaction failure; status=ASH_ERROR_TIMEOUTS. Last Frame: [FRAME: ID=83:"SET_CONFIGURATION_VALUE" Seq=12 Len=9].
[2026-06-15 01:54:52] error:     z2m: Error while starting zigbee-herdsman
[2026-06-15 01:54:52] error:     z2m: Failed to start zigbee-herdsman
[2026-06-15 01:54:52] error:     z2m: Error: ASH_ERROR_TIMEOUTS
    at Ezsp.ezspSetConfigurationValue (/app/node_modules/.pnpm/zigbee-herdsman@10.4.0/node_modules/zigbee-herdsman/src/adapter/ember/ezsp/ezsp.ts:1510:19)
    at EmberAdapter.emberSetEzspConfigValue (/app/node_modules/.pnpm/zigbee-herdsman@10.4.0/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:1450:24)
    at EmberAdapter.initEzsp (/app/node_modules/.pnpm/zigbee-herdsman@10.4.0/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:692:9)
    at EmberAdapter.start (/app/node_modules/.pnpm/zigbee-herdsman@10.4.0/node_modules/zigbee-herdsman/src/adapter/ember/adapter/emberAdapter.ts:1544:24)

Additionally, the log frequently shows:
zh:ember: Delivery of BROADCAST failed for '65533'.

Steps to reproduce the behavior

• Coordinator: SMLIGHT SLZB-06MU (EFR32MG21).
• Device: Schneider PowerTag R9M70 (Green Power) paired via a Philips Hue Plug (acting as GPP).
• PowerTag sends periodic ZGP energy reports.
• Z2M attempts to write to the ZGP multicast table or configuration, fails, loses the serial connection, and enters an infinite restart loop.

System/Debug Information

• Home Assitant V2026.6
• Zigbee2MQTT version: 2.12.0
• Zigbee-herdsman version: 10.4.0
• Coordinator hardware: SMLIGHT SLZB-06MU
• Coordinator firmware version: 20250220
• Coordinator MCU firmware: v3.3.1
• Adapter type: Ember (EZSP)
• Operating system: Home Assistant OS (Add-on)
• Connection type: TCP (Direct Ethernet connection to SLZB-06MU)

here the yaml

version: 5
mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://core-mosquitto:1883
  user: addons
  password: Ohch0cai8uwiNu8mahy4Ath7thohchooxeithoo2oo1oel7naechahtai9reeRuz
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
serial:
  port: tcp://192.168.0.138:6638
  baudrate: 115200
  adapter: ember
queue:
  delay: 15
  simultaneous_requests: 5
  availability: false
advanced:
  log_level: error
  channel: 11
  network_key:
    - 212
    - 6
    - 45
    - 17
    - 34
    - 211
    - 174
    - 96
    - 163
    - 49
    - 155
    - 222
    - 17
    - 179
    - 61
    - 121
  pan_id: 24710
  ext_pan_id:
    - 1
    - 113
    - 127
    - 210
    - 193
    - 232
    - 225
    - 172
  enable_external_js: false
frontend:
  enabled: true
  port: 8099
homeassistant:
  enabled: true
devices:
  '0x001788010f07f50a':
    friendly_name: Steckdose_Stiege
  '0x00000000e206a922':
    friendly_name: Energie_Poolpumpe
  '0x00000000e206b1f4':
    friendly_name: Energie_Geschirrspüler
  '0x54ef441001528e36':
    friendly_name: Bewegungsmelder_BAD

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

2.12.0

Adapter firmware version

SLZB OS: v3.3.1 -- Coordinator firmware version: 20250220

Adapter

Coordinator hardware: SMLIGHT SLZB-06MU

Setup

Home Assistant in KVM. Host Linux Mint.

Device database.db entry

No response

Debug log

No response

Notes

No response

[Nerivec]

Can you provide a debug log?
https://www.zigbee2mqtt.io/guide/configuration/logging.html#debugging

ECONNRESET means the adapter closed the connection on its end (SMLight core part). Can you also provide the logs from the SMLight UI?

[Automatisierer0]

Here is the log file for issue #32308.

Zigbee2MQTT Logs:
The logs demonstrate how the connection fails when processing Schneider PowerTag (ZGP) frames.
I am running the coordinator via a wired LAN connection (TCP-to-Serial bridge).
My local network is stable with 0% packet loss.
As shown, the initialization is delayed (RSTACK timeouts) and the driver immediately forces a fallback to EZSP protocol version 14.
Under load, specifically when the PowerTag/Hue environment is active, the connection consistently crashes after ~45-60 seconds.
It appears the current timeout thresholds for EZSP/TCP-based coordinators are too strict to handle the additional processing time required for these specific ZGP frames, causing the software to treat a transient delay as a fatal connection drop.

SMLight UI Logs:
Confirming that the SLZB-06MU hardware remains perfectly stable during the Z2M crash, showing no socket errors or disconnects.
The SMLight log starts at 21:03 due to the initial time synchronization and log rotation.
It confirms that the hardware remained perfectly stable during the Z2M crash period, showing no socket errors or disconnects.

[01.01.1970 00:00:00] setup | Starting firmware: v3.3.1
[01.01.1970 00:00:00] getDevType | using SLZB
[01.01.1970 00:00:00] setup | FS mounted
[01.01.1970 00:00:00] Config | load config
[01.01.1970 00:00:00] Config | config open: Ok
[01.01.1970 00:00:00] setup | HWCDC started
[01.01.1970 00:00:00] setup | Reboot reason: POWERON
[01.01.1970 00:00:00] setup | starting ZB1 serial on: 115200 baud. HW Flow: off
[01.01.1970 00:00:00] setup | Coordinator mode: LAN
[01.01.1970 00:00:00] setup | Device: 'SLZB-06MU' PCB revision: 173
[01.01.1970 00:00:00] setup | Radio mode: "ZB COORD" Radio FW version: 20250220 Radio FW CH: PROD
[01.01.1970 00:00:00] Network | init
[01.01.1970 00:00:00] taskAP | start task
[01.01.1970 00:00:00] Network | EVENT: 1 - ETH_START
[01.01.1970 00:00:00] Network | ETH init: OK
[01.01.1970 00:00:00] Network | ETH static IP config: OK
[01.01.1970 00:00:00] setup | Filesystem size: 3456
[01.01.1970 00:00:00] setup | Filesystem used: 252
[01.01.1970 00:00:00] setup | SM Console started
[01.01.1970 00:00:00] setup | done
[01.01.1970 00:00:02] [LEDs init] | done
[01.01.1970 00:00:02] Network | EVENT: 3 - ETH_CONNECTED
[01.01.1970 00:00:02] Network | EVENT: 5 - ETH_GOT_IP
[01.01.1970 00:00:02] Network | ETH MAC: 5A:E6:C5:46:A0:50 IPv4: 192.168.0.138 GW: 192.168.0.1 Speed: 10Mbps DNS1: 192.168.0.1 DNS2: 8.8.8.8
[01.01.1970 00:00:02] Network | AP task deleted
[01.01.1970 00:00:02] Network | Network up
[01.01.1970 00:00:02] SocketServer | [EFR32MG21] Setup done
[01.01.1970 00:00:02] SocketServer | [EFR32MG21] Task started
[01.01.1970 00:00:02] SocketServer | [EFR32MG21] Started server on port: 6638
[01.01.1970 00:00:02] Network | [mDNS] Started
[01.01.1970 00:00:02] loadMqttConfig | config does not exist! Using defaults
[01.01.1970 00:00:02] Web | Web services init done
[01.01.1970 00:00:02] time | time sync start
[01.01.1970 02:00:02] internet | connected
[01.01.1970 02:00:02] Network | [POST] result: 200
[01.01.1970 02:00:02] stats | Statistics sent
[01.01.1970 02:00:02] stats | Heap: 3684
[16.06.2026 21:03:34] time | timezone: EET-2EEST,M3.5.0/3,M10.5.0/4
[16.06.2026 21:03:34] time | Tuesday, June 16 2026 21:03:34
[16.06.2026 21:03:34] taskTimeSync | Heap: 1920
[16.06.2026 21:03:34] time | stop task
[16.06.2026 21:03:34] time | Heap: 1920
[16.06.2026 21:46:13] internet state | Heap: 2884
[16.06.2026 21:46:14] SSE | new client: 192.168.0.222
[16.06.2026 21:46:14] internet state | Heap: 2328

I hope this helps to fix the issue.

log - 2026_06_16.log

[Nerivec]

ECONNRESET has nothing to do with EZSP (the Zigbee stack is not involved in the TCP transportation - that's the job of the SMLight core part).
The error means the TCP socket was abruptly closed by the peer (here, the adapter). It can also be from something terminating the connection (like a firewall/proxy, or a network disruption).

The SMLight UI logs doesn't appear to match the Z2M logs:

[16.06.2026 21:46:14] SSE | new client: 192.168.0.222

[2026-06-16 18:48:13] debug: 	zh:ember:uart:ash: Opening TCP socket with 192.168.0.138:6638
[2026-06-16 18:48:13] debug: 	zh:ember:uart:ash: Socket connected
[2026-06-16 18:48:13] info: 	zh:ember:uart:ash: Socket ready

Assuming the hour difference is timezone config mismatch, there's still a weird 2-minute-ish difference. Are these from same startup of Z2M?
The SMLight UI log also doesn't show any disconnect, which is weird.

I'm not seeing any ASH_ERROR_TIMEOUTS in that log. This suggests you may be experiencing two separate issues, or a general TCP instability, which can result in various errors.

Note: There are quite a few people using powertags (and even more using GP), I haven't seen any report of this being linked to them before. But, just in case, it might be good to see what behavior you get after removing them from the network.

[Automatisierer0]

Thanks for your reply.
Since you responded, I have conducted several investigations and tests to narrow down the root cause and provide you with more precise data. I want to clarify the situation with my network setup, as it is key to identifying the issue.
My network infrastructure consists of the following components and connections:
* Host (Home Assistant): Connected to 'Switch Büro'.
* Switch Büro: Connected to 'Master Switch'.
* SLZB-06MU (Coordinator): Connected to 'Switch Schuhe'.
* Switch Schuhe: Connected to 'Master Switch'.

The findings:
My network is stable with no packet loss and I have fixed IP addresses for all devices.
I have discovered that the ECONNRESET / ASH_ERROR_TIMEOUTS issue is highly sensitive to the network path:

• When I connect the SLZB-06MU directly to the 'Master Switch', the system runs stable for hours.
• When I connect it to the 'Switch Schuhe' (which adds the hop: Switch Schuhe -> Master Switch -> Switch Büro to the host), the crashes occur consistently within minutes.

This confirms that the ember adapter's ASH-layer is sensitive to the minimal latency variations introduced by the additional switch hop during ZGP processing. I suspect that the specific nature of ZGP traffic, which is processed via a proxy (Philips Hue Bridge in my case), creates a timing pattern that is particularly prone to these timeouts when the connection is not perfectly direct.

Could we explore the following areas to make the adapter more robust to network fluctuations?

• Adjusting the ASH timeout threshold: Perhaps the default threshold could be increased slightly to better accommodate network-induced latency in multi-switch environments.
• Enhanced recovery mechanism: Would it be feasible to implement an auto-reconnect strategy that attempts to reset the serial connection without requiring a full zigbee2mqtt service restart?
• ZGP frame processing: Since ZGP frames often arrive in bursts via the Hue Bridge proxy, could the handling of these frames be optimized to prevent them from hitting the ASH layer's limits?

I believe these adjustments would be a great step forward for the stability of LAN-based coordinators.
As you can see in the logs I posted earlier, the ECONNRESET occurs exactly when these timeouts happen.
I am happy to provide further debug logs or test specific configurations if that helps.

[Nerivec]

Adjusting the ASH timeout threshold

The timeout handling is already pretty involved, as it will adapt to latency automatically (400..2400, with starting value of 800). Should be more than enough, which indicates the network may not be as stable as you think.
Note: It is irrelevant to Zigbee traffic. This is only for Z2M<>adapter low-level traffic.

reset the serial connection without requiring a full zigbee2mqtt service restart

Has been used in the past, but this causes more problems than it solves (too many things would need pausing/resuming capabilities). Restart of the adapter is the biggest part of the Z2M restart in any case.

The ECONNRESET is not linked to timeouts in your previous logs. In any case, you'd get one or the other, not both (first received would end the process).
ECONNRESET is not linked to ASH either; it is TCP layer.
I also don't think your issue is with ZGP in particular (at least I haven't seen anything that points to it yet), it's just a general latency issue between the adapter and Z2M - which explains why you randomly see the two likely errors in that scenario, ASH timeouts, or TCP drops.
Could be as simple as a hop becoming temporarily overwhelmed at random intervals from various network activities; might need to watch traffic more closely on each hop. Could also be one of the switches isn't doing its job very well anymore.
There has also been some cases of very strange behavior when some devices are present on the same network (e.g.).

[Automatisierer0]

Thanks for the clarification regarding the ASH/TCP layer separation.
As I stated in my initial report, the issue is strictly correlated with the network path and the hardware used.
I have now verified this through further testing:

My network infrastructure consists of the following components and connections:

• Host (Home Assistant): Connected to 'Switch Büro'.
• Switch Büro: Connected to 'Master Switch'.
• SLZB-06MU (Coordinator): Connected to 'Switch Schuhe'.
• Switch Schuhe: Connected to 'Master Switch'.

Result:

• The switch "Schuhe" is a Netgear GS105 (unmanaged).
  When the SLZB-06MU is connected via the Netgear GS105, the crashes occur consistently, even though the network has virtually
  no other traffic and the cables are verified as 100% functional.
• The master switch ist a Netgear GS115 (Smart Managed Plus-Switch).
  When the SLZB-06MU is connected directly to the master switch the system is 100% stable.

It seems that the Ember adapter's sensitivity to timing and latency is incompatible with the buffer/switching behavior of the GS105, while the GS115 handles it without issue. Since you noted that the timeout logic is adaptive but requires high stability, it seems the GS105 cannot maintain the tight latency requirements the adapter expects.

Furthermore, I suspect that the issue is not just the GS105 itself, but the cumulative effect of the cascaded switch setup (SLZB-06MU -> GS105 -> GS115 -> Switch Büro -> Host). This multi-hop path likely introduces just enough cumulative jitter and buffer delays to push the Ember adapter beyond its timing thresholds. The fact that the direct connection to the GS115 resolves it instantly confirms that the 3-switch cascade is the root cause of the timing instability.

I will move the coordinator to the GS115 permanently to bypass this hardware limitation.

Thank you for your time and for pointing me in the right direction.

[Nerivec]

2.4sec (the max adaptive timeout), should be more than enough though (that's crazy long in network-timing).
I'd be curious to see if another switch of same model behaves the same; I'd be more inclined to think that one specifically has an issue (or a misconfiguration of some kind).

But definitely, the more hops you have, the more likely it is to cause troubles (same goes for Zigbee networks depth by the way).

Worth noting that issues in the "core" part of the firmware can cause ASH timeouts (from the adapter-side); it's been know to happen when the core chip is overwhelmed, like a bug that slows it down, etc.. Watch out for update notes on that front.

[jbouv55151]

I think I am experiencing a very similar issue, but with a different setup.

My hardware:

• Raspberry Pi 5 (Home Assistant OS)
• Zigbee2MQTT add-on
• SLZB-06Mg26
• Ember adapter
• Ethernet TCP
• PoE
• Stable coordinator firmware 20240602
• ~128 Zigbee devices
• About 36 Legrand routers
• 5 Green Power Legrand ZLGP17/ZLGP18

Unlike the original report:

• I do not have any Schneider PowerTag devices.
• The coordinator is connected directly to my main switch.
• There are no intermediate switches between Home Assistant and the coordinator.

The network has been thoroughly investigated.

Already tested:

• Sonoff ZBDongle-E (USB, Ember)
• SLZB-06Mg26 (Ethernet, Ember)
• coordinator firmware upgrades/downgrades
• USB coordinator replaced by Ethernet coordinator
• adapter_concurrent = 8, 4 and 2
• removed suspected faulty devices (LiXee)
• disabled Zigbee automations
• verified Ethernet connectivity
• verified PoE power
• Wi-Fi moved away from Zigbee channel
• MQTT stable
• Home Assistant remains fully stable while Zigbee2MQTT crashes

Despite all of this, I still get repeated:

• ASH_NCP_FATAL_ERROR
• ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT
• Adapter disconnected

The coordinator logs remain perfectly normal during these crashes.

This makes me wonder whether there could be another cause triggering the same Ember failures besides network latency.

I can provide complete Zigbee2MQTT logs and SMLIGHT logs if useful.