search

zigpy / zha-device-handlers

ZHA device handlers bridge the functionality gap created when manufacturers deviate from the ZCL specification, handling deviations and exceptions by parsing custom messages to and from Zigbee devices.
Apache License 2.0
777 stars 703 forks source link

TZE200_locansqn TS0601 Temp / Humi / Clock #1286

Open toy3375 opened 2 years ago

toy3375 commented 2 years ago

Hi everybody,

My Tuya devices has no entities/controls in home assistant. It´s Zigbee Tuya Temp & Humi Display with integr. Clock.

Thanks in advance for the support.

image Log.txt

mrctorres commented 2 years ago

Full logs:

home-assistant.log

jacekk015 commented 2 years ago

Here I changed the temperature sensitivity to 1: 2022-01-29 18:38:55 DEBUG (MainThread) [zigpy.zcl] [0xab4b:1:0xef00] ZCL deserialize: 2022-01-29 18:38:55 DEBUG (MainThread) [zigpy.zcl] [0xab4b:1:0xef00] ZCL request 0x000b: [0, <Status.UNSUP_MANUF_CLUSTER_COMMAND: 131>]

And the logs start from

2022-01-29 18:47:24

Only errors I see are for 0x55be eWeLink MS01

If device didn't sent battery level status will be unknown. These are battery devices. They don't update each second or two. Battery level uses attribute 0x0204 - see in your logs if you have such data sent from the device.

mrctorres commented 2 years ago

This last log was after an HA reset and a command to change a device parameter. I was hoping it might be useful. The eWeLink MS01 is currently turned off. And even after almost an hour, the battery percentage is still unknown.

mrctorres commented 2 years ago

Now I removed the device, took out its 3 AAA batteries, restarted the HA, added the device again and recharged the ZHA, otherwise the temperature, humidity values ​​do not appear. Now the values ​​of the configurable attributes did not appear. The battery percentage is back. I hope it helps.

home-assistant.log

toy3375 commented 2 years ago

After Changing a value (ex. Humidity Alarm ) it will jump back to old value after a while ( at same time LOG Files receive Value from Device with old Value ) It seems that Value will not transmit to Device. Can you put some debug String in LOG after Sending or Polling a Value ? Thank you for your patience :+1:

toy3375 commented 2 years ago

I made value change at 11:34 and 11:35

2022-01-30 11:33:06 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0] for attribute 0x0409 (command 0x0002) 2022-01-30 11:33:06 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 1, 14] for attribute 0x020a (command 0x0002) 2022-01-30 11:33:06 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 100] for attribute 0x020b (command 0x0002) 2022-01-30 11:33:17 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 70] for attribute 0x020c (command 0x0002) 2022-01-30 11:33:17 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 30] for attribute 0x020d (command 0x0002) 2022-01-30 11:33:22 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 20] for attribute 0x0211 (command 0x0002) 2022-01-30 11:33:22 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 20] for attribute 0x0212 (command 0x0002) 2022-01-30 11:33:27 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 6] for attribute 0x0213 (command 0x0002) 2022-01-30 11:33:28 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 6] for attribute 0x0214 (command 0x0002) 2022-01-30 11:33:33 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:33:33 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [1] for attribute 0x040f (command 0x0002) 2022-01-30 11:33:38 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 222] for attribute 0x0201 (command 0x0002) 2022-01-30 11:33:39 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 83] for attribute 0x0202 (command 0x0002) 2022-01-30 11:33:39 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:33:39 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:33:39 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:33:39 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0] for attribute 0x0409 (command 0x0002) 2022-01-30 11:33:39 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:33:40 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:33:40 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:33:43 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0] for attribute 0x0409 (command 0x0002) 2022-01-30 11:33:43 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 1, 14] for attribute 0x020a (command 0x0002) 2022-01-30 11:33:43 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 100] for attribute 0x020b (command 0x0002) 2022-01-30 11:33:48 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 70] for attribute 0x020c (command 0x0002) 2022-01-30 11:33:49 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 30] for attribute 0x020d (command 0x0002) 2022-01-30 11:33:49 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 20] for attribute 0x0211 (command 0x0002) 2022-01-30 11:33:54 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 20] for attribute 0x0212 (command 0x0002) 2022-01-30 11:33:55 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 6] for attribute 0x0213 (command 0x0002) 2022-01-30 11:33:55 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 6] for attribute 0x0214 (command 0x0002) 2022-01-30 11:34:00 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:34:00 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 222] for attribute 0x0201 (command 0x0002) 2022-01-30 11:34:05 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 81] for attribute 0x0202 (command 0x0002) 2022-01-30 11:34:16 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:34:16 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:34:16 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:34:16 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:34:16 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:34:16 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:34:16 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0] for attribute 0x0409 (command 0x0002) 2022-01-30 11:34:17 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 1, 14] for attribute 0x020a (command 0x0002) 2022-01-30 11:34:22 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 100] for attribute 0x020b (command 0x0002) 2022-01-30 11:34:22 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:34:22 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:34:22 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:34:32 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0] for attribute 0x0409 (command 0x0002) 2022-01-30 11:34:32 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 1, 14] for attribute 0x020a (command 0x0002) 2022-01-30 11:34:38 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 100] for attribute 0x020b (command 0x0002) 2022-01-30 11:34:38 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 70] for attribute 0x020c (command 0x0002) 2022-01-30 11:34:43 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 30] for attribute 0x020d (command 0x0002) 2022-01-30 11:34:43 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 20] for attribute 0x0211 (command 0x0002) 2022-01-30 11:34:54 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 20] for attribute 0x0212 (command 0x0002) 2022-01-30 11:34:54 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 6] for attribute 0x0213 (command 0x0002) 2022-01-30 11:34:54 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 6] for attribute 0x0214 (command 0x0002) 2022-01-30 11:34:59 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:34:59 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [2] for attribute 0x040f (command 0x0002) 2022-01-30 11:35:10 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 223] for attribute 0x0201 (command 0x0002) 2022-01-30 11:35:20 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 69] for attribute 0x0202 (command 0x0002) 2022-01-30 11:35:21 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:35:21 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:35:21 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:35:21 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0] for attribute 0x0409 (command 0x0002) 2022-01-30 11:35:22 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 1, 14] for attribute 0x020a (command 0x0002) 2022-01-30 11:35:27 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 100] for attribute 0x020b (command 0x0002) 2022-01-30 11:35:27 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 70] for attribute 0x020c (command 0x0002) 2022-01-30 11:35:32 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 30] for attribute 0x020d (command 0x0002) 2022-01-30 11:35:32 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 20] for attribute 0x0211 (command 0x0002) 2022-01-30 11:35:43 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 20] for attribute 0x0212 (command 0x0002) 2022-01-30 11:35:43 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 6] for attribute 0x0213 (command 0x0002) 2022-01-30 11:35:48 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 6] for attribute 0x0214 (command 0x0002) 2022-01-30 11:35:48 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:35:49 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 223] for attribute 0x0201 (command 0x0002) 2022-01-30 11:35:49 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Received value [0, 0, 0, 66] for attribute 0x0202 (command 0x0002) 2022-01-30 11:35:54 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:35:54 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:35:54 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:35:54 DEBUG (MainThread) [zhaquirks.tuya] [0x4629:1:0xef00] Got set time request (command 0x0024) 2022-01-30 11:36:28 DEBUG (MainThread) [zhaquirks.tuya] [0x4f42:1:0xef00] Received value [0] for attribute 0x0409 (command 0x0002) 2022-01-30 11:36:28 DEBUG (MainThread) [zhaquirks.tuya] [0x4f42:1:0xef00] Received value [0, 0, 1, 4] for attribute 0x020a (command 0x0002) 2022-01-30 11:36:34 DEBUG (MainThread) [zhaquirks.tuya] [0x4f42:1:0xef00] Received value [0, 0, 0, 190] for attribute 0x020b (command 0x0002) 2022-01-30 11:36:34 DE

toy3375 commented 2 years ago

Maybe useful information. In TUYA Smartlife APP the value will change after next wake-up. I can force it , when I blow a little bit in to the device.

Screenshot_20220130-115514

mrctorres commented 2 years ago

From what I could see, the attributes are being updated correctly. Here's the log after setting the temperature reporting time to 60:

2022-01-30 09:40:56 DEBUG (MainThread) [zigpy.zcl] [0x1985:1:0xef00] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=236 command_id=Command.Default_Response> 2022-01-30 09:40:56 DEBUG (MainThread) [zigpy.zcl] [0x1985:1:0xef00] ZCL request 0x000b: [0, <Status.UNSUP_MANUF_CLUSTER_COMMAND: 131>]

Image1

mrctorres commented 2 years ago

Here the log after reading the attribute via the Manage Clusters panel:

2022-01-30 09:45:06 DEBUG (MainThread) [homeassistant.components.zha.api] Get bindable devices: source_ieee: [a4:c1:38:ce:dc:e0:24:35], bindable devices: [[{'ieee': '80:4b:50:ff:fe:0e:a4:6e', 'nwk': 0x0000, 'manufacturer': 'Silicon Labs', 'model': 'EZSP', 'name': 'Silicon Labs EZSP', 'quirk_applied': True, 'quirk_class': 'bellows.zigbee.application.EZSPCoordinator', 'manufacturer_code': 43981, 'power_source': 'Mains', 'lqi': 255, 'rssi': 0, 'last_seen': '2022-01-30T07:34:56', 'available': False, 'device_type': 'Coordinator', 'signature': {'node_descriptor': 'NodeDescriptor(logical_type=<LogicalType.Coordinator: 0>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice|AlternatePanCoordinator: 143>, manufacturer_code=43981, maximum_buffer_size=82, maximum_incoming_transfer_size=128, server_mask=11329, maximum_outgoing_transfer_size=128, descriptor_capability_field=<DescriptorCapability.NONE: 0>, allocate_address=True, is_alternate_pan_coordinator=True, is_coordinator=True, is_end_device=False, is_full_function_device=True, is_mains_powered=True, is_receiver_on_when_idle=True, is_router=False, *is_security_capable=False)', 'endpoints': {1: {'profile_id': 260, 'device_type': '0xbeef', 'in_clusters': [], 'out_clusters': []}}}, 'entities': [], 'neighbors': [{'device_type': 'EndDevice', 'rx_on_when_idle': 'Off', 'relationship': 'Child', 'extended_pan_id': 'cc:cc:cc:cc:9d:a8:cc:84', 'ieee': 'a4:c1:38:76:9f:6f:a2:a3', 'nwk': '0xF757', 'permit_joining': 'NotAccepting', 'depth': '1', 'lqi': '181'}, {'device_type': 'EndDevice', 'rx_on_when_idle': 'Off', 'relationship': 'Child', 'extended_pan_id': 'cc:cc:cc:cc:9d:a8:cc:84', 'ieee': '00:12:4b:00:22:cf:90:04', 'nwk': '0x82D1', 'permit_joining': 'NotAccepting', 'depth': '1', 'lqi': '112'}, {'device_type': 'EndDevice', 'rx_on_when_idle': 'Off', 'relationship': 'Child', 'extended_pan_id': 'cc:cc:cc:cc:9d:a8:cc:84', 'ieee': '00:12:4b:00:23:96:ae:96', 'nwk': '0x5CA2', 'permit_joining': 'NotAccepting', 'depth': '1', 'lqi': '108'}, {'device_type': 'EndDevice', 'rx_on_when_idle': 'Off', 'relationship': 'Child', 'extended_pan_id': 'cc:cc:cc:cc:9d:a8:cc:84', 'ieee': 'a4:c1:38:ce:dc:e0:24:35', 'nwk': '0x1985', 'permit_joining': 'NotAccepting', 'depth': '1', 'lqi': '139'}, {'device_type': 'EndDevice', 'rx_on_when_idle': 'Off', 'relationship': 'Child', 'extended_pan_id': 'cc:cc:cc:cc:9d:a8:cc:84', 'ieee': '00:12:4b:00:23:ad:5b:b3', 'nwk': '0x58A0', 'permit_joining': 'NotAccepting', 'depth': '1', 'lqi': '233'}], 'endpoint_names': [{'name': 'undefined_0xbeef'}], 'user_given_name': None, 'device_reg_id': 'f883394d03a3d2da871821f400ab4581', 'area_id': 'sala_de_estar'}]] 2022-01-30 09:45:06 DEBUG (MainThread) [homeassistant.components.zha.api] Requested attributes for: cluster_id: 13, cluster_type: 'in', endpoint_id: 12, response: [{'id': 28, 'name': 'description'}, {'id': 65, 'name': 'max_present_value'}, {'id': 69, 'name': 'min_present_value'}, {'id': 81, 'name': 'out_of_service'}, {'id': 85, 'name': 'present_value'}, {'id': 103, 'name': 'reliability'}, {'id': 104, 'name': 'relinquish_default'}, {'id': 106, 'name': 'resolution'}, {'id': 111, 'name': 'status_flags'}, {'id': 117, 'name': 'engineering_units'}, {'id': 256, 'name': 'application_type'}] 2022-01-30 09:45:06 DEBUG (MainThread) [homeassistant.components.zha.api] Requested commands for: cluster_id: 13, cluster_type: 'in', endpoint_id: 12, response: [] 2022-01-30 09:45:19 DEBUG (MainThread) [homeassistant.components.zha.api] Requested attributes for: cluster_id: 13, cluster_type: 'in', endpoint_id: 12, response: [{'id': 28, 'name': 'description'}, {'id': 65, 'name': 'max_present_value'}, {'id': 69, 'name': 'min_present_value'}, {'id': 81, 'name': 'out_of_service'}, {'id': 85, 'name': 'present_value'}, {'id': 103, 'name': 'reliability'}, {'id': 104, 'name': 'relinquish_default'}, {'id': 106, 'name': 'resolution'}, {'id': 111, 'name': 'status_flags'}, {'id': 117, 'name': 'engineering_units'}, {'id': 256, 'name': 'application_type'}] 2022-01-30 09:45:19 DEBUG (MainThread) [homeassistant.components.zha.api] Requested commands for: cluster_id: 13, cluster_type: 'in', endpoint_id: 12, response: [] 2022-01-30 09:45:32 DEBUG (MainThread) [homeassistant.components.zha.api] Read attribute for: cluster_id: [13] cluster_type: [in] endpoint_id: [12] attribute: [85] manufacturer: [None] response: [60.0] failure: [{}],

image2

mrctorres commented 2 years ago

Here the log after changing the attribute to 30 via the panel:

2022-01-30 09:48:26 DEBUG (MainThread) [zigpy.zcl] [0x1985:1:0xef00] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=240 command_id=Command.Default_Response> 2022-01-30 09:48:26 DEBUG (MainThread) [homeassistant.components.zha.core.device] 0x1985: set: 30 for attr: 85 to cluster: 13 for ept: 12 - res: ([WriteAttributesStatusRecord(status=<Status.SUCCESS: 0>)],) 2022-01-30 09:48:26 DEBUG (MainThread) [homeassistant.components.zha.api] Set attribute for: cluster_id: [13] cluster_type: [in] endpoint_id: [12] attribute: [85] value: [30] manufacturer: [None] response: [([WriteAttributesStatusRecord(status=<Status.SUCCESS: 0>)],)]

mrctorres commented 2 years ago

But update date and time on the device still doesn't work.

jacekk015 commented 2 years ago

@mrctorres I'm getting lost here. Some say it works, other it doesn't.

Works through HA or only Manage Clusters?? It should work either way.

toy3375 commented 2 years ago

Time never works...

Jacek Kończewski @.***> schrieb am So., 30. Jan. 2022, 14:00:

@mrctorres https://github.com/mrctorres I'm getting lost here. Some say it works, other it doesn't.

Works through HA or only Manage Clusters?? It should work either way.

— Reply to this email directly, view it on GitHub https://github.com/zigpy/zha-device-handlers/issues/1286#issuecomment-1025138517, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARNNXMZBCTZYWJWHC3ZXTM3UYUY73ANCNFSM5MA4XE2A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

mrctorres commented 2 years ago

@mrctorres I'm getting lost here. Some say it works, other it doesn't.

Works through HA or only Manage Clusters?? It should work either way.

After last night when I removed the batteries from the device, removed it from the HA, re-added it and re-charged the ZHA twice, it looks like it is accepting commands in both modes but the date and time update continues without work.

jacekk015 commented 2 years ago

Time sync is out of my control. It's managed by the already uploaded code, not the quirk. Exact that part of the code manages time sync when the device sends 0x0024 - which is set_time_request https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/tuya/__init__.py#L337

That message in the logs you see comes from here: https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/tuya/__init__.py#L347

Got set time request

So actually it enters in that part of the code and it should work. That command line is responsible for transmitting time back to the device: https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/tuya/__init__.py#L372

Line 153 of the quirk file ts0601_temperature.py contains:

set_time_offset = 1970

You can play with these and try 2000, or even replace and/or add a line:

set_time_local_offset = 1970

or = 2000 [each time HA full restart is needed!]

Here's the comment:

Some devices need the timestamp in seconds from 1/1/1970 and others in seconds from 1/1/2000. Also, there is devices which uses both timestamps variants (probably bug). Use set_time_local_offset var in this cases.

https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/tuya/__init__.py#L295

I don't see any other possibilities here. Maybe admins can suggest something. Those Chineese device sometimes doesn't use standards. Also if someone has a gate - maybe try to check if there's no new firmware available.

I can't debug it more myself - I do not own that device.

mrctorres commented 2 years ago

I noticed that the time request is no longer appearing in the log. What could be happening?

jacekk015 commented 2 years ago

I noticed that the time request is no longer appearing in the log. What could be happening?

Make the device to loose the time/date and check. Maybe it needs more time. Those Chinese devices lives with their own live. And they are battery operated - so they are lazy as possible. I don't own it. Can't guess anything without logs.

mrctorres commented 2 years ago

Please excuse my ignorance, but is there a way for me to manually send the time information to the device in the format below?

Payload for 0x24 - Time Synchronisation: Device -> Host 0xef00 Command 0x24 Payload 0x0008 Host -> Device 0xef00 Command 0x24 Payload 0x0008 600d8029 600d8e39 <-- THIS DATA The synopsis is like :

  1. Device send a Time synchronisation request with a uint16 as payload
  2. Host will respond with a payload equal to the same unint16 followed by the UTC time and the local time, for exemple
mrctorres commented 2 years ago

Would it be possible to insert an attribute like TUYA_TIME in Cluster 0xef00 (TuyaSensorManufCluster ?) to be able to manually send the time information to the device for testing?

mrctorres commented 2 years ago

I think I got it, but it returns an error:

2022-01-30 12:40:12 DEBUG (MainThread) [zigpy.zcl] [0x1985:1:0xef00] ZCL request 0x000b: [36, <Status.UNSUP_MANUF_CLUSTER_COMMAND: 131>]

I think this device is out of spec

jacekk015 commented 2 years ago

You can't send time if the device doesn't request it. You got that info in the code mentioned: https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/tuya/__init__.py#L297

NOTE: You need to wait for time request before setting it. You can't set time without request.

It has to be a response to the request. That's why it's handled by the Tuya code there - not the quirk.

There were some guys that were fighting with this also - present code comes from their findings: https://github.com/zigpy/zha-device-handlers/issues/831

mrctorres commented 2 years ago

I removed and replaced the batteries and it returned in the log "No handler for cluster command 36":

2022-01-30 12:54:19 DEBUG (MainThread) [zigpy.zcl] [0x1985:1:0xef00] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=91 command_id=36> 2022-01-30 12:54:19 DEBUG (MainThread) [zigpy.zcl] [0x1985:1:0xef00] ZCL request 0x0024: [[112, 0]] 2022-01-30 12:54:19 DEBUG (MainThread) [zigpy.zcl] [0x1985:1:0xef00] No handler for cluster command 36

jacekk015 commented 2 years ago

That should be totally transparent to the user. On of my TRV restarted.

2022-01-30 17:02:46 DEBUG (MainThread) [zigpy.zcl] [0x09ec:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=7 command_id=36>
2022-01-30 17:02:46 DEBUG (MainThread) [zigpy.zcl] [0x09ec:1:0xef00] ZCL request 0x0024: [[0, 4]]
2022-01-30 17:02:46 DEBUG (MainThread) [zhaquirks.tuya] [0x09ec:1:0xef00] Got set time request (command 0x0024)
2022-01-30 17:02:46 DEBUG (MainThread) [zigpy.zcl] [0x09ec:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=True is_reply=True disable_default_response=False> manufacturer=4098 tsn=113 command_id=Command.Default_Response>

That "No handler for cluster command 36" comes from here: https://github.com/zigpy/zigpy/blob/dev/zigpy/zcl/__init__.py#L220 It should NOT be executed since there's IF there, in earlier stage:

if hdr.command_id != 0x0024 or self.set_time_offset == 0:

That means if request command is NOT 0x0024 or set_time_offset = 0 the code execution is moved to the upper class:

return super().handle_cluster_request(
                hdr, args, dst_addressing=dst_addressing
            )

So either reuqest id is not 0x0024 - which is NOT true because you have "ZCL request 0x0024" or you have set_time_offset set to 0[zero]. Check line no 153 of my quirk if you have there

set_time_offset = 1970
jacekk015 commented 2 years ago

@mrctorres If you really wanna play with it here's a special version for you. ts0601_temperature_special.py.zip Between lines 176 and 211 you've got 0x0024[set_time_reuqest] code, modified that way so it should run it from there.

If you wanna log something just put there:

_LOGGER.info("test")

That's Python - so you need to keep indentation correct.

mrctorres commented 2 years ago 
set_time_offset = 1970

Actually I had removed this line for testing and forgot to put it back. Putting it back the log was "UNSUP_MANUF_CLUSTER_COMMAND: 131":

2022-01-30 13:57:19 DEBUG (MainThread) [zigpy.zcl] [0x1985:1:0xef00] ZCL request 0x0024: [[37, 0]] 2022-01-30 13:57:19 DEBUG (MainThread) [zhaquirks.tuya] [0x1985:1:0xef00] Got set time request (command 0x0024) 2022-01-30 13:57:25 DEBUG (MainThread) [zigpy.zcl] [0x1985:1:0xef00] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=59 command_id=Command.Default_Response> 2022-01-30 13:57:25 DEBUG (MainThread) [zigpy.zcl] [0x1985:1:0xef00] ZCL request 0x000b: [36, <Status.UNSUP_MANUF_CLUSTER_COMMAND: 131>]

jacekk015 commented 2 years ago

That's nothing good - from what I see: https://docs.bosch-iot-suite.com/gateway-software/API/modules/com.prosyst.mbs.zigbee.driver.api/com/prosyst/mbs/services/zigbee/metadata/provider/ZCLStatusEnumeration.html#UNSUP_MANUF_CLUSTER_COMMAND

A manufacturer specific unicast, cluster specific command was received with an unknown manufacturer code, or the manufacturer code was recognized but the command is not supported.

For Tuya manufacturer code is known - it's 4098. That's how my response is send

2022-01-30 17:02:46 DEBUG (MainThread) [zigpy.zcl] [0x09ec:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=True is_reply=True disable_default_response=False> manufacturer=4098 tsn=113 command_id=Command.Default_Response>

You have:

2022-01-30 13:57:25 DEBUG (MainThread) [zigpy.zcl] [0x1985:1:0xef00] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=59 command_id=Command.Default_Response>

manufacturer=None - that's strange. And the frame_control for you is empty. You are using newest, updated HA version??

Probably without proper frame_control manufacturer_specific=True it won't send manufacturer code.

jacekk015 commented 2 years ago

Your devices are:

2022-01-23 09:59:16 INFO (MainThread) [zigpy.device] [0x10f3] 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=4417, maximum_buffer_size=66, maximum_incoming_transfer_size=66, server_mask=10752, maximum_outgoing_transfer_size=66, descriptor_capability_field=<DescriptorCapability.NONE: 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)

manufacturer_code=4417 It's not really Tuya code id

You can check it clicking on Zigbee Device Signature and move the window to the left. It's in the first line.

MattWestb commented 2 years ago

Manufacture code 4098 = 0x1002 = Ember [0x1002] (from Silabs SDK). Can you posting the device signature or if its not in it repairing the device and looking in the log for device and simple description, one of them shall showing the device manufacturer code.

Very likely have some doing the coding and missed changing it in the SDK then its standard Ember [0x1002] if not changing it.

mrctorres commented 2 years ago

This is what I have:

"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=4417, maximum_buffer_size=66, maximum_incoming_transfer_size=66, server_mask=10752, maximum_outgoing_transfer_size=66, descriptor_capability_field=<DescriptorCapability.NONE: 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)",

toy3375 commented 2 years ago

i have the same manufacturer code

"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=4417, maximum_buffer_size=66, maximum_incoming_transfer_size=66, server_mask=10752, maximum_outgoing_transfer_size=66, descriptor_capability_field=<DescriptorCapability.NONE: 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)", "endpoints": { "1": { "profile_id": 260, "device_type": "0x0302",

toy3375 commented 2 years ago

Inside no information about manufacture..

MattWestb commented 2 years ago

@kkossev My TRVs have manufacturer_code=0 = dont need tagging messages with manufacture code.

Perhaps way the device is not responding to commands sent to it then the Zigbee module is ignoring the zigbee commands (ala Zigbee standard) if the manufacturing code is not the same if not doing special code for it, but with 0 is shall normally being OK but its no ZCL commands from no ZCL cluster commands so tuya can have doing different things.

Have some doing some sniffing with tuya ZBGW that can being looked at from the device ?

toy3375 commented 2 years ago

i got a mini Zigbee Gateway.... when anybody explains me how i,m doing that.

MattWestb commented 2 years ago

ZCL V8 is linked here if like reading how its working (very heavy reading) https://github.com/zigpy/zigpy/discussions/595#discussioncomment-1656808.

You need one device that can sniffing and sniffer firmware in it like TI CC-2531 and other TI, Cornbee II with sniff firmware or one EZSP coordinator with normal NCP firmware that all can doing sniffing. Also if you have some old IKEA devices and one device for flashing (ESP Rpi and so on) you can using the module / chip from them and flashing one EZSP firmware on them (I have them as coordinator).

MattWestb commented 2 years ago

Little sniffing links if not all is broken https://github.com/zigpy/zigpy/wiki/Sniffing-Zigbee-traffic.

This can being way LIDL / parkside water valve is not reacting on more than ON commands (ZCL standard) but no more commands / options is working with the device but devs have looking in sniffs and not finding the tuyya magic.

jacekk015 commented 2 years ago

@mrctorres

You are using newest, updated HA version??

You received response:

<Status.UNSUP_MANUF_CLUSTER_COMMAND: 131>

By the Bosch docs[above] it means:

A manufacturer specific unicast, cluster specific command was received with an unknown manufacturer code, or the manufacturer code was recognized but the command is not supported.

So there are two options.

mrctorres commented 2 years ago

You are using newest, updated HA version??

Home Assistant 2021.12.10

toy3375 commented 2 years ago

Little sniffing links if not all is broken https://github.com/zigpy/zigpy/wiki/Sniffing-Zigbee-traffic.

This can being way LIDL / parkside water valve is not reacting on more than ON commands (ZCL standard) but no more commands / options is working with the device but devs have looking in sniffs and not finding the tuyya magic.

Thx... but that´s too much for my old brain 😄 maybe next weekend with more time

mrctorres commented 2 years ago

New log´s for "special" version file:

home-assistant.log

toy3375 commented 2 years ago

I found the Manufacturer. Maybe helpful .

https://szwlx.en.alibaba.com/product/1600436170409-902386022/2022_New_Year_Promotion_Tuya_Zigbee_Temperature_and_Humidity_Sensor_with_Long_Battery_Life.html?spm=a2700.shop_index.94.12.e02847a3E5Pycl

jacekk015 commented 2 years ago

@mrctorres My mistake - didn't put else to if Added some debug comments that should be shown in logs ts0601_temperature_special.py.zip

kkossev commented 2 years ago

My TRVs have manufacturer_code=0 = dont need tagging messages with manufacture code.

I don't think the manufacturer code is the reason for the time synchronization problems. I have confirmation from a mate down under that this device works OK (including the time sync) with my Hubitat driver.

One difference is that I cast a Tuya Black Magic spell towards the device during the initialization :) Try the same approach as with the TS004F : await ep.basic.read_attributes(["manufacturer", "zcl_version", "app_version", "model", "power_source", 0xFFFE])

mrctorres commented 2 years ago

@mrctorres My mistake - didn't put else to if Added some debug comments that should be shown in logs ts0601_temperature_special.py.zip

New logs. I noticed that new errors are appearing in the log. The device also appears to be resetting itself frequently. And I can't change the attribute values ​​anymore.

home-assistant.log

toy3375 commented 2 years ago

I try special edition , too.

All Values from device to ZHA works fine. (exc. battery - display "none" ) From ZHA to Device - none (incl. time )

it´s really hard challenge :)

2022-01-31 19:33:36 ERROR (MainThread) [homeassistant.components.zha.core.channels.base] [0xADA4:13:0x000d]: Could not set value: [0xada4:1:0xef00]: Message send failure

LOG20220131.txt

jacekk015 commented 2 years ago

I don't see any possibilities here. @toy3375 logs shows that the request 0x0024 is served by code response:

2022-01-31 19:32:04 INFO (MainThread) [ts0601_temperature_special] TEST sending time response: [97, 248, 43, 36, 97, 248, 57, 52]

So there's need to be a bug elsewhere. Maybe device doesn't follow standards. Without it in my hands it's hard to debug it that way. Probably communication sniffing is needed to see messages going to gateway and back. Since the older version works with attributes, and there's a workaround with date/time setting I don't see any options to go forward.

mrctorres commented 2 years ago

I got a Tuya Hub and it syncs the date and time. I bought a CC2531 USB to try to use as a Sniffer as shown in https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html#with-cc2531, but it doesn't capture packets, even changing the channel and updating the firmware. Any light?

jacekk015 commented 2 years ago

I got a Tuya Hub and it syncs the date and time

It would be strange if it didn't do it ;-)

Network encryption key is crucial here. Did you set it properly??

MattWestb commented 2 years ago

@mrctorres Flash the firmware by instruction and downloading the ZBOSS sniffer and wireshark and starting the sniffer program and wireshark. I using EZSP and com.zsmartsystems.zigbee.sniffer with CLI so i dont have the GUI for setting up the sniffer.

You also need knowing the channel your tuya ZBGW is on but is normally on one standard 11,15,20 and 25 but is not 110%. Then the sniffer is running and try getting the device sending some commands also sending command to it shall see "somthing" in wireshark that is in sync with what you is sending.

You must have adding the "default well known zigbee key" for decrypting message plus your network key. The first is in the instruction (3.) and then you is paring one Zigbee device is using the default key and the system is sending the network key to your device and you can finding it in wireshark after the device have joining the network (3.2).

By posting one sniff with pairing one device = your network key for that network can being extracted from all ho downloading it and have the knowledge.

Edit: The well known default Zigbee key is in 3. and not 3.1 (have correcting in in the post).

mrctorres commented 2 years ago

I followed all the instructions, but I can't sniff out any Zigbee packages, neither from ZHA, on channel 15, nor from Tuya, which according to the app, is on channel 25.

mrctorres commented 2 years ago

I also tried using TI Packet Sniffer, but it doesn't even recognize the dongle, unlike Zboss, which does, but doesn't seem to find packets to send to WireShark