Unable to read data output from Watchman Sonic Advanced

106 views
Skip to first unread message

Harpalyke

unread,
Sep 30, 2024, 3:24:47 PM9/30/24
to rtl_433
Hi,

I've recently got a watchman sonic advanced sensor added to my oil tank. 
Im getting data from the unit to the supplied receiver unit and now I'd like to use rtl_433 to read the signal and log the oil level out.

Admittedly Im new to rtl_433 so I may be doing something wrong but when I try and log messages using the command rtl_443 -R 324 I get the following output...

rtl_433 version 23.11-163-ge25cfc0f branch master at 202409200913 inputs file rtl_tcp RTL-SDR
[Protocols] Registered 1 out of 263 device decoding protocols
[Input] The internals of input handling changed, read about and report problems on PR #1978
[SDR] Found 1 device(s)
[SDR] trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Found Rafael Micro R820T tuner
[SDR] Using device 0: Realtek, RTL2838UHIDIR, SN: 00000001, "Generic RTL2832U OEM"
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
[SDR] Sample rate set to 250000 S/s.
[Input] Bit detection level set to 0.0 (Auto).
[SDR] Tuner gain set to Auto.
[Input] Reading samples in async mode...
[SDR] Tuned to 433.920MHz.
Allocating 15 zero-copy buffers
[Baseband] low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us

And no messages are logged after that. Even when I pass a magnet over the side of the device to trigger a reed switch which then gets the device to send data much more frequently I still dont see anything (I can see the receiver unit updating when I manually move the device after doing this so I know its transmitting).

I've also tried without the -R switch for the  protocol and I get output relating to all sorts of things like thermostats and tyre pressure sensors but nothing about the watchman.

I did come across someone mentioning this command in a thread online.

rtl_433 -X 'n=Plus,m=OOK_PCM,s=800,l=800,r=5000' -F json

This does produce output from the device. When I run it I can see data from the device being logged about every 500ms after I trigger the reed switch. However it does not output anything meaningful and just repeats the same value over and over (even when I am manually moving the sensor).

{"time" : "2024-09-30 19:20:46", "model" : "Plus", "count" : 1, "num_rows" : 1, "rows" : [{"len" : 130, "data" : "fffffffffffffffffffffffffffffff00"}], "codes" : ["{130}fffffffffffffffffffffffffffffff00"]}
{"time" : "2024-09-30 19:20:46", "model" : "Plus", "count" : 1, "num_rows" : 1, "rows" : [{"len" : 130, "data" : "fffffffffffffffffffffffffffffff00"}], "codes" : ["{130}fffffffffffffffffffffffffffffff00"]}
{"time" : "2024-09-30 19:20:47", "model" : "Plus", "count" : 1, "num_rows" : 1, "rows" : [{"len" : 130, "data" : "fffffffffffffffffffffffffffffff00"}], "codes" : ["{130}fffffffffffffffffffffffffffffff00"]}
{"time" : "2024-09-30 19:20:48", "model" : "Plus", "count" : 1, "num_rows" : 1, "rows" : [{"len" : 130, "data" : "fffffffffffffffffffffffffffffff00"}], "codes" : ["{130}fffffffffffffffffffffffffffffff00"]}
{"time" : "2024-09-30 19:20:48", "model" : "Plus", "count" : 1, "num_rows" : 1, "rows" : [{"len" : 130, "data" : "fffffffffffffffffffffffffffffff00"}], "codes" : ["{130}fffffffffffffffffffffffffffffff00"]}
{"time" : "2024-09-30 19:20:49", "model" : "Plus", "count" : 1, "num_rows" : 1, "rows" : [{"len" : 130, "data" : "fffffffffffffffffffffffffffffff00"}], "codes" : ["{130}fffffffffffffffffffffffffffffff00"]}
{"time" : "2024-09-30 19:20:49", "model" : "Plus", "count" : 1, "num_rows" : 1, "rows" : [{"len" : 130, "data" : "fffffffffffffffffffffffffffffff00"}], "codes" : ["{130}fffffffffffffffffffffffffffffff00"]}
{"time" : "2024-09-30 19:20:50", "model" : "Plus", "count" : 1, "num_rows" : 1, "rows" : [{"len" : 130, "data" : "fffffffffffffffffffffffffffffff00"}], "codes" : ["{130}fffffffffffffffffffffffffffffff00"]}
{"time" : "2024-09-30 19:20:50", "model" : "Plus", "count" : 1, "num_rows" : 1, "rows" : [{"len" : 130, "data" : "fffffffffffffffffffffffffffffff00"}], "codes" : ["{130}fffffffffffffffffffffffffffffff00"]}


Apologies if I've missed something obvious or am doing something silly here, but from what I've read in the docs both the protocols for both the watchman advanced and the original watchman should be supported in rtl_433.
As I mentioned at the start, Im just picking up rtl_433 so im finding it difficult to know how to start debugging this to figure out where im going wrong.
Any pointers would be greatly appreciated.

Christian Z.

unread,
Sep 30, 2024, 3:50:58 PM9/30/24
to rtl_433
It's a good start that you already located the signal and can reproduce it (trigger the sender).
The signal should be FSK and so the center frequency might be a problem (hitting a freq exactly will likely mute it) but it could also be some difference in protocol.
Best you grab a signal https://triq.org/rtl_433/ANALYZE.html and inspect it with https://triq.org/pdv/ -- or share it as zip if you need help.
The timings should be -X 'n=name,m=FSK_PCM,s=500,l=500,r=12500'
And you could try the -v option for more infos from rtl_433 and of course -Y autolevel -M level -M noise  to see levels. Also -Y minmax is maybe needed for FSK at 433.92 MHz

Harpalyke

unread,
Sep 30, 2024, 5:53:38 PM9/30/24
to rtl_433
Thanks very much, Christian. 
After reading through the docs, for the sake of convenience, I decided to perform the trace on my laptop instead of the raspberryPI that I had been running on thus far.

I've since built the code on my macbook and even looking at the raw output from the original timings I was originally using I saw an immediate difference in the data.
I then tried the "rtl_433 -R 234 -F json" command from the macbook and its now working fine.

Must be either something with the  raspberry pi OS image or a problem with the dependencies when I built the application on the PI.
Anyway, looks like its user error rather than something wrong with the signal :-)

I will try loading a debian image on there and rebuild the code again and see how it goes.

Thanks very much for your help!



Christian Z.

unread,
Sep 30, 2024, 6:22:41 PM9/30/24
to rtl_433
Glad to hear. It's recommended to always use a USB extension cord to get some distance to interference -- it's really helps with PIs. Also try the mentioned options to get a feel for the levels to check if reception is good.

Harpalyke

unread,
Oct 1, 2024, 2:40:17 PM10/1/24
to rtl_433
Thanks, Christian. I had seen some comments about interference from the chip for the USB port so already had it on a 1M usb extension just to be on the safe side.

I had rebuilt the code and saw similar results on the PI. Unfortunately though, I think my success was short-lived. 

When I force the device to transmit at more frequent intervals with the reed switch, I do see some decoded signals from the watchman. Once I added the minmax and autolevel options you suggested, I also see much more transmissions being logged. 
However once the device settles back into its usual mode of sending every 30 mins or so I'm not getting valid decoded data anymore. When I log traffic with rtl_433 -X 'n=Plus,m=OOK_PCM,s=800,l=800,r=5000' -Y minmax -Y autolevel -F json then I do see a couple of log lines every half hour but its not decoded as expected.

I think its probably something similar to whats being described in this comment github where only some of the signals are being decoded properly. https://github.com/merbanan/rtl_433/issues/2306#issuecomment-1784252409
In my case when I trigger the reed switch on the watchman it transmits so much data, some of the signals get properly decoded. When its in normal mode its only sending one update every 1/2 hour so the chances of it working are much slimmer.

Will do a bit more reading and see if I can try and understand how to inspect some captures.
Reply all
Reply to author
Forward
0 new messages