Aqara OTA updates

[ditheo]

I cannot ota update AQARA devices such as aqara WKS-EU03 and WKS-EU04.

I can see on the repository there is a new firmware with date 26/07/2024 and version 25 for WKS-EU03 (lumi.switch.n2aeu1) but if I try to check for updates i cannot see the new firmware. My devices are on version 21/10/2021 and file vesrion 2839.

I cannot see WKS-EU04 on the OTA update section, even the device supports OTA updates.

I have the 2.7.1 version z2m and for adapter I use a smlight ZB-06M

[Koenkk]

We don't have the newer OTAs, to retrieve it from the Aqara hub see https://www.zigbee2mqtt.io/advanced/more/tuya_xiaomi_ota_url.html

[ditheo]

The version file that I wrote ( previous and newer) are from the zigbee ota collection mentioned on index.json and they exist under folder images/lumi. I think that is the way that someone can do ota update to zigbee devices, If I have misunderstanding that please don't bother

[andrei-lazarov]

Hi @ditheo! Thanks for spotting the issues. I'll recap:

Devices are:

1. 1-gang, lumi.switch.n1aeu1, WS-EUK03, imageType 5404, OTA enabled
2. 2-gang, lumi.switch.n2aeu1, WS-EUK04, imageType 5532, OTA not enabled (we should enable this)

There is a 2021 update for 1-gang and 2024 updates available for both (release):

• 1-gang 2021 version 2839
• 1-gang 2024 version 25
• 2-gang 2024 version 25

The fileVersion is lower for some reason.

• We can skip the version check and perform the update with force: true.
  But then, the update will keep showing up, even after it was installed. (until we remove force:true)

You can follow the instructions in #786 to update:
Enable OTA with custom converter, add custom index with force, update, remove custom index (force).

---

But we should find a solution, so other users don't have to manually do the steps above.
@Koenkk

I'm wondering if we can trick it by increasing the "fileVersion": 25

• If we just increment fileVersion, Z2M will refuse the update,
  because it checks the header inside the OTA file.
• So we must also hex-edit the header and update the hash.
  The fileVersion is stored as 4 little-endian bytes, at offset 14:
  19 00 00 00 -> 0x00000019 = 25
  The update goes through, but it achieves the same purpose as force:
  Device will get the non-incremented fileVersion: 25 (hard-coded in the firmware), so the update will show up forever.
  There are no more occurrences of fileVersion in the file.

A potential solution would be doing the above (force: true or hex-edit) and adding a new field oldFileVersion: 2839,
so Z2M will only provide the update when the version before the update matches exactly.
Then we must add the opposite to the 2021 version, so it doesn't downgrade: oldFileVersion: not 25

[Koenkk]

Z2M will refuse the update, because it checks the header inside the OTA file.

I would propose to add an option to index.json: quirks: ["skip-file-version-check"] and based on that skip the version check inside ZHC.

[mrmaximas]

@andrei-lazarov @Koenkk @Nerivec hi! Perhaps you know a way to make the Aqara sensor accept firmware with a lower version?
Please see this
#897 (comment)
#938
I tried to flash the previous one, but without success.

[
    {
    "url": "https://raw.githubusercontent.com/Koenkk/zigbee-OTA/master/images1/Lumi/20220718113235_OTA_lumi.sensor_smoke.acn03_0.0.0_0017_20220617_CB9276.ota",
    "force": true
    }
]

#897 (comment)

Here is zigbee dump
smoke.ota.pcapng.zip

[andrei-lazarov]

@mrmaximas please check Z2M debug logs when trying to update.
Also use the full entry + force true:

zigbee-OTA/index1.json

Line 14 in fb19e4f

"fileName": "20220718113235_OTA_lumi.sensor_smoke.acn03_0.0.0_0017_20220617_CB9276.ota",

[mrmaximas]

@andrei-lazarov That's exactly what I did at the beginning withe the same result.
smoke.json

[
    {
    "fileName": "20220718113235_OTA_lumi.sensor_smoke.acn03_0.0.0_0017_20220617_CB9276.ota",
    "fileVersion": 17,
    "fileSize": 222094,
    "url": "https://raw.githubusercontent.com/Koenkk/zigbee-OTA/master/images1/Lumi/20220718113235_OTA_lumi.sensor_smoke.acn03_0.0.0_0017_20220617_CB9276.ota",
    "imageType": 9728,
    "manufacturerCode": 4447,
    "sha512": "d5a8e5c323acd99ceaf02ab061e7145dbcf2da028c9d73a6042d02536f0b8aaefbc798b9b47e8fb03345721c0231374c8654e3979e73b10ba51997ad9d41cf0a",
    "otaHeaderString": "OM15082-WIN-JN5180--ENCRYPTED000",
    "modelId": "lumi.sensor_smoke.acn03",
    "force": true
    }
]

Z2M log
[1/3/2026, 12:48:05 AM] zhc:ota: [0x54ef441000a39e12 | lumi.sensor_smoke.acn03] Getting latest image, meta: {"fileName":"20220718113235_OTA_lumi.sensor_smoke.acn03_0.0.0_0017_20220617_CB9276.ota","fileVersion":17,"fileSize":222094,"url":"https://raw.githubusercontent.com/Koenkk/zigbee-OTA/master/images1/Lumi/20220718113235_OTA_lumi.sensor_smoke.acn03_0.0.0_0017_20220617_CB9276.ota","imageType":9728,"manufacturerCode":4447,"sha512":"d5a8e5c323acd99ceaf02ab061e7145dbcf2da028c9d73a6042d02536f0b8aaefbc798b9b47e8fb03345721c0231374c8654e3979e73b10ba51997ad9d41cf0a","otaHeaderString":"OM15082-WIN-JN5180--ENCRYPTED000","modelId":"lumi.sensor_smoke.acn03","force":true}

[1/3/2026, 12:50:35 AM] z2m: Update of 'Kitchen Smoke Alarm' failed ([0x54ef441000a39e12 | lumi.sensor_smoke.acn03] Timeout. Device did not start/finish firmware download after being notified. (Timeout - 64481 - 1 - undefined - 25 - 3 after 150000ms))

full entry dump
smoke.ota.full.entry.pcapng.zip

[andrei-lazarov]

@mrmaximas These look like info logs.
The 'log level config' setting enables generation of debug logs, but only info logs are sent to the UI (to avoid MQTT traffic).
You have to view debug logs on the host machine: HA > Add-ons > Z2M > Log, or docker container logs.
Disable debug logs when you are done.

The Zigbee traffic is encrypted with your network key.

Wake-up the device to prevent the timeout.

Also it says here "the device blocks any downgrades"
https://github.com/Koenkk/zigbee2mqtt.io/pull/4540/files

[mrmaximas]

@andrei-lazarov NW KEY is default - 01030507090b0d0f00020406080a0c0d
This sensor does not need to be woken up; it sends a data request packet every 15 seconds.

[andrei-lazarov]

I don't think you can do anything about it.
I see in the pcapng file it immediately replied to Image Notify, but never replied to Next Image Response.
Safe to say it doesn't accept downgrades.

Actually let's try to increase the file version.. maybe we can trick it

[andrei-lazarov]

@mrmaximas try this index. I edited the index and the OTA header inside the binary to v22 (0x16)
https://raw.githubusercontent.com/andrei-lazarov/zigbee-OTA/refs/heads/aqara/aqara.json

[mrmaximas]

@andrei-lazarov same result but now from z2m no image available

[
    {
    
    "fileName": "20220718113235_OTA_lumi.sensor_smoke.acn03_0.0.0_0017_20220617_CB9276.ota",
    "fileVersion": 22,
    "fileSize": 222094,
    "url": "https://raw.githubusercontent.com/Koenkk/zigbee-OTA/master/images1/Lumi/20220718113235_OTA_lumi.sensor_smoke.acn03_0.0.0_0017_20220617_CB9276.ota",
    "imageType": 9728,
    "manufacturerCode": 4447,
    "sha512": "3f5279c0a40d75c3e6de8922b5bedbdcd416c8365d026ab4951ba04add761caf156c3b151ff29ec98c1e83f27ed93d95293922ee26a349256ba0f781649be0ee",
    "otaHeaderString": "OM15082-WIN-JN5180--ENCRYPTED000",
    "modelId": "lumi.sensor_smoke.acn03",
    "force": true
    }
]

smoke.ota.fake.v22.pcapng.zip

[andrei-lazarov]

Sorry, try now:
https://raw.githubusercontent.com/andrei-lazarov/zigbee-OTA/refs/heads/aqara/aqara.json

[
  {
    "fileName": "20220718113235_OTA_lumi.sensor_smoke.acn03_0.0.0_0017_20220617_CB9276.ota",
    "fileVersion": 22,
    "fileSize": 222094,
    "url": "https://raw.githubusercontent.com/andrei-lazarov/zigbee-OTA/aqara/images1/Lumi/20220718113235_OTA_lumi.sensor_smoke.acn03_0.0.0_0017_20220617_CB9276.ota",
    "imageType": 9728,
    "manufacturerCode": 4447,
    "sha512": "3f5279c0a40d75c3e6de8922b5bedbdcd416c8365d026ab4951ba04add761caf156c3b151ff29ec98c1e83f27ed93d95293922ee26a349256ba0f781649be0ee",
    "otaHeaderString": "OM15082-WIN-JN5180--ENCRYPTED000",
    "modelId": "lumi.sensor_smoke.acn03"
  }
]