porting firmware for TS0201 _TZ3000_v1w2k9dd

[dynasticorpheus]

Would be great if someone could share some hints how to prep an OTA for my TS0201 _TZ3000_v1w2k9dd which is already Zigbee out of the box. Bit unsure how to create something that is recognized by ZHA when using below config.

Note they work out of the box in home assistant but only seem to update when registering big changes in temperature / humidity hence my wish to use this custom firmware.

Bought here

image_type_id 0x008 ---> 65535
manufacturer_id 0x007 ---> 4098

zha:
  zigpy_config:
    ota:
      extra_providers:
        - type: advanced
          warning: I understand I can *destroy* my devices by enabling OTA updates from
            files. Some OTA updates can be mistakenly applied to the wrong
            device, breaking it. I am consciously using this at my own risk.
          path: /config/zigpy_ota

zha_toolkit:

[juha63]

You first have to check if your board looks like https://pvvx.github.io/TS0201_TZ3000/. You need to check if LED and BUTTON are connected to the right ports of the ZTU also. If not, you can't use any prebuilt firmware and have to compile it yourself.

Look at #124

[dynasticorpheus]

@pvvx Tuya is obviously very messy so wondering if you can tell me if this variant is somehow already supported either by downloading an OTA binary or compile one myself? Thanks!

[dbmaxpayne]

I have the same boards as @dynasticorpheus and wanted to flash them with a new firmware to get configurable report intervals.
However, the PCB is wired completely different to others and I don't quite understand how to compile a new firmware for it.

The PCB traces as follows:
C2 -> LED (to GND)
C3 -> SDA
D2 -> SCL
B4 -> Button (to GND)
B5 -> 3V0/Bat+ (via 7.2k resistor)

I quickly had a look at https://github.com/pvvx/ZigbeeTLc where I saw that apprently the boards are defined in src/board_*.h.
Then I wanted to see if I can just make my own board definition and change the GPIOs to match this board, however, there is the following line
#define I2C_GROUP I2C_GPIO_GROUP_C2C3
which somehow defines an I2C_GROUP. As far as I can see, there is no I2C_GPIO_GROUP_D2C3.
How can this board be supported?
Or am I using the wrong ZTU schematic?

This is what I used.

Cheers,
Mark

[dbmaxpayne]

This is the sensor.
Also no idea what type it is.

maybe some SHT4x clone?

EDIT:
Pins of sensor trace as follows (see previous post for MCU traces):
Top Left -> VDD
Bottom Left -> SDA
Top Right -> GND
Bottorm Right -> SCL

EDIT2:
Seems to be Sensylink CHT8320ADNR.
However according to the datasheet SDA & SCL would be swapped.
Maybe the markings on the PCB are simply wrong.

[dbmaxpayne]

I'm currently trying to port the firmware for software I2C and the CHT832x sensors.
As I'm not a programmer and currently lacking a reliable SWire programmer (already ordered) it will take a while until I can tests things and report back, though.

[dbmaxpayne]

Alright. I couldn't wait for the programmer to get here so I fiddled around with the USB->UART SWire emulation and got a working firmware flashed.
All subsequent updates were done via OTA.
After a few tries it even works good and incorporates software I2C to talk to the CHT832x.
Temperature and humidty can already be read successfully.

I will download the old firmware when I get the hardware programmer.
It always stopped at 0x100 when using the emulator.

@pvvx How would you like me to contribute this?
Unfortunately I've got no experience with Github collaboration, but am happy to share my findings.

Also I'd be interested in a way to forcefully flash the original Tuya devices with the new firmware without having to solder an SWire programmer to the board.
I tried changing the following, but that resulted in an "Invalid image" error in Zigbee2Mqtt OTA.

#define MANUFACTURER_CODE_TELINK           	0x1002
#define	IMAGE_TYPE							0x203

[pvvx]

Full match with ZY-ZTH02Pro. But no LCD.
BLE firmware is already assembled and working, without LCD.

The sensor is probably a clone of SHT30.
Or https://github.com/pvvx/pvvx.github.io/blob/master/TH03Z/CZ_SHT30_GX_0001.pdf
https://xonstorage.blob.core.windows.net/pdf/gxcas_gxhtc3c_apr22_xonlink.pdf

https://www.gxcas.com/public/en/public/html/index.html#/proOne?pid=21&id=23

Already working in an unheated garage in "LE Long Range" mode:

At that distance from home and with multiple walls, Zigbee doesn't work:

https://github.com/pvvx/ATC_MiThermometer/raw/refs/heads/master/ZY02_v50.bin - Will work for your device temporarily.
Then the display will be added.

[pvvx]

I recommend unsoldering or breaking out R13 and R11. This is unnecessary battery consumption and does not provide anything else.

ZTU	Mark
D3		---
D7		---
C0	PC0	R3-VCC
SWS
B6
A0	RXD2
A1	TXD2
C2	LED
C3	SCL	R4 - VCC
D2	SDA	R5 - VCC
B4	KEY
B5	P34	R1 - VCC
GND
VCC
B1	TXD1
B7	RXD1
C4	+BAT	R13 R11
RST	RST
C1
D4
NC

[dbmaxpayne]

Good stuff, mate.
Thanks for your efforts :) Greatly appreciated.

The sensor is definitely a CHT832x.

If you are interested in my changes, I have just created a fork and uploaded my changes.
https://github.com/dbmaxpayne/ZigbeeTLc

Basically I created or changed the following files:

board_ts0201_tz3000_v1w2k9dd.h
i2c_drv.h
i2c_drv.c
sensor_cht832x.h
sensor_cht832x.c
version_cfg.h

Makes sense by the way that these boards are similar or share the firmware.
I saw, that the MCU also scans other I2C addresses like 7C or so.

Do you know why R13 and R11 are there in the first place?

Cheers,
Mark

[pvvx]

Do you know why R13 and R11 are there in the first place?

ADC divider for measuring battery voltage.
The device was made by children for Tuya, and they do not know how to work with TLSR8258 microcircuits.
The original firmware from Tuya for Zigbee has a huge power consumption...

[pvvx]

Analogue of STH30

02:15:46: Searching for devices
02:15:58: Connecting to: ZY2_E515C0
02:16:07: Hardware Revision String: V1.1
02:16:07: Software Revision String: V5.0
02:16:07: Firmware Revision String: github.com/pvvx
02:16:07: Detected custom Firmware
02:16:07: Hardware Version: Unknown or DIY (37) V1.1, Software Version: 5.0
02:16:07: Custom config HEX string: 55873000005004a9310025b4
02:16:10: Get Sensor Settings...
02:16:10: Sensor SHT30 id: 00308010, I2C address: 0x88, Kt: 17500, Kh: 10000, Zt: -4500, Zh: 0

id: 00308010 -> Status Register at startup: 0x8010.

[dynasticorpheus]

Good stuff, mate. Thanks for your efforts :) Greatly appreciated.

The sensor is definitely a CHT832x.

If you are interested in my changes, I have just created a fork and uploaded my changes. https://github.com/dbmaxpayne/ZigbeeTLc

Basically I created or changed the following files:

board_ts0201_tz3000_v1w2k9dd.h
i2c_drv.h
i2c_drv.c
sensor_cht832x.h
sensor_cht832x.c
version_cfg.h

Makes sense by the way that these boards are similar or share the firmware. I saw, that the MCU also scans other I2C addresses like 7C or so.

Do you know why R13 and R11 are there in the first place?

Cheers, Mark

@dbmaxpayne Is this still WIP or can I have a go at it? (make install; make ends up in error at my end hence asking)

[dbmaxpayne]

@dynasticorpheus
I have not uploaded all necessary files like the SDK itself.
That and TC32 would have to be extracted from pvvx's ZIP files.

Let me know in a private message what error you're getting and I might be able to help.
Also I didn't use the make commands, but Telink IoT Studio's build targets (Windows).
Maybe that's the same under the hood, maybe not.
I didn't go too deep into the whole thing and was happy when I was able to compile it :)

I will upload the bin files to my fork in a second if that helps.

Edit:
OTA: https://github.com/dbmaxpayne/ZigbeeTLc/blob/master/bin/1141-0225-01243001-ts0201_tz3000_v1w2k9dd.zigbee
SWire: https://github.com/dbmaxpayne/ZigbeeTLc/blob/master/bin/ts0201_tz3000_v1w2k9dd.bin

[vjaunet]

Hi there, many thanks for all your efforts.
I am a bit confused on how to flash this new firmware to the device. Can I use the z2m OTA procedure or what should I do ?
Many thanks for your help.
Vincent

[dbmaxpayne]

I'd be interested too if there is a way to flash this over a stock firmware via OTA.
I don't know, though.

I used this: https://github.com/pvvx/TlsrComSwireWriter
However, it requires soldering of at least the SWS pin.
GND and VCC can be temporarily connected via a clamp to the battery terminals.
I used a Raspberry Pi 3 for flashing, but it should also work with other USB->UART-Converters.

Erase flash: python3 ./TlsrComSwireWriter/TLSR825xComFlasher.py -p /dev/ttyS0 -t 5000 ea
Write firmware: python3 ./TlsrComSwireWriter/TLSR825xComFlasher.py -p /dev/ttyS0 -t 5000 we ./firmwareFile.bin
Reset CPU: python3 ./TlsrComSwireWriter/TLSR825xComFlasher.py -p /dev/ttyS0 -t 5000 -r

[pvvx]

@dbmaxpayne - what "Zigbee Image Type" does the original TS0201 _TZ3000_v1w2k9dd have?
This is needed for Zigbee OTA.

1002-0203-59013001 ?

Manufacturer Code	Image Type	File Version	Stack Version
1002	0203	5901	3001

?

[dbmaxpayne]

@pvvx
Is there a way to get that information via Zigbee2MQTT?
I haven't gotten my hardware flasher yet, so I cannot retrieve the firmware and check via a hex editor yet.

[pvvx]

ZHA only gives this:

1002-0203-59013001 I got from the header of the firmware binary file.

zigbee_ota.py TS0201_TZ3000_v1w2k9dd_ota.bin 

https://github.com/pvvx/ATC_MiThermometer/tree/master/utils -> zigbee_ota.py

fw 1002-0203-60993001-ZYZTH02BLE_v50.zigbee for converting Tuya Zigbee to BLE added to https://github.com/pvvx/ATC_MiThermometer

I don't use Zigbee2MQTT and I can't say anything about it.
It takes me a lot of time to check 30 versions of different devices in BLE and ZigBee in different programs... :)

[dbmaxpayne]

Sorry, I only started with Zigbee last week when I got those sensors, so my learning curve is still quite steep.
I just enabled debug logging and got the following line:
[2025-01-23 23:01:03] debug: z2m: Received Zigbee message from '0xa4c138bdf4a039ba', type 'commandQueryNextImageRequest', cluster 'genOta', data '{"fieldControl":0,"fileVersion":1510027265,"imageType":515,"manufacturerCode":4098}' from endpoint 1 with groupID 0

So I guess 1002 and 0203 are correct.
However, I don't understand the fileVersion here.

I will try 1002-0203-60993001-ZYZTH02BLE_v50.zigbee on my second sensor once I downloaded its stock firmware.

[pvvx]

For your ts0201_tz3000_v1w2k9dd.bin file, create a header for Zigbee OTA:

python3 make\zb_bin_ota.py bin\ts0201_tz3000_v1w2k9dd.bin bin\ts0201_tz3000_v1w2k9dd -m0x1002 -i0x0203 -v0x60993001 -s"Tuya to ZigbeeTlc"

It will be 1002-0203-60993001-ts0201_tz3000_v1w2k9dd.zigbee

Zigbee OTA is triggered automatically if the program version number is higher.
Or forced OTA is required, but this is difficult to do in Z2M and ZHA.

[vjaunet]

Thanks both for your inputs. I have an "Invalid Image" error from z2m ota update. It was so close ;-) but I am unsure how I can get the exact information
I will try the by-wire flashing asap.
best,

[dbmaxpayne]

@vjaunet
Did you also try Victor's 1002-0203-60993001-ts0201_tz3000_v1w2k9dd.zigbee file?

[vjaunet]

That's the one I tried, obtained as per pvvx instructions from your bin file.

[dbmaxpayne]

@pvvx
Do you know what the purpose of the following traces is?

ZTU	Board	Trace
C0	C0	->R3 (7.5k)->VCC
B5	P34	->R12 (7.5k)->VCC

Can or should they be removed when using your firmware to save power?

[pvvx]

Can or should they be removed when using your firmware to save power?

GPIO_PB5 and GPIO_PC0 are not used. This does not increase battery consumption.

[pvvx]

A large increase in consumption is created by ZHA, forcing the "Long Poll interval" to 6 seconds. This is the notification time of the device that it is working. In the Zigbee 3.0 standard, the "Long Poll interval" is set within the limits that the device transmits. But ZHA does not look at what the device says.

Have to write a patch into the firmware because of ZHA... And the firmware loses full compatibility with ZigBee 3.0.

zha\zigbee\cluster_handlers\general.py (LONG_POLL = 6 * 4 # 6s)

@registries.CLUSTER_HANDLER_ONLY_CLUSTERS.register(PollControl.cluster_id)
@registries.CLUSTER_HANDLER_REGISTRY.register(PollControl.cluster_id)
class PollControlClusterHandler(ClusterHandler):
    """Poll Control cluster handler."""

    CHECKIN_INTERVAL = 55 * 60 * 4  # 55min
    CHECKIN_FAST_POLL_TIMEOUT = 2 * 4  # 2s
    LONG_POLL = 6 * 4  # 6s
    _IGNORED_MANUFACTURER_ID = {
        4476,
    }  # IKEA

    async def async_configure_cluster_handler_specific(self) -> None:
        """Configure cluster handler: set check-in interval."""
        await self.write_attributes_safe(
            {PollControl.AttributeDefs.checkin_interval.name: self.CHECKIN_INTERVAL}
        )

    def cluster_command(
        self, tsn: int, command_id: int, args: list[Any] | None
    ) -> None:
        """Handle commands received to this cluster."""
        if command_id in self.cluster.client_commands:
            cmd_name = self.cluster.client_commands[command_id].name
        else:
            cmd_name = command_id

        self.debug("Received %s tsn command '%s': %s", tsn, cmd_name, args)
        self.emit_zha_event(cmd_name, args)
        if cmd_name == PollControl.ClientCommandDefs.checkin.name:
            self.cluster.create_catching_task(self.check_in_response(tsn))

    async def check_in_response(self, tsn: int) -> None:
        """Respond to checkin command."""
        await self.checkin_response(True, self.CHECKIN_FAST_POLL_TIMEOUT, tsn=tsn)
        if self._endpoint.device.manufacturer_code not in self._IGNORED_MANUFACTURER_ID:
            await self.set_long_poll_interval(self.LONG_POLL)
        await self.fast_poll_stop()

    def skip_manufacturer_id(self, manufacturer_code: int) -> None:
        """Block a specific manufacturer id from changing default polling."""
        self._IGNORED_MANUFACTURER_ID.add(manufacturer_code)

For some reason, for IKEA devices, ZHA ignores the forced LONG_POLL setting of 6 seconds.

CHECK_INTERVAL - after this interval, if the device has not notified, then it will be disconnected from the network.
That is, when the Zigbee coordinator is turned off, the device will drop out of the network in 55 minutes :)
In ZHA they write what they like without adding anything to the settings. And there's a lot of that kind of ugliness there.
It's no better in Z2M...
The batteries are not theirs and they don't care what the users end up with. :)

[pvvx]

"CheckInIntervalMin", "LongPollIntervalMin", "FastPollTimeoutMaximum" attributes are supported in legacy ZigbeeTLc. But ZHA doesn't care.

ZigBee Cluster Library Specification

ZHA believes that it is necessary to maximize the radio channel load so that users cannot use many ZigBee devices on one coordinator.

[dynasticorpheus]

That's the one I tried, obtained as per pvvx instructions from your bin file.

Any luck with applying OTA as soldering is out of my league unfortunately?

[vjaunet]

I'd be interested too if there is a way to flash this over a stock firmware via OTA. I don't know, though.

I used this: https://github.com/pvvx/TlsrComSwireWriter However, it requires soldering of at least the SWS pin. GND and VCC can be temporarily connected via a clamp to the battery terminals. I used a Raspberry Pi 3 for flashing, but it should also work with other USB->UART-Converters.

Erase flash: python3 ./TlsrComSwireWriter/TLSR825xComFlasher.py -p /dev/ttyS0 -t 5000 ea
Write firmware: python3 ./TlsrComSwireWriter/TLSR825xComFlasher.py -p /dev/ttyS0 -t 5000 we ./firmwareFile.bin
Reset CPU: python3 ./TlsrComSwireWriter/TLSR825xComFlasher.py -p /dev/ttyS0 -t 5000 -r

That worked nicely, it was just missing the write address in the second command line :

Write firmware: python3 ./TlsrComSwireWriter/TLSR825xComFlasher.py -p /dev/ttyS0 -t 5000 we 0 ./firmwareFile.bin

Many thanks !

[dbmaxpayne]

So my hardware programmer has finally arrived.
Using python .\TlsrPgm.py -t 1 -a 20 -p COM6 rf 0 0x80000 orig_512k.bin I was able to pull the original firmware which you can find here: TS0201_TZ3000_v1w2k9dd_NoDisplay_ff.bin

I have tried to upgrade the firmware of my second device without soldering by changing the zigbee header using the command @pvvx mentioned:
python3 make\zb_bin_ota.py bin\ts0201_tz3000_v1w2k9dd.bin bin\ts0201_tz3000_v1w2k9dd -m0x1002 -i0x0203 -v0x60993001 -s"Tuya to ZigbeeTlc"

However, I also get an INVALID_IMAGE error.
To me it's not a problem to solder, however, @pvvx would you have a idea what to change by looking at my downloaded firmware to make it work via OTA only?

With my narrow understanding of the topic and using a hex editor I can see that the MANUFACTURER_ID and IMAGE_TYPE should be correct at addresses 0x12 and 0x14.

Cheers,
Mark

[pvvx]

Here are the data obtained in the ZHA log about the firmware in the new https://pvvx.github.io/ZY-ZTH02/:

2025-02-10 17:12:30.243 DEBUG (MainThread) [zigpy.zcl] [0x1CF3:1:0x0019] Decoded ZCL frame: Ota:QueryNextImageCommand(field_control=<FieldControl: 0>, manufacturer_code=4098, image_type=515, current_file_version=1442918401)
2025-02-10 17:12:30.243 DEBUG (MainThread) [zigpy.zcl] [0x1CF3:1:0x0019] Received command 0x01 (TSN 162): QueryNextImageCommand(field_control=<FieldControl: 0>, manufacturer_code=4098, image_type=515, current_file_version=1442918401)

manufacturer_code=4098=0x1002,
image_type=515=0x0203,
current_file_version=1442918401=0x56013001

But, no matter what numbers I put in, ZHA complains during OTA:

I tried to feed it my own original firmware. The result is the same.

---

It seems that the original firmware does not support Zigbee OTA or has an error. It is also possible that some special registration is required from the manufacturer's device.

[dbmaxpayne]

@dynasticorpheus

Any luck with applying OTA as soldering is out of my league unfortunately?

So the most solderless version will probably be using Victor's https://github.com/pvvx/TLSRPGM repo.
However, you will still have to solder one wire on the TB-03F-KIT (see the repo for more info).
I got it on AliExpress for like $4.
(This soldered wire is only needed once and temporarily, though, so you might get away with holding a breadboard cable's pin to CH340's pin for a few seconds - same as I do below with the sensor's MCU).

I used the following command to write the firmware:
python .\TlsrPgm.py -t 1 -a 20 -p COM6 we 0 "..\ZigbeeTLc\bin\TS0201_TZ3000_v1w2k9dd.bin"
It takes like 10 seconds to flash and I used crocodile clamps to connect GND->BAT- and POWER->BAT+ on the sensor's board.
For SWS I simply held a breadboard cable's pin to the MCU's SWS pad.

This will be the way I'm going to reflash the rest of my sensors.
It's not worth it to me to fiddle around more now to get OTA working, sorry.

If you have a USB->UART converter you can also try https://github.com/pvvx/TlsrComProg825x.
You might get away without soldering at all.
However, here the flash process takes like 15 minutes or so.
That's a very long time to hold a cable to the MCU's SWS pin.

[pvvx]

It's not worth it to me to fiddle around more now to get OTA working, sorry.

Apparently, in this version of the original firmware, Zigbee OTA simply does not work. There are many things that point to this. The firmware does not support changing the communication interval, and in the analysis of the operation by current consumption, when turning on OTA, it simply breaks the connection, and when forced to start by short pressing the button, an error appears. Otherwise, OTA will be interrupted due to timeout at the initial 0.3%.

[pvvx]

_TZ3000_v1w2k9dd TS0201 is not suitable for IoT :

Such rare readings are completely unnecessary.

[dbmaxpayne]

_TZ3000_v1w2k9dd TS0201 is not suitable for IoT :

Such rare readings are completely unnecessary.

What do you mean? The stock firmware is very bad, yes, but with your firmware it works well for me.

[pvvx]

What do you mean? The stock firmware is very bad, yes, but with your firmware it works well for me.

I did give a comparison, but with BLE.

[vjaunet]

I'd be interested too if there is a way to flash this over a stock firmware via OTA. I don't know, though.

I used this: https://github.com/pvvx/TlsrComSwireWriter However, it requires soldering of at least the SWS pin. GND and VCC can be temporarily connected via a clamp to the battery terminals. I used a Raspberry Pi 3 for flashing, but it should also work with other USB->UART-Converters.

Erase flash: python3 ./TlsrComSwireWriter/TLSR825xComFlasher.py -p /dev/ttyS0 -t 5000 ea
Write firmware: python3 ./TlsrComSwireWriter/TLSR825xComFlasher.py -p /dev/ttyS0 -t 5000 we ./firmwareFile.bin
Reset CPU: python3 ./TlsrComSwireWriter/TLSR825xComFlasher.py -p /dev/ttyS0 -t 5000 -r

I can't get my flashed Thermometer to join Zigbee2mqtt. Have you managed to get it to join ? Also, no led is working anymore on the thermometer, is that for energy saving purposes ?
Thanks

[pvvx]

The LED works in the TS0201z and ZYZTH02 firmware

https://github.com/pvvx/ZigbeeTLc/raw/refs/heads/master/bin/ZYZTH02_v0124.bin
https://github.com/pvvx/ZigbeeTLc/raw/refs/heads/master/bin/1141-0225-01243001-ZYZTH02.zigbee

https://github.com/pvvx/ZigbeeTLc/raw/refs/heads/master/bin/ZTS0201Z3000_v0124.bin
https://github.com/pvvx/ZigbeeTLc/raw/refs/heads/master/bin/1141-d3a3-01983001-TS0201z_v0124.zigbee

Specify the device variant.

[vjaunet]

I have been delivered TS0201 _TZ3000_v1w2k9dd and try to get around.

[pvvx]

So something went wrong during the firmware. It's worth repeating.

[dbmaxpayne]

LED blinks only very shortly with my firmware.
Not sure if that is by error (I was messing around with it for debugging purposes).
Either way the devices paired quickly after pressing the buttom for like 7 seconds.

If that doesn't work I also recommend just flashing it again.

[pvvx]

@dbmaxpayne In your firmware, the LED always turns on when TLSR825x is active. Blinking indicates any chip activity.
You just have an error in the LED signal inversion.

In the ZigbeeTLc version, the LED works when the button is pressed or blinks on request "Identify", as well as at the time of pairing or when the network connection is lost.

[vjaunet]

I have repeated the flashing process many times without luck. I even read the firware of a brand new device and tried to burn it back, without success. Seems like my flashing set-up does not make it properly...
I am using the serial port of an RPi 4, is there any special care that needs to be done in that case ?

[pvvx]

Rpi cannot transmit a continuous stream of bytes to UART.
Cheap USB-COM adapters work fine.
And on RPi a lot of things work incorrectly.

[dbmaxpayne]

Interesting. I actually used an RPi 3B for intial flashing as my USB->UART (FTDI) didn't work.
Maybe I just got lucky.
However, did you use the resistor mentioned here?
https://github.com/pvvx/TlsrComSwireWriter

You must also connect GND of the MCU and RPi together so they share a common ground.
Also wires should be as short as possible.

[dbmaxpayne]

Oh and if you are using pigpiod or any other interrupt-based software, disable that before flashing as it might interfere with the correct timings.
Apart from that I can recommend pigpiod in combination with piscope for debugging of your UART.

[vjaunet]

Finally got it to work on the RPI 4 !
The wiring was ok, the resistor also and grounding was fine but :

• I was missing the reset line of tlsrComSwire
• I had to disable pigpiod as you mentioned.

Many many thanks both @dbmaxpayne and @pvvx !

[vjaunet]

Hi there, the TS0201-z work and seem to provide reliable temperature (although quite low), but tends to produce data at uneven time. Also, the "measurement interval" setting does not correspond to the indications. I had to set its value to 60 in order to have data every 2 to 4 minutes.
Could that be related to the z2m integration ?
Best,

[pvvx]

Also, the "measurement interval" setting does not correspond to the indications.

In Zigbee there are "report" settings.

DeepSeek response:

---

ZigBee is a specification for a suite of high-level communication protocols used to create personal area networks with small, low-power digital radios. It is commonly used in home automation, medical data collection, and other low-power low-bandwidth needs. The "report" settings in ZigBee typically refer to the configuration of how and when a device sends data to the coordinator or other devices in the network.

Here are some key concepts related to ZigBee reporting settings:

Attribute Reporting: In ZigBee, devices can report the status of their attributes (like temperature, humidity, etc.) to the network. The reporting can be configured based on changes in the attribute value or at regular intervals.

Reportable Change: This setting determines the minimum change in an attribute's value that must occur before a report is sent. For example, a temperature sensor might be set to report only if the temperature changes by more than 1 degree.

Reporting Interval: This is the maximum time interval between reports. Even if the attribute value hasn't changed by the reportable change amount, a report will be sent after this interval has elapsed.

Timeout: Some ZigBee devices can be configured to stop reporting if no changes are detected within a certain timeout period.

Bindings: ZigBee devices can be bound to each other, meaning that one device is configured to send reports directly to another. This is often used to create direct communication links between sensors and actuators without the need for a central coordinator.

Cluster-Specific Reporting: Different clusters (groups of attributes and commands) may have different reporting settings. For example, a lighting cluster might have different reporting requirements than a temperature sensing cluster.

Configuration via Commissioning Tools: Reporting settings are typically configured during the commissioning of the ZigBee network using specialized software tools provided by the device manufacturers or ZigBee stack vendors.

Over-the-Air (OTA) Configuration: Some ZigBee devices allow for the reporting settings to be configured or updated over the air, which means that the settings can be changed remotely without physical access to the device.

ZigBee Cluster Library (ZCL): The ZCL defines a set of clusters and their associated attributes and commands. Reporting settings are often defined within the context of the ZCL.

ZigBee Green Power: For devices that are energy harvesting or have very limited power, reporting settings might be optimized to minimize energy consumption, which could mean less frequent reporting or reporting only significant changes.

When setting up a ZigBee network, it's important to configure the reporting settings according to the needs of the application to balance between timely data updates and network traffic or power consumption. The specific methods for configuring these settings will depend on the ZigBee stack and tools being used.

---

[pvvx]

@vjaunet - DeepSeek's full answer to your question:

Hi there, the TS0201-z work and seem to provide reliable temperature (although quite low), but tends to produce data at uneven time. Also, the "measurement interval" setting does not correspond to the indications. I had to set its value to 60 in order to have data every 2 to 4 minutes.
Could that be related to the z2m integration ?

Hi! It sounds like you're experiencing some inconsistencies with the TS0201-Z temperature sensor, particularly with the measurement interval and data reporting times. Let's break down the potential issues and solutions:

1. Measurement Interval Not Matching Settings
   The TS0201-Z is a Zigbee-based temperature sensor, and its behavior can sometimes be influenced by the Zigbee network or the integration (like Zigbee2MQTT, or z2m).

If the "measurement interval" setting doesn't correspond to the actual data reporting frequency, it could be due to:

Power-saving mechanisms: Many Zigbee devices are designed to conserve battery life, so they might not report data exactly at the set interval.

Zigbee network latency: If your Zigbee network is busy or has interference, the device might delay sending data.

Firmware limitations: Some devices have firmware that doesn't strictly adhere to the configured interval.

Setting the interval to 60 and getting data every 2–4 minutes suggests the device might be aggregating data or waiting for a specific condition (e.g., significant temperature change) before reporting.

2. Uneven Reporting Times
   Uneven reporting times are common in Zigbee devices, especially battery-powered ones. This is often due to:

Battery-saving algorithms: The device might wait for a stable connection or a specific time window to send data.

Network congestion: If your Zigbee network has many devices or interference, the sensor might delay sending data until the network is clear.

Temperature change thresholds: Some sensors only report data if the temperature changes by a certain amount (e.g., 0.5°C). If the temperature is stable, the device might not report data as frequently.

3. Zigbee2MQTT (z2m) Integration
   The z2m integration itself is unlikely to cause the issue, but it can influence how the device behaves. Here are a few things to check:

Device configuration in z2m: Ensure the device is properly configured in z2m. Sometimes, settings like reporting interval or battery reporting can affect behavior.

z2m logs: Check the z2m logs for any errors or warnings related to the TS0201-Z. This might give you clues about why the data is irregular.

z2m version: Ensure you're using the latest version of z2m, as updates often include bug fixes and improvements for specific devices.

4. Temperature Readings Seem Low
   If the temperature readings seem consistently low, this could be due to:

Sensor calibration: Some sensors might need calibration or have an offset.

Placement: Ensure the sensor is placed in a location that accurately reflects the temperature you want to measure (e.g., away from drafts, direct sunlight, or heat sources).

Firmware bug: Check if there are any known issues or firmware updates for the TS0201-Z.

Recommendations:
Check Device Documentation: Look up the TS0201-Z's manual or specifications to confirm its expected behavior and configuration options.

Experiment with Settings: Try adjusting the measurement interval and temperature change threshold in z2m to see if it improves the reporting frequency.

Test in a Different Location: Move the sensor to a different location to rule out environmental factors affecting the readings.

Update Firmware: If the device supports firmware updates, ensure it's running the latest version.

Monitor Zigbee Network: Use a tool like z2m's network map to check for interference or weak signal strength that might affect the device's performance.

If the issue persists, you might want to reach out to the z2m community or the device manufacturer for further assistance. Let me know if you need help with any of these steps!

[pvvx]

reliable temperature (although quite low),

If the CHT8305 sensor is installed.
Do not forget that Tuya devices are made of cheap elements. The working voltage range of the sensor used is from 2.5V. At lower supply voltage, the readings are distorted. This sensor is not designed to operate from 3V batteries.

When the battery voltage drops below 2.5V, it often manifests itself as follows:

[dbmaxpayne]

I'm currently happy with the devices and dont see the erratic temperature measurement (yet).
However, I'm using rechargeable batteries, so it should manifest iteself shortly.
I don't think it will, though, as the sensors are CHT832x and their datasheet specifies an operating voltage of 1.8V to 5.5V.

About the uneven report intervals I have not tried to change anything as Victor's firmware reports every 0.1°C change anyway.

[pvvx]

I don't think it will, though, as the sensors are CHT832x and their datasheet specifies an operating voltage of 1.8V to 5.5V.

vjaunet indicated that he has TS0201-z.

Hi there, the TS0201-z work ...

The TS0201-z has a CHT8305 sensor installed.

About the uneven report intervals I have not tried to change anything as Victor's firmware reports every 0.1°C change anyway.

But ZHA sets its own values ​​for report. Changing to the desired settings is possible only by patching the ZHA code.

[dbmaxpayne]

vjaunet indicated that he has TS0201-z.
TS0201-z is what is reported for TS0201 _TZ3000_v1w2k9dd in Zigbee2MQTT after flashing your firmware.
If the PCB looks like the one mentioned earlier in this thread, the sensor should be CHT832x.

[pvvx]

https://pvvx.github.io/ZY-ZTH02/ - TS0201_TZ3000_v1w2k9dd

• Zigbee Image Type 0x0225,
• ZigbeeTLc file name: "ZYZTH02_v0124.bin" / "1141-0225-01243001-ZYZTH02.zigbee".
• Name displayed in Z2M/ZHA: ZCL_BASIC_MODEL_ID: "ZYZTH02-z" , ZCL_BASIC_MFG_NAME: "Tuya"

If the PCB looks like the one mentioned earlier in this thread, the sensor should be CHT832x.

Many people do not read carefully what is being discussed and write any questions in all topics.

https://pvvx.github.io/TS0201_TZ3000/ - TS0201 _TZ3000_xr3htd96, _TZ3000_qsefbina, display name in Z2M/ZHA: "TS0201-z"

[vjaunet]

I confirm that I have TS0201 _TZ3000_v1w2k9dd device that shows up as TS0201-z in z2m.

But ZHA sets its own values ​​for report. Changing to the desired settings is possible only by patching the ZHA code.

That is something I was not aware of. I need to dig more into the different possible firmware, but to be honest it is a bit complicated for me to figure all of this out.

About the uneven report intervals I have not tried to change anything as Victor's firmware reports every 0.1°C change anyway.

I was not aware of that and it that is probably why I am having uneven reports then...

I will continue to dig all of that in, but it seems that I need to write an external converter for z2m to correctly handle the device.

Thanks guys.