Just to give an example, my car key will send 3 or 4 MQTT messages. It would be nice if rtl_433 had a flag that meant it would "sleep" detection of a device for n milliseconds if it is detected. This would mean that a device that spams signals would only be detected once.
The guiding principle is to output everything that comes over the air fast and reliable. Coalescing events would introduce a lag. Pausing a decoder would need state, which decoders should not have.
It's not a bad idea as such, but needs to be generalized and designed well. Maybe something like token bucket rate limiting in the outputs.
I documented using this project here, to react to simple radio-buttons:
The only code change I made was to run an external program when a transmission was recognized, but I also made sure to do that only once per second. A very similar approach in the receiver could be used to do this - but I guess that @zuckschwerdt is right in saying that @merbanan wants to output __everything__.
I did consider sending a pull-request to allow (optional) limiting to once per second for all decoders, but I suspect that it would be rejected.
We can't have real coalescing (i.e. count the output) as that would introduce unwanted lag. But an option(!) to suppress repeats is ok in my mind -- I'm also thinking of not spamming MQTT brokers here. Maybe something simple like store timestamp and last output (global not per device) with an option to then silence for some milliseconds. (But not extending the timeout thus giving a periodical output if needed. And every different output would reset the logic / or maybe compare to the last 3 or so outputs.) A token bucket limiting option could be more flexible though.
Nice use-case with your buttons and good write up. You can use the flexible decoder (-X) to tailor a decoder for your button(s) without the need to patch. Along with the upcoming MQTT support this should enable you to send exactly the messages you need.
PR #908 rtl_433 -q -Y 1 -r rtl_433_tests/tests/generic_remote/01/gfile003.cu8 will filter out duplicates from these type of devices.
Most helpful comment
Nice use-case with your buttons and good write up. You can use the flexible decoder (
-X) to tailor a decoder for your button(s) without the need to patch. Along with the upcoming MQTT support this should enable you to send exactly the messages you need.