Subject: Critical OTA firmware mismatch – four Livarno RGBW GU10 bulbs converted into TS130F covering devices

[nexus767]

Hello,

Using deCONZ 2.33.2 with ConBee II, four Lidl Livarno RGBW GU10 bulbs (HG07834A, _TZ3000_quqaeew6, originally TS0505B) became unusable after OTA updates.

All four now identify as TS130F window-covering devices instead of RGBW lights. Their lighting functions no longer work, although Zigbee and OTA communication remain partially functional.

The installed firmware is version 0x47, associated with:

1002-1602-00000047-41ebf9.zigbee

This appears to be Tuya window-covering firmware incorrectly offered to RGBW bulbs.

Furthermore, two Lidl TS011F smart plugs stopped working after OTA updates. Their physical buttons and relays no longer respond.

We urgently need:

1. The original TS0505B firmware for _TZ3000_quqaeew6.

2. A safe Zigbee OTA recovery/downgrade procedure.

3. Investigation of the firmware compatibility checks to prevent further devices from being damaged.

I can provide screenshots, OTA files, device identifiers and deCONZ database information.

[Mimiix]

Sadly we don’t have these.

[Smanar]

I m curious to know wich one firmware it have used ?

Do you have the file, the manufacturerCode or other to find it here GitHub - Koenkk/zigbee-OTA: A collection of Zigbee OTA files · GitHub ?

Edit:
Manufacture code 0x1002 = 4098
Image type : 0x1602 = 5634
Firmware version : 0x47 = 71
??? : 41ebf9

Find it

  {
    "fileName": "1662693814-oem_mg21_zg_nh_win_cover_relay_OTA_1.0.7.bin",
    "fileVersion": 71,
    "fileSize": 222762,
    "url": "https://raw.githubusercontent.com/Koenkk/zigbee-OTA/master/images/Tuya/1662693814-oem_mg21_zg_nh_win_cover_relay_OTA_1.0.7.bin",
    "imageType": 5634,
    "manufacturerCode": 4098,
    "sha512": "41ebf9932d11708b81144232b2c3fccc7a58d76116be63785b978b91afb1180e32d8ba4f4c8f2f0960637f1662ec9ac28aa42b74e5ab57574000889671d2b8b9",
    "otaHeaderString": "EBL sdk_route",
    "manufacturerName": [
      "_TZ3000_1dd0d5yi"
    ]
  },

But sorry I m not able to find “light” firmware with thoses settings.

deCONZ OTA update bricked several smart plugs (Tuya based?)

It seems more like there is no one who can tell someone if it is safe to update certain ZigBee devices or if updating bricks them. Personal lesson learned: never ever use that feature again for any other devices than Philips and IKEA, which worked rather flawlessly. Everything else is a pretty huge risk.

For me the first thing to do is never use OTA firmware update for tuya.

[bcutter]

Sad to hear you’re just another victim of the OTA update feature. As Smanar was so kind to reference my issue deCONZ OTA update bricked several smart plugs (Tuya based?) and the discussion from back in August, you for sure won’t be the last one producing electronic waste. We’re all trained to perform updates, and deCONZ does not provide the necessary guardrails in terms of information/warnings.

I think adding a small note or a popup before one is using the OTA update feature would cost so little but prevent issues like these. Unfortunately, “they” don’t feel responsible enough to add such a user warning. Therefore I gave up on improving the docs which likely does not stop most users at all, a hint needs to be directly in the UI.

deCONZ has no responsibility

deCONZ OTA update bricked several smart plugs (Tuya based?)

To be honest? Nothing. Especially because you ask so nicely You act very entitled and have been told before what to expect. deCONZ has no responsibility. The software is not sold and mostly run by the community. You know that. That being said: Feel free to adjust the docs yourself. OTA Image Types Firmware versions · dresden-elektronik/deconz-rest-plugin Wiki · GitHub or GitHub - dresden-elektronik/deconz-ota-plugin: Server side implementation of the standard Zigbee OTA protocol. · …

[nexus767]

Thank you for investigating this and identifying the firmware image.

I would like to clarify how this situation occurred, because I believe it highlights a serious problem with the safeguards in deCONZ’s OTA update mechanism.

How it started

My original intention was to update several IKEA Zigbee devices, particularly a door/window sensor affected by a battery drain issue. These were the devices I actually wanted to update.

During that process, however, several Tuya-based devices were inadvertently included in the OTA update procedure. I certainly had no intention of flashing experimental or potentially incompatible firmware onto them.

The four affected GU10 bulbs originally reported:

• Manufacturer: _TZ3000_quqaeew6

• Model: TS0505B

• Device: Lidl Livarno RGBW GU10 bulbs

• Quantity: 4

Firmware offered and transferred by deCONZ:

• Local filename: 1002-1602-00000047-41ebf9.zigbee

• Manufacturer Code: 0x1002

• Image Type: 0x1602

• Firmware Version: 0x00000047 (71)

• Original image: 1662693814-oem_mg21_zg_nh_win_cover_relay_OTA_1.0.7.bin

• Intended manufacturer identifier in the OTA index: _TZ3000_1dd0d5yi

After the update, all four GU10 bulbs identified themselves as TS130F window-covering devices instead of TS0505B RGBW lights. Their normal lighting functions no longer work.

Two additional Tuya-based smart plugs became unusable, as did a TONGOU DIN-rail relay, although the exact firmware and cause of failure for those three devices have not yet been conclusively established.

My concern is not simply that firmware updates can fail.

We are routinely encouraged to keep firmware up to date. When an official application offers an update, users reasonably expect that the application has performed meaningful compatibility checks.

In this case, the firmware index explicitly identifies a different Tuya manufacturer string from the one reported by my GU10 bulbs. Nevertheless, deCONZ offered the firmware, and the bulbs apparently accepted it.

I understand that Tuya’s reuse of generic Zigbee model identifiers and firmware identifiers makes reliable matching difficult. But if this problem is already known, why does deCONZ continue to offer these images without additional safeguards?

Would it not be safer to exclude Tuya devices from automatic OTA discovery unless their precise model and manufacturer identifiers can be verified?

At the very least, I would expect a prominent warning requiring explicit confirmation, for example:

WARNING: This firmware has NOT been verified as compatible with your specific device. Installing it may permanently render the device unusable.

WARNING: The device manufacturer/model identifier does NOT match the firmware’s declared target device.

WARNING: ARE YOU ABSOLUTELY SURE YOU WANT TO PROCEED?

Perhaps three warnings sound excessive, but losing seven devices during what began as routine maintenance of IKEA sensors certainly puts that into perspective.

I appreciate that the underlying problem may originate with Tuya’s inconsistent identifiers rather than with the firmware repository itself. Nevertheless, deCONZ is the software that presents the update as available and initiates the flashing procedure.

I believe that creates a reasonable expectation that incompatible firmware will either be rejected or, at the very least, clearly identified as potentially dangerous before installation.

My main concern now, besides recovering the affected devices, is preventing the same thing from happening to other users.

Ultimately, this leaves me with three possible conclusions: avoid Tuya devices, avoid deCONZ, or avoid both.

For the time being, I am inclined towards the first option. I would genuinely prefer to keep it that way.

[Smanar]

Just for information, to make an OTA update, the device just ask for

1. Image type
2. File version
3. Manufacturer code

If you send a file that check all thoses fields it will be accepted.

The device never ask for model id or manufacture name, it’s not in the protocol. Good manufacture protect their devices just using good fields, you send bad file, the OTA will be refused.
But with tuya and it’s clone army …

It’s possible too checking ModelID or manufacture name on gateway side, but this is just a “Bonus” (and not always present) and can fail too, just take a look on Issues · Koenkk/zigbee-OTA · GitHub

It’s the vendors duty to protect their devices, ofc they will say it’s because you don’t use their Gateway.

And I m agree with @nexus767
It has been a long time since I last performed an OTA update, and the feature is currently disabled on my end. Furthermore, I believe the procedure could benefit from more detailed information such as the source of the firmware (official or otherwise) the filename, as well as a more comprehensive explanation regarding the associated risks and responsibilities.