Support of RTL_433 library

Thanks. I know Aliexpress quite well for a lot of my tech parts, but went for a more local seller now, so I can already do some testing this weekend :wink:

Hi again,

I’m still struggeling to make my hardware setup work. I discovered a few issues I’m looking for some advise or feedback:

  1. CC1101 pins used - I started with a Wemos D1 mini (ESP8266) where GDO0 is connected to “D1” (GPIO5) and GDO2 to “D2” (GPIO4). That worked at least for the Somfy actuator. As it was built on a “Shield” I moved it to a Wemos D1 ESP32 where GDO0 is now connected to GPIO22 and GDO2 to GPIO21. The SPI interface is working fine, but I’m confused about the RF_RECEIVER_GPIO (=GDO2?) and RF_EMITTER_GPIO (=GDO0?) defines in the platformio.ini file. So based on the documentation I should “define RF_RECEIVER_GPIO 21” and “define RF_EMITTER_GPIO 22” - correct? Is that OK as the Wemos D1 ESP32 documentation is telling those GPIOs are assigned to I2C (SCL/SDA) but can be used as IOs if no I2C is used. So any concern?

  2. I’m interested in receiving data from my RF433 weather station which my RTL.SDR stick is decoding as a Oregon-THGR122N. That device is supported by the rtl_433 lib, but not in the port to rtl_433_ESP (yet)? The device is covered in the oregon_scientific.c file but it is not copied over?! Why?

  3. Is there any conflict in running ZgatewayRF and ZgatewayRTL_433 at the same time on a single ZradioCC1101?

Thanks

As stated on the rtl_433_ESP GitHub page

The initial port implements only enables a subset of the available modulations and device decoders …

with OOK_PPM and OOK_PWM being currently supported.

Your Oregon-THGR122N uses OOK_PULSE_MANCHESTER_ZEROBIT (from the oregon_scientific.c file), so I assume it is therefor not (yet?) included, like any other device decoders using OOK_PULSE_MANCHESTER_ZEROBIT (ambient_weather.c, honywell.c …)

  1. CC1101 pins used - I started with a Wemos D1 mini (ESP8266) where GDO0 is connected to “D1” (GPIO5) and GDO2 to “D2” (GPIO4). That worked at least for the Somfy actuator. As it was built on a “Shield” I moved it to a Wemos D1 ESP32 where GDO0 is now connected to GPIO22 and GDO2 to GPIO21. The SPI interface is working fine, but I’m confused about the RF_RECEIVER_GPIO (=GDO2?) and RF_EMITTER_GPIO (=GDO0?) defines in the platformio.ini file. So based on the documentation I should “define RF_RECEIVER_GPIO 21” and “define RF_EMITTER_GPIO 22” - correct? Is that OK as the Wemos D1 ESP32 documentation is telling those GPIOs are assigned to I2C (SCL/SDA) but can be used as IOs if no I2C is used. So any concern?

RF_RECEIVER_GPIO is mapped to GDO2
RF_EMITTER_GPIO is mapped to GDO0

So you should be fine with moving to gpio21 and gpio22 ( In my setup I also have a BME280 connected via I2C and it is using gpio21 and gpio22 as they are the I2C default )

  1. I’m interested in receiving data from my RF433 weather station which my RTL.SDR stick is decoding as a Oregon-THGR122N. That device is supported by the rtl_433 lib, but not in the port to rtl_433_ESP (yet)? The device is covered in the oregon_scientific.c file but it is not copied over?! Why?

With the initial version of the port I limited demodulation support to only devices I had available to test with to ensure that it would work correctly so only OOK_PULSE_PWM and OOK_PULSE_PPM decoders were copied over and enabled. Next on the roadmap is FSK devices, ( Support for FSK Modulation - WH51 Soil Moisture sensor · Issue #5 · NorthernMan54/rtl_433_ESP · GitHub ) and could look at these afterwards. As I don’t have access to a device, would you be able to create a sample transmitter to emulate the device similar to what AusGunno created for FSK to emulate a WH51 device ?

  1. Is there any conflict in running ZgatewayRF and ZgatewayRTL_433 at the same time on a single ZradioCC1101?

Both receiving at the same time ? This is not supported or feasible at the present time. It may be possible to use RTL_433 to receive and ZgatewayRF to transmit at the same time, I’m not sure if the current release supports this, but it is something I have been using in my own branch for a bit.

With the next release of openMQTTGateway I have been looking at including a receiver switching function, so you could change active receiver gateway without having to the change firmware. I had something like this working in the fall, just never got it fully wrapped up for the most recent release ( Ability to switch the receiver between PiLight and RFGateway · Issue #848 · 1technophile/OpenMQTTGateway · GitHub )