Tuya Zigbee TRV

🚧 Developers Broken-code
1

Ill open this up saying i have no idea what im doing with zigbee.
I have hacked up a driver which is successfully receiving and decoding the data from the TRV. Now i am trying to send a command back to the device, but am unable to write in in such a way that HE will send it.
Ive found this in pythoon, but the data dsont aline perfectly with what ive been receiving

This is the data from the device in regard to its mode, with the last be in the mode its in
tuya mode 0404, raw=[raw:catchall: 0104 EF00 01 01 0040 00 3E03 01 00 0000 01 01 445F0404000102, profileId:0104, clusterId:EF00, clusterInt:61184, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:3E03, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:01, data:[44, 5F, 04, 04, 00, 01, 02]] data=[44, 5F, 04, 04, 00, 01, 02]

this is the code todate

but basicly i want to know how to format and send a zigbee message
Thanks

2

Anyone, how do I format a raw zigbee message

3

This post has some good information on raw messages:

I took on a different tactic and looked for drivers that relate to Tuya specific drivers:

Specifically pilfering from:

This has lead to me using:

def setHeatingSetpoint(preciseDegrees, delay = 0) {
	if (preciseDegrees != null) {
		def degrees = new BigDecimal(preciseDegrees).setScale(1, BigDecimal.ROUND_HALF_UP)

		log.debug "setHeatingSetpoint({$degrees} ${temperatureScale})"
        
        sendEvent(name: "heatingSetpoint", value: degrees, unit: temperatureScale)
    	sendEvent(name: "thermostatSetpoint", value: degrees, unit: temperatureScale)
        
        sendTuyaCommand("0202", "00", "00000000"+zigbee.convertToHexString(preciseDegrees.intValue() * 10, 2))
	}
}

private rand(n) {
	return (new Random().nextInt(n))
}

private getCLUSTER_TUYA() { 0xEF00 }
private getSETDATA() { 0x00 }

private sendTuyaCommand(dp, fn, data) {
	log.info "${zigbee.convertToHexString(rand(256), 2)}=${dp},${fn},${data}"
	zigbee.command(CLUSTER_TUYA, SETDATA, "00" + zigbee.convertToHexString(rand(256), 2) + dp + fn + data)
}

I can now set the setpoint of the TRV from Hubitat. Will play some more when I have time.

The python code you show generates a payload and issues a zigbee command using that data which I suspect can be translated across to hubitat to some extent:

4

update, now have mode working,
still to do

  • heating setpoint
  • battery reporting
  • refresh

https://raw.githubusercontent.com/Mark-C-uk/Hubitat/master/Zigbee-Tuya-TRV

ran out of non-family time

2 Likes
5

Fantastic!

I'll take a look later and have a fiddle a bit more - I'm wanting to see if I can get the child lock working on these too.

1 Like
6

Have to look at logs when you lock it on the device (if you can)

7

I've not worked out how to do it from the device, think its remote (app) only

Edit: Think I have it working, will play a bit more tomorrow and report back.

8

OK so I have child lock working. The "child lock" in the setup is A3 under the advanced options, I've then got the following code to parse the lock event:

case '0701':
String locked = HexUtils.hexStringToInt(data[6])
logging("tuya lock ${commandType}, raw=${msgMap} data=${data} ,dec=${mode}")
switch (locked){
    case '0':
        sendEvent(name: "childLock", value: "off" )
    break
    case '1':
        sendEvent(name: "childLock", value: "on")
    break
}
break

I can't get anywhere with the battery reporting at all.
I have the set point code working but only when it's already in "heat" mode.

1 Like
9

Hi, I never used a thermostat device in HE, so it is unclear to me how to use it.
I'm still waiting for receiving the device. Googling I see that it has an internal scheduler based on time windows. The thermostat HE apps seems working differently (mode based, afaik). Is it possible to overwrite the internal scheduler using a time window approach?
Which is the latest version of the ongoing driver?
Thank you

10

You would effectively run it in manual mode with HE sending the temp setpoints at times you wanted

11

Can you send code for setpoints and ill merge it in.
OFF is effectively away mode setpoint,

12

ok. It make sense and it is the simplest option. It would be great If the driver would be able to set the trv internal scheduler. It would not require any rule and t would save some work to the hub

13

I will do a PR once I've cleaned it up a bit.

Holding +/- when it is locked will unlock it. Holding - when it is unlocked will lock it.

When unlocked, holding +/- will put it into boost mode.

Events 6602 and 6702 (or 0x02 0x67 and 0x02 0x66 as I think they actually are) represent the maximum and minimum points (A4 and A5 config entries):

dev:2592020-12-11 13:36:58.533 debugother tuya cluster EF00 - 6702 - [12, 253, 103, 2, 0, 4, 0, 0, 0, 35]
dev:2592020-12-11 13:36:58.443 debugother tuya cluster EF00 - 6602 - [12, 252, 102, 2, 0, 4, 0, 0, 0, 5]

I note when playing with the onboard schedule there are 7000 and 7100 entries sent when changing the minutes for the time block boundaries. I need to spend more time with the logs to work out what is what.

14

Absolutely, Thermostat Scheduler can be setup using time base by adding modes just for the scheduler and you set the times those modes change in the mode manager. So I have all the regular modes and then I have thermostat modes, whenever we set the system to away, we use that mode to set thermostats in ECO state that will bring all temps 3 degrees less.

I also have a away for a long time button that sets all thermostats to 10°C and set it to HOLD, then when we are a few hours from returning home, we just flip that virtual switch and it sets all thermostats back to the scheduler settings.

15

(A1 setting change) Temperature correction reporting:

EF00 - 2C02 - [13, 170, 44, 2, 0, 4, 0, 0, 0, 20] => 22 degrees
EF00 - 2C02 - [13, 211, 44, 2, 0, 4, 255, 255, 255, 246] => 19 degrees

(A2 setting change) Open window setting:

EF00 - 6800 - [13, 237, 104, 0, 0, 3, 0, 5, 10] => off, 5 degrees, 10 minutes
EF00 - 6800 - [13, 241, 104, 0, 0, 3, 1, 5, 10] => on, 5 degrees, 10 minutes
EF00 - 6800 - [13, 245, 104, 0, 0, 3, 1, 6, 10] => on 6 degrees, 10 minutes

(A3 setting change) Lock mode reporting:

EF00 - 7401 - [14, 16, 116, 1, 0, 1, 1] => on
EF00 - 7401 - [14, 16, 116, 1, 0, 1, 0] => off

(A6 setting change) Boost:

EF00 - 6902 - [14, 64, 105, 2, 0, 4, 0, 0, 1, 144] => 30 on the TRV (300 seconds)

Device schedule setting:

EF00 - 7000 - [14, 136, 112, 0, 0, 18, 11, 13, 23, 13, 15, 15, 13, 16, 15, 13, 17, 15, 17, 30, 20, 22, 0, 15]

11:13 -> 23
13:15 -> 15
13:16 -> 15
13:17 -> 15
17:30 -> 20
22:00 -> 15

7100 is the second period (i.e. this is in 5+2 mode), there is 6+1 and 7 too

Battery is tres elusive

16

thought 0701 was lock but late you have?

17

7401 relates to me going into the device settings and changing the automatic lock (i.e. A3 setting).

0701 relates to when the device locks/unlocks.

Could have been clearer, was just wanting to disseminate information found

18

these as the have come from device or have they been converted from hex to decimal?

19

These are as decimal.

I've just been reading through this that I found on Github, it's a huge topic but this table is interesting:

Suggestion is that 6E01 is a low battery indicator as per on the device.

Edit: This is also a fantastic function:

20

do you know how to convert a number into hex string, stuggling with setpoint