Interest in limited support for rtl_433 device / protocol support on ESP32

Sensors
1

I have a working alpha codebase that supports using the rtf_433 device decoders on a ESP32 and a cc1101 transceiver. This is running under the openMQTTGateway codebase ( awesome framework), and am wondering if there is significant interest in merging this as a feature of the main code base. As the feature is heap and stack intensive, it is unlikely to function on devices with less resources than a ESP32, and it requires a CC1101 as radio. The CC1101 is a requirement as I used it’s signal strength indicator (rssi) to detect start and end of message. Also it is not 100% stable and occasionally restarts due to a experiences stack overflow error.

The ported library is here

And my branch of openMQTTGateway is here

I was thinking that due to the limitations of usage ( requiring a ESP32 and CC1101 ) it is likely to used minimally, but wanted to solicit feedback from the community first.

With the CC1101 requirement, when I was coding the signal receiver portion I found that the existing signal gap based approach to determine end of message problematic and used RSSI instead to more align with the existing rtl_sdr approach. This immensely improved the quality of signal reception.

PS I have been running this for about a month in conjunction with RF/RCSwitch, and a BME280 and it has been pretty good. I have been using RF/RCSwitch to control my ceiling fans at the same time as receiving rtl_433 messages.

1 Like
2

Thanks for this awesoommmeeee work!

I don’t think so, I think it has really good potential.

That’s great also to be able to combine this with RCSwitch.

I will test your solution, provide feedback here, and will be happy to merge it.

3

If your going to play with my branch, it is a bit messy at the present time but should compile okay

I had added a couple of other features to support my environment / setup

1 - multi wifi support and the ability to specify 2 hard coded access points
2 - Disabled Home Assistant Discovery ( I’m using home assistant auto discovery with Homebridge, and kept having my device randomly appear )
3 - Enabled mDNS discovery of Mqtt host. ie mqtt.local as the Mqtt host

I jump back and forth every week between my home and cottage and have different SSID’s and Mqtt setups etc, so tried to avoid recompiling etc and just wanted to to plug and play between locations

my prod_env settings ( I had both rtl_433 and

[env:rtl_433-9e0770]
platform = ${com.esp32_platform}
board = esp32dev
build_type = debug
monitor_filters = esp32_exception_decoder
lib_deps =
${com-esp.lib_deps}
${libraries.rc-switch}
${libraries.smartrc-cc1101-driver-lib}
${libraries.bme280}
${libraries.rtl_433_ESP}
ESPiLightDev

build_flags =
${com-esp.build_flags}
‘-Dota_password=""’
‘-DMQTT_SERVER=“mqtt.local”’
‘-DMDNS_SD=true’
‘-DESPWifiManualSetup=true’
‘-DGateway_Name=“breadboard-9e0770”’
‘-DOMG_VERSION=“cc1101”’
‘-Dwifi_ssid1=“xxxxx”’
‘-Dwifi_ssid=“xxxx”’
‘-Dwifi_password=“xxxx”’
‘-Dwifi_password1=“xxxx”’
‘-DSERIAL_BAUD=921600’
‘-DZgatewayRF=“RF”’
‘-DZgatewayRTL_433=“rtl_433”’
‘-DZgatewayPilight=“Pilight”’
‘-DZradioCC1101=“CC1101”’
‘-DZsensorBME280=“BME280”’
; ‘-DLOG_LEVEL=LOG_LEVEL_TRACE’
; ‘-DMEMORY_DEBUG=true’
; ‘-DDEMOD_DEBUG=true’
; ‘-DRTL_DEBUG=4’ ; rtl_433 verbose mode
; ‘-DRAW_SIGNAL_DEBUG=true’
‘-DRF_EMITTER_GPIO=2’
‘-DRF_RECEIVER_GPIO=4’
‘-DMY_DEVICES=true’

monitor_port = /dev/cu.SLAB_USBtoUART
upload_port = /dev/cu.SLAB_USBtoUART
upload_speed = 921600
monitor_speed = 921600

1 Like
5

A pull request based on the current development branch is now available.

I have been running this for the last few weeks and it has been pretty good, but would appreciate additional feedback.

1 Like
6

I finally get my weather station decoded with an ESP32!

7

Congrats

With your weather station, how does the decode look versus the real rtl_433 ? I had found that when playing with my devices and testing that I was seeing the same signal decode issues between my esp32 based code and my RPI running rtl_433.

Also if you find that the memory usage is too much or it isn’t stable enough, you can always adjust which device decoders are included in the build by changing this

The devices I have are part of the ‘MY_DEVICES’ list, and you could adjust to match your setup/devices

8

Didn’t compared it yet with my SDR but it looks consistent on physical value point of view.

Thanks for the tip!

9

After one day of operation it seems that the gateway is not pushing RF signals anymore, it is still alive (I get the SYStoMQTT) but it doesn’t react to RF signal. If I restart it by a restart MQTT command it starts again receiving RF signals.
I will let it connected to serial to see what trace I get.

10

If you send ‘{“status”:1}’ to ~/commands/MQTTtoRTL_433

It will return the status and state of the receiver code ie

{“model”:“status”,“protocol”:“debug”,“debug”:0,“duration”:25870762,“Gap length”:-142304,“signalRssi”:-75,“train”:1,“messageCount”:1211,“_enabledReceiver”:1,“receiveMode”:0,“currentRssi”:-88,“minimumRssi”:-82,“pulses”:0,“StackHighWaterMark”:5320,“freeMem”:195992}

One possible issue with it going quiet is the level of background noise ie currentRssi

If it ran into a resource issue I would have ( likely ) I would have expected a restart

To keep an eye on things this is a dashboard I created in Node Red

PS My test device also has a local BME280 and BH1750, and is running with a subset of device decoders

Screen Shot 2021-03-12 at 12.50.35 PM
Screen Shot 2021-03-12 at 12.50.35 PM1297×661 112 KB

13

I’m seeing restarts when the weather station is ON
image

Here is the log of one restart:
N: Received json : {“model”:“unknown”,“protocol”:“signal parsing failed”,“duration”:142587,“signalRssi”:-40,“pulses”:32,“train”:1,“messageCount”:29,“_enabledReceiver”:1,“receiveMode”:0,“currentRssi”:-89,“minimumRssi”:-82}
T: jsonPublishing

rtl_433_ESP(6): Unparsed Signal length: 146842, Signal RSSI: -58, train: 0, messageCount: 30, pulses: 27
rtl_433_ESP(6): RAW (146842): +1373-1510+1501-1502+1476-1503+754-756+748-747+765-731+770-721+1518-1496+1490-744+764-741+749-745+767-1484+738-762+749-745+765-734+1494-1493+769-747+737-750+1517-736+750-1497+763-745+1495-1488+1496-1512+739-763+1496-1480+1521-1485+1494-1512 
N: Subject: /RTL_433toMQTT
N: Received json : {"model":"unknown","protocol":"signal parsing failed","duration":146842,"signalRssi":-58,"pulses":27,"train":0,"messageCount":30,"_enabledReceiver":1,"receiveMode":0,"currentRssi":-87,"minimumRssi":-82}
T: jsonPublishing
 
***ERROR*** A stack overflow in task loopTask has been detected.
abort() was called at PC 0x4008c78c on core 1

Backtrace: 0x4008c544:0x3ffaf000 0x4008c775:0x3ffaf020 0x4008c78c:0x3ffaf040 0x40089820:0x3ffaf060 0x4008b4a0:0x3ffaf080 0x4008b456:0x2813e07a

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2

and the last SYStoMQTT:

N: Received json : {"uptime":622,"version":"version_tag","freemem":106936,"freestack":4776,"rssi":-34,"SSID":"","ip":"192.168.1","mac":"","mhz":433,"RTLminRssi":-82,"RTLRssi":-89,"RTLCnt":24,"modules":["rtl_433"]}
T: jsonPublishing

I will go in deep tomorrow

14

Been running mine with a subset of device decoders and it is stable. But if I run with the full set of device decoders I get a similar stack overflow, so am thinking that one or more of the device decoders may be triggering the issue. Now the trick would be to identify
which one is triggering the issue without breaking down and without doing a code review of each one individually.

As it is stable with a subset of device decoders, am thinking my receiver code is okay and that the issue is with the device decoders. Also one other data point, in my stable setup, free stack is sitting at 5320 versus 4776 in yours.

1 Like
15

Spent the last few days doing some testing to attempt to identify which device decoder is triggering the stack overflow and found this line in a couple of device decoders which I think is triggering it. I found this by enabling ’ ‘-DRTL_DEBUG=4’ and letting it run until it had restarted a couple of times, then going back and seeing which device decoder it was processing when it overflowed.

bitbuffer_t databits = {0};

That would have allocated on the stack…

That is in the newkaku.c, nexa.c, and proove.c device decoders. Starting another test loop with them removed

1 Like
16

In my side I build it with the ws2032 only and the weather station running, it is working fine since 9h.

17

10 hours and no issues, am thinking this is resolved. At some point will need to look into the flash and heap size of this.

image

Will submit a pull request to the updated library shortly, just need to update my notes etc

1 Like
18

Here are my production units, ESP32 with cc1101, bme280 and 2 with bh1750. I had ordered cc1101 devices a couple of times and ended up with 3 different styles of units. For a case, I don’t have a 3D printer so I’m using Hammond 1593LBK cases. My local supplier has these pretty cheap ( Sayal ).

image
image1116×837 433 KB

3 Likes
19

Nice!
Did you found a CC1101 with a spacing between pins that fits regular breadboards?

20

Unfortunately not, everything was either 5x2 or 6x2. If you look left to right you can see a bit of my progression in design, with the right most two being the final build. In the first 2 builds ( left side ) I had used a basic perf board and jumpers to each pin. And for the final 2 I had found a perf board with spacing to match the CC1101. Too make it work I ended up using 2 different styles of perf boards, one for the ESP32 and one for the CC1101.

One other thing I hadn’t taken into account was the thermal output of the esp32, it seems to add a couple of degrees versus an esp8266 and throws the BME280 temperature off slightly.

1 Like