Reduce spurious Secplus-V1 receptions from the radio environment

[sheilbronn]

In my suburb radio environment I get several rare decodings (pickups) for the Secplus-V1 protocol.

Since these decodings don't seem sensible to me, I'm putting up for discussion some more sanity checks for this decoder, e.g.:

Don't decode successfully, if ...

1. ... the reception is on a frequency >433MHz (but rather in 310, 315 or 390 MHz as described in devices/secplus_v1.c), or ...
2. ... the resulting id is a negative integer (or is that allowed on purpose?), or ...
3. ... the resulting id is larger than 65535 (or is that allowed on purpose?).

These suggestions are based on the observations of receptions withe ther following prevalence in 5 days in my suburb environment:

openhabian@nextcloudpi:~/openhab/Secplusv1 $ sort S1 | uniq -c | sort -g   -b -k 3
      1 id: -78215037
      1 id: -78018215
      1 id: -77741954
      1 id: -76541753
      2 id: 0
      1 id: 18
      1 id: 34
      1 id: 51
      1 id: 53
      1 id: 152
      1 id: 153
      1 id: 203
      1 id: 243
      1 id: 254
     12 id: 263
      1 id: 296
      1 id: 549
      1 id: 1016
      1 id: 1478
      2 id: 1721
      1 id: 2006
      1 id: 2085
      1 id: 1186832
      1 id: 15485526
      1 id: 15543304
      1 id: 17028275
      1 id: 17028276
      1 id: 17395413
      1 id: 25156440
      1 id: 26979125
      1 id: 26980585
      1 id: 26980798
      1 id: 27090635
      1 id: 27280904
      1 id: 32293780
      1 id: 36361135
      1 id: 37004303
      1 id: 37340402
      1 id: 77807112

What do you think about this? Does that make sense?

[gdt]

It does make sense, but it's very tricky business to add rules that get rid of decodes you find spurious while not excluding valid signals from these devices that are different than the ones you experience. Stepping back, there are two aspects to your suggestions.

One is limiting to a frequency band that the devices are known to operate on. My impression is that we don't do that, but maybe we should. But, if you want to do this, then probably the decoder shouldn't be enabled by default. I don't see any kind of CRC/checksum on a quick scan.

The other is about id, and not being "negative" or too large. That's a clue that the true id field is smaller than how the decoder is written, and that the extra bits which are, by this theory, wrongly in the id field, really are a "must be zero". The decoder code is fairly complicated, and I'd encourage you to read it carefully and see if you can spot where it is doing something different from how you think it should, and try out your own version and work towards a PR.