Closed SebLz closed 2 years ago
@Smanar this should be supported right?
21:24:56:269 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 (0x02,0x66) Fn: 0 Data 545460846821
is temperature
21:25:30:485 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846732
is setpoint
21:25:31:396 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00016501000100 21:25:31:397 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 (0x01,0x65) Fn: 0 Data 545460846592
Is the mode off = 0 manu = 1. But on code I m changing the value only if the mode is "off".
21:32:06:615 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00516c01000101 21:32:06:616 Tuya debug 5 : Status: 0 Transid: 81 Dp: 364 (0x01,0x6C) Fn: 0 Data 545460846593
is the mode too, heat = 0 auto = 1
I m seing some problem too. First, this device don't seem support "config/preset" and "config/setvalve" I think this device have it because it s the same device than_TYST11_KGbxAXL2 and the second one support them. Secondly mode command don't trigger an update. Can you try to change the mode, and check direclty in the API (on the JSON) ?
When you see
Tuya debug 5 : Status: 0 Transid: 81 Dp: 364 (0x01,0x6C)
This value need to change, for "heat" or "auto"
@Smanar and now 😅 ?
Lol. The last part is a question.
For the bad "config/setvalve" I think I will let it for the moment, will be easy to correct with DDF (there is other TRV with same issue) For the second one I think I need to correct the missing update, but I m waiting for a confirmation.
When you see
Tuya debug 5 : Status: 0 Transid: 81 Dp: 364 (0x01,0x6C)
The "mode" value need to change, for "heat" or "auto", not in third app because the missing update, but If I m right you can see it direclty on the json.
21:24:56:269 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 (0x02,0x66) Fn: 0 Data 545460846821
is temperature
21:25:30:485 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846732
is setpoint
21:25:31:396 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00016501000100 21:25:31:397 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 (0x01,0x65) Fn: 0 Data 545460846592
Is the mode off = 0 manu = 1. But on code I m changing the value only if the mode is "off".
21:32:06:615 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00516c01000101 21:32:06:616 Tuya debug 5 : Status: 0 Transid: 81 Dp: 364 (0x01,0x6C) Fn: 0 Data 545460846593
is the mode too, heat = 0 auto = 1
I m seing some problem too. First, this device don't seem support "config/preset" and "config/setvalve" I think this device have it because it s the same device than_TYST11_KGbxAXL2 and the second one support them. Secondly mode command don't trigger an update. Can you try to change the mode, and check direclty in the API (on the JSON) ?
When you see
Tuya debug 5 : Status: 0 Transid: 81 Dp: 364 (0x01,0x6C)
This value need to change, for "heat" or "auto"
Hello @Smanar and thanks for your reply. I've removed the batteries, then added them again. The device started in mode "auto". I switched it to mode "inactive" in HA and the result in the REST API was also mode = "off". Then I tried to change the mode to "heat" but it immediately reverted to "auto" (also in the rest api, mode = "auto" in the JSON). Here is a log capture of the whole sequence:
21:13:37:381 DeviceAnnce of SensorNode: 0x847127FFFE7BC0D0 [1]
21:13:37:906 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00016501000100
21:13:37:906 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 (0x01,0x65) Fn: 0 Data 545460846592
21:13:38:048 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00170a01000101
21:13:38:048 Tuya debug 5 : Status: 0 Transid: 23 Dp: 266 (0x01,0x0A) Fn: 0 Data 545460846593
21:13:38:250 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00180801000101
21:13:38:251 Tuya debug 5 : Status: 0 Transid: 24 Dp: 264 (0x01,0x08) Fn: 0 Data 545460846593
21:13:38:444 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00198201000101
21:13:38:445 Tuya debug 5 : Status: 0 Transid: 25 Dp: 386 (0x01,0x82) Fn: 0 Data 545460846593
21:13:38:651 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 001a1b02000400000000
21:13:38:652 Tuya debug 5 : Status: 0 Transid: 26 Dp: 539 (0x02,0x1B) Fn: 0 Data 545460846592
21:13:38:851 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00162801000101
21:13:38:852 Tuya debug 5 : Status: 0 Transid: 22 Dp: 296 (0x01,0x28) Fn: 0 Data 545460846593
21:13:39:052 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000266020004000000da
21:13:39:053 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 (0x02,0x66) Fn: 0 Data 545460846810
21:13:39:255 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000a0
21:13:39:256 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846752
21:13:39:454 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00046905000100
21:13:39:454 Tuya debug 5 : Status: 0 Transid: 4 Dp: 1385 (0x05,0x69) Fn: 0 Data 545460846592
21:13:39:654 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00056a01000100
21:13:39:654 Tuya debug 5 : Status: 0 Transid: 5 Dp: 362 (0x01,0x6A) Fn: 0 Data 545460846592
21:13:39:853 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00076c01000101
21:13:39:854 Tuya debug 5 : Status: 0 Transid: 7 Dp: 364 (0x01,0x6C) Fn: 0 Data 545460846593
21:13:40:017 reuse dead link (dead link container size now 1)
21:13:40:089 Tuya : Schedule command
21:13:40:090 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00ff7b00001104016800c801e000a0043800c8052800a0
21:13:40:090 Tuya debug 5 : Status: 0 Transid: 255 Dp: 123 (0x00,0x7B) Fn: 0 Data 545460846592
21:13:40:091 Tuya : Schedule data error
21:13:40:309 Tuya : Schedule command
21:13:40:310 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 01007c00001104016800c801e000a0043800c8052800a0
21:13:40:311 Tuya debug 5 : Status: 1 Transid: 0 Dp: 124 (0x00,0x7C) Fn: 0 Data 545460846592
21:13:40:312 Tuya : Schedule data error
21:13:40:524 Tuya : Schedule command
21:13:40:525 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 01017d00001104016800c801e000a0043800c8052800a0
21:13:40:526 Tuya debug 5 : Status: 1 Transid: 1 Dp: 125 (0x00,0x7D) Fn: 0 Data 545460846592
21:13:40:526 Tuya : Schedule data error
21:13:40:742 Tuya : Schedule command
21:13:40:743 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 01027e00001104016800c801e000a0043800c8052800a0
21:13:40:744 Tuya debug 5 : Status: 1 Transid: 2 Dp: 126 (0x00,0x7E) Fn: 0 Data 545460846592
21:13:40:745 Tuya : Schedule data error
21:13:41:050 Tuya : Schedule command
21:13:41:051 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 01037f00001104016800c801e000a0043800c8052800a0
21:13:41:051 Tuya debug 5 : Status: 1 Transid: 3 Dp: 127 (0x00,0x7F) Fn: 0 Data 545460846592
21:13:41:052 Tuya : Schedule data error
21:13:41:267 Tuya : Schedule command
21:13:41:268 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 01048000001104016800c801e000a0043800c8052800a0
21:13:41:269 Tuya debug 5 : Status: 1 Transid: 4 Dp: 128 (0x00,0x80) Fn: 0 Data 545460846592
21:13:41:269 Tuya : Schedule data error
21:13:41:486 Tuya : Schedule command
21:13:41:487 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 01058100001104016800c801e000a0043800c8052800a0
21:13:41:487 Tuya debug 5 : Status: 1 Transid: 5 Dp: 129 (0x00,0x81) Fn: 0 Data 545460846592
21:13:41:488 Tuya : Schedule data error
21:13:41:709 Tuya : Schedule command
21:13:41:710 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000973000018000000000000000000000000000000000000000000000000
21:13:41:710 Tuya debug 5 : Status: 0 Transid: 9 Dp: 115 (0x00,0x73) Fn: 0 Data 545460846592
21:13:41:711 Tuya : Schedule data error
21:13:41:824 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000266020004000000eb
21:13:41:825 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 (0x02,0x66) Fn: 0 Data 545460846827
21:13:42:041 Tuya : Schedule command
21:13:42:042 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000d6e000018000000000000000000000000000000000000000000000000
21:13:42:042 Tuya debug 5 : Status: 0 Transid: 13 Dp: 110 (0x00,0x6E) Fn: 0 Data 545460846592
21:13:42:043 Tuya : Schedule data error
21:13:42:269 Tuya : Schedule command
21:13:42:270 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 001177000018000000000000000000000000000000000000000000000000
21:13:42:270 Tuya debug 5 : Status: 0 Transid: 17 Dp: 119 (0x00,0x77) Fn: 0 Data 545460846592
21:13:42:271 Tuya : Schedule data error
21:13:42:470 Tuya : Schedule command
21:13:42:470 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000a7400000700000000000000
21:13:42:471 Tuya debug 5 : Status: 0 Transid: 10 Dp: 116 (0x00,0x74) Fn: 0 Data 545460846592
21:13:42:472 Tuya : Schedule data error
21:13:42:692 Tuya : Schedule command
21:13:42:692 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000e7000000700000000000000
21:13:42:693 Tuya debug 5 : Status: 0 Transid: 14 Dp: 112 (0x00,0x70) Fn: 0 Data 545460846592
21:13:42:694 Tuya : Schedule data error
21:13:42:882 Tuya : Schedule command
21:13:42:882 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00127800000700000000000000
21:13:42:883 Tuya debug 5 : Status: 0 Transid: 18 Dp: 120 (0x00,0x78) Fn: 0 Data 545460846592
21:13:42:883 Tuya : Schedule data error
21:13:43:001 Tuya : Schedule command
21:13:43:001 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000a7400000700000000000000
21:13:43:002 Tuya debug 5 : Status: 0 Transid: 10 Dp: 116 (0x00,0x74) Fn: 0 Data 545460846592
21:13:43:003 Tuya : Schedule data error
21:13:43:225 Tuya : Schedule command
21:13:43:225 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000b7500001f00000000000000000000000000000000000000000000000000000000000000
21:13:43:226 Tuya debug 5 : Status: 0 Transid: 11 Dp: 117 (0x00,0x75) Fn: 0 Data 545460846592
21:13:43:227 Tuya : Schedule data error
21:13:43:456 Tuya : Schedule command
21:13:43:456 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000f7100001f00000000000000000000000000000000000000000000000000000000000000
21:13:43:457 Tuya debug 5 : Status: 0 Transid: 15 Dp: 113 (0x00,0x71) Fn: 0 Data 545460846592
21:13:43:458 Tuya : Schedule data error
21:13:43:687 Tuya : Schedule command
21:13:43:687 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00137900001f00000000000000000000000000000000000000000000000000000000000000
21:13:43:688 Tuya debug 5 : Status: 0 Transid: 19 Dp: 121 (0x00,0x79) Fn: 0 Data 545460846592
21:13:43:689 Tuya : Schedule data error
21:13:44:061 Tuya : Schedule command
21:13:44:061 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000c7600000c000000000000000000000000
21:13:44:062 Tuya debug 5 : Status: 0 Transid: 12 Dp: 118 (0x00,0x76) Fn: 0 Data 545460846592
21:13:44:063 Tuya : Schedule data error
21:13:44:365 Tuya : Schedule command
21:13:44:365 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00107200000c000000000000000000000000
21:13:44:366 Tuya debug 5 : Status: 0 Transid: 16 Dp: 114 (0x00,0x72) Fn: 0 Data 545460846592
21:13:44:366 Tuya : Schedule data error
21:13:44:681 Tuya : Schedule command
21:13:44:681 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00147a00000c000000000000000000000000
21:13:44:682 Tuya debug 5 : Status: 0 Transid: 20 Dp: 122 (0x00,0x7A) Fn: 0 Data 545460846592
21:13:44:683 Tuya : Schedule data error
21:13:44:810 Tuya debug 1 : Time sync request
21:13:44:811 Send Tuya command 0x24, data: 00006182ed786182fb88
21:13:46:367 Device TTL 2039 s flags: 0x7
21:13:47:657 Tuya debug 1 : Time sync request
21:13:47:658 Send Tuya command 0x24, data: 00056182ed7b6182fb8b
21:14:10:607 ZCL attribute report 0x00158D000450D0C8 for cluster: 0x0000, ep: 0x01, frame control: 0x1C, mfcode: 0x115F
21:14:10:609 0x00158D000450D0C8 extract Xiaomi special attribute 0xFF01
21:14:10:609 01 battery 3015 (0x0BC7)
21:14:10:610 03 Device temperature 22 °C
21:14:10:610 04 unknown 17320 (0x43A8)
21:14:10:611 05 RSSI dB (?) 71 (0x0047)
21:14:10:611 06 LQI (?) 4294967296 (0x0100000000)
21:14:10:612 0a Parent NWK 64132 (0xFA84)
21:14:10:612 64 on/off 0
21:14:10:613 0b lightlevel 0 (0x0000)
21:14:23:289 ZCL attribute report 0x842E14FFFE139AEF for cluster: 0x0702, ep: 0x01, frame control: 0x08, mfcode: 0x0000
21:14:23:360 GW firmware version: 0x26660700
21:14:23:361 GW firmware version is up to date: 0x26660700
21:14:23:364 Bind response success for 0x842e14fffe139aef ep: 0x01 cluster: 0x0B04
21:14:45:042 ZCL attribute report 0x588E81FFFED395CC for cluster: 0x0702, ep: 0x01, frame control: 0x08, mfcode: 0x0000
21:14:45:111 Bind response success for 0x588e81fffed395cc ep: 0x01 cluster: 0x0B04
21:14:46:368 Device TTL 1979 s flags: 0x7
21:14:50:708 ZCL attribute report 0x00158D00053FDA83 for cluster: 0x0000, ep: 0x01, frame control: 0x18, mfcode: 0x0000
21:14:50:709 0x00158D00053FDA83 extract Xiaomi special attribute 0xFF01
21:14:50:710 01 battery 2955 (0x0B8B)
21:14:50:710 04 unknown 17320 (0x43A8)
21:14:50:711 05 RSSI dB (?) 349 (0x015D)
21:14:50:712 06 LQI (?) 4294967296 (0x0100000000)
21:14:50:712 64 temperature 568
21:14:50:713 65 humidity 9800
21:14:50:714 66 pressure 97386 (974)
21:14:50:715 0a Parent NWK 64132 (0xFA84)
21:15:02:233 Send Tuya request 0x847127FFFE7BC0D0 : Dp_type: 0x01, Dp_identifier 0x65, data: 00
21:15:03:858 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00906501000100
21:15:03:859 Tuya debug 5 : Status: 0 Transid: 144 Dp: 357 (0x01,0x65) Fn: 0 Data 545460846592
21:15:03:974 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00906501000100
21:15:03:975 Tuya debug 5 : Status: 0 Transid: 144 Dp: 357 (0x01,0x65) Fn: 0 Data 545460846592
21:15:11:057 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000a0
21:15:11:058 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846752
21:15:42:967 ZCL attribute report 0x588E81FFFED397B2 for cluster: 0x0702, ep: 0x01, frame control: 0x08, mfcode: 0x0000
21:15:43:018 Bind response success for 0x588e81fffed397b2 ep: 0x01 cluster: 0x0B04
21:15:46:365 Device TTL 1919 s flags: 0x7
21:15:51:928 Bind response success for 0x842e14fffe139aef ep: 0x01 cluster: 0x0B04
21:16:01:300 ZCL attribute report 0x842E14FFFE139AEF for cluster: 0x0702, ep: 0x01, frame control: 0x08, mfcode: 0x0000
21:16:02:026 ZCL attribute report 0x00158D000444E917 for cluster: 0x0000, ep: 0x01, frame control: 0x18, mfcode: 0x0000
21:16:02:027 0x00158D000444E917 extract Xiaomi special attribute 0xFF01
21:16:02:028 01 battery 2775 (0x0AD7)
21:16:02:028 04 unknown 17320 (0x43A8)
21:16:02:029 05 RSSI dB (?) 708 (0x02C4)
21:16:02:030 06 LQI (?) 4294967296 (0x0100000000)
21:16:02:030 64 temperature 511
21:16:02:031 65 humidity 7020
21:16:02:032 0a Parent NWK 64132 (0xFA84)
21:16:15:917 Bind response success for 0x588e81fffed395cc ep: 0x01 cluster: 0x0B04
21:16:23:628 Send Tuya request 0x847127FFFE7BC0D0 : Dp_type: 0x01, Dp_identifier 0x6C, data: 01
21:16:23:629 Send Tuya request 0x847127FFFE7BC0D0 : Dp_type: 0x01, Dp_identifier 0x65, data: 01
21:16:23:630 delay sending request 56 dt 0 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:23:630 delay sending request 56 dt 0 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:23:657 delay sending request 56 dt 0 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:23:757 delay sending request 56 dt 0 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:23:857 delay sending request 56 dt 0 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:23:958 delay sending request 56 dt 0 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:24:057 delay sending request 56 dt 0 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:24:157 delay sending request 56 dt 0 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:24:188 delay sending request 56 dt 0 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:24:258 delay sending request 56 dt 0 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:24:358 delay sending request 56 dt 1 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:24:458 delay sending request 56 dt 1 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:24:557 delay sending request 56 dt 1 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:24:657 delay sending request 56 dt 1 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:24:757 delay sending request 56 dt 1 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:24:857 delay sending request 56 dt 1 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:24:957 delay sending request 56 dt 1 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:24:975 delay sending request 56 dt 1 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:25:057 delay sending request 56 dt 1 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:25:157 delay sending request 56 dt 1 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:25:257 delay sending request 56 dt 1 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:25:357 delay sending request 56 dt 2 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:25:457 delay sending request 56 dt 2 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:25:557 delay sending request 56 dt 2 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:25:657 delay sending request 56 dt 2 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:25:758 delay sending request 56 dt 2 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:25:857 delay sending request 56 dt 2 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:25:868 delay sending request 56 dt 2 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:25:957 delay sending request 56 dt 2 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:26:057 delay sending request 56 dt 2 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:26:157 delay sending request 56 dt 2 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:26:258 delay sending request 56 dt 2 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:26:357 delay sending request 56 dt 3 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:26:457 delay sending request 56 dt 3 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:26:557 delay sending request 56 dt 3 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:26:658 delay sending request 56 dt 3 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:26:757 delay sending request 56 dt 3 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:26:857 delay sending request 56 dt 3 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:26:957 delay sending request 56 dt 3 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:27:057 delay sending request 56 dt 3 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:27:157 delay sending request 56 dt 3 ms to 0x847127FFFE7BC0D0, ep: 0x01 cluster: 0xEF00 onAir: 1
21:16:27:255 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00c06c01000101
21:16:27:256 Tuya debug 5 : Status: 0 Transid: 192 Dp: 364 (0x01,0x6C) Fn: 0 Data 545460846593
21:16:27:395 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00c06c01000101
21:16:27:395 Tuya debug 5 : Status: 0 Transid: 192 Dp: 364 (0x01,0x6C) Fn: 0 Data 545460846593
21:16:27:501 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00c06c01000101
21:16:27:501 Tuya debug 5 : Status: 0 Transid: 192 Dp: 364 (0x01,0x6C) Fn: 0 Data 545460846593
21:16:27:704 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00c16501000101
21:16:27:704 Tuya debug 5 : Status: 0 Transid: 193 Dp: 357 (0x01,0x65) Fn: 0 Data 545460846593
21:16:41:055 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000c8
21:16:41:056 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846792
21:16:46:366 Device TTL 1859 s flags: 0x7
21:17:06:916 verified group capacity: 255 and group count: 1 of LightNode 0x842e14fffe139aef
21:17:06:917 0x842e14fffe139aef found group 0xFFF0
21:17:15:894 Bind response success for 0x588e81fffed397b2 ep: 0x01 cluster: 0x0B04
21:17:28:177 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000c8
21:17:28:178 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846792
21:17:28:492 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000c8
21:17:28:493 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846792
21:17:29:273 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000b4
21:17:29:274 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846772
21:17:29:804 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000aa
21:17:29:805 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846762
21:17:30:254 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000a0
21:17:30:254 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846752
21:17:35:354 ZCL attribute report 0x842E14FFFE139AEF for cluster: 0x0702, ep: 0x01, frame control: 0x08, mfcode: 0x0000
21:17:35:429 Bind response success for 0x842e14fffe139aef ep: 0x01 cluster: 0x0B04
21:17:46:366 Device TTL 1799 s flags: 0x7
Hope it helps, please let me know if more output are required.
Edit: something else I've noticed: if I turn off the device using the physical wheel, the mode will update to inactive/off in both HA and rest api. However when I turn it back on, the mode remains "off" although the temperature set point is read in real time correctly in HA/REST API.
then I tried to change the mode to "heat" but it immediately reverted to "auto"
21:16:23:628 Send Tuya request 0x847127FFFE7BC0D0 : Dp_type: 0x01, Dp_identifier 0x6C, data: 01
21:16:23:629 Send Tuya request 0x847127FFFE7BC0D0 : Dp_type: 0x01, Dp_identifier 0x65, data: 01
From the code you have send "auto"
if (match.key == QLatin1String("off"))
{
if (sendTuyaRequest(task, TaskThermostat, DP_TYPE_BOOL, DP_IDENTIFIER_THERMOSTAT_SCHEDULE_ENABLE, QByteArray("\x00", 1)) &&
sendTuyaRequest(task, TaskThermostat, DP_TYPE_BOOL, DP_IDENTIFIER_THERMOSTAT_MODE_3, QByteArray("\x00", 1)))
{
updated = true;
}
}
else if (match.key == QLatin1String("heat"))
{
if (sendTuyaRequest(task, TaskThermostat, DP_TYPE_BOOL, DP_IDENTIFIER_THERMOSTAT_SCHEDULE_ENABLE, QByteArray("\x00", 1)) &&
sendTuyaRequest(task, TaskThermostat, DP_TYPE_BOOL, DP_IDENTIFIER_THERMOSTAT_MODE_3, QByteArray("\x01", 1)))
{
updated = true;
}
}
else
{
if (sendTuyaRequest(task, TaskThermostat, DP_TYPE_BOOL, DP_IDENTIFIER_THERMOSTAT_SCHEDULE_ENABLE, QByteArray("\x01", 1)) &&
sendTuyaRequest(task, TaskThermostat, DP_TYPE_BOOL, DP_IDENTIFIER_THERMOSTAT_MODE_3, QByteArray("\x01", 1)))
{
updated = true;
}
}
For heat you need to have
21:16:23:628 Send Tuya request 0x847127FFFE7BC0D0 : Dp_type: 0x01, Dp_identifier 0x6C, data: 00
21:16:23:629 Send Tuya request 0x847127FFFE7BC0D0 : Dp_type: 0x01, Dp_identifier 0x65, data: 01
something else I've noticed: if I turn off the device using the physical wheel, the mode will update to inactive/off in both HA and rest api. However when I turn it back on, the mode remains "off" although the temperature set point is read in real time correctly in HA/REST API.
Can you show the same logs when doing this procedure ?
And yes I m seing some possible problem, this device use 2 different command with 2 values but for only 3 used mode, so it can miss in some situations.
For information: 0x01 0x6C is the schedule mode enabled or not 0x01 0x65 is the mode.
So
From the code you have send "auto"
To send those commands I'm simply using the default lovelace card in homeassistant, I'm not exactly sure how HA issues the command to deconz
Can you show the same logs when doing this procedure ?
Yes:
22:45:08:150 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000266020004000000aa
22:45:08:150 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 (0x02,0x66) Fn: 0 Data 545460846762
22:45:08:184 verified group capacity: 255 and group count: 1 of LightNode 0x588e81fffed395cc
22:45:08:185 0x588e81fffed395cc found group 0xFFF0
22:45:23:518 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000b4
22:45:23:519 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846772
22:45:24:466 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00036702000400000064
22:45:24:467 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846692
22:45:24:912 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00016501000100
22:45:24:913 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 (0x01,0x65) Fn: 0 Data 545460846592
22:45:25:230 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00036702000400000032
22:45:25:231 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846642
22:45:25:636 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00036702000400000032
22:45:25:637 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846642
22:45:28:481 discovery for zombie 0x680ae2fffe771ec7 dropped, last try was 447 seconds ago
22:45:39:598 ZCL attribute report 0x00158D0006B79636 for cluster: 0x0000, ep: 0x01, frame control: 0x1C, mfcode: 0x115F
22:45:39:599 0x00158D0006B79636 extract Xiaomi special attribute 0xFF01
22:45:39:599 01 battery 3025 (0x0BD1)
22:45:39:600 03 Device temperature 25 °C
22:45:39:601 04 unknown 17320 (0x43A8)
22:45:39:602 05 RSSI dB (?) 11 (0x000B)
22:45:39:602 06 LQI (?) 21474836480 (0x0500000000)
22:45:39:603 0a Parent NWK 64132 (0xFA84)
22:45:39:603 64 on/off 0
22:45:39:604 0b lightlevel 7 (0x0007)
22:45:46:364 Device TTL 3000 s flags: 0x7
22:45:49:394 Bind response success for 0x588e81fffed397b2 ep: 0x01 cluster: 0x0B04
22:45:51:409 Bind response success for 0x842e14fffe139aef ep: 0x01 cluster: 0x0B04
22:45:56:516 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00036702000400000032
22:45:56:516 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846642
22:45:56:810 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00016501000101
22:45:56:811 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 (0x01,0x65) Fn: 0 Data 545460846593
22:45:57:306 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 0003670200040000006e
22:45:57:307 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846702
22:45:57:844 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000aa
22:45:57:845 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846762
22:45:58:398 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000d2
22:45:58:398 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 545460846802
22:46:03:352 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000266020004000000b2
22:46:03:352 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 (0x02,0x66) Fn: 0 Data 545460846770
22:46:23:358 GW firmware version: 0x26660700
22:46:23:359 GW firmware version is up to date: 0x26660700
22:46:31:362 discovery for zombie 0x680ae2fffe771ec7 dropped, last try was 509 seconds ago
22:46:46:364 Device TTL 2940 s flags: 0x7
22:47:03:186 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000266020004000000b9
22:47:03:187 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 (0x02,0x66) Fn: 0 Data 545460846777
Ok, so it's normal, in this situation the device use only the command 0x01 0x65 and not the 0x01 0x0C ....
Have you a linux machine wth full OS to test some changes ?
Have you a linux machine wth full OS to test some changes ?
Yes I do
You have the procedure here https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Compiling-the-REST-plugin-for-device-specific-testing So for you, after having installed deconz :
sudo apt install deconz-dev
git clone --branch tuya_trv_47 https://github.com/Smanar/deconz-rest-plugin.git
cd deconz-rest-plugin
qmake && make -j2
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins
No need to re-include the device. This PR will improve the mode update, but not solve this issue
The device started in mode "auto". I switched it to mode "inactive" in HA and the result in the REST API was also mode = "off". Then I tried to change the mode to "heat" but it immediately reverted to "auto" (also in the rest api, mode = "auto" in the JSON). Here is a log capture of the whole sequence:
For this one can you try to take a look in the logs with the flag "http", to see the request made by HA, no need to copy/paste the log, just check if you relay see "auto" or "heat".
Thanks @Smanar I've been trying to build a test version of the HA deconz plugin that includes your changes (I simply clone the plugin locally, edit the build & config.json to build it locally, then edit Dockerfile to build your branch and include it). So far I can build it, I can run it and restore in the test environment my current deconz config but HA doesn't seem to communicate with the plugin (all my existing entities are "unavailable"). Of course I stop the official deconz plugin before starting the test version, but it doesn't solve the issue. Testing changes with no connection to HA is really unconvenient, do you maybe have an idea how I could achieve this ?
Ha, you are on HA too. On the previous link you have a procedure to compile the code on docker. but I m using only real OS so I realy can't help you for that.
Phoscon is still running ? Perhaps something have moved IP or port ?
I've eventually got it working... HA autodiscovery kept modifying core.config_entries file where deconz host and port is specified... Even when modifying it when HA is stopped, it would update it when HA container starts up again => I had to temporarily uninstall core-deconz plugin. Observations with latest beta and your branch:
Trying to put "operation" to "auto" in HA gives an exception in HA:
2021-11-07 22:40:14 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [547553123152] /sensors/55/config/mode Could not set attribute
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 185, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1491, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1526, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 213, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 658, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 830, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 695, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/deconz/climate.py", line 186, in async_set_hvac_mode
await self._device.set_config(**data)
File "/usr/local/lib/python3.9/site-packages/pydeconz/sensor.py", line 921, in set_config
return await self.request(field=f"{self.deconz_id}/config", data=data)
File "/usr/local/lib/python3.9/site-packages/pydeconz/api.py", line 137, in request
return await self._request("put", path=field, json=data)
File "/usr/local/lib/python3.9/site-packages/pydeconz/gateway.py", line 141, in request
return await self._request(
File "/usr/local/lib/python3.9/site-packages/pydeconz/gateway.py", line 167, in _request
_raise_on_error(response)
File "/usr/local/lib/python3.9/site-packages/pydeconz/gateway.py", line 261, in _raise_on_error
raise_error(data["error"])
File "/usr/local/lib/python3.9/site-packages/pydeconz/errors.py", line 59, in raise_error
raise cls("{} {}".format(error["address"], error["description"]))
pydeconz.errors.pydeconzException: /sensors/55/config/mode Could not set attribute
I can switch to "Inactive" and "Heat" modes with no problem. On this device, it seems "Heat" mode is similar to the mode "auto" with preset "manual" of my other TS0601 device (on that other device, heat mode = full opening of the valve).
When going from off to a given temperature setpoint using the device, then querying the rest api, I see it in mode "manu":
{
"config": {
"heatsetpoint": 1200,
"locked": true,
"mode": "manu",
"offset": 0,
"on": true,
"preset": "manual",
"reachable": true,
"schedule": {},
"schedule_on": false,
"setvalve": false,
"windowopen_set": false
},
"ep": 1,
"etag": "3cdbcc2488ce67dfd57d2c7998c035e7",
"lastannounced": "2021-11-07T19:19:44Z",
"lastseen": "2021-11-07T19:19Z",
"manufacturername": "_TZE200_c88teujp",
"modelid": "TS0601",
"name": "Thermostat 55",
"state": {
"lastupdated": "2021-11-07T21:54:08.248",
"lowbattery": null,
"on": null,
"temperature": 2030,
"valve": null
},
"type": "ZHAThermostat",
"uniqueid": "84:71:27:ff:fe:7b:c0:d0-01-0201"
}
.... OK, idk what happen to code, but there is a problem in code, it s able to manage off/auto/heat, but the list contain only off and heat
RConfigModeValuesTuya2 = { { {QLatin1String("off"), {0x00}}, {QLatin1String("heat"), {0x01}} } };
You will be enable to set the "auto" mode again.
On this device, it seems "Heat" mode is similar to the mode "auto" with preset "manual" of my other TS0601 device
Yes, on this device the "heat" is the same mode than "auto" but with schedule enabled (and I don't remember what is it, it seem schedule off = a kind of manu)
To test again the "auto"
cd deconz-rest-plugin
git pull
qmake && make -j2
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins
.... OK, idk what happen to code, but there is a problem in code, it s able to manage off/auto/heat, but the list contain only off and heat
RConfigModeValuesTuya2 = { { {QLatin1String("off"), {0x00}}, {QLatin1String("heat"), {0x01}} } };
You will be enable to set the "auto" mode again.
On this device, it seems "Heat" mode is similar to the mode "auto" with preset "manual" of my other TS0601 device
Yes, on this device the "heat" is the same mode than "auto" but with schedule enabled (and I don't remember what is it, it seem schedule off = a kind of manu)
To test again the "auto"
cd deconz-rest-plugin git pull qmake && make -j2 sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins
Tested the new branch and I can now change to auto ! Here a picture just after setting to "heat":
Then when going to "auto":
I've noticed that the "valve" value always remains equal to "0" (regardless of its actual state). Will need to test it further as I don't know exactly how the device is supposed to work (there is no doc and I don't have a tuya hub) but it's looking good so far ! thanks!
From the code to have the value state/valve you probably need to enable the report using config/setvalve.
But the code have moved a lot, not sure your device support it.
Other strange behaviors I've noticed: the device sometimes changes mode itself. Here are two different scenarios I've experienced (on the two device I own):
The TRV starts heating the room in the middle of the night although no command was issued.
IDK, it don't trigger if the temperature go under a value ?
It changes mode to "heat" in HA although it is still "off" on the physical device screen (again without any command issued, I just notice it in the history).
We are using 2 commands for this device
So this can happen if the device send the "tuya manual" report but was "off", heat = "manual on" and off = "manual off"
If (1) = 0 > mode "off" if (2) = 1 > mode "auto"
For other it s another story, have modified the code but it depend off the order of thoses 2 commands to work.
Have updated too the code with the last official, can you remake a try ?
cd deconz-rest-plugin
git pull
qmake && make -j2
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins
No more issue since 2 days after recompiling, thanks @Smanar !
I missed this : when the device is is "off - manual", its state won't be updated to "heat - manual" in hassio after setting a new temperature set point on the device itself (temperature/set points readings are still correct though)
Can you show logs when doing this procedure ? To check if you have a 0x01 0x65 or a 0x01 0x6C if you just set a new temperature setpoint ?
Yes:
08:04:24:361 ZCL attribute report 0x84FD27FFFECE7BE7 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
08:04:27:917 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00036702000400000078
08:04:27:918 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 120
08:04:29:036 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00036702000400000078
08:04:29:037 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 120
08:04:29:528 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00016501000101
08:04:29:529 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 (0x01,0x65) Fn: 0 Data 1
08:04:29:913 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00036702000400000064
08:04:29:914 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 100
08:04:30:374 ZCL attribute report 0x84FD27FFFECE7BE7 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
08:04:30:481 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 0003670200040000008c
08:04:30:482 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 140
08:04:30:911 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000b4
08:04:30:912 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 180
08:04:31:261 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000c8
08:04:31:262 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 200
08:04:31:992 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000d2
08:04:31:993 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 210
08:04:36:446 ZCL attribute report 0x84FD27FFFECE7BE7 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
08:04:29:529 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 (0x01,0x65) Fn: 0 Data 1
And the mode have not switched to "auto" ?
And the mode have not switched to "auto" ?
In HA it remains on 'inactive' even though the temp and set point are updated
It remains on 'inactive' but the value is updated or not (IDK how worj HA) On the code
case 0x0165: // off / on > [off = off, on = heat] for Saswell devices
{
QString mode;
if (data == 0) { mode = QLatin1String("off"); }
else if (data == 1) { mode = QLatin1String("manu"); }
else
{
return;
}
ResourceItem *item = sensorNode->item(RConfigMode);
if (item && item->toString() != mode &&
(mode == QLatin1String("off") || item->toString() == QLatin1String("off"))) // Only change if the state is off or become off
{
item->setValue(mode);
enqueueEvent(Event(RSensors, RConfigMode, sensorNode->id(), item));
update = true;
}
}
If the previous mode was "off" and ONLY in this situation, the mode is updated to "manu" and trigger a device update.
Indeed the mode was set to "manu" but this doesn't seem to be a known mode for HA. Is there somewhere a list of possible values for both "mode" and "preset" fields and what they mean ? Are those values device specific or is it a standard ? I can imagine some devices might only support a subset of the possible values combinations, but will 2 different thermostats with the same values for "mode" and "preset" behave the same way ?
PS: here are some detailed logs :
Initial state:
{
"config": {
"heatsetpoint": 500,
"locked": true,
"mode": "off",
"offset": 0,
"on": true,
"preset": "manual",
"reachable": true,
"schedule": {
"W124": [
{
"heatsetpoint": 7,
"localtime": "T11:12"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
}
],
"W3": [
{
"heatsetpoint": 2,
"localtime": "T00:00"
},
{
"heatsetpoint": 17,
"localtime": "T16:14"
},
{
"heatsetpoint": 16,
"localtime": "T15:05"
},
{
"heatsetpoint": 16,
"localtime": "T16:16"
},
{
"heatsetpoint": 11,
"localtime": "T16:15"
},
{
"heatsetpoint": 0,
"localtime": "T12:07"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
}
]
},
"schedule_on": false,
"setvalve": false,
"windowopen_set": false
},
"ep": 1,
"etag": "9964fc1eb973b8990d207f109846744a",
"lastannounced": "2021-11-07T22:08:40Z",
"lastseen": "2021-11-18T17:29Z",
"manufacturername": "_TZE200_c88teujp",
"modelid": "TS0601",
"name": "Thermostat 55",
"state": {
"lastupdated": "2021-11-17T07:06:08.448",
"lowbattery": false,
"on": false,
"temperature": 1490,
"valve": 0
},
"type": "ZHAThermostat",
"uniqueid": "84:71:27:ff:fe:7b:c0:d0-01-0201"
}
Setting target temp on the device:
21:55:26:828 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00036702000400000032
21:55:26:829 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 50
21:55:26:944 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 00016501000101
21:55:26:945 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 (0x01,0x65) Fn: 0 Data 1
21:55:27:391 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 0003670200040000005a
21:55:27:392 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 90
21:55:27:927 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 0003670200040000008c
21:55:27:928 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 140
21:55:28:575 Tuya debug 4 : Address 0x847127FFFE7BC0D0 Payload 000367020004000000d2
21:55:28:576 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 210
New state:
{
"config": {
"heatsetpoint": 2100,
"locked": true,
"mode": "manu",
"offset": 0,
"on": true,
"preset": "manual",
"reachable": true,
"schedule": {
"W124": [
{
"heatsetpoint": 7,
"localtime": "T11:12"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
}
],
"W3": [
{
"heatsetpoint": 2,
"localtime": "T00:00"
},
{
"heatsetpoint": 17,
"localtime": "T16:14"
},
{
"heatsetpoint": 16,
"localtime": "T15:05"
},
{
"heatsetpoint": 16,
"localtime": "T16:16"
},
{
"heatsetpoint": 11,
"localtime": "T16:15"
},
{
"heatsetpoint": 0,
"localtime": "T12:07"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
}
]
},
"schedule_on": false,
"setvalve": false,
"windowopen_set": false
},
"ep": 1,
"etag": "85cb828311d1e88c8b7af601e26c23fd",
"lastannounced": "2021-11-07T22:08:40Z",
"lastseen": "2021-11-18T17:29Z",
"manufacturername": "_TZE200_c88teujp",
"modelid": "TS0601",
"name": "Thermostat 55",
"state": {
"lastupdated": "2021-11-18T20:55:26.945",
"lowbattery": false,
"on": false,
"temperature": 1490,
"valve": 0
},
"type": "ZHAThermostat",
"uniqueid": "84:71:27:ff:fe:7b:c0:d0-01-0201"
}
There is no "manu" support right now. And why would it be called "manu" rather than "manual"?
Arf, right. My bad, mode are off/heat/auto and not manu or manual And preset use manual and noy manu
I have removed the "manu" from code too, if you can try the new version ?
Now when inactive it changes to "auto" (mode) - manual (preset) which is looking good. I'm just wondering: what is difference between "auto - manual" and "heat - manual" on this device ? On my other device (MOES TRV HY368 TS0601), "heat" mode just opens completely the valve (it ignores target temp).
It s because this device (not all TRV are working same) use 2 commands, on we use only 1 for integration, so we need to mix them
And you can play with them, so you can have 4 possibilities.
if (1) is "off" mean the device is "off" if (2) is "on" it mean the device is on "automatic mode"
But for others combinations, can be anything.
EDIT: The device was not removed completely and therfore the updates didnt apply.
I just added this TRV today initially with deczon 2.12.x. Removed the devices and added it again with deconz 2.13.2, and it is still added with the modes off
and heat
. I read this issue and if I am not misunderstanding, that's not correct, is it? It doesn't matter what I do, the operation mode is always off
You are speaking about the PR ? It was validated, but you still need to compile the code to use it, there is not yet a public version that use it.
there is not yet a public version
I see a patch has been merged. I'm new here. What is the PR process? Does this get in after a predictable amount of time, or is it more or less random?
The beta with the patch was released yesterday.
Updated deconz and re-paired the valve. Do i understand it correctly that i need to customize the thermostat to provide the hvac modes off and auto? This is not easy possible anymore as the HA customizing menu was removed.
Currently the situation is again that off
is the only state. Before i could turn it on and off but now the mode seems to be always auto
which results in off
on the home assistant side
{
"config": {
"heatsetpoint": 2100,
"locked": true,
"mode": "auto",
"offset": 0,
"on": true,
"preset": null,
"reachable": true,
"schedule": {
"W124": [
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
}
],
"W3": [
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
},
{
"heatsetpoint": 0,
"localtime": "T00:00"
}
]
},
"schedule_on": false,
"setvalve": false,
"windowopen_set": false
},
"ep": 1,
"etag": "42cf60b8d13bd1e47992d01fc8dbeadc",
"lastannounced": null,
"lastseen": "2021-12-11T22:40Z",
"manufacturername": "_TZE200_c88teujp",
"modelid": "TS0601",
"name": "Thermostat 12",
"state": {
"lastupdated": "2021-12-11T22:46:57.861",
"lowbattery": false,
"on": false,
"temperature": 2040,
"valve": null
},
"type": "ZHAThermostat",
"uniqueid": "84:71:27:ff:fe:23:7e:63-01-0201"
}
Home Assistant:
hvac_modes:
- heat
- 'off'
min_temp: 7
max_temp: 35
current_temperature: 20.4
temperature: 21
offset: 0
locked: true
friendly_name: Thermostat Küche
supported_features: 1
Do i understand it correctly that i need to customize the thermostat to provide the hvac modes off and auto? This is not easy possible anymore as the HA customizing menu was removed
With the last version it need to work, what do you have in log when trying to change the mode ?
Sometimes HA doesn't show all hvac modes directly, have you tried restarting HA after pairing the TRV ?
@SebLz Yes i recreated the container multiple times and ensured i removed the TRV before pairing it (remove it from core.device_registry
)
I deleted the devices from deconz via an API call, that should be sufficient, right?
If i set the mode to auto
via developer tools the log says nothing but the card changes its color to green for some time before going to off
again:
If i set the mode to heat
the log says again nothing and the card changes to heat
. After a short time its off
again
But i cant control the thermostat from the card itself, besides turning the TRV to off. Pressing the heat
button does nothing.
And if you try manualy, direclty on the device ? Ca, you try directly using the API ?
What exactly do you mean?
@SebLz Yes i recreated the container multiple times and ensured i removed the TRV before pairing it (remove it from
core.device_registry
) I deleted the devices from deconz via an API call, that should be sufficient, right?
No it's not, I had a similar issue, I had to actually restart the HA core container before the lovelace card would display all options correctly (you can do that from within the UI at
ha core restart
@SebLz I effectively did that by removing the HA container completely and started it again.
-> docker stop home-assistant; docker rm home-assistant; docker run home-assistant <options...>
Let me do the following:
I think that did the trick. The restart of HA between removing and paring the TRV again:
hvac_modes:
- auto
- heat
- 'off'
min_temp: 7
max_temp: 35
current_temperature: 21.2
temperature: 16
offset: 0
locked: true
friendly_name: Thermostat 15
supported_features: 1
Only question left:
I cant use the left button. This results in:
2021-12-12 11:46:59 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [281473106286624] /sensors/15/config/mode Could not set attribute
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 185, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1495, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1530, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 209, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 663, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 896, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 700, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/deconz/climate.py", line 222, in async_set_hvac_mode
await self._device.set_config(**data)
File "/usr/local/lib/python3.9/site-packages/pydeconz/sensor.py", line 1045, in set_config
return await self.request(field=f"{self.deconz_id}/config", data=data)
File "/usr/local/lib/python3.9/site-packages/pydeconz/api.py", line 137, in request
return await self._request("put", path=field, json=data)
File "/usr/local/lib/python3.9/site-packages/pydeconz/gateway.py", line 141, in request
return await self._request(
File "/usr/local/lib/python3.9/site-packages/pydeconz/gateway.py", line 167, in _request
_raise_on_error(response)
File "/usr/local/lib/python3.9/site-packages/pydeconz/gateway.py", line 261, in _raise_on_error
raise_error(data["error"])
File "/usr/local/lib/python3.9/site-packages/pydeconz/errors.py", line 59, in raise_error
raise cls("{} {}".format(error["address"], error["description"]))
pydeconz.errors.pydeconzException: /sensors/15/config/mode Could not set attribute
Setting the auto
mode via developer tools works 😕
I had this problem too, I'm not exactly sure why to be honest. This is what I did to get it working (not sure if it will work for you but I guess it's worth a try):
I tried that but the issue persists. Or do you think i need to repair it again?
pydeconz.errors.pydeconzException: /sensors/15/config/mode Could not set attribute
Look if you have the config/mode in the device json, if no, try to restart deconz, if yes "re synchronise HA".
"config": {
"heatsetpoint": 2150,
"locked": true,
"mode": "heat",
...
I did a device refresh and restarted deconz again. Now the card is completely without response
If I compare with my setup, I have similar json output than yours when querying the deconz REST API. However, in HA dev tools, my entity has a different values:
hvac_modes: auto, heat, off
min_temp: 7
max_temp: 35
preset_modes: auto, boost, comfort, complex, eco, holiday, manual
current_temperature: 14.2
temperature: 16
preset_mode: manual
valve: 0
locked: true
friendly_name: Radiateur du bureau
supported_features: 17
I'm currently on HA core-2021.11.4 (supervised mode), what version are you running ?
Oh yeah that looks different. I am running on core-2021.12.0
Device
Screenshots
Basic
Groups
Scenes
Other clusters that are not mentioned above
Set point is read correctly, but for instance "mode" is always "off" and "valve" always "null":
Deconz logs (filtered on tuya lines)