Decoding Watts Vision thermostats

[floe]

Hi everyone,

I'm trying to build a decoder for the Watts Vision thermostats (see bottom of post for a picture to avoid confusion with other Watts models).

I'm writing this issue both as a kind of memory aid for myself, and also to illustrate where I got stuck.

Here's what I know:

• This is not the same device as in Help decoding Watts Thermostat #2230
• It's on 868.3 MHz and uses the Texas Instruments CC110L transceiver.
• The transceiver can do 2-FSK, 2-GFSK, OOK, and 4-FSK.

So I recorded a couple of samples with an RTL2832 SDR (Elonics E4000 tuner) and a random old DVB antenna using:

rtl_433 -g 10 -f 868.25M -s 2M -S unknown

I had initially used autogain, but that apparently clipped the signal pretty badly, so I arrived at that gain setting using some trial and error.

When I upload the files to triq.org, I get (e.g.) the following signal:

g011_868.25M_2000k.cu8.gz

To my untrained eye, this looks pretty much like GFSK.

After some more fiddling, I came up with a general-purpose decoder for testing (I had read in another issue that GFSK may be a bit tricky to decode and should use the minmax detector - neither auto nor classic worked).

rtl_433 -g 10 -f 868.25M -s 2M -X "name=WattsVision,m=FSK_PCM,s=26,l=26,r=500,preamble={8}55" -Y minmax

And this is the point where I'm currently stuck on some issues (which may well be due my limited RF background knowledge):

• The decoded length isn't constant, it's sometimes 238 bits, sometimes 239, 240, or 244.
• AFAICT from the datasheet, the preamble should be 0xAA, but here it's always 0x55. Is this just a matter of convention?
• I would assume the preamble to be longer, 4 bytes based on what I can count in the spectrum view, but the decoder almost never actually sees 4 times 0x55.

So, am I actually going in the right direction with my approach, or am I rather barking up the entirely wrong tree?

P.S. Picture of thermostat in question:

[zuckschwerdt]

Well researched and the conclusions are sound.

A 55 is nearly the same as aa, just shifted by one bit.
With FSK it's likely to get some garbage bits at end.
You want to include the syncword at the end of the preamble to "anchor" it.

There are bit errors in the preamble, it is longer than it seems. And by shifting the code a few bits we can spot the common syncword of d391 d391. Try preamble=aad391d391, you get something like in this BitBench.

[klohner]

I'm seeing rtl_433's decode dropping a bit every now and again, 4 bits total over the signal, when comparing to a URH decode. I'm not sure why or how to prevent it with the flex decoder. I think the 26µ symbol width is correct.

rtl_433 -r g011_868.25M_2000k.cu8 -X n=WattsVision,m=FSK_PCM,s=26,l=26,r=500 -Y minmax
{243}55556aab4e474e445342826c4e3681ba3540301df00110200760192182c0e

URH decode, I get:
{248}aaaaaaaad391d39114d0904d89c6d03746540301df001101003b00c90c1607
(or shifted a bit to align with the start of rtl_433's decode:
{247}55555555a723a72229a1209b138da06e8ca80603be00220200760192182c0f)

BitBench

[floe]

Try preamble=aad391d391, you get something like in this BitBench.

Brilliant, thank you! That would probably have taken me a while to spot the repeated sync word 😅

This works, I'll put a bunch of captures into BitBench and fiddle with them a bit to see if I can figure out the relevant fields and CRC.

I'm seeing rtl_433's decode dropping a bit every now and again, 4 bits total over the signal, when comparing to a URH decode. I'm not sure why or how to prevent it with the flex decoder. I think the 26µ symbol width is correct.

Good to know about the symbol width. Can you recommend a starting point for writing a "full" decoder? How would you work around the dropped bits?

[klohner]

Regarding dropped bits, I think this is a weaker signal and the gain on the recording is high. I'd try maybe using -s 1024k to collect the signal to see if that helps. I might also try positioning the transmitting device a few cm from the SDR with its antenna disconnected to see if that helps improve the signal quality.

[klohner]

Maybe a coincidence since I've only seen 1 sample, but, removing the prefix, the last byte might be "CRC-8/DVB-S2":

$ reveng -w 8 -s 14d0904d89c6d03746540301df001101003b00c90c1607
reveng: warning: you have only given 1 sample
reveng: warning: to reduce false positives, give 4 or more samples
width=8  poly=0xd5  init=0x00  refin=false  refout=false  xorout=0x00  check=0xbc  residue=0x00  name="CRC-8/DVB-S2"

BitBench

[floe]

According to the CC110L datasheet, it does CRC-16 in hardware... but I haven't found a match with reveng yet (awesome tool BTW).

Lower sample rate was a good idea, thanks, here's a few samples I collected with rtl_433 -g 8 -f 868.25M -s 1M -X "name=WattsVision,m=FSK_PCM,s=26,l=26,r=500,preamble=aad391d391" -Y minmax:

14d0904d89e6d03715c10304df001100003b0010e73b58
14d0904d89c6d03745900302df001100003b00c34852fc
22d0374654c6d0904d898d0011008a02f0034b02c4cc00000
22d0374654c6d0904d898d0011018a0285034b02c6cc00000

But still no CRC matches AFAICT.

[klohner]

Great. It would still be useful to look at .cu8 files to verify decodings if you're able to post those as well.

[floe]

Sure, here's a few captures and what I currently know about them:

[Bathroom]
14d0904d89c6d03715c10304df001101003b00111b4750  [current 22.0, target 20.0 (heating off) g001_868.25M_1000k.cu8] 
14d0904d89c6d03746550307df001108003b001b7fc3280 [current 22.1, target 22.0 (heating off) g002_868.25M_1000k.cu8]  
14d0904d89c6d03715c10304df001100003b0010e73b58  [current 22.2, target 22.0 g003_868.25M_1000k.cu8] 

samples.zip

It's been trickier than expected to only capture a single sensor, because everyone in the house has the same ones and they're hardwired to a floor sensor, so you can't remove them. I'll try moving the SDR antenna around and putting it close to a sensor next.

[floe]

Oh, so I just noticed that some of the messages occasionally also get decoded as Marlec-Solar!

That explains quite a bit. Now I know that the CRC is "CRC-16/CMS" according to reveng, and also that a lot of the samples I've been capturing apparently still have bit errors, because there was no CRC match across them. Also, the first byte is a length byte, which apparently is always 0x14 for the Watts devices AFAICT.

./reveng-3.0.5/reveng -w 16 -s 14d0904d89c6d03746540301df001101003b00c90c1607 14d0904d89c6d03715c10304df001100003b0010e73b58 14d0904d89c6d03715c10304df001101003b00111b4750 14d0904d89c6d03746550307df001108003b001b7fc328
width=16  poly=0x8005  init=0xffff  refin=false  refout=false  xorout=0x0000  check=0xaee7  residue=0x0000  name="CRC-16/CMS"

I think this should perhaps even work with a decoder { ... } definition, is that documented anywhere in more detail?

[klohner]

Great work! I think the next step is to collect more labeled samples and play around with identifying the data in BitBench. Here's a start: BitBench

Since you've uncovered the CRC and are now familiar with reveng, you can make sure data points are good before adding them to the BitBench.

[klohner]

Here's an interesting find - the 16 bits before the CRC-16/CMS are CRC-16/MODBUS on the bits after the initial length byte.

$ reveng -w 16 -s d0904d89c6d03746540301df001101003b00c90c d0904d89c6d03715c10304df001101003b00111b d0904d89c6d03746550307df001108003b001b7f d0904d89c6d03715c10304df001100003b0010e7
width=16  poly=0x8005  init=0xffff  refin=true  refout=true  xorout=0x0000  check=0x4b37  residue=0x0000  name="CRC-16/MODBUS"

BitBench

[floe]

Here's an interesting find - the 16 bits before the CRC-16/CMS are CRC-16/MODBUS on the bits after the initial length byte.

Trust issues, anyone? Seems like the CRC-CMS is done by the transceiver directly, and the CRC-MODBUS is done by the controller.

Here's a couple more captures with verified CRCs: BitBench

[floe]

BTW, if I want to try and write a decoder { ... } definition, what would I need to pick for the CRC type(s)? I've only seen one example in #2582 (comment) which uses CRC-16_1021_XMODEM, so is there also something like CRC-16_8005_CMS?

[zuckschwerdt]

That field is just a plain output, there is no processing. Some day we might add checksum validation options to the flex decoder, but there is nothing right now.

[floe]

Oh, new discovery: there's actually two message lengths, r=500 was too low. With r=1000, I get a bunch of 0x22 length messages as well (this is from setting the target temperature to 24˚C and thereby turning on the heating):

14 d0904d89 c6 d0374654 03 01df001101003b00 c90c 1607 [good]
22 d0374654 c6 d0904d89 8d 0011018a0284034b02bfcc000000008e0a24934c0000 310d 98a4 [good]
14 d0904d89 c6 d0374654 03 01df001100003b00 c8f0 6a0f [good]
22 d0374655 c6 d0904d89 8d 0010088a02cc004b02cfcc000000008e0a24934c0000 7492 faf3 [good]
14 d0904d89 c6 d0374655 03 07df001008003b00 26bf 4eb8 [good]

I'm pretty certain that the shorter messages are sent by the thermostat, and the longer ones are from the base station. That would also correspond to the first 12 bytes being source and destination address, respectively.

AFAICT Bitbench doesn't support different format strings for different lengths, though? That makes it a bit harder to see what's going on...

Bitbench

[floe]

P.S. I can't seem to spot anything in the data that corresponds to a sensible representation of the temperature value. 😕 The closest I've found is somewhere around offset 18 in the longer messages, but no matter what conversion factor I try, this doesn't really match the measured temperature nor the target temperature. Are there any experiences with other thermostat-type devices that also have odd value representation?

[zuckschwerdt]

What we usually recommend is to capture data over a longer period, say a day, while the value is slowly changing and observe that -- it should be easier to spot the lowest bit then.
But that is obviously only workable for outdoor-ish sensors and not for something that should mostly be fixed like your thermostat :/