False Positives with Oregon Scientific SL109H

[evilpete]

I've noticed I was receiving a lot of of "hits" for the Oregon Scientific SL109H device across multiple frequencies, after taking a closer look it seems that any packet with a length of 38 bits and comprised of all zeros is reported as a valid packet ( the "checksum" is calculated by simple addition of 5 nibbles ).

Suggested fix: add a simple sanity check to reject packet with something like the following:

IF  Id == temp_raw == humidity == channel == 0
   Reject_packet() 

(What are the odds of having Id humidity and channel be all be zero?) If this is an acceptable work around I'll generate a pull request...

This can be easily reproduced with :

rtl_433 -R 54 -y "{38}0000000000" or rtl_433 -R 54 -y "{38}ff000000000". (not all zeros)

time      : 2020-07-24 23:52:37
Model     : Oregon-SL109H Id        : 0
Channel   : 3            Celsius   : 0.00 C        Humidity  : 0 %           Status    : 0             Integrity : CHECKSUM

Actual Received Packet:

time      : 2020-07-24 23:38:18
Model     : Oregon-SL109H Id        : 0
Channel   : 3            Celsius   : 0.00 C        Humidity  : 0 %           Status    : 0             Integrity : CHECKSUM
Modulation: ASK          Freq      : 910.0 MHz
RSSI      : -12.1 dB     SNR       : 7.5 dB        Noise     : -19.7 dB
pulse_demod_ppm(): Oregon Scientific SL109H Remote Thermal Hygro Sensor
bitbuffer:: Number of rows: 2
[00] {38} 00 00 00 00 00             : 00000000 00000000 00000000 00000000 000000
[01] {68} 00 00 00 00 00 00 00 00 00

[evilpete]

Here is a list of decoders found, I'll generate a pull request for solve these:

Protocol	Name
21	Calibeur-RF104
47	Conrad-S3318P
49	Quhwa-Doorbell
54	Oregon-SL109H
68	Kerui-Security
84	Thermopro-TP11
108	Hyundai-WS
115	Honeywell-ActivLink
116	Honeywell-ActivLink
121	Opus-XT300
137	GT-TMBBQ05
149	ERT-SCM
151	Visonic-Powercode

** IKEA Sparsnäs generates a json report with '-vvv' option, even though the behavior is unique, I am not considering it a bug

{"time" : "2020-07-25 16:28:37", "protocol" : 130, "msg" : "IKEA Sparsnäs", "num_rows" : 1, "codes" : ["{10}000"]}

---

Update: here is a simple test script to detect the problem (@zuckschwerdt : feel free to add rtl_433_test )

(edit rtl_433 path in test_zero.sh first)

test_zero.sh script will generate test data file count_zero.txt, run rtl_433 writing results to zero_out.json, then sort/unique/print results (requires jq command )

pkt_fill_tests.zip

Files:

• test_zero.sh runs all commands for test, results to stdout
• gen_zero.py generates test data for file count_zero.txt
• count_zero.txt test data generated by gen_zero.py
• zero_out.json rtl_433 output
• zero_out.stderr rtl_433 stderr

[evilpete]

Update # 2 : added simular test with 0xff packet data :

Protocol	Name	0x00	0xff
19	Nexus-TH		X
21	Calibeur-RF104	X	X
47	Conrad-S3318P	X
49	Quhwa-Doorbell	X
50	Oregon-v1		X
54	Oregon-SL109H	X
68	Kerui-Security	X
84	Thermopro-TP11	X	X
87	Generic-Motion		X
95	Schrader-EG53MA4	X
108	Hyundai-WS	X	X
114	Maverick-ET73		X
115	Honeywell-ActivLink	X	X
116	Honeywell-ActivLink	X	X
121	Opus-XT300	X
131	Microchip-HCS200		X
135	Philips-AJ7010		X
137	GT-TMBBQ05	X
149	ERT-SCM	X
151	Visonic-Powercode	X
152	Eurochron-EFTH800		X

Test files:

test_0xff.sh
gen_0xff.py
count_0xff.txt 
0xff_out.json

[evilpete]

Fixed in Pull Request #1444

[Mindavi]

Thanks for fixing this. If this is not fully resolved, feel free to reopen and explain :).