Best practices for dealing with false detections as a user and/or in the code.

[homeautomaton]

We all see rtl_433 sometimes mis-categorize a transmission as coming from a different device, often making the reported data meaningless. Depending on your use case, and which protocols you use, this could range from a curiosity to a severe annoyance. I'd like to see ideas for how to improve both the way we use rtl_433, as well as suggestions for how to improve the program.

In the short time I've been using rtl_433, I've gotten some great advice from others and a few ideas of my own to share. If you post other solutions in the comments, I'll add them here to the list. Some of these ideas are mutually exclusive, others can be used together.

Ways to handle false detections, from a user's perspective

• Ignore them, if we're just observing transmissions for fun.
• Use just the more reliable protocols (on by default) and don't enable some of the others, prone to false positives.
• Turn off all protocols (-R 0), and re-enable just what's of known interest, to minimize false detections from other protocols.
• Effectively set priority by the order of re-enabling (-R nn), as each protocol will be checked in order (I think).
• Post process the data. Let rtl_433 produce all of its normal results, then filter (white-list) what's monitored downstream.

Ways to handle false detections in the code

• Some protocols with no checksum or CRC are disabled by default. Stick with this, unless they can be improved.
• All protocols that can, should use CRCs and checksums. (Is there a list of protocols that need work to do this?)
• Fine tune various message-length/other assertions used to eliminate false positives. (Need list of viable improvements?)
• Flex protocols have a user-settable priority. Should we extend this to built-in decoders to allow the user to specify?
• For some protocols, we could check repeated reports for consistency.
• We could add (more) sanity checks, even testing that a value, like temperature, is in a valid range (optionally).
• We could use historical data (from the stats/state data) to predict the likelihood that a decoder is only reporting false positives.
• And, possibly, dynamically re-order the priorities based on the stats/state data history.

[zuckschwerdt]

Priority level is different from plain order of protocols. All decoders in a priority "tier" will be run, only if there is no output then the next priority will run. This feature is pretty new and we could use it better.

[homeautomaton]

Can you confirm my assertion that the user has complete control if willing to "re-add" protocols in a specific order?

• Effectively set priority by the order of re-enabling (-R nn), as each protocol will be checked in order (I think).

[zuckschwerdt]

I don't think the order matters much. All decoders of a given priority will be run.

[homeautomaton]

So a single message could potentially report twice, if two different decoders see it as "theirs"? Or is there some other kind of arbitration as to which should be trusted?

[zuckschwerdt]

Yes, there can be multiple outputs from a single pulse data event.

[homeautomaton]

I think this is the comment (in r_api.c) which I misinterpreted. Once again, upon re-read, I see what you are saying:

    unsigned next_priority = 0; // next smallest on each loop through decoders
    // run all decoders of each priority, stop if an event is produced

The "stop" is for the priority level, not after any/each decoder. Could say "stop if any events are produced," given any priority might produce multiple events?

[homeautomaton]

Here is my "model" of how I think the detection and priorities currently works, from observing the operation of the program, and some very minimal familiarity with the code:

A list of protocols is generated at the beginning of the run, and this will generally determine the order which protocols are checked. Each protocol has some known factors about pulse widths and pulse-stream length, which will be used in the following step.

Each time a pulse stream is received, the list of protocols is traversed in order, looking for viable candidates given the pulse widths and stream length. Each protocol decoder that has no priority set will be called to give it a shot at decoding the transmission. The search ends at the first decoder which accepts the transmission. Only a transmission that is rejected by all decoders will pass on to the decoders with a priority set.

[rct]

[...] Each protocol decoder that has no priority set will be called to give it a shot at decoding the transmission. The search ends at the first decoder which accepts the transmission.

The last part seems surprising, implying that a false positive could prevent a successful decode in a different decoder. Interesting in knowing if this is correct or not.

[homeautomaton]

I'm learning that's not how it works. I'll have to revise the above description.

[rct]

Ways to handle false detections in the code

* We could add (more) sanity checks, even testing that a value, like temperature, is in a valid range (optionally).

There is a relevant discussion of this in #1964. It's under issues because I don't think discussions were available yet.

I added some sanity checking for a number of devices I use. This drastically cut down, but unfortunately did not completely eliminate, bad data occasionally making its way into my system.

If I ever got around to it, I would implement a consumer that would republish a sanitized feed for clients like Home Assistant and time series DBs. So far the problem the problem hasn't been enough of an annoyance.

[homeautomaton]

I use NodeRED to "sanitize" as you say.