New SubGHz protocol: Legrand doorbell

[user890104]

What's new

• Added a new SubGHz protocol encoder and decoder for wireless doorbells. It seems to be used by many brands, but the most reputable brand is Legrand. Both the battery operated version and the AC powered version use the same protocol. It is a static code OOK, that repeats over and over. The receiver only needs to hear one complete message, in order to ring.

https://www.legrand.com/ecatalogue/en/catalog/products/comfort-radio-kit-wireless-chime-and-doorbell-round-white-100m-radio-range-and-15-melodies-094252

https://www.legrand.com/ecatalogue/en/catalog/products/comfort-radio-kit-230v-plug-in-chime-and-wireless-doorbell-round-white-100m-radio-range-and-15-melodies-094254

---

For the reviewer

• [ ] I've uploaded the firmware with this patch to a device and verified its functionality
• [ ] I've confirmed the bug to be fixed / feature to be stable

[user890104]

After testing, it seems like the receiver needs to hear 2 messages in a short interval, and for some reason the SubGHz app does not repeat the message when holding down the Send option. Can somebody help with diagnosing this issue?

[Willy-JL]

The subghz app, in the history helper, checks the received signal hash with last received hash, and if less than 500ms went by it ignores the same hash. That's probably what you're encountering. Not sure how to go about this one

[user890104]

I was referring to sending, not receiving. It correctly adds the decoded message to the history list only once, but when sending it does not respect the .repeat parameter in the encoder struct, nor holding down the send button (like RM does in order to keep repeating).

[user890104]

Clicking Send two times in a rapid succession seems to work around this bug, and triggers the doorbell receiver.

[user890104]

There's a false positive with this file, so I'll need to make the checks more strict. Currently the spaces aren't measured at all, just the marks. Also the delta is quite high, 300 uS is very generous. I haven't seen any deviations of more than 50-100 uS.

Home doorbell raw bug.sub.txt

Also I see there's a linter used in CI, how do I make sure my code is properly formatted before pushing?

[Willy-JL]

You can use ./fbt format format_py for the linter, or setup an IDE formatter on save (on vscode you can use ./fbt vscode_dist, other IDEs will be a manual setup, there's a clang format config in repo root)

[user890104]

Re-implemented the decoder and lowered the delta. Tested with the broken file, and with raw signal replayed from another Flipper, LGTM.

[Willy-JL]

gonna be 100% honest that i had never really used flipper unit tests but just spent a bit of time figuring them out, seems like we aren't doing too bad. indeed this addition doesn't seem to cause issues anymore. only tests that failed in subghz is the random test which picks up 330 signals instead of 329, gonna have to check what the extra one is and if it is expected, but this discrepancy happens on current dev branch too.

thank you!