[Device Support Request] TS0222 by _TYZB01_kvwjujy9 (E-Ink Brightness Thermometer)

[almico]

The problem The device is identified and added. Reported readings are humidity, illuminance, power and temperature. The temperature is often reported as 0° C, and, when this happens, illuminance shown on the device display is 0 Lux. About every 150 seconds, the devices seems to reset (its screen goes blank and then reappears) and, at the same time, in the log appear the following messages:

2021-07-15 08:26:50 DEBUG (MainThread) [zigpy.device] Ignoring message (b'08010a01f0211400') on cluster 1024: unknown endpoint or cluster id: 'No cluster ID 0x0400 on (xx:yy:zz:aa:bb:cc:dd:ee, 2)'
2021-07-15 08:26:52 DEBUG (MainThread) [zigpy.device] Ignoring message (b'08010a01f0211400') on cluster 1024: unknown endpoint or cluster id: 'No cluster ID 0x0400 on (xx:yy:zz:aa:bb:cc:dd:ee, 2)'
2021-07-15 08:26:53 DEBUG (MainThread) [zigpy.device] Ignoring message (b'08010a01f0211400') on cluster 1024: unknown endpoint or cluster id: 'No cluster ID 0x0400 on (xx:yy:zz:aa:bb:cc:dd:ee, 2)'

Where xx:yy:zz:aa:bb:cc:dd:ee is the anonymized form of the device address. The messages above always appear in a group of three consecutive ones.

Desired solution I would like to read correct values and not see the device resetting every 150 seconds.

Device signature

[0x0000:zdo] ZDO request ZDOCmd.Mgmt_Permit_Joining_req: [60, <Bool.false: 0>]
[0xcb5b] Delivery error for seq # 0x49, on endpoint id 0 cluster 0x0034: message send failure
Sending 'zdo_leave_req' failed: [0xcb5b:0:0x0034]: Message send failure
[0x7c46:zdo] ZDO request ZDOCmd.NWK_addr_req: [00:21:2e:ff:ff:06:be:73, 0, 0]
[0x7c46:1:0x0000] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=5 command_id=Command.Report_Attributes>
[0x7c46:1:0x0000] ZCL request 0x000a: [[Attribute(attrid=1, value=<TypeValue type=uint8_t, value=67>)]]
[0x7c46:1:0x0000] Attribute report received: app_version=67
[0x7c46:5:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=4 command_id=Command.Report_Attributes>
[0x7c46:5:0x0006] ZCL request 0x000a: [[Attribute(attrid=0, value=<TypeValue type=Bool, value=Bool.false>)]]
[0x7c46:5:0x0006] Attribute report received: on_off=0
[0x0bd7:zdo] ZDO request ZDOCmd.Match_Desc_req: [0xFFFD, 49246, [25], []]
light.linea_sotto_tv: polling current state
[0xae4f:11:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=81 command_id=Command.Read_Attributes_rsp>
[0xae4f:11:0x0008] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=83 command_id=Command.Read_Attributes_rsp>
[0xAE4F:11:0x0008]: received attribute: 0 update with value: 20
[0xae4f:11:0x0300] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=85 command_id=Command.Read_Attributes_rsp>
New device 0xf824 (xx:yy:zz:aa:bb:cc:dd:ee) joined the network
[0xf824] Scheduling initialization
Received frame on uninitialized device <Device model=None manuf=None nwk=0xF824 ieee=xx:yy:zz:aa:bb:cc:dd:ee is_initialized=False> from ep 0 to ep 0, cluster 19: b'\x8c$\xf8\xd9?\x04\xfe\xffr\x02\\\x80'
[0xf824:zdo] ZDO request ZDOCmd.Device_annce: [0xF824, xx:yy:zz:aa:bb:cc:dd:ee, 128]
Tries remaining: 3
[0xf824] Requesting 'Node Descriptor'
Tries remaining: 2
[0xf824] Extending timeout for 0x57 request
Received frame on uninitialized device <Device model=None manuf=None nwk=0xF824 ieee=xx:yy:zz:aa:bb:cc:dd:ee is_initialized=False> from ep 0 to ep 0, cluster 32770: b'W\x00$\xf8\x02@\x80\x02\x10RR\x00\x00,R\x00\x00'
[0xf824] Got Node Descriptor: NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.0: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)
[0xf824] Discovering endpoints
Tries remaining: 3
[0xf824] Extending timeout for 0x59 request
Received frame on uninitialized device <Device model=None manuf=None nwk=0xF824 ieee=xx:yy:zz:aa:bb:cc:dd:ee is_initialized=False> from ep 0 to ep 0, cluster 32773: b'Y\x00$\xf8\x02\x01\x02'
[0xf824] Discovered endpoints: [1, 2]
[0xf824] Initializing endpoints [<Endpoint id=1 in=[] out=[] status=<Status.NEW: 0>>, <Endpoint id=2 in=[] out=[] status=<Status.NEW: 0>>]
[0xf824:1] Discovering endpoint information
Tries remaining: 3
[0xf824] Extending timeout for 0x5b request
Received frame on uninitialized device <Device model=None manuf=None nwk=0xF824 ieee=xx:yy:zz:aa:bb:cc:dd:ee is_initialized=False> from ep 2 to ep 1, cluster 1024: b'\x08\n\n\x01\xf0!\x14\x00'
[0xf824] Received ZCL while uninitialized on endpoint id 2, cluster 0x0400 id, hdr: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=10 command_id=Command.Report_Attributes>, payload: b'\x01\xf0!\x14\x00'
[0xf824] Uninitialized device command 'Command.Report_Attributes' args: [[Attribute(attrid=61441, value=<TypeValue type=uint16_t, value=20>)]]
Received frame on uninitialized device <Device model=None manuf=None nwk=0xF824 ieee=xx:yy:zz:aa:bb:cc:dd:ee is_initialized=False> from ep 0 to ep 0, cluster 32772: b'[\x00$\xf8\x12\x01\x04\x01\x06\x01\x01\x03\x00\x00\x01\x00\x00\x04\x02\x19\x00\n\x00'
[0xf824:1] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=1, profile=260, device_type=262, device_version=1, input_clusters=[0, 1, 1024], output_clusters=[25, 10])
[0xf824:2] Discovering endpoint information
Tries remaining: 3
[0xf824] Extending timeout for 0x5d request
Received frame on uninitialized device <Device model=None manuf=None nwk=0xF824 ieee=xx:yy:zz:aa:bb:cc:dd:ee is_initialized=False> from ep 0 to ep 0, cluster 32772: b']\x00$\xf8\x0c\x02\x04\x01\x02\x03\x01\x02\x02\x04\x05\x04\x00'
[0xf824:2] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=2, profile=260, device_type=770, device_version=1, input_clusters=[1026, 1029], output_clusters=[])
[0xf824] Extending timeout for 0x5f request
[0xf824:1:0x0000] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=95 command_id=Command.Read_Attributes_rsp>
[0xf824] Read model 'TS0222' and manufacturer '_TYZB01_kvwjujy9' from <Endpoint id=1 in=[basic:0x0000, power:0x0001, illuminance:0x0400] out=[ota:0x0019, time:0x000A] status=<Status.ZDO_INIT: 1>>
[0xf824] Discovered basic device information for <Device model='TS0222' manuf='_TYZB01_kvwjujy9' nwk=0xF824 ieee=xx:yy:zz:aa:bb:cc:dd:ee is_initialized=True>
Device is initialized <Device model='TS0222' manuf='_TYZB01_kvwjujy9' nwk=0xF824 ieee=xx:yy:zz:aa:bb:cc:dd:ee is_initialized=True>
Checking quirks for _TYZB01_kvwjujy9 TS0222 (xx:yy:zz:aa:bb:cc:dd:ee)
Considering <class 'zhaquirks.xbee.xbee_io.XBeeSensor'>
Fail because endpoint list mismatch: {232, 230} {1, 2}
Considering <class 'zhaquirks.xbee.xbee3_io.XBee3Sensor'>
Fail because endpoint list mismatch: {232, 230} {1, 2}
Considering <class 'zhaquirks.smartthings.tag_v4.SmartThingsTagV4'>
Fail because endpoint list mismatch: {1} {1, 2}
Considering <class 'zhaquirks.smartthings.multi.SmartthingsMultiPurposeSensor'>
Fail because endpoint list mismatch: {1} {1, 2}
Considering <class 'zhaquirks.netvox.z308e3ed.Z308E3ED'>
Fail because endpoint list mismatch: {1} {1, 2}
Considering <class 'zhaquirks.gledopto.soposhgu10.SoposhGU10'>
Fail because endpoint list mismatch: {11, 13} {1, 2}
Considering <class 'bellows.zigbee.application.EZSPCoordinator'>
Fail because endpoint list mismatch: {1} {1, 2}
device - 0xF824:xx:yy:zz:aa:bb:cc:dd:ee entering async_device_initialized - is_new_join: True
device - 0xF824:xx:yy:zz:aa:bb:cc:dd:ee has joined the ZHA zigbee network
[0xF824](TS0222): started configuration
[0xF824:ZDO](TS0222): 'async_configure' stage succeeded
[0xf824] Extending timeout for 0x61 request
[0xF824:1:0x0000]: finished channel configuration
[0xf824] Extending timeout for 0x63 request
[0xF824:1:0x0019]: finished channel configuration
[0xf824] Extending timeout for 0x65 request
Error handling '_save_attribute' event with (xx:yy:zz:aa:bb:cc:dd:ee, 1, 0, 4, '_TYZB01_kvwjujy9') params: FOREIGN KEY constraint failed
Error handling '_save_attribute' event with (xx:yy:zz:aa:bb:cc:dd:ee, 1, 0, 5, 'TS0222') params: FOREIGN KEY constraint failed
[0xF824:1:0x0400]: bound 'illuminance' cluster: Status.SUCCESS
[0xf824] Extending timeout for 0x67 request
[0xF824:1:0x0001]: bound 'power' cluster: Status.SUCCESS
[0xf824] Extending timeout for 0x69 request
[0xF824:2:0x0405]: bound 'humidity' cluster: Status.SUCCESS
[0xf824] Extending timeout for 0x6b request
Ignoring message (b'080a0a01f0211400') on cluster 1024: unknown endpoint or cluster id: 'No cluster ID 0x0400 on (xx:yy:zz:aa:bb:cc:dd:ee, 2)'
[0xf824:1:0x0400] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=103 command_id=Command.Configure_Reporting_rsp>
[0xF824:1:0x0400]: reporting 'measured_value' attr on 'illuminance' cluster: 30/900/1: Result: '[[ConfigureReportingResponseRecord(status=0)]]'
[0xF824:1:0x0400]: finished channel configuration
[0xf824] Extending timeout for 0x6d request
[0xf824:1:0x0001] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=105 command_id=Command.Configure_Reporting_rsp>
[0xF824:1:0x0001]: reporting 'battery_voltage' attr on 'power' cluster: 3600/10800/1: Result: '[[ConfigureReportingResponseRecord(status=0)]]'
[0xf824] Extending timeout for 0x6f request
[0xF824:2:0x0402]: bound 'temperature' cluster: Status.SUCCESS
[0xf824] Extending timeout for 0x71 request
[0xf824:1:0x0001] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=111 command_id=Command.Configure_Reporting_rsp>
[0xF824:1:0x0001]: reporting 'battery_percentage_remaining' attr on 'power' cluster: 3600/10800/1: Result: '[[ConfigureReportingResponseRecord(status=0)]]'
[0xF824:1:0x0001]: finished channel configuration
[0xF824:1:0x0400]: 'async_configure' stage succeeded
[0xF824:1:0x0000]: 'async_configure' stage succeeded
[0xF824:1:0x0001]: 'async_configure' stage succeeded
[0xF824:1:0x0019]: 'async_configure' stage succeeded
[0xf824:2:0x0402] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=113 command_id=Command.Configure_Reporting_rsp>
[0xF824:2:0x0402]: reporting 'measured_value' attr on 'temperature' cluster: 30/900/50: Result: '[[ConfigureReportingResponseRecord(status=0)]]'
[0xF824:2:0x0402]: finished channel configuration
[0xf824:2:0x0405] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=107 command_id=Command.Configure_Reporting_rsp>
[0xF824:2:0x0405]: reporting 'measured_value' attr on 'humidity' cluster: 30/900/100: Result: '[[ConfigureReportingResponseRecord(status=0)]]'
[0xF824:2:0x0405]: finished channel configuration
[0xF824:2:0x0405]: 'async_configure' stage succeeded
[0xF824:2:0x0402]: 'async_configure' stage succeeded
[0xF824](TS0222): completed configuration
[0xF824](TS0222): stored in registry: ZhaDeviceEntry(name='_TYZB01_kvwjujy9 TS0222', ieee='xx:yy:zz:aa:bb:cc:dd:ee', last_seen=1626330794.7582607)
[0xF824](TS0222): started initialization
[0xF824:ZDO](TS0222): 'async_initialize' stage succeeded
[0xF824:1:0x0400]: initializing channel: from_cache: False
[0xf824] Extending timeout for 0x73 request
[0xF824:1:0x0000]: initializing channel: from_cache: False
[0xF824:1:0x0000]: finished channel configuration
[0xF824:1:0x0001]: initializing channel: from_cache: False
[0xf824] Extending timeout for 0x75 request
[0xF824:1:0x0019]: initializing channel: from_cache: False
[0xF824:1:0x0019]: finished channel configuration
[0xF824:2:0x0405]: initializing channel: from_cache: False
[0xf824] Extending timeout for 0x77 request
[0xf824:2:0x0402] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=11 command_id=Command.Report_Attributes>
[0xf824:2:0x0402] ZCL request 0x000a: [[Attribute(attrid=0, value=<TypeValue type=int16s, value=2730>)]]
[0xf824:2:0x0402] Attribute report received: measured_value=2730
[0xf824:1:0x0400] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=115 command_id=Command.Read_Attributes_rsp>
[0xF824:1:0x0400]: finished channel configuration
[0xF824:2:0x0402]: initializing channel: from_cache: False
[0xf824] Extending timeout for 0x7a request
[0xf824:1:0x0001] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=117 command_id=Command.Read_Attributes_rsp>
[0xf824] Extending timeout for 0x7c request
[0xf824:2:0x0405] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=119 command_id=Command.Read_Attributes_rsp>
[0xF824:2:0x0405]: finished channel configuration
[0xf824:2:0x0405] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=12 command_id=Command.Report_Attributes>
[0xf824:2:0x0405] ZCL request 0x000a: [[Attribute(attrid=0, value=<TypeValue type=uint16_t, value=4992>)]]
[0xf824:2:0x0405] Attribute report received: measured_value=4992
[0xf824:2:0x0402] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=122 command_id=Command.Read_Attributes_rsp>
[0xF824:2:0x0402]: finished channel configuration
[0xF824:2:0x0405]: 'async_initialize' stage succeeded
[0xF824:2:0x0402]: 'async_initialize' stage succeeded
[0xf824:1:0x0001] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=124 command_id=Command.Read_Attributes_rsp>
[0xF824:1:0x0001]: finished channel configuration
[0xF824:1:0x0400]: 'async_initialize' stage succeeded
[0xF824:1:0x0000]: 'async_initialize' stage succeeded
[0xF824:1:0x0001]: 'async_initialize' stage succeeded
[0xF824:1:0x0019]: 'async_initialize' stage succeeded
[0xF824](TS0222): power source: Battery or Unknown
[0xF824](TS0222): completed initialization
[0xf824:1:0x0400] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=13 command_id=Command.Report_Attributes>
[0xf824:1:0x0400] ZCL request 0x000a: [[Attribute(attrid=0, value=<TypeValue type=uint16_t, value=10001>)]]
[0xf824:1:0x0400] Attribute report received: measured_value=10001
[0xf824:1:0x000a] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=19 command_id=Command.Read_Attributes>
[0xf824:1:0x000a] ZCL request 0x0000: [[7]]
[0x0ef7:1:0x0400] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=83 command_id=Command.Report_Attributes>
[0x0ef7:1:0x0400] ZCL request 0x000a: [[Attribute(attrid=0, value=<TypeValue type=uint16_t, value=24984>)]]
[0x0ef7:1:0x0400] Attribute report received: measured_value=24984

Additional context The device, if not paired to Home Assistant, worked properly, showing correct values and never resetting.

[almico]

I have found this page, where I read:

ZHA: When the screen refreshes, some values get reported as 0 for a while!

I think this is a wrong description of what's going on, because I've seen the device change displayed values without having to turn off and on the whole display. A better description on that page should be "ZHA: the device seems to reset every 150 seconds and this causes the temperature to be reported, via ZigBee (not on the display), as 0° C, and the display displays 0 Lux".

[almico]

In the meantime, I have connected the device to an official Tuya ZigBee gateway and upgraded the firmware. Like I noticed prior to connecting it to Home Assistant, the device doesn't "reset" (doesn't show a blank screen every 150 seconds), thus my best guess is that ZHA sends something to the device causing it to sort of "reconfigure" some parameter that causes it to "reset" every 150 seconds.

[almico]

I reconnected to Home Assistant after the firmware upgrade and the issue is exactly the same as before 😭

[almico]

After about 18 hours, I had to remove the device from HA, remove the battery, put the battery back in and connect to an official Tuya ZigBee gateway where it is currently working perfectly. I had to remove from HA, because a small "!" appeared in the upper left side of the device's display and, after the usual "resets", everything was set to ZERO. Then, only LUX changed to something meaningful, while temperature and humidity remained set at ZERO.

[almico]

Is there any way I can help to make this device usable within ZHA?

[nohat]

I don't have a solution yet, but I am going to attempt to make a quirk for this device (I have 4 of them and have the same problem).

My hypothesis is that the crashing is related to an error in the way the device reports its configuration when pairing. During pairing, the device reports input cluster 1024 (0x0400 Illuminance Measurement) configured on endpoint 1:

[0xf824:1] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=1, profile=260, device_type=262, device_version=1, input_clusters=[0, 1, 1024], output_clusters=[25, 10])

It reports the 0x0402 Temperature Measurement (1026) and 0x0405 Relative Humidity Measurement (1029) clusters on endpoint 2:

[0xf824:2] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=2, profile=260, device_type=770, device_version=1, input_clusters=[1026, 1029], output_clusters=[])

But then it attempts to send attribute report messages for cluster 1024 on endpoint 2:

2021-07-15 08:26:50 DEBUG (MainThread) [zigpy.device] Ignoring message (b'08010a01f0211400') on cluster 1024: unknown endpoint or cluster id: 'No cluster ID 0x0400 on (xx:yy:zz:aa:bb:cc:dd:ee, 2)'

I'm not completely certain, but my guess is that when the device makes those reports on the wrong endpoint, somewhere in the ZHA stack is not acknowledging those reports in a way the device expects. The zigpy.device log message says "Ignoring message". The device tries to send the report 3 times before giving up or crashing, leaving it in the broken state observed here:

the device seems to reset every 150 seconds and this causes the temperature to be reported, via ZigBee (not on the display), as 0° C, and the display displays 0 Lux

I assume it was an error for the configuration to report cluster 1024 on endpoint 1. Endpoint 1 seems to be mostly for general device configuration: 0x0000 Basic Cluster (0), 0x0001 Power Configuration Cluster (1), 0x0019 OTA Upgrade Cluster (25), and 0x000A Time Cluster (10). Endpoint 2 has two of the three measurement clusters: 0x0402 Temperature Measurement (1026) and 0x0405 Relative Humidity Measurement (1029). It would stand to reason that the Illuminance Measurement cluster is also meant to be on endpoint 2, and it appears that at least some of the device's firmware is set up to work that way, as the measurement reporting on that cluster which zigpy is ignoring is coming from endpoint 2. I believe the endpoint descriptor with cluster 0x0400 on endpoint 1 is simply a firmware bug and I hope it can be compensated for with a ZHA quirk.

[nohat]

I created a quirk, but it still doesn't work quite right.

• The quirk creates two illuminance sensors in HA but only one of them ever gets any data.
• The devices don't reboot quite as often, some don't reboot at all, but some do occasionally.
• The devices report their data unreliably, and I see illuminance attribute reports from both endpoints, 1 and 2.

I'm not sure if it's my ZHA instance or something else, but, I only have one Zigbee coordinator, a HUSBZB-1, and I have not yet attempted to collect traces using Wireshark.

"""Tuya illuminance temperature humidity sensor."""
from zigpy.profiles import zha
from zigpy.quirks import CustomDevice
from zigpy.zcl.clusters.general import (
    Basic,
    Ota,
    PowerConfiguration,
    Time,
)
from zigpy.zcl.clusters.measurement import (
    IlluminanceMeasurement,
    TemperatureMeasurement,
    RelativeHumidity,
)

from zhaquirks.const import (
    DEVICE_TYPE,
    ENDPOINTS,
    INPUT_CLUSTERS,
    MODELS_INFO,
    OUTPUT_CLUSTERS,
    PROFILE_ID,
)

class IlluminanceTemperatureHumiditySensor(CustomDevice):
    """Tuya illuminance temperature humidity sensor."""

    signature = {
        MODELS_INFO: [("_TYZB01_kvwjujy9", "TS0222")],

        ENDPOINTS: {
            1: {
                # <SimpleDescriptor endpoint=1 profile=260 device_type=262
                # input_clusters=[0, 1, 1024],
                # output_clusters=[25, 10])
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.LIGHT_SENSOR,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    PowerConfiguration.cluster_id,
                    IlluminanceMeasurement.cluster_id,
                ],
                OUTPUT_CLUSTERS: [Ota.cluster_id, Time.cluster_id]
            },
            2: {
                #  <SimpleDescriptor endpoint=2 profile=260 device_type=770
                # input_clusters=[1026, 1029]
                # output_clusters=[]
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.TEMPERATURE_SENSOR,
                INPUT_CLUSTERS: [
                    TemperatureMeasurement.cluster_id,
                    RelativeHumidity.cluster_id,
                ],
                OUTPUT_CLUSTERS: [],
            },
        },
    }
    replacement = {
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.LIGHT_SENSOR,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    PowerConfiguration.cluster_id,
                    IlluminanceMeasurement.cluster_id,
                ],
                OUTPUT_CLUSTERS: [Ota.cluster_id, Time.cluster_id]
            },
            2: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.TEMPERATURE_SENSOR,
                INPUT_CLUSTERS: [
                    IlluminanceMeasurement.cluster_id,
                    TemperatureMeasurement.cluster_id,
                    RelativeHumidity.cluster_id,
                ],
                OUTPUT_CLUSTERS: [],
            },
        },
    }

I wonder if we need a solution similar to what the folks commenting at #862 are working towards.

[nohat]

I created a quirk, but it still doesn't work quite right.

For those who would like to follow along at home, in order to test this quirk I put the following into my configuration.yaml:

zha:
  custom_quirks_path: /config/custom_zha_quirks/

And then dropped the file (named ts0222.py) into /config/custom_zha_quirks/ on my HA instance using the File Editor add-on.

[almico]

I wonder if we need a solution similar to what the folks commenting at #862 are working towards.

Are you referring to the 255 broadcast endpoint?

[kkossev]

Hi @nohat Is there anything new towards finding the reason(s) for TS0222 self-reboots?

[kkossev]

@almico is your TS0222 device connected to the Zigbee coordinator directly, or via a zigbee repeater?

[almico]

@kkossev directly to the coordinator (one meter away) I removed the battery of the TS0222 and haven't reconnected since I opened this issue, though, because I don't know if the continuous resets could harm the device itself.

[kkossev]

I've been trying in the last few weeks to make the same device working in another home automation platform (Hubitat). Finally, it turned out that TS0222 works OK, without any resets and false zero readings only when the device is connected to the hub radio via any kind of Zigbee repeating device... Contrary, when paired directly to the Zigbee coordinator it resets every hour... Frequent resetting is unlikely to harm the device itself, but undoubtedly it affects the battery life (as the device re-joins the zigbee network 24 times a day!), the visual experience is very unpleasant and it also may send zero values for all the 3 parameters immediately following the self-reset.

I have now two devices connected to two different hubs and both are working without a single self-reset in the past 3 days after I ensured they are communicating to the Zigbee coordinator via repeaters. What worked for me was to remove the battery and re-insert it after 30 seconds being very close to a zigbee repeater or mains-powered zigbee device in the same network. (link)

So it will be interesting to see whether the same 'effect' can be observed with ZHA ?

[almico]

Might this PR be useful for this device too?

[kkossev]

@almico I checked the Neo temperature humidity and illuminance sensor link, but this is another device and probably the problems there are different..

BTW, yesterday I made the same experiment using zigtbee2mqtt in HA, where it is assumed that TS0222works fine. Nope! Exactly the same problems and exactly the same workaround! The device resets rather often when paired directly to the zigbee coordinator ( CC2531 ). When the communication goes through a zigbee repeater, there are no resets, no false zero readings and all works fine.

[almico]

@kkossev I will check, then. At the beginning, it was connected via a repeater and failed miserably. Maybe some changes in the code improved things.

[almico]

@kkossev unfortunately, I paried it via a Philips Hue and, after some seconds, reported (and showed) "0 LUX". I'm going to remove from the network, remove the battery and wait for better times 😢

[almico]

It just reset in front of me, showing all zeroes 😭

[kkossev]

That's weird.... I have replicated the same "repeater / no repeater" behavior in several different combinations, in 3 different platforms ( SmartThings, Hubitat and zigbee2mqtt) with 2 different TS0222 devices. Also I used different zigbee repeating devices.

Is there a way in ZHA to verify whether the communication from a particular device to the zigbee coordinator is going through a specific repeater or is direct?

[almico]

Is there a way in ZHA to verify whether the communication from a particular device to the zigbee coordinator is going through a specific repeater or is direct?

Well... I simply put the device in a place the coordinator cannot reach 😃

[almico]

in 3 different platforms ( SmartThings, Hubitat and zigbee2mqtt)

Did you verify it with ZHA?

[kkossev]

I am experimenting with ZHA right now, and the results are not good.. :(

Last hope - a Tuya device communicating through a Tuya repeater.

If this doesn't work - I give up.. :(

[almico]

There are two sad things I see:

1. It looks like Tuya integration in Home Assistant doesn't support zigbee devices. Sad.
2. This path taken by Tuya of using out-of-standard zigbee communications will force me to stay away from Tuya. Very sad.

[MattWestb]

@kkossev you have founding the network card that great for see the devices is connected but is updated in the background around every 4 hour but you can clicking on update on the map and clicking on somthing else (like groups) and back and you is getting the updated view (if you is doing to oft ZHA is canceling the scan).

Next trick is "adding device thru this device" then you can forcing witch parent your devices shall having for joining but all devices dont like all routers so it can being problem forcing one special router with some devices.

Its looks like different radios (Zigbee coordinators) is working little different and can having problems with some devices like IKEA controllers and direct children and can being little tricky 2.

[almico]

@MattWestb Thank you for the tip about refreshing the map in HA ❤️ According to what I've read in some repositories, my best bet is that Z2M has better support for these Tuya devices using non-standard protocols and, I think, the presence of an intermediate repeater making things work better might be due to some timing issues in Z2M (communicating too fast, for example?).

[kkossev]

@almico let me disagree with you, my observation is that the Home Assistant community provides remarkable good support for Tuya (or 'Powered by Tuya' devices) Of course, what works 100% is only when Tuya devices are paired to a Tuya hub... Tuya platform has its own huge number of customers, and probably 95% of them are absolutely satisfied with the basic automation features provided and the cloud solution. But we fall into the small group of the other 5%, that need much more complex automation and that's why we are here .. :)

One possible (and working!) approach would be to use a Tuya hub integration to HA. I have tested it, both cloud and the local integrations ( V2 ) and it works reliably, but not all Tuya devices are supported yet. The disadvantage of this approach for me is one more hub in my home to take care of, and one more, separate Zigbee network that will double all the efforts for building a solid Zigbee mesh.. :(

[kkossev]

@MattWestb thank you for the information! Yes, I know that updating the Zigbee routing tables takes time, and that's why any experiments take a long time and sometimes the observations and the conclusions may be wrong. I also tried to use "add device thru this device" , although I am not sure whether this really worked or not.

One new observation from today : when paired to HA via z2m, I noticed, that TS0222 device started to reset again when I try to configure the reporting of any of the battery, illuminance, temperature, or humidity. When I disable the reporting configuration, it starts working again without any resets!.

Do you know if ZHA by default tries to configure the reporting intervals for the detected battery, illuminance, temperature, or humidity clusters?

Can this reporting configuration be disabled from a quirk ?

[MattWestb]

@kkossev Then you is using "add device thru this device" and you is getting it pairing OK is normally working OK and using the device as its parent (can being that TI coordinators is also "open" then they is having bugs in the firmware that i dont knowing if they is fixed) bbut they can jumping to on other if they like. I have some versions of Aqara sensors that dot like being paired to IKEA Zigbee 3 routers but i can paring then thru some old HA1.2 routers and the tricking them moving to the IKEA outlets by power the parent off and punching the button on the sensor and it is moving to one new (hopefully my preferred router) and working OK.

I dont knowing wot ZHA is configuring reporting then is changed for some mouth ago but IKEA controllers is not working OK if only paring or changing the binding they is needing doing one "reconfigure this device" for reporting OK to the coordinator. I being 100% sure ZHA is configuring reporting for PowerConfigurationCluster for getting the battery status from the device.

If you is having debut logging on and paring the device you can see how ZHA is configuring thee attribute reporting in the device.

I think its possible disabling binding / attribute reporting config in the quirk but i dont knowing to do that and then it can the device is not reporting the attribute changes to the coordinator if they is doing all things OK but some devices is sending the changed attributes to network address 0x0000 and cant being configured in the device (Xiaomi pre Zigbee 3 devices).

I think the problem is more is the coordinator sending default response to the device then its sending its attribute reports and if not i can being on good reason for the device getting problems and is rebooting or leaving the network.

[almico]

@MattWestb

Of course, what works 100% is only when Tuya devices are paired to a Tuya hub...

The main issue, at least for me, is that once I find a device that ZHA is unable to support because that device uses non-standard approaches and protocols, then, virtually any device from the manufacturer could reveal to be (partly) unusable. The fact that Tuya is using custom approaches, IMHO, means that Tuya's goal is NOT to be have its devices used outside its infrastructure.

One possible (and working!) approach would be to use a Tuya hub integration to HA

I am glad to hear that things work for you. For me that's not true: I purchased a Tuya zigbee gateway, connected this TS0222 device to it, and it's not available in Home Assistant. As far as I understood, devices connected to Tuya zigbee gateways are not available in Home Assistant 😭 Currently, I have two paperweights on my table in the form of two TS0222 😆

[MattWestb]

@almico Its very true tuya is the second pain in the a.... after Xiaomi !! HA is starting implanting tuya protocol v2 but i dont knowing if they is starting supporting Zigbee devices in that but i hope so. Also tuya is one member of Zigbee alliance but if looking there is very little device that is certified and i normally looking for that before baying devices that i dont knowing if there is well supported in my systems (like my X-production was deCONZ but they is not supporting "simple devices" like KNYCKLAN Open/Close remote (E1841) that is very Zigbee and the devs have no interest helping the deCONZ user doing it then the users have putting all information on the request in last December) before i baying more "advanced" devices.

I have 2 tuya ZBGW one LIDL and one no named but i have converting both to ZHA network coordinators but i can redoing the firmware changes and using them with tuya cloud if i like (that i dont like if not very urgent) but i dont have so much tuya devices only some TRVs and some LIDL light strips controller and the last is working out of the box like most of the the tuya lights is doing.

On the sensor side is more problematic and i think then one ZHA / Zigbpy dev is getting one tuya GW and some devices it can being easier getting then supported but for the moment its not the case.

If baying tuya dont baying the tuya MCU devices (they is using tuya MCU protocol and is normal TS0601 in the device name string) then they cant working without the GW. One normal tuya dual dimmer switch i have is working great with binding and all and some user have baying one "TS0601 version" and cant binding it to groups and is not working then the system is down = very bad for lights.

My problem is that i like getting the tuya Temp/Humid/Light or light sensor but its not so well supported at all in our open systems and i like getting my 2 Philips HUE motion sensor out of production then they is jumping around all the time and using the worse parent they can finding and that i dont like at all.

[kkossev]

I am glad to hear that things work for you. For me that's not true: I purchased a Tuya zigbee gateway, connected this TS0222 device to it, and it's not available in Home Assistant. As far as I understood, devices connected to Tuya zigbee gateways are not available in Home Assistant 😭

Have you tried the Tuya v2 local integration? https://github.com/tuya/tuya-home-assistant It is a bit tricky to setup (as you have to create a 'developer' account with Tuya), but the instructions are rather detailed and if followed strictly will work.

With the local Tuya v2 integration to HA you can use also Zigbee devices connected to the gateway! Not all ( for example no support for the problematic Tuya zigbee scene switches), but TS0222 is supported and it works fine for me! I have one of the units connected via the Tuya gateway to HA for comparison (and sniffing :) ) reasons. This is how it looks like:

[kkossev]

@MattWestb I found one possible problem.

At the end of the pairing process, TS0222 sends on time cluster (0x000A) a command ReadAttributes (0x00) with a parameter Local Time (0x0007).

Immediately Tuya hub Zigbee coordinator responds with the command Read Attributes Response (0x01), attribute local time (0x0007), status success (0x00), data is 32-bit integer value of the current time.

Note, that in this case, it the command is sent from the device, and the Zigbee coordinator replies to the device command!

My hub does not respond in any way to the time cluster command received. The raw data sent on cluster 0x000A can be seen in the zigbee low-level logs, but seems like it is filtered and does not reach the device driver, so can't be parsed in any way.

Do you know if ZHA supports a time cluster Server?

[almico]

@kkossev

Have you tried the Tuya v2 local integration?

I started adding it yesterday. The documentation is not the best, but all the issues opened by users about it helped me 😄 Right now, I'm waiting for the "Message Service" to become active. I think (hope) that's the reason why, yesterday evening, a smart plug wasn't properly reporting its state. By the way: the message, when enabling that service, that if we exceed the free number of messages we'll be charged is not the best companion through this test 😄 Later today, I will reset the Tuya Zigbee Gateway while I will try to generate traffic on my current Zigbee network to discourage the Tuya gateway from using the same channel 😄

[MattWestb]

I think most or all radios is supporting that but i dont knowing it for sure. I think only the ZHA devs can saying how it working but they need more info for doing that fixing the response on the time cluster.

I think some tuya switches was having problem with turning them self off if getting time from the coordinator and the quirk is "hiding" the time cluster so it was not getting the time and working OK.

Do you have one EM35X / EFR32MG or TI CC-253X devices that you can using for sniffing the Zigbee traffic then paring and communicating with the tuya GW for comparing with ZHA ?

[kkossev]

@MattWestb I have CC2531 + ZBOSS + WireShark, but I have had this setup working for a first time since last Sunday so I still have not much experience with it. Attached is the WireShark capture file, the pairing process starts around frame 181 :

Tuya TS0222 WireShark.zip . Checking @vvuk log file attachment on 1047 I see that actually there is a response from ZHA on the time cluster command!. So I may have been wrong in my previous post. I will double-check / will repeat the sniffing with ZHA probably this weekend when will have more free time, and I will correct/delete my previous post if it was wrong.

[MattWestb]

I have not time digging the the sniff for the moment but i do it later. Still the time cluster response can being the key to the problem. On tuya switches they have deleting the time cluster (in the quirk replacement) so ZHA is not sending the normal time response and only saying its dont have the the function and the switches is working normal but need looking in the sniff if its the same replay in ZHA as in tuya ZBGW (deCONZ haveing problem getting it working then they is sending the wrong response then getting time requests).

[MattWestb]

I was making on fast look and the time looks logic and also the coordinator is requesting the time from the device and its replaying with the attribute and one string that looks like one time string (i have not decoding the string so not knowing if its one real time or not).

That catching my eye is that some attribute is not ZCL (Zigbee Cluster Library) standard and the coordinator is replaying with one default response like this:

ZigBee Cluster Library Frame, Command: Report Attributes, Seq: 4
    Frame Control Field: Profile-wide (0x08)
    Sequence Number: 4
    Command: Report Attributes (0x0a)
    Attribute Field, Uint16: 30
        Attribute: Unknown (0xf001)
        Data Type: 16-Bit Unsigned Integer (0x21)
        Uint16: 30 (0x001e)

ZigBee Cluster Library Frame, Command: Default Response, Seq: 4
    Frame Control Field: Profile-wide (0x00)
    Sequence Number: 4
    Command: Default Response (0x0b)
    Response to Command: 0x0a
    Status: Success (0x00)

If its one no ZCL frame then ZHA is not sending any default response and the device can do all strange things like leaving the network without saying anything, re sending the command in infinite and so on.

I was looking in @vvuk log that is great but it not so easy comparing with the sniff that i have more experience sniff and its easier comparing the same format of logs.

The rest of the pairing looks very normal for one Zigbee 3 device is joining and getting the network key (be ware of your curent network key is in the sniff in clear if some like abusing it) and requesting on updated trust center link key and all is nicely acked all the was and looks OK.

And one tuya thing the device is starting sending attribute reports to 0x0000 (the coordinator) before its complete configured (normally the coordinator need setting up attribute reporting to the coordinator) but is not bad only not standard and its getting one clue to the problem you was seeing with it looks working if not configuring attribute reporting on this device so somthing is strange with the implantation tuya have doing that is not zigbee standard.

Hope you can doing one sniff then paring the device with ZHA !!

[kkossev]

Hi @MattWestb , I am attaching the sniff file of TS0222 pairing with ZHA (without the custom quirk enabled) Sorry it is a bit messy, I was trying to move the ZHA zigbee coordinator on a free channel, but I felt into a lot of problems, so this pcapng file is a bit polluted with packages from other networks. Anyway, applying a zbee_nwk.addr eq 0x6aa7 filter works! : ZHA TS0222 WireShark.zip )

[kkossev]

Seems like I managed to switch ZHA coordinator to channel 16. I used z2m to change the channel, made sure the device is discovered and communicates on it, then removed it from z2m, stop z2m service and start a fresh ZHA integration. ZHA TS0222 (channel 16) - repairing on a clean channel 16 ZHA TS0222 (reset!) - includes TS0222 resetting itself, around frame 730 ZHA TS0222 (quirk) - pairing with the quirk posted in this tread activated. ZHA TS0222 (reset!).zip ZHA TS0222 (channel 16).zip ZHA TS0222 (quirk).zip

Hope this may help

[kkossev]

That catching my eye is that some attribute is not ZCL (Zigbee Cluster Library) standard and the coordinator is replaying with one default response like this: ....

ZHA coordinator response to TS0222 time reading request seems OK ...

`329 229.164597 0xf694 0x0000 ZigBee HA 50 ZCL: Read Attributes, Seq: 21 Frame 329: 50 bytes on wire (400 bits), 48 bytes captured (384 bits) on interface \.\pipe\zboss_sniffer_COM6, id 0 IEEE 802.15.4 Data, Dst: 0x0000, Src: 0xf694 ZigBee Network Layer Data, Dst: 0x0000, Src: 0xf694 ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1 Frame Control Field: Data (0x00) Destination Endpoint: 1 Cluster: Time (0x000a) Profile: Home Automation (0x0104) Source Endpoint: 1 Counter: 243 ZigBee Cluster Library Frame, Command: Read Attributes, Seq: 21 Frame Control Field: Profile-wide (0x00) Sequence Number: 21 Command: Read Attributes (0x00) Attribute: Local Time (0x0007)

333 229.272306 0x0000 0xf694 ZigBee HA 56 ZCL: Read Attributes Response, Seq: 21 Frame 333: 56 bytes on wire (448 bits), 54 bytes captured (432 bits) on interface \.\pipe\zboss_sniffer_COM6, id 0 IEEE 802.15.4 Data, Dst: 0xf694, Src: 0x0000 ZigBee Network Layer Data, Dst: 0xf694, Src: 0x0000 ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1 Frame Control Field: Data (0x00) Destination Endpoint: 1 Cluster: Time (0x000a) Profile: Home Automation (0x0104) Source Endpoint: 1 Counter: 45 ZigBee Cluster Library Frame, Command: Read Attributes Response, Seq: 21 Frame Control Field: Profile-wide (0x18) Sequence Number: 21 Command: Read Attributes Response (0x01) Status Record, Uint32: 686511365 Attribute: Local Time (0x0007) Status: Success (0x00) Data Type: 32-Bit Unsigned Integer (0x23) Uint32: 686511365 (0x28eb5505)

`

[kkossev]

The unix hex timestamp date portion is wrong, but the hours, minutes and the seconds are matching my local time, i.e. when the device requests Local Time (0x0007) on Cluster: Time (0x000a), endpoint:1 - ZHA response seems OK.

[MattWestb]

The time is: 2010-10-20 20:12:12 (from your log: 686511365).

Its starting at first January 2000 ;-)

You can using this and setting the start to the Zigbee one https://www.dcode.fr/timestamp-converter

Edit i was missing the day i wos only looking n the year and mounts :-(((

[MattWestb]

Better adding 946684800 seconds (its the different between epoch and 1/1/2020) and converting it from unix to normal and you is getting: Sat Oct 02 2021 17:36:05 GMT+0000 and lit looks little better.

[kkossev]

Yep, I forgot the Y2K problem, it was a too long time ago... :)

Matt, I will continue chasing the problem using the hub that I know better - Hubitat. What I am experimenting with now is to remove any forced bindings, remove any forced reporting configuration from the hub to the device. So the coordinator does not send any commands to the device!

What I observe for the moment is that after the confirmation of the Transport key exchange, TS0222 sends to the coordinator:

• Illuminance measurement, endpoint 2
• temperature measurement, endpoint 2
• humidity measurement, endpoint 2
• illuminance measurement, endpoint 1
• Cluster Time (0x000a) endpoint 1 Read Attributes (0x00), Attribute: Local Time (0x0007) The coordinator replies with Read Attributes Response : Cluster Time (0x000a) endpoint 1 Read Attributes Response (0x01), Attribute: Local Time (0x0007) and Uint32 data

And that's all! Note - no interviewing on any clusters, no power repotting configuration, nothing else! The zigbee coordinator just answers to the local time read request from the device.

What followed in the next hour are just standard illuminance, humidity, and temperature reports from the device to the coordinator, but they are all on endpoint 1.

For the moment the device is performing very well, no restarts / no re-joins, etc... but let's do not speak too early, will see what will be in the logs tomorrow :)

[MattWestb]

I think the time setting / check is not the problem. I think configure attribute reporting is making the trouble but i was have not time looking in your new sniffs.

And tuya is famous sending things to / from cluster that is not existing like reporting the attribute from EP 2 for clusters that is on EP 1.

[kkossev]

The results are encouraging for now! :) No restarts in the last 12 hours. One of the 2 devices is communicating directly to the hub, the second one via a repeater. Just one strange reading of the temperature value from one of them (the one that goes through a repeater), but I don't see a reboot/rejoin sequence at this time in WireShark logs, so the reason for this could be different. I have updated my Hubitat driver, hopefully will receive a feedback from other users.

Is it possible in ZHA to disable the power/temp/hum/illum reporting configuration from a quirk? (without forcing any custom reporting settings, TS0222 reports the t/h/i every 60 minutes, even if no change of the measurements!)

[MattWestb]

Sounds great !!

Do you getting battery reports from the device ? It can being needed looking for it with wireshark then (at least ZHA) is cashing the last received value and can being false and bets being verified its being sent from the device.

Then you is sure its working well you can trying adding reporting on one cluster (i think battery reporting on PowerConfiguration.cluster_id is one good candidate for testing).

Perhaps is its better letting the devices having its default reporting if its working well but first verifying its reporting all OK over some time.

I knowing its possible disabling attribute reporting (its made with old Xiaomi devices) but i dont knowing hot to do that but i thing its not being made in the quirk then its needs more deep tweaking for doing that.

[MattWestb]

I was finding one good parameter for tuya devices that dont liking being stetted up like normal Zigbee device (Its looks most touy devices is sending all things to the coordinator without doing attribute reporting or binding of clusters). By adding SKIP_CONFIGURATION: True in the replacement shall ZHA not configuring extra things and leaving the device "alone" with its default settings and is used on Xiaomi devices that dont accepting setting up reporting and bindings on there clusters.

replacement = {
    SKIP_CONFIGURATION: True,
    ENDPOINTS: {

Its one candidate for TS0222 i think :-))

[vvuk]

Just tried SKIP_CONFIGURATION -- no go. Still getting resets/rejoins every ~3 minutes or so.

[MattWestb]

Thanks for testing !!

Shall being interesting see one sniff if ZHA is configuring attribute reporting and binding with it being sett.