Tuya X5H-GB-B / Beok TGR85B-ZB clone (_TZE200_2ekuz3dz) heating thermostate

[mrblur]

Device

• Product name: ZIGBEE THERMOSTAT (Beok TGR85B clone)
• Manufacturer: _TZE200_2ekuz3dz
• Model identifier: TS0601
• Device type :
  • Thermostat

This seems to be a clone of Beok TGR85B-ZB, it came with no branding and manual says only "Zigbee THERMOSTAT USER GUIDE". It looks like this one: https://zigbee.blakadder.com/Beok_TGR85-ZB.html, seems to be added to z2m already at https://github.com/Koenkk/zigbee2mqtt/issues/12849 (and my device looks exactly like the one linked in here), should be supported by zigpy with https://github.com/zigpy/zha-device-handlers/pull/1507/commits.

So far my device was able to only join the network. It did flip the time by 5hr upon joining. And somehow ended up with time being set as 25:13 (:roll_eyes:).

Edit: Tested it with zigbee2mqtt, detected as Tuya X5H-GB-B, seems all functions are operating correctly on z2m.

Screenshots

Basic

Groups

Scenes

[Smanar]

Long story but we need a PR in waiting list to include tuya TRV with DDF.

[mrblur]

It seems that PR somehow got stuck.

Can we push it forward in any way? I'm open for debugging and testing. Have some experience with Qt and C++.

"Winter is coming" and so far my stupid device flips the time randomly during the day. I've seen hours of 27 and 35 already :roll_eyes: .

I've seen something about incorrect time synchronization on tuya flying around, is it possible to "patch" it over with a DDF? I can live with it being unsupported, but this time sync issue breaks scheduling completely.

[Smanar]

I have just updated the PR.

Sure you can compile the code on your side.

You have 2 possibilities, start from official code and mimic an exiting TRV that use the same dp than this one. From this link https://github.com/Koenkk/zigbee-herdsman-converters/pull/3840/files it seem this device use same dp than moes TRV (for exemple 40 for childlock and 16 for heatpoint) Or start from the tuya TRV PR https://github.com/dresden-elektronik/deconz-rest-plugin/pull/6054 and just create a DDF for your device

On my side I prefer help you for the second one, because the first one will be never merged, and the second can improve the PR.

The time sysnchronisation use only the leagcy code, so if I m right there is no impact on the solution you wana try.

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[mrblur]

Keep this open, the issue with time sync is still there and irritating as never.

I also tried to compile the plugin myself, but it seems my Gentoo uses different libraries as the plugin fails to load. It looses all device names, there is no DDF editor available. Waiting for THE PR to get merged in hope this will fix all my issues :+1:

[Smanar]

9 Days ago, there was a PR probably usefull for you https://github.com/dresden-elektronik/deconz-rest-plugin/pull/6305 But the PR for tuya TRV is still in waiting list.

[mrblur]

Thanks @Smanar, already on latest release (unraid + docker), re-added device to the network, but it doesn't stop it from displaying "29:55" once in a while :laughing:

Either I read the changelog wrong, or this is something different happening. Like the time sync somewhat is working, as the minutes and day of week is always good, only the hour display switches during the day. I can setup the hour manually and after some time it displays "25:14" again :shrug:

I've seen something about tuya byte ordering on time sync while browsing old commits, could this be related?

[Smanar]

So you are on version 2.18.1 ? It's perhaps because your device is not supported, so it doesn't use the deconz code at all.

[mrblur]

Yes, I am.

I see the app (at least for docker) is built on GCC 7.5, that is ancient on Gentoo (anything below 10 is..), I see there is a docker version available, would try again this weekend over docker, maybe this time the plugin would be compatible.

[Smanar]

The problem is your device is not supported. So lof of thing are just ignored for your device.

[jplahl]

@Smanar yesterday I posted the following thread in the phoscon forum before I found this issue. https://forum.phoscon.de/t/hama-tuya-thd-smart-radiator-trv-tze200-yw7cahqs-some-state-values-not-updated/2512

I think my problems with the Hama smart radiatior have the same reason like all the tuya based thermostat devices.

So I compiled your git repository for testing your tuya changes. But for my hama thermostat nothing changes. Still no update for temperature or battery status. Maybe I missed something.

[Smanar]

So I compiled your git repository for testing your tuya changes

Hu, wich one ?

Still no update for temperature or battery status

This is strange because it worked when you include the device or when you use the device manualy. And tuya device don't use bind and reporting. So if it work at least one time, no reason for it stop working ?

As you have the GUI, you can take a look in deconz log with "info" you can see thoses logs lines, for all incoming request from the device

        DBG_Printf(DBG_INFO, "Tuya debug 4 : Address 0x%016llX Payload %s\n", ind.srcAddress().ext(), qPrintable(zclFrame.payload().toHex()));
        DBG_Printf(DBG_INFO, "Tuya debug 5 : Status: %u Transid: %u Dp: %u (0x%02X,0x%02X) Fn: %u Data %d\n", status, transid, dp, dp_type, dp_identifier, fn, data);

Have you tried to include the device a second time ? (without deleting it)

[jplahl]

Hu, wich one ? https://github.com/Smanar/deconz-rest-plugin/tree/tuya_trv_clean

Have you tried to include the device a second time ? (without deleting it) yes

This is strange because it worked when you include the device or when you use the device manualy. And tuya device don't use bind and reporting. So if it work at least one time, no reason for it stop working ?

That's. If the mapping/code is wrong why are the values set the first time. I have no idea. It seems that only a change of the heatsetpoint value is transmitted. If I manually lock or unlock the device the state is always locked.

Here are some logs change temperature at device: 16:51:21:367 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000367020004000000d2 16:51:21:369 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 210 16:51:22:212 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000367020004000000dc 16:51:22:214 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 220 16:51:23:051 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000367020004000000d2 16:51:23:053 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 210 16:51:23:893 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000367020004000000be 16:51:23:895 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 190 16:51:25:309 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000367020004000000c8 16:51:25:311 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 200

rejoin of the device: 17:00:22:940 send permit join, duration: 65 17:00:26:492 Device TTL 3418 s flags: 0x7 17:00:27:920 ZCL attribute report 0x540F57FFFE23E58A for cluster: 0x0001, ep: 0x01, frame control: 0x08, mfcode: 0x0000 17:00:28:825 Tuya : Schedule command 17:00:28:828 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000973000018000000000000000000000000000000001600000000000000 17:00:28:830 Tuya debug 5 : Status: 0 Transid: 9 Dp: 115 (0x00,0x73) Fn: 0 Data 0 17:00:28:831 Tuya : Unknow Schedule mode 17:00:28:913 Bind response success for 0x540f57fffe23e58a ep: 0x01 cluster: 0x0000 17:00:29:124 Tuya : Schedule command 17:00:29:126 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000d6e000018000000000000000000000000000000001400000000000000 17:00:29:128 Tuya debug 5 : Status: 0 Transid: 13 Dp: 110 (0x00,0x6E) Fn: 0 Data 0 17:00:29:130 Tuya : Unknow Schedule mode 17:00:29:307 Tuya : Schedule command 17:00:29:309 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 001177000018000000000000000000000000000000000000000000000000 17:00:29:311 Tuya debug 5 : Status: 0 Transid: 17 Dp: 119 (0x00,0x77) Fn: 0 Data 0 17:00:29:313 Tuya : Unknow Schedule mode 17:00:31:945 DB SELECT manufacturername FROM nodes WHERE mac LIKE '60:a4:23:ff:fe:53:73:4f%' COLLATE NOCASE: _TZ3000_kohbva1f 17:00:31:965 DB SELECT manufacturername FROM nodes WHERE mac LIKE '60:a4:23:ff:fe:53:6c:b8%' COLLATE NOCASE: _TZ3000_kohbva1f 17:00:31:982 DB SELECT manufacturername FROM nodes WHERE mac LIKE 'bc:33:ac:ff:fe:b1:3d:9f%' COLLATE NOCASE: _TZ3000_iivsrikg 17:00:31:998 DB SELECT manufacturername FROM nodes WHERE mac LIKE '60:a4:23:ff:fe:53:6b:41%' COLLATE NOCASE: _TZ3000_kohbva1f 17:00:32:939 Skip idle timer callback, too early: elapsed 927 msec 17:00:33:875 0x26BF seems to be a zombie recv errors 13 17:00:33:877 Node zombie state changed 0x84fd27fffeb8bb9a 17:00:34:355 0x2CAF seems to be a zombie recv errors 25 17:00:34:357 Node zombie state changed 0x680ae2fffe6e05aa 17:00:34:533 DeviceAnnce of SensorNode: 0x04CD15FFFE100F22 [1] 17:00:34:536 nwk address changed 0x0000 -> 0xE5A9 [2] 17:00:34:538 device announce 0x04CD15FFFE100F22 (0xE5A9) mac capabilities 0x80 17:00:34:540 set fast probe address to 0x04CD15FFFE100F22 (0xE5A9) 17:00:34:542 FP indication 0x0000 / 0x0013 (0x04CD15FFFE100F22 / 0xE5A9) 17:00:34:543 ... (0x04CD15FFFE100F22 / 0xE5A9) 17:00:34:545 device announce 0x04CD15FFFE100F22 (0xE5A9) mac capabilities 0x80 17:00:34:546 DEV Tick.Join: event/device.anounce 17:00:34:548 DEV Tick: fast poll 0x04CD15FFFE100F22, mac capabilities: 0x80 17:00:35:439 [1] get node descriptor for 0x04cd15fffe100f22 17:00:35:441 ZDP get node descriptor for 0xE5A9 17:00:41:243 0xE5A9 nwk changed to 0x69F4 17:00:41:246 DeviceAnnce of SensorNode: 0x04CD15FFFE100F22 [1] 17:00:41:249 nwk address changed 0xE5A9 -> 0x69F4 [2] 17:00:41:252 FP indication 0x0000 / 0x0013 (0x04CD15FFFE100F22 / 0x69F4) 17:00:41:254 ... (0x04CD15FFFE100F22 / 0xE5A9) 17:00:41:255 device announce 0x04CD15FFFE100F22 (0x69F4) mac capabilities 0x80 17:00:41:257 FP indication 0x0000 / 0x0013 (0x04CD15FFFE100F22 / 0x69F4) 17:00:41:259 ... (0x04CD15FFFE100F22 / 0xE5A9) 17:00:41:261 device announce 0x04CD15FFFE100F22 (0x69F4) mac capabilities 0x80 17:00:41:263 DEV Tick.Join: event/device.anounce 17:00:41:943 DB SELECT manufacturername FROM nodes WHERE mac LIKE '60:a4:23:ff:fe:53:73:4f%' COLLATE NOCASE: _TZ3000_kohbva1f 17:00:41:961 DB SELECT manufacturername FROM nodes WHERE mac LIKE '60:a4:23:ff:fe:53:6c:b8%' COLLATE NOCASE: _TZ3000_kohbva1f 17:00:41:977 DB SELECT manufacturername FROM nodes WHERE mac LIKE 'bc:33:ac:ff:fe:b1:3d:9f%' COLLATE NOCASE: _TZ3000_iivsrikg 17:00:41:993 DB SELECT manufacturername FROM nodes WHERE mac LIKE '60:a4:23:ff:fe:53:6b:41%' COLLATE NOCASE: _TZ3000_kohbva1f 17:00:42:939 Skip idle timer callback, too early: elapsed 933 msec 17:00:43:810 Search sensors done 17:00:43:939 send permit join, duration: 0 17:00:46:470 ZCL attribute report 0x04CD15FFFE100F22 for cluster: 0x0000, ep: 0x01, frame control: 0x08, mfcode: 0x0000 17:00:49:591 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00016501000100 17:00:49:594 Tuya debug 5 : Status: 0 Transid: 1 Dp: 357 (0x01,0x65) Fn: 0 Data 0 17:00:49:789 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00170a01000101 17:00:49:791 Tuya debug 5 : Status: 0 Transid: 23 Dp: 266 (0x01,0x0A) Fn: 0 Data 1 17:00:49:990 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00180801000101 17:00:49:992 Tuya debug 5 : Status: 0 Transid: 24 Dp: 264 (0x01,0x08) Fn: 0 Data 1 17:00:50:191 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00198201000101 17:00:50:193 Tuya debug 5 : Status: 0 Transid: 25 Dp: 386 (0x01,0x82) Fn: 0 Data 1 17:00:50:391 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 001a1b02000400000000 17:00:50:393 Tuya debug 5 : Status: 0 Transid: 26 Dp: 539 (0x02,0x1B) Fn: 0 Data 0 17:00:50:589 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00162801000101 17:00:50:591 Tuya debug 5 : Status: 0 Transid: 22 Dp: 296 (0x01,0x28) Fn: 0 Data 1 17:00:50:793 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000266020004000000e6 17:00:50:795 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 (0x02,0x66) Fn: 0 Data 230 17:00:50:993 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00036702000400000032 17:00:50:995 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 50 17:00:51:194 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00046905000100 17:00:51:196 Tuya debug 5 : Status: 0 Transid: 4 Dp: 1385 (0x05,0x69) Fn: 0 Data 0 17:00:51:392 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00056a01000100 17:00:51:394 Tuya debug 5 : Status: 0 Transid: 5 Dp: 362 (0x01,0x6A) Fn: 0 Data 0 17:00:51:511 Tuya Time sync request: 0x04cd15fffe100f22 17:00:51:516 Send Tuya command 0x24, data: 00076333102363332c43 17:00:51:594 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00076c01000101 17:00:51:596 Tuya debug 5 : Status: 0 Transid: 7 Dp: 364 (0x01,0x6C) Fn: 0 Data 1 17:00:51:932 Tuya : Schedule command 17:00:51:934 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00ff7b00001104016800c801e000a0043800c8052800a0 17:00:51:936 Tuya debug 5 : Status: 0 Transid: 255 Dp: 123 (0x00,0x7B) Fn: 0 Data 0 17:00:52:147 Tuya : Schedule command 17:00:52:149 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 01007c00001104016800c801e000a0043800c8052800a0 17:00:52:151 Tuya debug 5 : Status: 1 Transid: 0 Dp: 124 (0x00,0x7C) Fn: 0 Data 0 17:00:52:363 Tuya : Schedule command 17:00:52:365 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 01017d00001104016800c801e000a0043800c8052800a0 17:00:52:366 Tuya debug 5 : Status: 1 Transid: 1 Dp: 125 (0x00,0x7D) Fn: 0 Data 0 17:00:52:584 Tuya : Schedule command 17:00:52:586 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 01027e00001104016800c801e000a0043800c8052800a0 17:00:52:587 Tuya debug 5 : Status: 1 Transid: 2 Dp: 126 (0x00,0x7E) Fn: 0 Data 0 17:00:52:802 Tuya : Schedule command 17:00:52:805 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 01037f00001104016800c801e000a0043800c8052800a0 17:00:52:807 Tuya debug 5 : Status: 1 Transid: 3 Dp: 127 (0x00,0x7F) Fn: 0 Data 0 17:00:53:018 Tuya : Schedule command 17:00:53:020 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 01048000001104016800c801e000a0043800c8052800a0 17:00:53:022 Tuya debug 5 : Status: 1 Transid: 4 Dp: 128 (0x00,0x80) Fn: 0 Data 0 17:00:53:233 Tuya : Schedule command 17:00:53:236 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 01058100001104016800c801e000a0043800c8052800a0 17:00:53:237 Tuya debug 5 : Status: 1 Transid: 5 Dp: 129 (0x00,0x81) Fn: 0 Data 0 17:00:53:478 Tuya : Schedule command 17:00:53:481 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000973000018000000000000000000000000000000000000000000000000 17:00:53:482 Tuya debug 5 : Status: 0 Transid: 9 Dp: 115 (0x00,0x73) Fn: 0 Data 0 17:00:53:484 Tuya : Unknow Schedule mode 17:00:53:705 ZCL attribute report 0x84FD27FFFEABBE91 for cluster: 0x0300, ep: 0x01, frame control: 0x08, mfcode: 0x0000 17:00:53:730 Tuya : Schedule command 17:00:53:733 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000d6e000018000000000000000000000000000000000000000000000000 17:00:53:735 Tuya debug 5 : Status: 0 Transid: 13 Dp: 110 (0x00,0x6E) Fn: 0 Data 0 17:00:53:737 Tuya : Unknow Schedule mode 17:00:53:894 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000367020004000000a0 17:00:53:896 Tuya debug 5 : Status: 0 Transid: 3 Dp: 615 (0x02,0x67) Fn: 0 Data 160 17:00:54:127 Tuya : Schedule command 17:00:54:130 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 001177000018000000000000000000000000000000000000000000000000 17:00:54:132 Tuya debug 5 : Status: 0 Transid: 17 Dp: 119 (0x00,0x77) Fn: 0 Data 0 17:00:54:134 Tuya : Unknow Schedule mode 17:00:54:312 Tuya : Schedule command 17:00:54:314 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000a7400000700000000000000 17:00:54:315 Tuya debug 5 : Status: 0 Transid: 10 Dp: 116 (0x00,0x74) Fn: 0 Data 0 17:00:54:317 Tuya : Unknow Schedule mode 17:00:54:521 Tuya : Schedule command 17:00:54:523 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000e7000000700000000000000 17:00:54:524 Tuya debug 5 : Status: 0 Transid: 14 Dp: 112 (0x00,0x70) Fn: 0 Data 0 17:00:54:722 Tuya : Schedule command 17:00:54:724 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00127800000700000000000000 17:00:54:726 Tuya debug 5 : Status: 0 Transid: 18 Dp: 120 (0x00,0x78) Fn: 0 Data 0 17:00:54:727 Tuya : Unknow Schedule mode 17:00:54:843 Tuya : Schedule command 17:00:54:845 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000a7400000700000000000000 17:00:54:846 Tuya debug 5 : Status: 0 Transid: 10 Dp: 116 (0x00,0x74) Fn: 0 Data 0 17:00:54:848 Tuya : Unknow Schedule mode 17:00:54:995 Bind response success for 0x7cb03eaa0a024332 ep: 0x03 cluster: 0x0006 17:00:55:068 Tuya : Schedule command 17:00:55:070 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000b7500001f00000000000000000000000000000000000000000000000000000000000000 17:00:55:072 Tuya debug 5 : Status: 0 Transid: 11 Dp: 117 (0x00,0x75) Fn: 0 Data 0 17:00:55:074 Tuya : Unknow Schedule mode 17:00:55:120 ZCL configure reporting rsp seq: 155 0x7CB03EAA0A024332 for ep: 0x03 cluster: 0x0006 attr: 0x0000 status: 0x00 17:00:55:147 ZCL attribute report 0x84FD27FFFEABBE91 for cluster: 0x0006, ep: 0x01, frame control: 0x08, mfcode: 0x0000 17:00:55:305 Tuya : Schedule command 17:00:55:307 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000f7100001f00000000000000000000000000000000000000000000000000000000000000 17:00:55:309 Tuya debug 5 : Status: 0 Transid: 15 Dp: 113 (0x00,0x71) Fn: 0 Data 0 17:00:55:536 Tuya : Schedule command 17:00:55:538 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00137900001f00000000000000000000000000000000000000000000000000000000000000 17:00:55:539 Tuya debug 5 : Status: 0 Transid: 19 Dp: 121 (0x00,0x79) Fn: 0 Data 0 17:00:55:541 Tuya : Unknow Schedule mode 17:00:55:624 ZCL attribute report 0x84FD27FFFEABBE91 for cluster: 0x0008, ep: 0x01, frame control: 0x08, mfcode: 0x0000 17:00:55:847 Tuya : Schedule command 17:00:55:849 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000c7600000c000000000000000000000000 17:00:55:851 Tuya debug 5 : Status: 0 Transid: 12 Dp: 118 (0x00,0x76) Fn: 0 Data 0 17:00:55:852 Tuya : Unknow Schedule mode 17:00:56:018 ZCL attribute report 0x84FD27FFFEABBE91 for cluster: 0x0300, ep: 0x01, frame control: 0x08, mfcode: 0x0000 17:00:56:056 Tuya : Schedule command 17:00:56:058 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00107200000c000000000000000000000000 17:00:56:060 Tuya debug 5 : Status: 0 Transid: 16 Dp: 114 (0x00,0x72) Fn: 0 Data 0 17:00:56:061 Tuya : Unknow Schedule mode 17:00:56:272 Tuya : Schedule command 17:00:56:274 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00147a00000c000000000000000000000000 17:00:56:276 Tuya debug 5 : Status: 0 Transid: 20 Dp: 122 (0x00,0x7A) Fn: 0 Data 0 17:00:56:277 Tuya : Unknow Schedule mode 17:00:57:825 ZCL attribute report 0x60A423FFFE536CB8 for cluster: 0x0008, ep: 0x01, frame control: 0x18, mfcode: 0x0000 17:00:57:990 ZCL attribute report 0x60A423FFFE536CB8 for cluster: 0x0300, ep: 0x01, frame control: 0x18, mfcode: 0x0000 17:00:59:708 ZCL attribute report 0x7CB03EAA0A024332 for cluster: 0x0006, ep: 0x03, frame control: 0x18, mfcode: 0x0000 17:01:00:060 Bind response success for 0x7cb03eaa0a06cc0c ep: 0x03 cluster: 0x0006 17:01:00:262 ZCL configure reporting rsp seq: 159 0x7CB03EAA0A06CC0C for ep: 0x03 cluster: 0x0006 attr: 0x0000 status: 0x00 17:01:04:765 ZCL attribute report 0x7CB03EAA0A06CC0C for cluster: 0x0006, ep: 0x03, frame control: 0x18, mfcode: 0x0000 17:01:04:949 binding for cluster 0x0006 of 0x5C0272FFFE5DD8D4 exists (verified by reporting) 17:01:04:953 skip configure report for cluster: 0x0006 attr: 0x0000 of node 0x5C0272FFFE5DD8D4 (seems to be active) 17:01:05:483 Bind response success for 0x5c0272fffe5dd8d4 ep: 0x01 cluster: 0x0000 17:01:05:547 ZCL configure reporting rsp seq: 164 0x5C0272FFFE5DD8D4 for ep: 0x01 cluster: 0x0000 attr: 0x4000 status: 0x00 17:01:06:797 ZCL attribute report 0xCC86ECFFFE499B04 for cluster: 0x0001, ep: 0x01, frame control: 0x08, mfcode: 0x0000 17:01:10:373 ZCL attribute report 0x60A423FFFE536B41 for cluster: 0x0300, ep: 0x01, frame control: 0x18, mfcode: 0x0000

[Smanar]

Ha ok, this PR is for future, to add new Tuya TRV using the DDF editor, your device is already in the code, so it need to work.

The temperature is this one

17:00:50:793 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000266020004000000e6
17:00:50:795 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 (0x02,0x66) Fn: 0 Data 230

0x02 0x66 > 23 degre. But it s during the inclusion, and it work for you at this moment. After 5/10 mn do you still have return like thoses one ?

And if you try to set yourself the heatpoint (using API, it work manualy), it work or not ? If not, nothing visible in logs ?

[jplahl]

it seems that status update are only send every 1 hours.

Setting heatsetpoint is working 18:26:06:821 Send Tuya request 0x04CD15FFFE100F22 : Dp_type: 0x02, Dp_identifier 0x67, data: 000000be 18:26:11:688 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 005e67020004000000be 18:26:11:690 Tuya debug 5 : Status: 0 Transid: 94 Dp: 615 (0x02,0x67) Fn: 0 Data 190 18:26:11:806 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 005e67020004000000be 18:26:11:808 Tuya debug 5 : Status: 0 Transid: 94 Dp: 615 (0x02,0x67) Fn: 0 Data 190 18:26:11:930 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 005e67020004000000be 18:26:11:933 Tuya debug 5 : Status: 0 Transid: 94 Dp: 615 (0x02,0x67) Fn: 0 Data 190 18:26:12:034 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 005e67020004000000be 18:26:12:037 Tuya debug 5 : Status: 0 Transid: 94 Dp: 615 (0x02,0x67) Fn: 0 Data 190

Setting locked is not working 18:28:36:944 Send Tuya request 0x04CD15FFFE100F22 : Dp_type: 0x01, Dp_identifier 0x07, data: 01 no response

Setting offset is working 18:30:30:519 Send Tuya request 0x04CD15FFFE100F22 : Dp_type: 0x02, Dp_identifier 0x1B, data: ffffffff 18:30:34:719 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00c71b020004ffffffff 18:30:34:721 Tuya debug 5 : Status: 0 Transid: 199 Dp: 539 (0x02,0x1B) Fn: 0 Data -1 18:30:34:836 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00c71b020004ffffffff 18:30:34:839 Tuya debug 5 : Status: 0 Transid: 199 Dp: 539 (0x02,0x1B) Fn: 0 Data -1 18:30:34:970 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 00c71b020004ffffffff 18:30:34:975 Tuya debug 5 : Status: 0 Transid: 199 Dp: 539 (0x02,0x1B) Fn: 0 Data -1

Also setting mode is working: heat -> auto 18:33:51:447 Send Tuya request 0x04CD15FFFE100F22 : Dp_type: 0x01, Dp_identifier 0x6C, data: 01 18:33:51:450 Send Tuya request 0x04CD15FFFE100F22 : Dp_type: 0x01, Dp_identifier 0x65, data: 01 18:33:51:965 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 001b6c01000101 18:33:51:968 Tuya debug 5 : Status: 0 Transid: 27 Dp: 364 (0x01,0x6C) Fn: 0 Data 1 18:33:52:196 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 001c6501000101 18:33:52:199 Tuya debug 5 : Status: 0 Transid: 28 Dp: 357 (0x01,0x65) Fn: 0 Data 1 18:33:54:307 ZCL attribute report 0x60A423FFFE53734F for cluster: 0x0300, ep: 0x01, frame control: 0x18, mfcode: 0x0000

[Smanar]

it seems that status update are only send every 1 hours.

So the temperature is updated but only every hour ? From my memory it's not something that can be changed ...

For the childlock can you change it manualy to compare the request 0x01 0x07 on your previous logs.

8:26:06:821 Send Tuya request 0x04CD15FFFE100F22 : Dp_type: 0x02, Dp_identifier 0x67, data: 000000be

In this exemple deconz is sending the tuya request 0x02 0x67

[jplahl]

The device has two different "temperature"

heatsetpoint -> desired temperature This is working. heatsetpoint can be set with the REST API and a manually change is received. This value is in the config section of the device

temperature -> measured temperature This is the actual measured temperature. This value is only set when adding the device and currently get never updated. This value is in the state section.

When I manually lock oder unlock the device nothing is logged.

[Smanar]

This value is only set when adding the device and currently get never updated

Ok so this one is not updated every hour.

After 1 hour of working mode (after inclusion), do you still have other report ? like

17:00:50:793 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000266020004000000e6
17:00:50:795 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 (0x02,0x66) Fn: 0 Data 230

If you don't make action on it, because it seem report are working if you change manualy the heatpoint. And I don't see why a manual action on childlock don't make report if changing heatpoint is working, you are sure for battery ?

[jplahl]

I think the device has a problem. I bought this device as a set with 2 thermostats and one gateway last week. Today I assigned the thermostat to the supplied gateway. After some minutes the gateway lost the connection to the device.

Batteries are fine, but I already replayed them to verify. Tomorrow I will try the second thermostat of the set.

[JanBackman]

I made a working SmartThings Groovy driver for this device about 1.5 years ago by simply modifying the standard Tuya Thermostat driver (Groovy) and fix the problem that this thermostat has the read temperature value off by a factor of 10x (if i rememer things correctly). So if we have a working generic Tuya driver for thermostats, then this should work. That was the only difference to the MOEs's driver that I also use.

Anyway, with that driver I get temperature updates regularly (as soon as the temperature changes and every minute):

Date	Name	Value	Units
2022-10-07 3:24 em CEST - 9 minuter sedan	temperature	15.1 C	C
2022-10-07 3:24 em CEST - 10 minuter sedan	temperature	15.2 C	C
2022-10-07 3:22 em CEST - 12 minuter sedan	temperature	15.1 C	C
2022-10-07 3:21 em CEST - 13 minuter sedan	temperature	15.2 C	C
2022-10-07 3:20 em CEST - 14 minuter sedan	temperature	15.1 C	C
2022-10-07 3:20 em CEST - 14 minuter sedan	temperature	15.2 C	C
2022-10-07 3:18 em CEST - 15 minuter sedan	temperature	15.1 C	C
2022-10-07 3:18 em CEST - 16 minuter sedan	temperature	15.2 C	C
2022-10-07 3:17 em CEST - 16 minuter sedan	temperature	15.1 C	C
2022-10-07 3:16 em CEST - 18 minuter sedan	temperature	15.2 C	C

I don't know if this helps, but it seems to answer some of the questions/postings from the thread at least,

[jplahl]

Now it took me longer to test different things. The devices are working fine. The reason why the devices with the Tuya Gateway were offline after a short time were blocked ports. Both the gateway and the app on the mobile phone require port activations because the gateway and the app are sending data to the Tuya cloud. Of course I don't like that at all.

So I again paired my devices to my conbee network.

Every hour the devices are sending data. As I understand it, various values are not yet implemented here. 19:00:53:568 Tuya : Schedule command 19:00:53:568 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000973000018000000000000000000000000151515151515150000000000 19:00:53:568 Tuya debug 5 : Status: 0 Transid: 9 Dp: 115 (0x00,0x73) Fn: 0 Data 0 19:00:53:568 Tuya : Unknow Schedule mode 19:00:53:738 Tuya : Schedule command 19:00:53:738 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 000d6e000018000000000000000000000000151416161515120000000000 19:00:53:738 Tuya debug 5 : Status: 0 Transid: 13 Dp: 110 (0x00,0x6E) Fn: 0 Data 0 19:00:53:738 Tuya : Unknow Schedule mode 19:00:53:965 Tuya : Schedule command 19:00:53:965 Tuya debug 4 : Address 0x04CD15FFFE100F22 Payload 001177000018000000000000000000000000000000000000000000000000 19:00:53:965 Tuya debug 5 : Status: 0 Transid: 17 Dp: 119 (0x00,0x77) Fn: 0 Data 0 19:00:53:965 Tuya : Unknow Schedule mode

As @JanBackman wrote the devices are sending the measured temperature if the value has changed 18:30:08:653 Tuya debug 4 : Address 0x540F57FFFEBC56DF Payload 000266020004000000e3 18:30:08:653 Tuya debug 5 : Status: 0 Transid: 2 Dp: 614 (0x02,0x66) Fn: 0 Data 227

@JanBackman I don't understand how you are made your devices working

[PastCoder]

Hi, great to see that work is progressing for this device. Could you already estimate how long it may take until it will be included in a (beta) release?

[jplahl]

I bought a second Conbee to trace the traffic between the HAMA device and gateway with zshark. I was able to add the support for lime protection (Kalkschutz) and the away function.

Enable limeprotection: 0x01 0x82 data::01:01 Disable lime protection: 0x01 0x82 data::01:00 away on: 0x01 0x6a data::01:01 away off: 0x01 0x6a data:01:00 Now I want to add the schedule/program function: This is an example of the command: 00:47: 6d:00:00:12: 43:07:01:2c:00:be:02:1c:00:a0:04:38:00:c8:05:28:00:a0

I did several configurations and change values and was able to decode: Monday: 0x01 Tuesday: 0x02 Wednesday: 0x04 Thursday: 0x08 Friday: 0x10 Saturday: 0x20 Sunday: 0x40

      command           day(s)     schedule 1     schedule 2        schedule 3        schedule 4

00:47: 6d:00: 00:12: 43:07: 01:2c:00:be: 02:1c:00:a0: 04:38:00:c8: 05:28:00:a0

When I try to send a command of the already implemented code I can see entries in the debug log but nothing in the wireshark trace: 17:48:09:633 Tuya data: 3430393839303430313230643031363038 17:48:09:634 Send Tuya request 0x04CD15FFFE100F22 : Dp_type: 0x00, Dp_identifier 0x70, data: 3430393839303430313230643031363038 17:48:09:690 0x04CD15FFFE100F22 error APSDE-DATA.confirm: 0xD0 on task

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[mrblur]

So.. I'm back. I gave up trying to build up development env for rest plugin under Gentoo, too modern. Configured WSL.

I'm commenting on this thread for two reasons:

1. That stupid bot trying to avoid making deconz more useful
2. I've been trying to work on that time sync issue having zero knowledge on tuya or zigbee.

@Smanar I've compared zigbee2mqtt time syncing code with deconz and noticed they use UTC time as relative number of seconds since 01-01-2000, and we use UNIX_EPOCH. There is J2000_EPOCH defined and seems to also be implemented, but you have changed it here . Do you recall, why?

I have setup a very limited DDF for my regulator so that I'm receiving current heatpoint, temperature and mode (well.. made it report heating status as mode, so it displays nice flame in HA 😅 ). But the time sync issue drives me crazy.

I patched today's master with J2000_EPOCH, waited until full on-device hour so that it triggered time syncing and... At 22 I got 00:00. When manualy set time to 21:59, on next sync it moved to 29. Seems like it's adding 7 hours. Funny thing, on J2000_EPOCH it actually changes the day of week displayed, with UNIX_EPOCH only the hour is wrong. Tried sending stdTime instead of timeNow but no luck - it's putting up the hour to 30 (on actual 22).

It seems it adds 7 or 8 hours, like mathematically and happily displays the result.

At time.cpp there is a link to tuya docs, but it is invalid, at least it doesn't open for me. Do you know if there is something extra to debug/dump/read to look for that 7 hour offset? Device's manual says nothing about setting time offset or timezone.

It is possible I bought a piece of garbage with broken firmware, but since I'd need to buy tuya gateway only to look for possible updates, I want to cross out deconz-related issue. Especially I'm convinced that on z2m the invalid clock actually jumped to right time right after the device joined its network.

Can you help me in in any way with this? :D

PS. What is wrong with the PR for broader TRV support, it is in the queue for months?

[Smanar]

Old topic ^^.

I have give up for the moment, waiting for the tuya support using DDF.

@Smanar I've compared zigbee2mqtt time syncing code with deconz and noticed they use UTC time as relative number of seconds since 01-01-2000, and we use UNIX_EPOCH. There is J2000_EPOCH defined and seems to also be implemented, but you have changed it here . Do you recall, why?

I can try to find the original issue, but it's from an user after snifff on the original gateway, but from my memory it's device dependent, it's for the that both are definied in the code UNIX_EPOCH and J2000_EPOCH.

with UNIX_EPOCH only the hour is wrong

It's not because the winter/summer hour ? IDK if it exist on your country ?

At time.cpp there is a link to tuya docs

In time.cpp ? You mean tuya .cpp ? and yes the path have moved https://developer.tuya.com/en/docs/iot/tuya-zigbee-module-uart-communication-protocol?id=K9ear5khsqoty

PS. What is wrong with the PR for broader TRV support, it is in the queue for months?

Yeah :( Idk how many users are waiting for it ... The good news is the next step in deconz will be TRV, so I realy hope for this PR. The DDF core will be improved too, so perhaps we will be able to use it for them.

Can you help me in in any way with this? :D

I m looking the device cluster list, are you sure this device use the tuya time sync ? He have too the time cluster. Z2M is using the tuya synch and effectively with J2000_EPOCH for this device

async function onEventSetTime(type, data, device) {
    // FIXME: Need to join onEventSetTime/onEventSetLocalTime to one command

    if (data.type === 'commandMcuSyncTime' && data.cluster === 'manuSpecificTuya') {
        try {
            const utcTime = Math.round(((new Date()).getTime() - constants.OneJanuary2000) / 1000);
            const localTime = utcTime - (new Date()).getTimezoneOffset() * 60;
            const endpoint = device.getEndpoint(1);

            const payload = {
                payloadSize: 8,
                payload: [
                    ...convertDecimalValueTo4ByteHexArray(utcTime),
                    ...convertDecimalValueTo4ByteHexArray(localTime),
                ],
            };
            await endpoint.command('manuSpecificTuya', 'mcuSyncTime', payload, {});
        } catch (error) {
            // endpoint.command can throw an error which needs to
            // be caught or the zigbee-herdsman may crash
            // Debug message is handled in the zigbee-herdsman
        }
    }
}

If I m right You can see value used by the code in logs

DBG_Printf(DBG_INFO, "Send Tuya command 0x%02X, data: %s\n", commandId, qPrintable(data.toHex()));

Can use the code

function convertDecimalValueTo4ByteHexArray(value) {
    const hexValue = Number(value).toString(16).padStart(8, '0');
    const chunk1 = hexValue.substr(0, 2);
    const chunk2 = hexValue.substr(2, 2);
    const chunk3 = hexValue.substr(4, 2);
    const chunk4 = hexValue.substr(6);
    return [chunk1, chunk2, chunk3, chunk4].map((hexVal) => parseInt(hexVal, 16));
}

OneJanuary2000 = new Date('January 01, 2000 00:00:00 UTC+00:00').getTime();
utcTime = Math.round(((new Date()).getTime() - OneJanuary2000) / 1000);
localTime = utcTime - (new Date()).getTimezoneOffset() * 60;

a = convertDecimalValueTo4ByteHexArray(utcTime),
b = convertDecimalValueTo4ByteHexArray(localTime),

window.alert('8,' + a  + ',' + b);

[mrblur]

I can try to find the original issue, but it's from an user after snifff on the original gateway, but from my memory it's device dependent, it's for the that both are definied in the code UNIX_EPOCH and J2000_EPOCH.

Yeah, now I figured out how to build, update and force time sync, I played a bit yesterday. With J2000_EPOCH also the day changes (rolls back by 1), with UNIX_EPOCH only the hour has 8 hours added.

It's not because the winter/summer hour ? IDK if it exist on your country ?

It does, but I'm at UTC+1/2 (depending on dst) and the diff is 8 hours from local. Unsuprisingly, that is China's offset to UTC, I'm starting to believe this has firmware borked and hardcodes something :/

At time.cpp there is a link to tuya docs

In time.cpp ? You mean tuya .cpp ?

Yeah, It was late yesterday :sweat_smile:

I m looking the device cluster list, are you sure this device use the tuya time sync ? He have too the time cluster. Z2M is using the tuya synch and effectively with J2000_EPOCH for this device

Well, I did change the code, resynced the time and got different results, so I'm saying: yeah, it uses tuya time sync :) Could it be it gets confused on getting time synced two times? :thinking:

What got me more confused is that switching to J2000 made matter worse on my device as it also skewed the day of week :rofl:

I only have a single controller dongle, so it is not easy to turn off all the lights at home for playing with z2m again, I'll try to confirm it works/or not with z2m though :)

Meanwhile waiting for that DDF support :+1:

[Smanar]

I have put a JS code you can try on JS script online on previous post, it will be the data send by Z2M

Try to compare result with the one in deconz log ? Z2M use decimal value and deconz Hexadecimal

[mrblur]

I need to run the code on the device itself, I don't trust it anymore ;)

The docs you provided say:

Data | 8 | The time value is 8 bytes. It takes the format of 4-byte Unix timestamp + 4-byte local timestamp. (...) The Unix timestamp tracks time as a running count of seconds. The count begins at the Unix epoch on January 1st, 1970 at 00:00:00, so a Unix timestamp is the total seconds between any given date and the Unix epoch. The local timestamp is calculated by adding the time zone offset and DST to the Unix timestamp.

That's exactly what getTime used on tuya.cpp does.

[Smanar]

Yep, it's one of the the first TRV we have added "MRT 200" or something like that, an user have sniffed packet and we have reproduced it (and it's working for this device)

But it seem it's device specific, and some devices can use different values, and probably this one ...

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[github-actions[bot]]

As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.

[cagnulein]

any update on this device? I just bought it :(

[Mimiix]

@Smanar ?

[Smanar]

Can make a try with this DDF https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5844#issuecomment-1535190225

It seem both device use same DPID, except your device don't need the tuya unlock sequence.

{
  "schema": "devcap1.schema.json",
  "manufacturername": "_TZE200_2ekuz3dz",
  "modelid": "TS0601",
  "vendor": "Tuya",
  "product": "Tuya TRV",
  "sleeper": false,
  "status": "Gold",
  "subdevices": [
    {
      "type": "$TYPE_THERMOSTAT",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0xef00"
      ],
      "meta": {
        "values": {
          "config/mode": {"auto": 0, "heat": 1, "off": 3}
        }
      },
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "state/lowbattery",
          "parse": {"fn": "tuya", "dpid": 35, "eval": "Item.val = Attr.val != 0"},
          "read": {"fn": "none"}
        },
        {
          "name": "config/heatsetpoint",
          "parse": {"fn": "tuya", "dpid": 16, "eval": "Item.val = Attr.val * 10;"},
          "write": {"fn": "tuya", "dpid": 16, "dt": "0x2b", "eval": "Item.val / 10;"},
          "read": {"fn": "tuya"}
        },
        {
          "name": "config/locked",
          "parse": {"fn": "tuya", "dpid": 40, "eval": "Item.val = Attr.val;"},
          "write": {"fn": "tuya", "dpid": 40, "dt": "0x10", "eval": "Item.val;"},
          "read": {"fn": "none"}
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "config/mode",
          "values": [
              ["auto", 0], ["heat", 1], ["off", 3]
          ],
          "parse": {"fn": "tuya", "dpid": 2, "eval": "if (Attr.val == 0) { Item.val = 'auto' } else if (Attr.val == 1) { Item.val = 'heat' } else { Item.val = 'off' }"},
          "write": {"fn": "tuya", "dpid": 2, "dt": "0x30", "eval": "if (Item.val == 'auto') { 0 } else if (Item.val == 'heat') { 1 } else { 3 }"},
          "read": {"fn": "none"}
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/temperature",
          "parse": {"fn": "tuya", "dpid": 24, "eval": "Item.val = Attr.val * 10;"},
          "read": {"fn": "none"}
        }
      ]
    }
  ]
}

[cagnulein]

sure @Smanar , thanks! do you have a link of a guide that can i follow to use this DPID? sorry for the n00b question :(

[cagnulein]

ok I found this https://forum.phoscon.de/t/how-to-add-edit-a-ddf-on-home-assistant-using-text-editor/1839 Let me try to add your file now

[cagnulein]

@Smanar it worked! should I create a PR adding also this device?

[Smanar]

Sure you can. Just use a better title than "Create _TZE200_TS0601_thermostat.json" ^^. And if you can add the device type and the manufacture name in the file ? Like "_TZE200_bvu2wnxz_trv.json"

[cagnulein]

ok i can do it the next week

[sonny608]

Hi. How am I able to control the head using MQTT Explorer? I tried "iobroker/deconz/0/Sensors/11/heatsetpoint" "iobroker/deconz/0/Sensors/11/heatsetpoint/set" "iobroker/deconz/0/Sensors/11/heatsetpoint/cmnd" "iobroker/deconz/0/Sensors/11/heatsetpoint/command" with no effect. Does anyone know the commands used by MQTT to change the temperature, turn on/off the device?

[sonny608]

Hi. How am I able to control the head using MQTT Explorer? I tried "iobroker/deconz/0/Sensors/11/heatsetpoint" "iobroker/deconz/0/Sensors/11/heatsetpoint/set" "iobroker/deconz/0/Sensors/11/heatsetpoint/cmnd" "iobroker/deconz/0/Sensors/11/heatsetpoint/command" with no effect. Does anyone know the commands used by MQTT to change the temperature, turn on/off the device?

I used the solution on the website: "https://www.zigbee2mqtt.io/devices/TS0601_thermostat_3.html". Still does not work

[Smanar]

Deconz don't use MQTT, but a native REST protocol.

You need to send a body {"heatsetpoint":12} at the endpoint http://IP:PORT/api/API_KEY/sensors/ID/state

https://dresden-elektronik.github.io/deconz-rest-doc/getting_started/

[sonny608]

I followed your advice, but unfortunately it still didn't do anything

[Smanar]

Ops, sorry my bad, it's not "state", but "config"

http://IP:PORT/api/API_KEY/sensors/11/config

[sonny608]

Changing from "state" to "config" helped with the on/off change. Changing the temperature via {"heatsetpoint":12} does not work yet.

[Smanar]

You still have the error message "parameter not available" ? Try with 1200 instead of 12

[sonny608]

its working, thank you :) 👍