-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Contribution Question: Adding Multiple Decoders #2754
Comments
Usually this type of sender (doorbell style) sends only a fixed code, likely EV1527 protocol. This is best implemented with flex decoders. See https://github.com/merbanan/rtl_433/tree/master/conf |
@eshaz Would you mind posting some .cu8 files of these samples with descriptions here? I took a look through your audiovox_car_remote.c code in the PR and I'm concerned that without any matching of a product ID code or CRC verification in the samples, it will find itself matching other kinds of devices out in the wild too readily. A flex decoder might be more appropriate. |
@klohner I was thinking it would be a good idea to include sample data and docs for these in the rtl_433_tests repo. I can open a PR there with the samples / docs. Regarding the Nutek remotes, (I renamed |
I've added some samples / docs / pictures here: merbanan/rtl_433_tests#462 if you want to take a look. This has about half of the devices. I plan on adding the rest tomorrow. |
Everything is added now into the tests PR. Also, I've moved that Nutek remote into a flex decoder. |
Seems like this was a question about process, answered, and some progress. Future contributions welcome, but I don't see this issue being open as helpful to anyone. If I got that wrong please tell me. |
I recently purchased a box of 50 or so old car keyfobs, and I also have a few other devices that I plan on using for various home automation things. I quickly tried these devices with rtl_433, and only a handful of them are implemented. I think it would be nice to contribute back to the community by creating decoders in this library that will support the various protocols implemented by these devices.
What would be the best way for me to contribute these additions? Would separate PRs for each protocol be OK, or is there some other way that would be easier for maintainers to review and merge a bunch of new devices?
The text was updated successfully, but these errors were encountered: