OTA firmware upgrade fails and crashes Z2M on Sonoff devices

[vinne81]

What happened?

I want to upgrade a Sonoff ZBMINIR2 firmware trough Z2M. Current firmware is 1.0.2. Available firmware is 1.0.4. I click "Update device firmware" in Z2M front-end, it starts. After a short while, Z2M crashes.

Others having this issue as well: https://community.home-assistant.io/t/error-messages-trying-to-ota-update-devices-using-z2m-on-a-ha-yellow/788913

What did you expect to happen?

That the upgrade process would complete and that I would have firmware 1.0.4 on my device.

How to reproduce it (minimal and precise)

Open Z2M front-end
Navigate to OTA
Click Update device firmware on ZBMINIR2.

Zigbee2MQTT version

2.0.0 commit: 060ae99

Adapter firmware version

7.4.4 [GA]

Adapter

SONOFF ZigBee 3.0 USB type E

Setup

Z2M manually installed on Rasp + Mosquito + HA core

Debug log

Jan 13 09:37:08 rasp pnpm[497207]: [2025-01-13 09:37:08] debug: z2m: Received Zigbee message from 'ZBMINIR2 16spots', type 'commandImageBlockRequest', cluster 'genOta', data '{"fieldControl":0,"fileOffset":32550,"fileVersion":4100,"imageType":8,"manufacturerCode":4742,"maximumDataSize":63}' from endpoint 1 with groupID 0
Jan 13 09:37:09 rasp pnpm[497207]: [2025-01-13 09:37:09] debug: zh:ember:uart:ash: <--- [FRAME type=ERROR]
Jan 13 09:37:09 rasp pnpm[497207]: [2025-01-13 09:37:09] error: zh:ember:uart:ash: Received ERROR from adapter, with code=ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT.
Jan 13 09:37:09 rasp pnpm[497207]: [2025-01-13 09:37:09] error: zh:ember:uart:ash: ASH disconnected | Adapter status: ASH_NCP_FATAL_ERROR
Jan 13 09:37:09 rasp pnpm[497207]: [2025-01-13 09:37:09] error: zh:ember:uart:ash: Error while parsing received frame, status=ASH_NCP_FATAL_ERROR.
Jan 13 09:37:09 rasp pnpm[497207]: [2025-01-13 09:37:09] error: zh:ember: Adapter fatal error: HOST_FATAL_ERROR
Jan 13 09:37:09 rasp pnpm[497207]: [2025-01-13 09:37:09] debug: zh:controller: Adapter disconnected

[vinne81]

I might have found a workaround. But this might still be an issue of course.

I was able to OTA update my ZBMINIR2 by changing OTA settings in the Zigbee2MQTT config.

According to the documentation (https://www.zigbee2mqtt.io/guide/usage/ota_updates.html#troubleshooting), these are the default values:

ota:
image_block_response_delay: 250 (min 50)
default_maximum_data_size: 50 (min 10, max 100)

Below are my scenario's and their results.

Default settings (image_block_response_delay:250, default_maximum_data_size:50): FAIL
=> OTA UPDATE FAIL. Update starts and runs for a while, then gives an error:
zh:ember:uart:ash: Received ERROR from adapter, with code=ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT

Jan 14 08:50:57 rasp pnpm[577172]: [2025-01-14 08:50:57] info: z2m: Update of 'ZBMINIR2 16spots' at 0.00%
Jan 14 08:59:28 rasp pnpm[577172]: [2025-01-14 08:59:28] info: z2m: Update of 'ZBMINIR2 16spots' at 36.86%, ≈ 15 minutes remaining

So the update would have take about 30 minutes if it would have continued.

Fast settings (image_block_response_delay:50, default_maximum_data_size:100): FAIL This would mean a very fast update, but hard on the network.
=> OTA UPDATE FAIL. Doesn't even start:
Jan 14 09:07:07 rasp pnpm[578187]: [2025-01-14 09:07:07] error: z2m: Update of 'ZBMINIR2 16spots' failed (Device didn't respond to OTA request)
This is probably to be expected, as the documentation states that such values are not really supported by many devices.

Small max data size settings (image_block_response_delay:200, default_maximum_data_size:10): SUCCESS
=> OTA UPDATE SUCCESS! ZBMINIR2 now running firmware 1.0.4.
Update took 90 minutes but it didn't fail.

Jan 14 07:14:17 rasp pnpm[571624]: [2025-01-14 07:14:17] info: z2m: Update of 'ZBMINIR2 Keukeneiland' at 0.00%
Jan 14 08:47:03 rasp pnpm[571624]: [2025-01-14 08:47:03] info: z2m: Update of 'ZBMINIR2 Keukeneiland' at 100.00%

---

I had another ZBMINIR2 so I could try more scenario's:

• image_block_response_delay: 100, default_maximum_data_size: 20: OTA doesn't even start

• image_block_response_delay: 200, default_maximum_data_size: 20: OTA UPDATE FAIL** , same error returned that I have with the default settings.
  Jan 14 09:12:13 rasp pnpm[578613]: [2025-01-14 09:12:13] info: z2m: Update of 'ZBMINIR2 16spots' at 0.00%
  Jan 14 09:35:15 rasp pnpm[578613]: [2025-01-14 09:35:15] info: z2m: Update of 'ZBMINIR2 16spots' at 49.87%, ≈ 23 minutes remaining

• image_block_response_delay: 200, default_maximum_data_size: 15: SUCCESS
  => OTA UPDATE SUCCES! ZBMINIR2 now running firmware 1.0.4.
  Update took about 60 minutes.

Note: these ZBMINIR2 are close to the Coordinator and have an LQI of 175+, so it's not like they are in some far away corner of my Zigbee network.

[Koenkk]

The 8.x firmware should also improve this: https://www.zigbee2mqtt.io/guide/adapters/emberznet.html, do you have another device to try with?

[antst]

It is ZBDongle-E coordinator, so it is possibly yet another manifestation of this
#23861

[vinne81]

I have two more ZBMINIR2 that I can try with, will do that in the next few days.

In the meanwhile I flashed my ZBDongle_E to 8.0.2, which gave me even more ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT, for example when trying to generate the 'Map'.

Then I tried the Nerivec 8.0.2 update5 firmware (https://github.com/Nerivec/silabs-firmware-builder/releases/tag/v2024.6.2-update5) that increases RX_BUFFER_SIZE. So far, good results! Generating the Map works. And I was able to update the firmware of my Aqara plugs, something that didn't work with 7.x

[vinne81]

I connected one of the brand new ZBMINIR2 running firmware 1.0.2. Out of the box this device, just like the previous ones, generates some minor Z2M errors, unrelated to OTA.

Jan 15 20:09:29 rasp pnpm[708843]: [2025-01-15 20:09:29] error: z2m: Failed to configure 'ZBMINIR2 Reserve', attempt 2 (Error: ZCL command 0xe406bffffe352b78/1 customClusterEwelink.read(["radioPower",1,20,21,22,23], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')

The ZBMINIR2 is close to my ZBDongle_E cöördinator, excellent LQI 224. I started with MAX speed ota settings to see how low I needed to go before it started working:

ota:
  image_block_response_delay: 50
  default_maximum_data_size: 100

Guess what, OTA just started and completed the upgrade in less than 5 minutes! Flawless.

@Nerivec Your silabs firmware v2024.6.2-update5 is performing miracles here. Thanks!

[vinne81]

Issue seems to be resolved by using this firmware for the Sonoff Zigbee Dongle E: https://github.com/Nerivec/silabs-firmware-builder/releases/tag/v2024.6.2-update5

[AURELB87]

Hello @vinne81,

Thank you for your feedback.
I do not well understand this part:

ota:
image_block_response_delay: 50
default_maximum_data_size: 100

Do we have to change ota settings ? If yes, where ?

Thanks.

[AURELB87]

I change the firmware and I installed Updade 5 and I confirm that it is a success! 26 minutes without error and device updated!

[Nerivec]

Thanks for the feedback on the new firmware, others are reporting the same, so, looks like we have a workaround until flow issues are resolved by Silabs!

---

Do we have to change ota settings ? If yes, where ?

These are Z2M advanced configurations: https://www.zigbee2mqtt.io/guide/usage/ota_updates.html#advanced-configuration
These change the behavior of OTA updates, but are for very specific needs, or for testing, and should otherwise not be changed.

[AURELB87]

OK. I just finished all my updates. It is working well! Thanks.

I still have some devices that displayed new OTA but after I start the OTA I have this message : z2m: Update of 'NAME_DEVICE' failed (Device didn't respond to OTA request) but this ... is another topic! ;)

[Nerivec]

@AURELB87 When that happens, and the target device is battery-powered, it usually means you have to wake it up (by pressing the button several times until it starts to update). That's usually the case for all IKEA stuff for example. Although, in some cases, it's just devices with poor design, or that are not meant to be used without the manufacturer's hub...