Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Option to prevent a device from "firing" multiple times #664

Closed
BenWoodford opened this issue Jan 7, 2018 · 7 comments
Closed
Assignees
Labels
todo Maintainers should do something, but there is no defect

Comments

@BenWoodford
Copy link

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.

@zuckschwerdt
Copy link
Collaborator

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.

@skx
Copy link

skx commented Mar 10, 2018

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.

@zuckschwerdt
Copy link
Collaborator

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.

@zuckschwerdt
Copy link
Collaborator

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.

@zuckschwerdt zuckschwerdt self-assigned this Dec 8, 2018
@zuckschwerdt zuckschwerdt added the todo Maintainers should do something, but there is no defect label Dec 8, 2018
@merbanan
Copy link
Owner

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.

@gdt
Copy link
Collaborator

gdt commented Sep 24, 2023

I have opened #2635 about the big picture and linked the PR. I'd like to close this as we have an unmanageable about of open issues and it would be good to reduce/coalesce.

@gdt
Copy link
Collaborator

gdt commented Sep 25, 2023

This is now a dup of #2640

@gdt gdt closed this as completed Sep 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
todo Maintainers should do something, but there is no defect
Projects
None yet
Development

No branches or pull requests

5 participants