added PTSPDP Doorbell support (conf and device) #2723
Conversation
|
Thanks! We can only accept the decoder conf, generic (EV1527 style) senders with just a (24-bit) fixed code don't have anything interesting to really decode. |
I don't disagree, but in order for this to be incorporated into downstream (like rtl_433_ESP and then into openMQTTgateway) that don't support flex decoder, this is the only way I can see getting support for my doorbell into the standard release. |
|
Good point, this has been asked before and we need a solution. I was toying with the idea to generate source code from decoder specs. Not ideal for downstream projects though. |
|
That would be awesome as when I started going down this route I wondered why this wouldn't just exist. But now understand the whole reason a custom decoder written in C would be needed for complex RF interfaces like many already included in the project, and why the flex decoder is good enough for many problems. However, the flex decoder could use a simple API, whereas some kind of call could turn on or off and adjust parameters for the flex decoder on the fly while rtl_433 is running. In the OpenMQTTgateway, this would be a simple decoder like the one I sent in could be configured over an MQTT persistent call. |
|
Runtime configuration of (flex) decoders is possible. For the MQTT idea we need to look into receiving topics -- currently we only send. |
|
I've been working to build the latest rtl_433_ESP with the latest rtl_433 head, and for sure some build issues to work out. I may go back and just port my one decoder to just do a proof of concept for my one need. While I'm doing that, I'll look into the MQTT side of things and how callbacks are happening now. There's already a callback from MQTT message to change the frequency on the fly. I'll look into how that interfaces with rtl_433 ESP port. |
No description provided.