TY0201 (_TZ3000_bjawzodf) wrong custom firmware submitted

[jehos]

wrong custom firmware submitted with index.json at a02dbd5
This causes firmware update notifications on device that have the same ID, but are actually different.

TY0201 (_TZ3000_bjawzodf) -> LYWSD03MMC (Custom devices (DiY))

SEE:

1. TS0201 does not update frequently enough. zigbee2mqtt#4202 (comment)
2. TS0201 does not update frequently enough. zigbee2mqtt#4202 (comment)

[jehos]

@KipK I'm sorry to bother you..

This is a sample of index.json.

Is there any information to know which device and firmware can match?
I think Z2m should be able to know which device can use that firmware.

For example, such as the 'ModelID' attribute, it seems that there is a way that only certain device models can use this firmware.

Certainly, there seems to be a procedure to parse the "fileName" attribute to find out the firmware magic code...

  {
    "fileName": "1141-0203-11003001-z03mmc.zigbee",
    "fileVersion": 285224961,
    "fileSize": 131362,
    "url": "https://github.com/Koenkk/zigbee-OTA/raw/master/images/Telink/1141-0203-11003001-z03mmc.zigbee",
    "imageType": 515,
    "manufacturerCode": 4417,
    "sha512": "d0ff5ed064be67820f5528d40f1b95ea93650ad0ff9d831fd51dae049544134fa7d5bcf43fb53b889cb1f986fa8562c844e6ddf62333b96368c0376322f18681",
    "otaHeaderString": "\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000"
  },

[KipK]

Ota updates are matched by devices using manufacturer
Code and imageType.
However, Tuya mess it up by manufacturing different devices using same values.
I guess Tuya has their own way of doing OTA to not flash wrong fw on them, but ZigBee standard is not respected.

That said, I think it's better to disable OTA for those device, than automatically push a wrong fw. ,

[jehos]

Thank you for your kind reply. @KipK

Actually, I was just a user until I upgraded the wrong firmware today.
If it's simply my fault, I'll be able to apply a good best practice that disables automatic updates as you said.
But I'm sure there are a lot of people who trust and use the update feature. (Of course I did.)

Based on the many clues you mentioned, i read the source code and made the following guess.
I'm sure you're already familiar with this, but I'll write it down in detail for others who will read it later. (Please understand this situation for beginners like me.)

The index.json file in Z2m's OTA feature may contain metadata describing the firmware, as well as metadata limiting the devices covered by the firmware, which can be found in the zigbee-OTA repository.

A new firmware has been registered in index.json in the zigbee-ota repository, which shows that it can be updated even for the wrong device, so today I updated the Z03MM firmware on my TY0201 thermometer.

Unfortunately, due to the incorrectly updated firmware, my TY0201 now recognizes it as a completely different device Z03MM, which cannot be restored with OTA, only to using USB-COM and flash the firmware.

1. https://github.com/pvvx/TlsrComSwireWriter
2. https://pvvx.github.io/ATC_MiThermometer/USBCOMFlashTx.html

This problem occurred because the identifier of the TY0201 device I had and the identifier of the firmware of the Z03MM provided by index.json happened to be the same.

• 1141-0203
• "imageType": 515
• "manufructurerCode": 4417

As you say, Tuya-based devices often have the problem of overlapping unique identifiers, as many of them are randomly made by many small and medium-sized companies.

Therefore, when describing metadata in index.json, we can avoid many problems by adding additional information so that you can select only a specific device closely.

If this is correct under your review, I would like to describe additional metadata for the problem item of index.json, so that other TY0201 users do not experience the same problem.

I think the problem can be avoided by describing modelId and manufacturerName additionally.

I found the basis in the following source code.

• https://github.com/Koenkk/zigbee-herdsman-converters/blob/v20.58.0/src/lib/ota/zigbeeOTA.ts#L58

• https://github.com/koenkk/zigbee-ota#adding-new-and-updating-existing-ota-files

interface RepoImageMeta {
    //-- automatic from parsed image
    imageType: number;
    fileVersion: number;
    manufacturerCode: number;
    fileSize: number;
    otaHeaderString: string;
    //-- automatic from image file
    url: string;
    sha512: string;
    fileName: string;
    //-- extra metas
    force?: boolean;
    hardwareVersionMin?: number;
    hardwareVersionMax?: number;
    modelId?: string;
    manufacturerName?: string[];
    minFileVersion?: number;
    maxFileVersion?: number;
    originalUrl?: string;
    releaseNotes?: string;
}

[KipK]

If it's simply my fault, I'll be able to apply a good best practice that disables automatic updates as you said.

Not your fault, Zigbee Ota has been enabled for TS0201 on latest z2m release, and so it pushed you the wrong firmware.
When I said it's better to disable ota, I meant to remove the latest commit that enabled it. I've already let a message to @koenk on the PR thread

I think the problem can be avoided by describing modelId and manufacturerName additionally.

ManufactuerName can be the same but modelID is probably different yes.

[Koenkk]

I removed the firmware for the time being (removing ota functionality of TS0201 requires a z2m update leading to users having bricked devices until then). @KipK could you re-submit it with the modelId included?

[KipK]

@Koenkk , I'm not sure this fw should be kept. It could be a transition ota file from ofw to custom fw. ( pvvx ? )
Look at this capture from a user who got bricked:

Manufacturer field says Custom Device (DIY)

Installing custom fw should only be made manually. Updating them is not a problem.
Do we know who pushed it to get more informations on this fw ?
I'm only speculating here.

@jehos, can you post the state tab content for your bricked device, I want to see the "device": {} content.
Mostly manufacturer code
Would be also nice to add the imageType on it @Koenkk in a future z2m update :)

[jehos]

@KipK Sorry, Actually after hanging on for over 12 hours yesterday, I deleted the bricked device registered in Z2m. Now there is no way to re-register...

However, since I have screenshots and log files that I kept for my issue management, I will give you some information to refer to.

{
    "availability": [
        {
            "topic": "zigbee2mqtt/bridge/state",
            "value_template": "{{ value_json.state }}"
        },
        {
            "topic": "zigbee2mqtt/0xa4c13847a075b8ea/availability",
            "value_template": "{{ value_json.state }}"
        }
    ],
    "availability_mode": "all",
    "command_topic": "zigbee2mqtt/0xa4c13847a075b8ea/set/show_smiley",
    "device": {
        "identifiers": [
            "zigbee2mqtt_0xa4c13847a075b8ea"
        ],
        "manufacturer": "Custom devices (DiY)",
        "model": "Xiaomi temperature & humidity sensor with custom firmware (LYWSD03MMC)",
        "name": "0xa4c13847a075b8ea",
        "sw_version": "3001-1100",
        "via_device": "zigbee2mqtt_bridge_0x00124b0025e14e1c"
    },
    "name": "Show smiley",
    "object_id": "0xa4c13847a075b8ea_show_smiley",
    "origin": {
        "name": "Zigbee2MQTT",
        "sw": "1.42.0",
        "url": "https://www.zigbee2mqtt.io"
    },
    "payload_off": "HIDE",
    "payload_on": "SHOW",
    "state_topic": "zigbee2mqtt/0xa4c13847a075b8ea",
    "unique_id": "0xa4c13847a075b8ea_switch_show_smiley_zigbee2mqtt",
    "value_template": "{{ value_json.show_smiley }}"
}

---

And this issues started here.

• update ZigbeeTLc for Z03MMC to v0.1.2.3 #598

Submmiter's original intention was to just update the Z03MM device.
However, various problems overlapped and caused problems.

1. When registering firmware with index.json, the specifier(metadata) was a little less detailed.
2. There were variant devices in the Real World that used the same identifier.
3. Fail validate to incorrect firmware flashing on device.

I was simply a user, so I never imagined that the community would run with the efforts of so many people.

In particular, I would like to thank you very much as a maintainer of Z2M. (@Koenkk)
I could understand your efforts by reading the source code one by one. (and a lot of documentation)

And i know @KipK also active in the HA community and helping.
Because of you, I was able to understand this system more detail.
(It was very kind, considering how many harsh communities there are for Newbie.)

The people who develop custom firmware are valuable to the community.
The numerous data they posted and work is priceless.
Contributors who have submitted PR are also important people in the community.

As a career system engineer, I believe no one does anything wrong on purpose. (But in security, I don't trust anyone.. :-)
It's just that they don't have a good understanding of the system, or they make mistakes because the system is overly complicated or unfriendly.

This won't happen often, but once it happens, it has a huge impact, so I hope it will be improvement in the OTA's contribution procedure and firmware update procedure more explicit.

As we all agree, people are not perfect and always make mistakes, so we can learn from mistake and improvement the system. People who participate in each stage are bound to make mistakes, so there is a need for a way to review or prevent problems that may arise at each stage. If the sieve is tighter, the system will be stable even with a lot of participation.

This discussion is beyond the scope of this issue, so I would like to create an issue and discuss it separately.

“Talk is cheap. Show me the code.”
I understand the meaning of this. I'm not asking you to create this feature.
However, I wanted to discuss that there is this feedback.

I appreciate your hard work

[KipK]

Ok so the firmware is actually @pvvx custom fw.
The manufacturerID + imageType choosen for this custom version is in collision with TY0201 device from Tuya.

[pvvx]

Most Tuya devices have the same IDs:

Manufacturer Code	Image Type	Stack Version
0x1141 - Telink	0xd3a3	0x3001

It is not worth publishing firmware with the specified identifiers, since many Tuya devices respond to them.

Similarly, with the name of the model and manufacturer of Tuya devices. Several completely different Zigbee devices have already been found on sale under the Tuya brand, but with the same model name and manufacturer.
Sample: TS0201 _TZ3000_bguser20

Also, under the same IDs, but with different "File Version" Tuya devices have different functionality.

As you say, Tuya-based devices often have the problem of overlapping unique identifiers, as many of them are randomly made by many small and medium-sized companies.

Currently, Tuya devices have already started using other identifiers from other brands, which makes the situation even more confusing. Favorite hobby: making fakes.

[pvvx]

There is a text string in the "*.zigbee" file format for OTA. It can be used to specify the device model for the user.
If display this text to the user, the user will be able to specify the device type for OTA...

[pvvx]

ID numbers of alternative firmware.

HW ID	Zigbee Image Type	Device	Note
0		LYWSD03MMC_B14	BLE
1	0x0201	MHO_C401(old)	BLE
2	0x0202	CGG1(old)	BLE
3		LYWSD03MMC_B19	BLE
	0x0203	LYWSD03MMC_DEVBIS	Default Telink Zigbee SDK and old version from devbis
4		LYWSD03MMC_B16	BLE
	0x0204	WATERMETER	Default Telink Zigbee SDK and old version from slacky1965
5		LYWSD03MMC_B17	BLE
6	0x0206	CGDK2	BLE & ZigBeeTLc
7		CGG1N(2022)	BLE
8	0x0208	MHO_C401N(2022)	BLE & ZigBeeTLc
9	0x0209	MJWSD05MMC	BLE
10		LYWSD03MMC_B15	BLE
	0x020A	all LYWSD03MMC	ZigBeeTLc
11	0x020B	MHO_C122	BLE & ZigBeeTLc
12..15			reserved for BLE
16	0x0210	TB03F	BLE (DIY TB-03F-Kit)
17	0x0211	TS0201_TZ3000	BLE & ZigBeeTLc
18	0x0212	TNKS	BLE Water tank controller
19	0x0213	THB2	BLE
20	0x0214	BTH01	BLE
21	0x0215	TH05	BLE
22	0x0216	TH03Z	BLE & ZigBeeTLc
23	0x0217	THB1	BLE
24	0x0218	TH05D	BLE
25	0x0219	TH05F	BLE
26	0x021A	THB3	BLE
27	0x021B	ZTH01	BLE & ZigBeeTLc
28	0x021C	ZTH02	BLE & ZigBeeTLc
29	0x021D	PLM1	(not yet published at the moment) Tuya BLE Plant monitor ECF-SGS01-A rev1.3 (BT3L Tuya module)
30	0x021E	ZTH03	BLE & ZigBeeTLc
31	0x021F	LKTMZL02	BLE & ZigBeeTLc

All ZigBeeTLc:

Manufacturer Code	Image Type	File Version	Stack Version
0x1141 - Telink	0x02nn - 02: TLSR825x, nn: HW	0xrrbb - rr: App release, bb: App build	0x3001 - Zigbee v3.0, Release 0.1

• "Manufacture name" and "Device name" are user-defined. They have the write permission attribute.

See the table update here.

Ok so the firmware is actually @pvvx custom fw.

Last year I came to an agreement with all known Russian-speaking creators of alternative firmware regarding the distribution of Zigbee OTA identifiers. Since then we have been using different "manufacturer codes".

[lukas1760]

Hello, unfortunately, I found this topic only after an unsuccessful attempt at an OTA update that caused it to malfunction. Symptoms are the same.

My device (originally Tuya TS0201) is still connected to the coordinator. Could you please help me how to force ota update? I tried to create my index.json with path to the default firmware.zigbee but I still recieve notification No update found.
As you can see also properties of device where changed. Both of them are Tuya TS0201.

[pvvx]

@lukas1760 - There are more than a dozen different Tuya devices with the name "TS0201".
Specify which specific model you have.

[lukas1760]

@pvvx here it is.

Zigbee Model
TY0201
Zigbee Manufacturer
_TZ3000_bjawzodf

[pvvx]

The names provided do not identify the model of the Tuya device.
Small manufacturers insert any names they want into devices sold under the Tuya brand.

RSH-HS06 ?
TH03Z ?
... ?

Determine the Tuya device model by the following criteria:

1. Appearance
2. PCB of the device (marking) and which components are installed.

[lukas1760]

Okay I understand.
On the PCB is marking RSH-HS03-V2.0

[pvvx]

Unfortunately, I did not have such a thermometer and I do not have its original firmware to restore.

[lukas1760]

That is sad. Is there any way/method to get the firmware from a working device to a PC?

[pvvx]

That is sad. Is there any way/method to get the firmware from a working device to a PC?

Yes.
https://github.com/pvvx/TlsrComSwireWriter -> TLSR825xComFlasher.py

[pvvx]

@lukas1760
There is FullFlash -> pvvx/ZigbeeTLc#107

1141-0203-10013001-TY0201_TZ3000_bjawzodf.zigbee

[KipK]

If it can help, I've made an ota file from @pvxx previous post , with higher version than the one that was installed by mistake. Just in case z2m refuse to downgrade. After install it will use the correct version, it's just to trick ota.

1141-0203-10013001-TY0201_TZ3000_bjawzodf.zip

[lukas1760]

If it can help, I've made an ota file from @pvxx previous post , with higher version than the one that was installed by mistake. Just in case z2m refuse to downgrade. After install it will use the correct version, it's just to trick ota.

1141-0203-10013001-TY0201_TZ3000_bjawzodf.zip

Many thanks. But i have no sucess with ota update propably because of changed device properties. I don't know how to force update.

[KipK]

After searching a bit, it seems to be this firmware that has been installed , not from @pvvx

It should work they have same manufacturer code and image type. Could be OTA is broken too. You can then try to flash it using links posted above: https://github.com/pvvx/TlsrComSwireWriter

[pvvx]

1141-0203-10013001
These are the numbers from the firmware itself. (IDs are obtained by reading from the firmware binary itself https://github.com/pvvx/ZigbeeTLc/blob/master/make/zigbee_ota.py ) Telink's Zigbee SDK writes all data to the beginning of the binary file. But this firmware has a different CRC than the standard Telink utility ("tl_check_fw2.exe") gives. This was observed in the first versions of the SDK, several years ago. There was a different CRC calculation algorithm.
And the firmware does not have a bootloader, which usually indicates that Tuya devices have 512 KB of flash memory. With 1 MB, Tuya usually sticks the bootloader at the beginning of the Flash.

All these data are not involved in the Zigbee OTA process. They are information data for automating the creation of Zigbee OTA header in Telink applications...

According to the encoding from the Telink SDK 1141-0203-10013001, they indicate:

• MANUFACTURER_CODE_TELINK: 0x1141 - Telink
• IMAGE_TYPE: 0x0203 - TLSR_8258_512K, No bootloader, IMAGE_TYPE_CONTACT_SENSOR
• APP_RELEASE: 0x10 - app release 1.0
• APP_BUILD: 0x01 - app build 01
• STACK_RELEASE: 0x30 - stack release 3.0
• STACK_BUILD: 0x01 - stack build 01

Such IDs are installed in the Telink SDK by default (in "version_cfg.h") and the Tuya firmware writer did not change anything.

---

Another version of the SDK from Telink contains the following imageType::

typedef enum{
	TL_IMAGETYPE_LIGHT				= 0xd3a3,
	TL_IMAGETYPE_RC					= 0xd3a2,
	TL_IMAGETYPE_ONOFFSWITCH		= 0xd3a1,
}tl_imageType_e;

This is what all the identifiers look like in the firmware from Tuya - no one changes anything there that is written in the Telink SDK.
And all firmware from Tuya on TLSR825x have the same IDs.
Firmware updates are not provided for such devices. Sold and that's it.

[KipK]

According to the encoding from the Telink SDK 1141-0203-10013001, they indicate:

• MANUFACTURER_CODE_TELINK: 0x1141 - Telink
• IMAGE_TYPE: 0x0203 - TLSR_8258_512K, No bootloader, IMAGE_TYPE_CONTACT_SENSOR
• APP_RELEASE: 0x10 - app release 1.0
• APP_BUILD: 0x01 - app build 01
• STACK_RELEASE: 0x30 - stack release 3.0
• STACK_BUILD: 0x01 - stack build 01

Yes I had checked ota headers on booth files and manufacturer code + image type are the same. So this should work. I guess installing the wrong firmware broke OTA then. But I haven't tested myself, I don't have this device anyway.

[lukas1760]

@KipK if you tell me what to check, I will do it. But I don't have com flasher possibility yet.

[KipK]

@pvxx, reading the python script you've posted , I think I get why.

OTA header has 0x1141 manufacturer code, but bin file has 0xDB15 , ( from bytes 16-17 little indian )
Imagetype is still 0x0203

So it seems once the wrong firmware has been installed, it changed the manufacturer code to 0xDB15.
@lukas1760 ,I've made 2 ota to test, can you try those: https://drive.google.com/drive/folders/11TNhWNIlG2bqZNlFBtjeCZc2okgngH5N?usp=sharing

try this one first:
DB15-0203-1001FFFF-TY0201_TZ3000_bjawzodf.zigbee is just the same as previous one but with changed manufacturer code on OTA header

if it doesn't work then this one:
TY0201-by-TZ3000_DB15manuf_ota.zigbee same OTA header but also has modified .bin manufacturer code, not sure it will pass the crc check if there is, but let's try.

[lukas1760]

@KipK many thanks for help.
I have tried with these results:
TY0201-by-TZ3000_DB15manuf_ota.zigbee
update available in ota menu. At the beginning finished with error:
z2m: Update of 'Teplomer pracovna' failed (Update failed with reason: 'INVALID_IMAGE')

DB15-0203-1001FFFF-TY0201_TZ3000_bjawzodf.zigbee
update available in ota menu. The same error at the end of update process (transfer finished on 100% )
z2m: Update of 'Teplomer pracovna' failed (Update failed with reason: 'INVALID_IMAGE')

[joannawolthuis]

Hi! I have the same situation with my TY0201, unfortunately. I managed to get the point of getting new firmware to upload (but failed at the end), so I will keep an eye on this thread, appreciate your efforts :)

[pvvx]

Why don't you look at what IDs the firmware installed on the device has? These are standard Zigbee commands. Guessing the ID without having the device is stupid.

Next, take any script that replaces the IDs in the OTA file header for Zigbee and set the required IDs, replacing the "File Version" number with a larger one.

---

File from message #620 (comment) do not use!
There is a 90% suspicion that the file was read by diggit incorrectly.

---

Flashing the pvvx/ZigbeeTLc#107 (comment) provided by @diggit into the ZTU module showed that the file does not work!

[trenchcoatjedi]

Is there an alternate firmware for _TZ3000_bjawzodf that increases polling frequency and doesn't brick the device?

I'm unable to see let alone pair this device with this: https://pvvx.github.io/ATC_MiThermometer/TelinkMiFlasher.html

Currently working with factory firmware: