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
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:
-
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?
-
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?
-
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 …)
- 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 )
- 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 ?
- 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 )