Ability to switch the receiver between PiLight and RFGateway

[NorthernMan54]

As part of my device build out ( esp32 with cc1101 ) want to build a single device with the following capabilities

1 - Ability to transmit either Pilight or RFGateway protocols, on any supported CC1101 frequency. And after transmitting switch back to previous receive configuration ( MHz and active Receiver decoder module )

2 - Ability to receive on any supported CC1101 frequency ( complete #847 )

3 - Ability to receive and decode either PiLight or RFGateway protocols

Wish list, likely not feasible

4 - Ability to scan multiple frequencies for a signal ( 303mhz, 315mhz and 433mhz ) and receive a transmission

5 - Ability to handle multiple protocol decoders similtaniously

I have a working PoC for 1,2 and 3 and will be submitting a pull request shortly

To manage decoder switching, am thinking to leverage the existing command structure as follows

To enable RFGateway receiver and decoder, send a message to commands/MQTTto433 containing a frequency ie commands/MQTTto433 { “mhz”: 303 }

To enable PiLight receiver and decoder, send a message to commands/MQTTtoPilight containing a frequency ie commands/MQTTtoPilight { “mhz”: 433.92 }

Does this make sense?

FYI - My setup has these devices

1 - Hampton Bay Fans ( 303mhz ) works with RCSwitch/RFGateway

2 - GE ceiling fans and a fireplace ( 315mhz ) works with RCSwitch/RFGateway

3 - Numerous 433 MHz temperature and motion sensors that work with PiLight

[NorthernMan54]

For item 4 and 5, I pulled together an example using just the cc1101 library that works okay. Now to see if this will work inside the openmqttgateway framework.

[1technophile]

To enable RFGateway receiver and decoder, send a message to commands/MQTTto433 containing a frequency ie commands/MQTTto433 { “mhz”: 303 }

To enable PiLight receiver and decoder, send a message to commands/MQTTtoPilight containing a frequency ie commands/MQTTtoPilight { “mhz”: 433.92 }

On other gateways we use a config key in the topic, which makes more explicit that this command is persistent. So could be coherent to use the same principle.

I'm asking myself also if we should extend the gateway activation to usages without CC1101, if we do this, activating the gateways by their frequency is less relevant compared to CC1101. Maybe using a command like for CC1101: commands/MQTTtoPilight/config {"active": "true", "mhz": 433.92 }

and like this without CC1101 (not necessarily to be implemented in this PR): commands/MQTTtoPilight/config {"active": "true"}

As we don't want to have too many API changes, it could be nice to take into account this in your PR.

For further thinking, we may also publish the current state of gateways every X seconds as we do for SYStoMQTT.

[NorthernMan54]

For item 4 and 5 have had it running now for about a day, and found that about 75% of messages are received and about 25% are missed. So am thinking that this feature many not work as well as I had thought. Will need a deeper dive into the timing / CC1101 signal detection logic ( using RSSI to determine if their is a signal ) to determine if it resolvable.

It may be useful for a chatty service, but for something like a motion sensor not reliable enough

[1technophile]

Regarding 5, a track to follow could be to use the raw receiving of ESPilight. It could in some ways replace a part or totally RCSwitch. And modify the Pilight library to add decoding to this raw mode. If you are interested in going further you may test the raw mode and check if it answers your need. If yes I don't think it is difficult to enrich it with the decoding that is already available into the ESPilight library.

[NorthernMan54]

The proposed SYStoMQTT message with Scanner active ( MHz is 0 as it is moving between the configured frequencies ). Also "RFScanner":"Enabled" only appears when the module is included.

{"uptime":484,
"version":"RFScanner-9e0770",
"freemem":229696,
"rssi":-45,
"SSID":"The_Beach",
"ip":"192.168.1.103",
"mac":"3C:71:BF:9E:07:70",
"wifiprt":0,
"RFScanner":"Enabled",
"Mhz":0,
"ActiveReceiver":"RFScanner",
"modules":["BME280","RFScanner","RF","Pilight"]}

Scanner disable and PiLight active on 433.92

{"uptime":844,
"version":"RFScanner-9e0770",
"freemem":229712,
"rssi":-42,
"SSID":"The_Beach",
"ip":"192.168.1.103",
"mac":"3C:71:BF:9E:07:70",
"wifiprt":0,
"RFScanner":"Disabled",
"Mhz":433.92,
"ActiveReceiver":"Pilight",
"modules":["BME280","RFScanner","RF","Pilight"]}

Scanner disable and RF/RCSwitch active on 303

{"uptime":964,
"version":"RFScanner-9e0770",
"freemem":229712,
"rssi":-41,
"SSID":"The_Beach",
"ip":"192.168.1.103",
"mac":"3C:71:BF:9E:07:70",
"wifiprt":0,
"RFScanner":"Disabled",
"Mhz":303.732,
"ActiveReceiver":"RF",
"modules":["BME280","RFScanner","RF","Pilight"]}

Regarding #5 multi protocol receive, your concept of both PiLight and RCSwitch decoders operating is interesting and definitely something I'm going to explore with this.

I'm also playing with a concept of using rtl_433 instead of PiLight and seeing how feasible it is to use the rtl_433 device decoders instead. I have found rtl_433 seems to have more device coverage and a more robust decoder logic, but will it work on a ESP32 ? My play code is using a flavour of the PiLight interrupt based receiving code wired to the rtl_433 libraries and using cc1101 RSSI to detect signal presence. Still working thru wiring up the rtl_433 decoders though, without success.

[1technophile]

I'm also playing with a concept of using rtl_433 instead of PiLight and seeing how feasible it is to use the rtl_433 device decoders instead. I have found rtl_433 seems to have more device coverage and a more robust decoder logic, but will it work on a ESP32 ? My play code is using a flavour of the PiLight interrupt based receiving code wired to the rtl_433 libraries and using cc1101 RSSI to detect signal presence. Still working thru wiring up the rtl_433 decoders though, without success.

This is great, I was thinking of the same thing in 2020 but did not get the time to go further with the research around integrating RTL_433 to OMG. I struggled also with the decoder's wiring (I tried to wire them to RCSwitch). My point of view is that ESP32 should work with most of the decoders but we may have to deactivate a part. If you port RTL_433 decoders to ESP32 this is a killer feature. :-)

[1technophile]

{"uptime":964, "version":"RFScanner-9e0770", "freemem":229712, "rssi":-41, "SSID":"The_Beach", "ip":"192.168.1.103", "mac":"3C:71:BF:9E:07:70", "wifiprt":0, "RFScanner":"Disabled", "Mhz":303.732, "ActiveReceiver":"RF", "modules":["BME280","RFScanner","RF","Pilight"]}

Could you put all the keys in lower case please, also if you can reduce their length it would be cool.

[NorthernMan54]

Just a little update on my efforts to port rtl_433 to an esp32, and I have success for 2 of the OOK demodulation schemes ( matching the devices I have ) and a running sample. Main challenge now is that it is a memory hog, approx 200k flash and 100k ram. ( that was with about 100 device protocols enabled ). With a bit of cleanup I should have a poc sample for sharing in a few days. My approach for this will be an external library similar to ESPiLight to reduce code base impact to a minimum.

For my receiver logic, it does require a CC1101 Transceiver as I’m using its signal detection feature to determine when a signal starts and stops, which may limit take up of this.

[NorthernMan54]

@1technophile This feature will be my next pull request, and it will also include switching support for rtl_433. Did you have a rough timeline for when you where looking to publish the current DEVELOPMENT branch, as I wanted to try and get this included.

PS I had been running this version, with switching of decoder modules during the testing of rtl_433, as I was jumping back and forth between rtl_433 and PiLight for devices that supported both.

[1technophile]

Hi! A beta will be published this week and a release during the week after. I'm well advanced in terms of testing, is it going to impact the main.ino, ZgatewayRF or/and ZgatewayPilight? If it is we may release it after the v0.9.6.

[NorthernMan54]

@1technophile Yes it will require changes to all of those components and config_RF.h. So I will hold off on pull request for a few weeks then.

[NorthernMan54]

This has been merged in to the current development branch, and part of v0.9.7