Proposal to introduce SUPPRESS_UNPARSED build flag to suppress MQTT messages being published for unparsed signals

[DigiH]

While testing my OMG 0.9.6 setup with an 868Mhz CC1101 I found that the MQTT broker constantly receives messages from my many Homematic devices, as unknown/signal parsing failed

{"model":"unknown","protocol":"signal parsing failed","duration":72226,"signalRssi":-59,"pulses":146,"train":1,"messageCount":1,"_enabledReceiver":1,"receiveMode":0,"currentRssi":-90,"minimumRssi":-82}

etc.

Using a custom reduced definition for MY_DEVICES did help in bringing down these unrecognised messages a bit, but I thought it would be desirable to be able to completely suppress any unparsed signal from creating MQTT messages, so I came up with the following changes.

So setting the build_flag

'-DSUPPRESS_UNPARSED=true'

all recognised but unparsed signals do not get published, reducing the MQTT load.

Maybe you think this might be helpful to be included in your great rtl_433 OMG implementation.

Thanks

[NorthernMan54]

This is a good improvement Tks. Could you a comment to the README to document the setting?

Also are they noise and possibly MINRSSI is set too low, or just signals that can’t be decoded?

Should this also be a real time setting as well?

[DigiH]

Could you a comment to the README to document the setting?

Sure, I can also comment in the README docs, once we finalise how it should be included.

Also are they noise and possibly MINRSSI is set too low, or just signals that can’t be decoded?

It's very clear that most, if not all, are encrypted signals from all my Homematic devices which cannot be decoded. I double checked with serial monitoring and compared with the Homematic log, as much as I can, as my neighbours also radio in with their Homematic devices ;)

Should this also be a real time setting as well?

I suppose so, now that you mention it, as some people only use the prebuilt OMG binaries and don't have the setup for custom builds. For them to be able to change this setting by sending a command at runtime would be handy.

Maybe @1technophile can also chime in about the need for this to be MQTT command accessible?

I've only tested this with my 868Mhz setup so far. Once I get my 433Mhz CC1101s I'd like to do some more testing, especially seeing if and how existing 433Mhz OMG gateway signals are being processed, possibly also creating "model":"unknown","protocol":"signal parsing failed" messages?!?

BTW - On a side note: is it possible to define MY_DEVICES at build time as a flag, or is it only possibly with a local or forked version with amended rtl_433_ESP.cpp and rtl_433_devices.h?

Thanks

[NorthernMan54]

MY_DEVICES are my personal devices and with the current build process it needs to be defined prior to build, so you would need to use a local or forked copy if you don't like my device choice ;-). I was using this when I was dealing with memory leaks and constant stack overflows to get something stable enough to test with. Once I had everything stable I stopped using the flag.

Am thinking the default should mimic the RTL_433 behaviour which is too not indicate failed decodes, and have a runtime switch and a build flag to change the behaviour. Possibly tied into enabling decoder debug/verbose mode.

[DigiH]

MY_DEVICES are my personal devices and with the current build process it needs to be defined prior to build, so you would need to use a local or forked copy if you don't like my device choice ;-)

I have already tested that here, as even with the above '-DSUPPRESS_UNPARSED=true' I sometimes, but regularly, get a recognition of

{"model":"Skylink HA-434TL motion sensor","motion":"false","id":"00000","raw":"00000","protocol":"Skylink HA-434TL motion sensor","rssi":-80,"duration":421314}

where I'm pretty sure that there is not such device anywhere near me, and the fact that it only ever produces "motion":"false" messages supports the theory that it is a misreccognised Homematic signal as well.

Therefor I was thinking about using the MY_DEVICES option as a personal white-list to avoid such miss-parsed messages. Only available through the above mentioned options, which is fair enough.

Also, since the Skylink HA-434TL decoder probably comes straight from the rtl_433 package, it is probably an issue to log there, once I can reliably reproduce this, knowing from which Homematic sensor(s) this comes from.

[NorthernMan54]

The Skylink HA-434TL decoder is something I injected to the build as it wasn't supported by rtl_433. I have a bunch of these and had been running a custom build of rtl_433 with it added. Looks like it has too many false positives.

[DigiH]

The Skylink HA-434TL decoder is something I injected to the build as it wasn't supported by rtl_433. I have a bunch of these and had been running a custom build of rtl_433 with it added. Looks like it has too many false positives.

Ah ok, didn't even look that closely where it came from, was just an assumption with it coming straight from the rtl_433 package :)

I'll probably keep a fork here in the end with my own MY_DEVICES list for my builds, which will include the acurite_986, which I got inspired from from your list. I just hope that the look-alike version I ordered here is compatible.

[1technophile]

Maybe @1technophile can also chime in about the need for this to be MQTT command accessible?

I would deactivate it by default for the builds and take the assumption that users interested in decoding the protocol have the level to use PIO or Arduino IDE, and activate it themselves.