Tuya Zigbee TRV

Hey @mark.cockcroft I just got the _TZE200_ckud7u2l TRV delivered from China (same as your's). Paired fine and I played with it all seems to be working fine in terms of temperature setting and temperature reporting. Valve position reporting works as expected as well.

The only thing that I see is slightly wrong is the battery reporting shows the battery at 116.666666
I'll come back in a day or 2 to see if it changes, but I'm wondering could the battery calculation be slightly wrong? The batteries I put in were fresh high quality ones, so I'm wondering if their voltage is higher than what you would have seen Mark

Strange don't know if I did something to mine during development but never got battery reporting working

Oh interesting. So you added the battery reporting code to the driver without getting it to work on your device?
I wonder then perhaps is it possible that mine didn't report the battery either and the driver just picked a "default" value to display?

Let me know if it changes

Hey Mark,

Would you be interested in me making some code changes to support the Moes TRV that I bought before buying the same one as you?

The Moes thermostat is supported by zigbee2mqtt and the parsing is documented here in the dataPoints (list or map? not sure the datatype name in javascript but that's not relevant):

In that decoding they actually seem to just ignore the MSB of the command. so hex 15 02 they ignore the 02 and 15 hex is 21 which is the battery command as decoded both by you and zigbee2mqtt

So I've managed so far to decode the internal temperature. The data encoding is the same as for your TRV except it's in a different commandType

18 02 which looking at the zigbee2mqtt file maps to 24 moesLocalTemp

Internal temperature logs

dev:952021-03-29 11:29:04.313 debugTRV other EF00 cluster - 1802 - [0, 24, 24, 2, 0, 4, 0, 0, 0, 249] [00, 18, 18, 02, 00, 04, 00, 00, 00, F9]
dev:952021-03-29 11:29:04.213 debugTRV other EF00 cluster - 1802 - [0, 24, 24, 2, 0, 4, 0, 0, 0, 250] [00, 18, 18, 02, 00, 04, 00, 00, 00, FA]

dev:952021-03-29 10:28:04.758 debugTRV other EF00 cluster - 1802 - [0, 24, 24, 2, 0, 4, 0, 0, 1, 3] [00, 18, 18, 02, 00, 04, 00, 00, 01, 03]
dev:952021-03-29 10:28:04.664 debugTRV other EF00 cluster - 1802 - [0, 24, 24, 2, 0, 4, 0, 0, 1, 4] [00, 18, 18, 02, 00, 04, 00, 00, 01, 04]
dev:952021-03-29 10:27:54.037 debugTRV other EF00 cluster - 1802 - [0, 24, 24, 2, 0, 4, 0, 0, 1, 3] [00, 18, 18, 02, 00, 04, 00, 00, 01, 03]

I've also managed to decode the setpoint temperature in commandType 10 02 it maps to command 16 moesHeatingSetpoint
This is encoded differently than the internal temperature. The data needs to be divided by 2

Setpoint temperature

dev:952021-03-29 11:22:29.855 debugTRV other EF00 cluster - 1002 - [0, 16, 16, 2, 0, 4, 0, 0, 0, 52] [00, 10, 10, 02, 00, 04, 00, 00, 00, 34]
dev:952021-03-29 11:22:13.878 debugTRV other EF00 cluster - 1002 - [0, 16, 16, 2, 0, 4, 0, 0, 0, 27] [00, 10, 10, 02, 00, 04, 00, 00, 00, 1B]

26 degrees data divided by 2 is temperature

dev:952021-03-29 11:30:19.273 debugTRV other EF00 cluster - 1002 - [0, 16, 16, 2, 0, 4, 0, 0, 0, 36] [00, 10, 10, 02, 00, 04, 00, 00, 00, 24]
18 degrees

But the thing I'm most excited about is that I was able to actually send data from Hubitat and get the TRV to update itself.
By hacking your code temporarily I got the setpoint on the TRV to change.

def setHeatingSetpoint(preciseDegrees) {
	if (preciseDegrees != null) {
        def dp = "1002"
        def fn = "00"
        def SP = preciseDegrees *2
        def X = (SP / 256).intValue()
        def Y = SP.intValue() % 256

        def data = "040000" + zigbee.convertToHexString(X.intValue(), 2) + zigbee.convertToHexString(Y.intValue(), 2)
	    log.info "heating setpoint to ${preciseDegrees}"
	    sendTuyaCommand(dp,fn,data)
	}
}

If you're happy for your driver to support multiple devices I can have a look at how Markus does it, and then inside setHeatingSetpoint() depending on the model that's used the correct data would be sent out.
I'll put in the time evenings at the weekend to implement it, I'd just need you to make sure you're happy with the changes.

I had to go back and edit the post as I mixed up the logs between internal temperature and setpoint

@daren_naylor - just for info if you select all the text in the log information you provided above and then click the right hand cog icon and select hide details it will fold the information into a one liner that can be expanded. Makes it much easier to read through the thread.

image

Look in here

like
this
does

1 Like

@abraham had a look at that driver from ST and it actually is very similar to my device _TZE200_zion52ef in terms of parsing commands. If myself and Mark can collaborate, there might be an update you can try that might work for you as well.

@mark.cockcroft something interesting in that driver from SmartThings, the second byte in commandType is actually used to described the data type. The various commandTypes make a lot more sense now

// tuya DP type
private getDP_TYPE_BOOL() { "01" }
private getDP_TYPE_VALUE() { "02" }
private getDP_TYPE_ENUM() { "04" }

The more help the better

1 Like

I'm not skilled enough to "code" anything, but I may contribute as a tester.

that's more than enough and sending back logs :slight_smile:

I hope to get some time this weekend to tidy the code up.
At the moment the code is working ok for me, but I broke the functionality for the original Tuya valve, so need to add model detection

@mark.cockcroft finished work early so I got a chance to tidy the code so that it now works for both TRVs.

The basic functionality is in the driver now for Moes TRV and if I get some more time I will pair both the Moes TRV and the one you have to my Tuya gateway and run a sniffer to see if I can figure out what some of the other packets are.

Edit: There's a pull request for you on GitHub. Let me know there if you've any comments. There might be one or 2 things you disagree with how I've done it but we'll find a solution

Seen it just not had time to look, I'd be interested in battery reporting packets when sniffing as mine is still 100% after 6 months!

yes will do that. My day job is an electronic engineer so I have a bench power supply and I should be able to make some sort of test rid to power it up via the bench power supply and vary the voltage.

So far with the model that we have in common I only see a battery report initially when putting the batteries in. It reports 35 in the data so that explains why with the current calculation that comes out at 35/3 * 10 = 116.666 %
I haven't seen any more logs apart from the initial one. I can get it to report it again by taking out the battery and plugging it back in.

I've corrected that in my local version, but as soon as I get a better sense of how the data is encoded I should be able to tell how the calculation is made.

No rush with the pull request. We all have work and personal lives :slight_smile:

1 Like

Hey @mark.cockcroft it looks like we've both been busy.
I've 3 more TRVs on the way. They were shipped from China to the Netherlands and now they're on the airplane to Ireland. When it arrives within a week or so I'll connect one to my power supply and have a look at the battery reporting.

Have you had a chance at all to look at the pull request?

No but thanks for reminder I had forgotten

Please provide link to current github. I'll gladly do some test on my TRV.

implemented the pull, done some testing and seem to still work ok ish.
just wish i could get reliable battery and temperature reporting

What issue are you having with the temperature reporting?
Mine seems to be working fine. I think

@abraham my changes are merged in so here's the github link

Have a try and see how you get on.
If setting the mode or the setpoint doesn't work, then it probably uses slightly different commands. I can tell you what line of code to modify to test the other commands instead.

It's been like that since I installed it, battery dosnt report and temperature is infrequent.
I must have done something when I was setting up and testing and developing the driver