Create a new RF Device... does it make sense or not?

I’m using the RF module in up/downstream and via MQTT command I can change the state of strip-light Novostella 79ft 24M 3000K - 6000K Tunable White Strip Lights, White Showroom Lights because with the reverse engineering I have discovered the value to pass for any buttons of my remote command.

ultimately I simply send the command:
mosquitto_pub -t "home/OMG_BTRF_1/commands/MQTTto433" -m '{ "value": 215308, "protocol": 1, "delay": 388}'

Do you think is useful to create/add/encode this value into RF decoder of OpenMQTTGateway? if YES then do you have some tutorial (or PR) that explains how to add it?


Hi odyno,

decoders are currently only really implemented for RF - rtl_433, or for BLE.

So if you’re using the stock RF gateway, which is how I read it from your posting, there is not a way to wrap this into a decoder.

This is probably also due to the fact that RF signals/values a lot of times differ, even within the same models of devices, at least it is for me like that with my RF devices. Otherwise it would be hard to differentiate two or more of the same model device like your Novostella 79ft 24M 3000K - 6000K Tunable White Strip Lights, White Showroom Lights as you only get/set the "value", "protocol" and "delay" (where just "value" might be enough as no "protocol" uses the default 1 anyway, and the default delay is 350, so could work for you as well), but no distinct model identifier, like with BLE or rtl_433/.

I’m pretty certain that if you get another one of the same light strip it will actually need different values.

Hope this helps


Yes I’m using Stock RF for all my devices… simply because of my pir and now the led remote… none of these is recognized by rtl_433 or rf2. So I’m using them the old-fashioned way…clone the signal and play it back when I need it. (and please note: I also wanted to notify you that if I do not put the protocol and delay it’s doesn’t work.)


Most of my RF devices are the stock RF as well, only requiring rtl_433 for one set of sensors, wasn’t meant derogatory or old-fashioned at all, just as a way to differentiate it from the other RF variants :wink:

Sorry, it’s the delay 350 vs. 388, , but protocol should be superfluous being the default. It’s just almost all of my devices only need the value so I wrote too quickly without looking close enough.

no no, I got it!
Thanks again

Hi there
I can see there are more people with needs like mine. I have a sensor EMOS E6016 which is supported by rtl_433, i can see decoded data.

I even wrote my own sketch that listens using SRX882, decodes the signal (inspired by rtl_433 sensor id 214). But I’d like to stay with OMG

Is there a way (for my) to extend OMG RF and include this sensor? I already have 6 different esp32’s in my house hehe

Thanks a lot!


I think you’re confusing the different RF possibilities of OMG a bit here. Odyno asked about the possibility of decoders for the stock RF OMG implementation. As stated above, this is not possible or even really desirable, but for BLE and rtl_433_ESP, with their included decoder libraries of OMG, such decoders are existing.

Since rtl_433_ESP is an Arduino library port containing a subset of the available modulations and device decoders, and the EMOS E6016 decoder was only added to rtl_433 very recently, not even being in an official release there yet, it might only be a matter of time and currently enabled pulse demodulation possibilities (which should already be ok for the EMOS E6016) for it to be included in rtl_433_ESP with a future update.

For any help, support and contributions for the rtl_433_ESP library …

Hope this helps

Ah right, thanks a lot, sure it helps! I was confused indeed, but now on track. Thanks