Decoding Watts Vision thermostats about rtl_433 HOT 20 OPEN

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.

from rtl_433.

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.

from rtl_433.

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

from rtl_433.

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?

from rtl_433.

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.

from rtl_433.

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

from rtl_433.

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.

from rtl_433.

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

from rtl_433.

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.

from rtl_433.

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?

from rtl_433.

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.

from rtl_433.

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

from rtl_433.

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

from rtl_433.

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?

from rtl_433.

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

from rtl_433.

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?

from rtl_433.

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 :/

from rtl_433.

@floe What's the status and plan here?

from rtl_433.

I'd agree with @zuckschwerdt that we'd need captures over a long period labeled with the temperature readings to better attempt to decode the values in the signal.

FWIW, here's a rough flex decoder I put together which may help capture what we know so far. The one for the longer messages is a guess since I don't have any samples to test it on.

decoder {
    name          = WattsVision_20,
    modulation    = FSK_PCM,
    short         = 26,
    long          = 26,
    reset         = 1000,
    bits         >= 200,
    bits         <= 299,
    preamble      = aad391d391,
    get           = length:@0:{8}:%d,
    get           = id:@8:{32}:%08x,
    get           = dest:@44:{32}:%08x,
    get           = CRC-MDB:@152:{16}:%04x,
    get           = CRC-CMS:@168:{16}:%04x,
}
decoder {
    name          = WattsVision_34,
    modulation    = FSK_PCM,
    short         = 26,
    long          = 26,
    reset         = 1000,
    bits         >= 309,
    bits         <= 600,
    preamble      = aad391d391,
    get           = length:@0:{8}:%d,
    get           = id:@8:{32}:%08x,
    get           = dest:@44:{32}:%08x,
    get           = CRC-MDB:@264:{16}:%04x,
    get           = CRC-CMS:@280:{16}:%04x,
}

$ rtl_433 -Y minmax -r g011_868.25M_2000k.cu8

from rtl_433.

@floe What's the status and plan here?

Not much at the moment TBH... completely swamped with work. Hopefully will be able to look into this again around July. Any hints/extra captures very welcome!

from rtl_433.