OTA firmware update stalls for Legrand device

[OliviezGit]

logs-19.txt

Summary:
OTA update for Legrand Zigbee device (e.g., Double gangs remote switch) initiates and transfers image blocks successfully, but stalls before completion.

Details:

• Device: Double gangs remote switch (IEEE 0x0004740000b92752)
• ManufacturerCode: 4129, imageType: 22
• Update starts, blocks transfer as expected, controller responds with status=0
• Progress remains at 0%, never completes
• Near end of transfer, device sends cluster 'manuSpecificLegrandDevices' command '9', which fails:
  Failed to parse frame: Error: Cluster 'manuSpecificLegrandDevices' has no command '9'
• Zigbee2MQTT logs: No converter available for this cluster/command
• No "upgrade end request" or error message received from device

Possible causes:

• Missing manufacturer-specific command support in Zigbee2MQTT/OTA handler
• Firmware expects unsupported protocol after block transfer
• Firmware image or device resource issue

Suggested actions:

• Investigate support for Legrand manufacturer-specific clusters/commands post-OTA
• Add or update converter for 'manuSpecificLegrandDevices' (command '9')
• Confirm full OTA update sequence and post-transfer handling for Legrand devices

Relevant log excerpt:

[2025-09-30 15:12:12] zh:controller: Failed to parse frame: Error: Cluster 'manuSpecificLegrandDevices' has no command '9'
[2025-09-30 15:12:12] z2m: No converter available for '067774' with cluster 'manuSpecificLegrandDevices' and type 'raw' and data '{"data":[21,33,16,32,9,82,39,185,0,0,116,4,0,1],"type":"Buffer"}'

Log file available for full details.

[OliviezGit]

@Nerivec @Koenkk could please have a quick look on that issue? any advice appreciate.
log file has been sent to Legrand for investigation too...

thanks
/olivier

[Nerivec]

Legrand/btcino is one of the worse when it comes to OTA. Issues are numerous. Most users that have investigated eventually end up giving up on the brand...

[OliviezGit]

Hi i ve made made a log with zigbee sniffer and submit to legrand dev team, answer is:

The coordinator doesn't respond to the request "Query next Image Request" sent in packet 2517 and repeated quite a large number of times. So, there is a problem with the coordinator as it should respond to this command.

Could you please help me to understand whats wrong with z2m or coordinator ?

Attached wireshark log. File to be rename PCAPNG file extension.

update 0x1078.log

network key in decimal format:
184, 70, 227, 155, 141, 125, 0, 88, 220, 243, 134, 116, 12, 231, 207, 213

[Nerivec]

Do you have the Z2M debug logs that goes with that sniff? We need to look at what Z2M is doing with that frame.

Note that this does not appear to be the same problem that you mentioned in first post.

Did you try with the schedule update feature? Seems to be the only way to make Legrand devices update (and it can take quite some time to trigger... since it's dependent on the device).

[OliviezGit]

Schedule update was engaged before i trig ota update from Legrand device. (pressing up and down switch together for 18 secondes launch an ota update!)

find below requested log:
device: 0x000474000105259e / 0x1078 / Simple_Switch_Salon_Porte_Exterieur.
network key in decimal format:
184, 70, 227, 155, 141, 125, 0, 88, 220, 243, 134, 116, 12, 231, 207, 213

1078.pcapng.log

45df7312_zigbee2mqtt_2025-10-28T19-18-27.695Z.log

[Nerivec]

The update is starting fine in this log/pcap. But it seems the device just stops requesting blocks after a short while (at file offset 1286, line 1331 in log), the pcap shows the same thing, nothing after packet 485/489.

[OliviezGit]

Legrand said, this is a Coordinator issue. i'm not sure too...

1950    187.554211    0x1078    0xf1fd    IEEE 802.15.4    10    Data Request
1951    187.554978            IEEE 802.15.4    3    Ack
1952    187.632458    0x1078    0x0000    ZigBee HA    62    ZCL OTA: Image Block Request, Seq: 37
1953    187.634890            IEEE 802.15.4    3    Ack
1954    187.653850    0x1078    0x0000    ZigBee HA    62    ZCL OTA: Image Block Request, Seq: 37
1955    187.656279            IEEE 802.15.4    3    Ack
1956    187.665491    0x0000    0x1078    ZigBee    43    APS: Ack, Dst Endpt: 1, Src Endpt: 13
1957    187.667315            IEEE 802.15.4    3    Ack
1958    187.713856    0x0000    0x1078    ZigBee HA    124    ZCL OTA: Image Block Response, Seq: 37
1959    187.716227            IEEE 802.15.4    3    Ack

i never see any query from device Image Block Request after Seq: 37 ... no Image Block Request, Seq: 38 ? 0x1078 device stalls?
the device just stops requesting blocks after a short while

I will ask again Legrand about this device stalls during ota process...

[Nerivec]

Make sure to send them the second capture (with the log), the first one showed a different issue.

[OliviezGit]

Hi.
Here below a copy and paste answer coming from Legrand dev team:

---

Finally, it looks like a problem on our side ! Here is what the embedded team told me :

"the ZED stops sending the command "Data Request" during the firmware upgrade and gets completely mute. This command shall be sent regularly until the end of the firmware upgrade. Otherwise nobody will ever send any data to the ZED. This is a bug in our side. I don't know its cause."

A bug ticket is opened and I follow it. I'll tell you once I know more and what would be the solution

---

Wait and see...

Have a nice day
Olivier

[SilentT19]

all is here : #328

[SilentT19]

the problem its about a size of 50 and the legrand device need 62
#328 (comment)

[Nerivec]

@SilentT19 it doesn't appear related to this issue. The update just stalls without reason/feedback here, it's not aborted/explicitly failing. I think the Legrand answer to @OliviezGit is right, in that there appears to be a bug in the looping of DATA_REQ on the device, which means it stops receiving the OTA block responses from its parent, effectively stalling. I'm assuming the device has a crazy long timeout to detect this as a plain "failure" (like most OTA stuff), so it probably aborts hours/days later.

---

About #328:
OTA now uses (has been for a while) the device's asked size for Legrand.
E.g. here with 64:

[2025-10-28 20:09:56] �[34mdebug�[39m: 	zhc:ota: [0x000474000105259e |  Remote switch�����������������] Request offsets: fileOffset=1286 pageOffset=0 maximumDataSize=64
[2025-10-28 20:09:56] �[34mdebug�[39m: 	zhc:ota: [0x000474000105259e |  Remote switch�����������������] Payload offsets: start=1286 end=1350 dataSize=64

And there's a workaround for the soft-bricked state for Legrand too (not triggered by this issue either).
https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/src/lib/ota.ts#L477-L506

[pipiche38]

+1