Hi!
I noticed in the documentation that this board is supported with receive only for rtl_433, while other boards support transmit also.
Is transmission with these boards something that might be added in the future, or is it practically impossible to do because of their limitations?
Hi @louisnichols,
In general rtl_433_ESP works only for receiving and decoding RF transmission from devices using rtl_433 encoding. AFAIk this is the same for rtl_433 with an RTL-SDR stick - hence rtl_433 being called a data receiver.
If you are referring to other RF gateways being able to also transmit, this is correct, but for such other RF gateways different RF receivers and transmitters are necessary - as listed in the documentation table - as the LilyGo/Heltec devices’ built in SX127X only allows for rtl_433_ESP receiving (and decoding) - similar to an ESP32 with an external SX127X.
So the limitation is due to SX127X only allowing for rtl_433, which in turn is only a receiving library.
Hope this helps in clarifying the issue.
Thanks for the reply. I understand.
The only thing is, the rtl_sdr dongles are by construction Rx only devices. So I guess that is why rtl_433 itself probably never even considered transmitting.
But if I understand correctly, LoRa is (always?) bidirectional. This might mean that the radio on a device auch as a Lora32 might in principle be able to also transmit, unless there are other limitations. I’m not sure.
So it might be the case that with additional software, they can also transmit.
It would be pretty cool. 
Absolutely correct, and AFAIK with the LoRa protocol it is also currently already possible to transmit, but I do not have any experience with it.
Which devices are you actually interested in transmitting commands to? Which protocol do they support?
I have a bunch of these remote plugs that you find everywhere. I already control some of them with a simple transmitter from an RPi, using rpi-rf. Which is a big glitchy sometimes but generally works. I think their protocol is “Generic Remote”.
But my biggest pain is that I have some other such plugs which don’t work with rpi-rf. Worse still, I have some switches using the same protocol which are mounted inside electrical boxes in the walls. I don’t really want to change those.
I believe these use the KAKU protocol. OpenMQTTGateway (i have one running on a lora32 Board) seems to pick them up as either KAKU, or Nexa Security, or another Security protocol, whose exact name I don’t remember right now.
It’s a tricky protocol this one. My rtl_433 with rtl_sdr on am RPi picks up some of these, but not all. OpenMQTTGateway actually picks up more of them. Although, interestingly, from 2 identical remote buttons, it “sees” one on all 3 protocols (Kaku, Nexa and the other one), but the second only on the last two protocols.
Anyway, if would be cool to add such a feature to lora32.
It sounds as if both your RF plugs, as well as the flush-mounted switches are already supported by OpenMQTTGateway (RF/Pilight and RF2 protocols) , just not with a LilyGo LoRa32 board’s internal SX127X transceiver, but with hooking up the SRX882/STX882 receiver/transmitter, which you likely are already using with your rpi-rf setup.
For that I would use a generic ESP8266 though, as the LoRa/rtl_433_ESP/BLE capabilities of the LilyGo LoRa32 are not really required and are better put to use for actual rtl_433_ESP decoding.
Yes, I’m already planning to build such a board with a D1 mini.
I just thought I would ask, because doing this directly with the LoRa32 board would be soooo much more elegant .
I had similar hopes initially, i.e. that the OMG’d Lilygo LoRa433 would allow me to replace my tasmota’d Sonoff bridge since I found the latter has limited range and also compatibility.