New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decoding Watts Vision thermostats #2885
Comments
Well researched and the conclusions are sound. A 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 |
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.
URH decode, I get: |
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.
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? |
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. |
Maybe a coincidence since I've only seen 1 sample, but, removing the prefix, the last byte might be "CRC-8/DVB-S2":
|
According to the CC110L datasheet, it does CRC-16 in hardware... but I haven't found a match with Lower sample rate was a good idea, thanks, here's a few samples I collected with
But still no CRC matches AFAICT. |
Great. It would still be useful to look at .cu8 files to verify decodings if you're able to post those as well. |
Sure, here's a few captures and what I currently know about them:
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. |
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
I think this should perhaps even work with a |
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. |
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 |
BTW, if I want to try and write a |
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. |
Oh, new discovery: there's actually two message lengths,
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... |
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? |
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. |
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:
So I recorded a couple of samples with an RTL2832 SDR (Elonics E4000 tuner) and a random old DVB antenna using:
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).
And this is the point where I'm currently stuck on some issues (which may well be due my limited RF background knowledge):
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:
The text was updated successfully, but these errors were encountered: