LoRa / LoRaWan support

[ilgrank]

Hello
I've followed the discussion here and in 2018 @gemu2015 added initial support for Lora with PR3309
What I don't get, is the current status of Lora/LoraWAN in Tasmota.

My progect would be to have two LORA32 (such as TTGO) relaying informations between them via MQTT.
(Remote BLE sensors -> Tasmota reading BLE -> LoRa -> Tasmota Relaying BLE sensors to MQTT Broker)
Of course mine is just an idea, but from what I've read, this should be a reasonable approach, since the remote location is too far away (800+ meters) from my home with no clear LoS and so Wifi is not an option.
Of course if I'm on a completely wrong path/anyone has better ideas on how to handle such a scenario, any suggestion is very welcome.
Thanks!

[barbudor]

I don't now why PR3309 is linked to that Lora discussion but it's not related at all
As of today there is NO support for Lora/Lorawan in Tasmota

I understand your use case, using Tasmota as a bridge/gateway from Lora to MQTT just like already supported for Bluetooth or Zigbee makes sense when using far remote sensors

Unfortunately no-one has ever proposed to work on that feature.
I may have a possible use case on my side but didn't yet had time to buy the devices and work on it. I also have zero experience with Lora/LoraWan

How is the connection between the Lora chip and the ESP32 ?
If it's serial, it should be easy to implement something in Berry language
If not, a native driver would then be needed

[ilgrank]

Reading the Arduino libraries, the protocol for basic LoRa is plain old serial
LoRaWAN of course is a completely different matter, but even just LoRa should be enough for data bridges.
as for PR3309, it was this comment that made me think basic support had been added...

[ilgrank]

Oh, and there's a very interesting video here

[joba-1]

I have quite some experience with using RF95W chips for LoRa and LoraWAN (LoraGw, STM32L0LoraTx, STM32L0TTN, ...).

I think, LoraWAN with Tasmota makes no sense. Sensordata goes through special and relatively expensive gateways (at least compared to rf or zigbee bridges) to a cloud (here TTN) where you can already query the data with http, mqtt and more. Sensors are usually "out there" with no or low power and often no wlan - not an ESP/Tasmota domain.

Pure LoRa would be a better match, but also not perfect: the LoRa chip communicates via SPI.
I use it for battery powered sensors that send data via LoRa to an ESP8266 based gateway feeding my Influx database. Sensors work well with 2xAAA-battery life >2 years - nothing you can do with an ESP. But the gateway could run Tasmota instead of my own firmware (except for SPI I guess).
LoRa does not define a data format, it just sends binary data. Tasmota would still need (is free) to define the structure it expects to be able to interpret it and the sensor devices would need to implement that.
This better not be chatty because power consumption is nearly completely caused by airtime. Double the bytes -> half the battery life. E.g. if sending a 16bit int temperature results in 1 year lifetime, sending a json like {"temperature":-10.5}\n and you switch batteries after ~1 month...

[ilgrank]

Thanks @joba-1 .
I do agree on keeping the complexity down to reduce air time (an in fact, in my question above I say: LoRaWAN of course is a completely different matter, but even just **LoRa should be enough for data bridges**.
That said, Tasmota already does implement almost 100% of the gateway logics, it does that already for Zigbee and BLE as @barbudor said.

[Jason2866]

There is a well maintained solution for such a gateway https://github.com/1technophile/OpenMQTTGateway/releases

[Jason2866]

We will see if someday, someone will write something. Don't hold your breath waiting for.

[ilgrank]

I think the purpose of a discussion is thread is.. to discuss and propose.
I'm not the only one asking for LoRa support, and in fact, many people did over the years,as this thread and the other I linked earlier showed..

[sfromis]

Well, while this thread indeed can be seen as a proposal for a feature, what counts is if "someone" is feeling the urge to do the work of coding a driver, integrated into how Tasmota works, and submitting a PR (pull request) for inclusion into the Tasmota project. A very large part of the existing drivers are created outside of the core Tasmota developer team, on normal open source terms.

[jeroenhubgit]

Maybe a little update in my experience. I have the same problem and tried many solutions. You can also can get cheap lora modules for the nodes, and only need a bit more for the gateway. So i wouldn't say that it is far more expensive. Just the lack of standardised software is missing.

• OpenMQTTGateway won't work without wifi and cannot receive and detect lora messages automatically, so the concept of using multiple lora nodes on far locations is just useless.
• FDRS comes the most close. It works, but the big limitation is that you need to code all nodes manually in arduino and the used systematic has still many limitations.
• TTN works, but the big limitation is the amount of data that can be transferred with the free account. Let's face it, it's a commercial business, everything relates to using the paid licences which kills all open source experimental projects when you want to use more than 10 sensors or update more than just 20 messages per day.
• So Tasmota would be still a special solutions which would fix everything. The big advantage is that everything is written with arduino libraries already, so it should be possible to add the LoRa arduino based libaries with it. The Tasmota interface is extremely useful to adjust and change the pin settings for different sensors or actuators in the experimental phase which i am currently missing when using my own programed Lora arduino codes.

I am not so advanced in the way how to make a setup or change it in a Tasmota developer version. If I know where to look, I would gladly try to help make it work. Who could help or give me some directions???

So please, let's get Tasmota WORK with LoRa!! :)

[barbudor]

The problem is not to get Tasmota to work with Lora.
It would be totally possible to do something similar to what have been done with Bluetooth or Zigbee (with a problem that AFAIK there is no standard for Lora messages)
But that wouldn't be much different than OpenMqttGateway : a bridge from Lora to MQTT that needs wifi.

Tasmota is meant to run from WiFi and has not been designed for low power that most Lora application would need.

So Lora-gateway in Tasmota is possible, a Lora-node isn't what Tasmota has been designed for.

[nikito7]

// Tasmota LoRa driver
// easyhan.pt

#define LORA_VERSION "2024.02.19.2347"

#ifdef USE_LORA_V1

#warning **** LORA_V1 Driver is included... ****

#define XDRV_101 101

// This variable will be set to true after initialization
bool initSuccess = false;

char *payload = nullptr;
size_t payload_size = 512;
char *topic = nullptr;
size_t topic_size = 50;

// LoRa

#include <LoRa.h>

// esp8266
#define LORA_SCK 14
#define LORA_MISO 12
#define LORA_MOSI 13
#define LORA_SS 15
#define LORA_RST -1
#define LORA_DI0 5

// ### CHA_CHA_POLY ###

#include "../../easyhan_secrets_cha.h"
#include "ChaChaPolyHelper.h"

byte iv[CHA_CHA_POLY_IV_SIZE];

// ### CHA_CHA_POLY EOF ###

// **********************

void LoRaInit() {
  //
  payload = (char *)calloc(payload_size, sizeof(char));
  topic = (char *)calloc(topic_size, sizeof(char));

  if (!payload || !topic) {
    AddLog(LOG_LEVEL_INFO, PSTR("LORA: out of memory"));
    return;
  }

  AddLog(LOG_LEVEL_INFO, PSTR("LORA: Init..."));

  SPI.begin();

  LoRa.setPins(LORA_SS, LORA_RST, LORA_DI0);
  LoRa.setSyncWord(0x12);

  if (!LoRa.begin(868E6)) {
    while (true)
      ;
  }

  AddLog(LOG_LEVEL_INFO, PSTR("LORA: SCK  %d"), LORA_SCK);
  AddLog(LOG_LEVEL_INFO, PSTR("LORA: MISO %d"),
         LORA_MISO);
  AddLog(LOG_LEVEL_INFO, PSTR("LORA: MOSI %d"),
         LORA_MOSI);
  AddLog(LOG_LEVEL_INFO, PSTR("LORA: SS   %d"), LORA_SS);
  AddLog(LOG_LEVEL_INFO, PSTR("LORA: RST  %d"), LORA_RST);
  AddLog(LOG_LEVEL_INFO, PSTR("LORA: DI0  %d"), LORA_DI0);

  LoRa.receive();

  // Set initSuccess at the very end of the init process
  // Init is successful
  initSuccess = true;

}  // end LoRaInit

void LoRaWork(void) {
  //
  int packetSize = LoRa.parsePacket();

  if (packetSize) {
    AddLog(LOG_LEVEL_INFO,
           PSTR("LORA: Packet received !"));
    byte rxArray[packetSize];

    for (uint8_t i = 0; i < packetSize; i++) {
      rxArray[i] = (char)LoRa.read();
    }

    bool noVerify = false;
    uint8_t polySize =
        CHA_CHA_POLY_TAG_SIZE + CHA_CHA_POLY_IV_SIZE;

    if (packetSize > polySize & packetSize < 250) {
      // ### if packet size is Cha Cha ###

      byte tag[CHA_CHA_POLY_TAG_SIZE];
      byte plainText[sizeof(rxArray) - polySize];
      byte cipherText[sizeof(plainText)];

      // copy arrays
      memcpy(cipherText, rxArray, sizeof(cipherText));
      memcpy(tag, &rxArray[sizeof(cipherText)],
             sizeof(tag));
      memcpy(iv,
             &rxArray[sizeof(cipherText) + sizeof(tag)],
             sizeof(iv));

      // clear array
      for (uint8_t i = 0; i < sizeof(plainText); i++) {
        plainText[i] = 0xff;
      }

      // decrypt message from cipherText to plainText
      // output is valid only if result is true
      bool verify = ChaChaPolyCipher.decrypt(
          key, iv, auth, cipherText, plainText, tag);

      if (verify) {
        // hex to json

        // LORAdata["byte0"] = plainText[0];
        // LORAdata["byte1"] = plainText[1];

        uint32_t up = plainText[2] << 24 |
                      plainText[3] << 16 |
                      plainText[4] << 8 | plainText[5];
        AddLog(LOG_LEVEL_INFO,
               PSTR("LORA: Packet valid ! Up: %d"), up);

        snprintf_P(topic, topic_size,
                   PSTR("home/lora/eb1"));

        snprintf_P(payload, payload_size,
                   PSTR("{\"id\":\"eb1\",\"up\":%d}"),
                   up);

        // retain = true
        MqttPublishPayload(topic, payload,
                           strlen(payload), false);

      }  // eof if verify
      else {
        noVerify = true;
      }  // eof else if verify
    }    // eof if packet size is cha cha true
    else {
      noVerify = true;
    }

    if (noVerify) {
      //
      AddLog(LOG_LEVEL_INFO,
             PSTR("LORA: Packet invalid !"));
    }  // if noVerify

  }  // end if packetSize

}  // end LoRaWork

void LoRaJson(bool json) {
  if (json) {
    //

  } else {
    WSContentSend_PD("{s}LoRa Gateway {m} {e}");
    WSContentSend_PD("{s}Build: " LORA_VERSION
                     " {m} {e}");
    WSContentSend_PD("{s}<br>{m} {e}");

    float tmpHeap = ESP.getFreeHeap() / 1000.0;

    WSContentSend_PD("{s}Free Heap{m} %1_f kB{e}",
                     &tmpHeap);

  }  // eof !json

}  // HanJson

/********************************************\
 * Interface
\********************************************/

bool Xdrv101(uint32_t function) {
  bool result = false;

  if (FUNC_INIT == function) {
    LoRaInit();
  } else if (initSuccess) {
    switch (function) {
      case FUNC_LOOP:
        LoRaWork();
        break;
      case FUNC_JSON_APPEND:
        LoRaJson(true);
        break;
#ifdef USE_WEBSERVER
      case FUNC_WEB_SENSOR:
        LoRaJson(false);
        break;
#endif  // USE_WEBSERVER
    }
  }

  return result;
}

#warning **** LORA_V1 End! ****

#endif  // USE_LORA_V1

[ilgrank]

Great news!
Thanks @nikito7 !

[ilgrank]

@nikito7 : are you going to do a PR for your code? let me know if I can be of any help

[nikito7]

@ilgrank

@arendst already is doing something

https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xdrv_driver/xdrv_73_0_lora_struct.ino

[arendst]

What are you people wanting to achieve with lora/lorawan on tasmota?

The current implementation supports lora to be used like serialbridge AND allows any command initiated on a lora node to be executed on a selected lora receiver like the OP envisionend. Implementing lorawan as a node won't happen as there are better options AND tasmota on esp8266/esp32 is too power hungry.

My current project is mimicking a lorawan gateway and app server on Tasmota allowing to use standard cheap lorawan nodes to receive and act upon without the need for cloud solutions. I'm able to decode the join message from a lorawan node but still fail to send a valid join accept message to the node (lorawan is NOT just lora with overhead; it needs frequency hops and all kinds of security keys to work). Do not expect a (small codesize) solution soon.

[cbalint13]

Hi folks,
Hi Theo,

@arendst

As per others and your very good concern "what is achieveable with lora on tasmota" permit some few lines:

• A tasmota node could be a Class C device that always listen as RX (continuous mode)
• Given Class C context, the energy budget don't matters, continuous listening already jepardise energy buged or the "battery" concept
• What matters and make the conext of LoRa & Tasmota (in Class C) valuable is the extraordinary radio range coverage
• Tasmota over LoRa node would simpy push at intervals it's aggregated sensor data to the gateway OR respond to explicit pull requests
• As frontend for users, a simple menu to setup crypto-keys of the lorawan gateway and a simple status as "registered" would be enough

I believe that the most valuable here is the connectivity range and we could completely ignore the idea of "energy budgets".
The implementation of the serial bridge is also very nice decentralised one of broadcasting (to selective audience) commands or messages.

If you agree as principle on a Class C node implementation I am willing to contribute it to the Tasmota project, for a LoraWAN compliance.
There are very simple & cheap solutions for simple LoraWAN gateways too, permit to mention one of mine as a lora usb stick

Thanks.

[FulvioSpelta]

I agree that adding LoRaWan capability to tasmota would be and interesting feature (i'm using tasmota & LoRaWan due to a simple AT command driver developed in berry and RAK sip modules).

I add my notes to the topic:
In order to fulfill a straightforward use like mqtt a "standard" payload encoder could be implemented eg: google protobuf
https://github.com/protocolbuffers/protobuf
https://github.com/nanopb/nanopb

Maybe that the implementation could be "mixed" native and berry leaving in berry the flexibility to select what payload to send and how to decode the incoming control messages implementing not only simple straightforward messages suc as "power1 1" but complete custom command that activate scenarios.

@cbalint13 I'm not a skilled programmer in berry but if you are able we can start to implement payload encoding in berry. I'm available for simple development and for structured testing.

Another, simpler, payload encoder: https://github.com/thesolarnomad/lora-serialization

[cbalint13]

@FulvioSpelta ,

I agree that adding LoRaWan capability to tasmota would be and interesting feature (i'm using tasmota & LoRaWan due to a simple AT command driver developed in berry and RAK sip modules).

I add my notes to the topic: In order to fulfill a straightforward use like mqtt a "standard" payload encoder could be implemented eg: google protobuf https://github.com/nanopb/nanopb

Yep, payload size (in LoRaWAN ascenssion) now can be a concern, i agree with you totaly.
A binarization like the google's protobuf (via a small nanopb) I believe is a good addition for Tasmota (as JSON alternative).

Maybe that the implementation could be "mixed" native and berry leaving in berry the flexibility to select what payload to send
and how to decode the incoming control messages implementing not only simple straightforward messages suc as "power1 1" but complete custom command that activate scenarios.

• No, I wont mix it with berry, i'll leave it as C++ backend (just like zigbee) and period.

• The Tasmota implementation (Class C LoraWAN node) as a single C++ driver in a short nutshell:
  (x) Tasmota register to a LoraWAN with credentials (user settable via web).
  (x) Tasmota registers to LoraWAN and keep registered while SX127X is in continous RX mode.
  (x) Periodically (OR on request) it sends (push) aggregated sensor(s) data via the LoraWAN gateway.
  (x) LoraWAN network may call Tasmota node (pull) either for a report either for a command.

  This would be pretty similar to the WiFi actual network behaviour, even mimicking the MQTT's push/pull thing.
  As reminder this Class C requires a LoraWAN gateway so will be in a centralized & cloud like fashion.

@cbalint13 I'm not a skilled programmer in berry but if you are able we can start to implement payload encoding in berry. I'm available for simple development and for structured testing.

• I refuse to mix it with berry, of course the final implementation would be capable to interact with berry just as the actual WiFi behaviour (not sure about ZigBee backend for now) is capable to be interfaced, currently I also know little about Berry extension for Tasmota.

Another, simpler, payload encoder: https://github.com/thesolarnomad/lora-serialization

• I would strongly vote for google's protobuffer instead, due to it's high popularity (on par with JSON) and wide adoption.

As last mention, I also like very much @arendst current work on his lora serial-bridge idea, that would be a super nice decentralized approach not needing any kind of gateway/cloud, but this Class C LoraWAN would be a completley separate alternative (which might share only the backend drivers for the SX127X SPI HW modules) giving the Tasmota a LoraWAN compliance to act as a node within it.

@FulvioSpelta , Thanks a lot for the inputs, I was't aware (yet) on this super-light weight nanopb library !

PS (Later Edit):

My initial data-payload approach was a basic sensorx=value,senzory=value plain serialization push, and that's it.
If turns out nanopb / lora-serialization would weight too much size, I will go opt for own basic TXT serialization.

[FulvioSpelta]

Thanks for replay....

Maybe that i'm a bit biased by my current implementation that push me towards a "berry approach" to have maximum flexibility.

I don't want to push and leave the space to other comments.

About the current implementation, me too started with a textification of json but the payload becamed too long quickly so i've implemented a simple binary coding using bits for power and switch states and byte or int for other measures.

I've adopted a "template" approach in order to avoid sending measure names in the LoRaWan payload but adding them during payload decoding in chirpstack.

To be clear: the first byte of the payload is the "payload type" and this "type" drive the decoder to add the expected names to the measures.

Here from chirpstack:
UP message (this payload have space (bytes) not used by the template so you see a lot of zeroes):

payload decoded:

Waiting for other LoRaWan enthusiast to comment.

[arendst]

Thank you for your responses. It's valued very much.

As earlier mentionend I'm trying to receive and act upon standard low-cost LoraWan End-nodes without the need for a cloud connection. I managed to receive valid data from both a Dragino LDS02 and a MerryIoT DW10. The join process works well and occasional reception of data at a fixed frequency works too. See code snippet below:

          if (0x00161600 == LoraSettings.end_node[n].DevEUIh) {  // MerryIoT
            if (120 == FPort) {                                  // MerryIoT door/window Sensor (DW10)
              // 03 0F 19 2C 8A00 040000 - button
              // 00 0F 19 2C 0000 050000 - door
              uint8_t status = payload_decrypted[0];
              float battery_volt = (float)(21 + payload_decrypted[1]) / 10.0;
              int temperature = payload_decrypted[2]; 
              int humidity = payload_decrypted[3];
              uint32_t elapsed_time = payload_decrypted[4] | payload_decrypted[5] << 8;
              uint32_t events = payload_decrypted[6] | payload_decrypted[7] << 8 | payload_decrypted[8] << 16;
              AddLog(LOG_LEVEL_DEBUG, PSTR("LOR: Node %d, DevEUI %08X%08X, Events %d, LastEvent %d min, DoorOpen %d, Button %d, Tamper %d, Tilt %d, Battery %1_fV, Temp %d, Hum %d"), 
                n +1, LoraSettings.end_node[n].DevEUIh, LoraSettings.end_node[n].DevEUIl,
                events, elapsed_time,
                bitRead(status, 0), bitRead(status, 1), bitRead(status, 2), bitRead(status, 3),
                &battery_volt,
                temperature, humidity);
            }
          }
          else if (0xA840410E == LoraSettings.end_node[n].DevEUIh) {  // Dragino
            if (10 == FPort) {                                        // Dragino LDS02
              // 8CD2 01 000010 000000 00 - Door Open, 3.282V
              // 0CD2 01 000011 000000 00 - Door Closed
              uint8_t status = payload_decrypted[0];
              float battery_volt = (float)((payload_decrypted[1] | payload_decrypted[0] << 8) &0x3FFF) / 1000;
              uint8_t MOD = payload_decrypted[2];  // Always 0x01
              uint32_t events = payload_decrypted[5] | payload_decrypted[4] << 8 | payload_decrypted[3] << 16;
              uint32_t open_duration = payload_decrypted[8] | payload_decrypted[7] << 8 | payload_decrypted[6] << 16;
              uint8_t alarm = payload_decrypted[9];
              AddLog(LOG_LEVEL_DEBUG, PSTR("LOR: Node %d, DevEUI %08X%08X, Events %d, LastEvent %d min, DoorOpen %d, Battery %3_fV, Alarm %d"), 
                n +1, LoraSettings.end_node[n].DevEUIh, LoraSettings.end_node[n].DevEUIl,
                events, open_duration,
                bitRead(status, 7),
                &battery_volt,
                bitRead(alarm, 0));
            }
          }

I very much want to move the message decode, as done above, from C to Berry simply because it allows future device decoding without LoRaWan (= Tasmota) code recompilation (as berry is interpreted at runtime).

Notice the word "occasional" above. The issue here is that on EU868 devices they use frequency and DataRate (DR) hopping to lower the blocking of LoRanWan frequency bands. I'm currently struglling to get MAC control of end-node functional. Using MAC command LinkADRReq I hope the configure the end-node from frequency hopping to one fixed frequency and DR solving the current missed frames.

At the moment I'm not working on Tasmota being a LoRaWan end-node because I do not see battery powered Tasmota having a long life-time. I agree with @cbalint13 that AC powered Tasmota LoRaWan end-nodes might be possible and if someone feels the need to write a driver I'm willing to add it to the current LoRaWan support.

[FulvioSpelta]

I agree that battery powered tasmota/LoRaWan node isn't an easy use case due the enrgy management required.

My use case is simpler because I've added the LoRaWan as an "emergency channel", so primary data collection is done using IP/MQTT and if IP go down i can collect data and send commands using LoRaWan.

The node is powered by power supply and is a class_c in order to be always RX ready.

I've hidden the LoRaWan complexity using an RAK3272-SIP module and it's AT command firmware that take care of most of the complexity and require a simple driver (the most complex part is the payload encoder).

I'll try to understand better your implementation.

My use case is full LoRaWan compliant in EU868 zone, so I've nodes (tasmota on top of a WT32-ETH01+RAK3272-SiP), gateways (Dragino and mikrotik) and my own network server based on the open ChirpStack.

[sfromis]

I suddenly remembered to accidentally having bought a couple of LilyGO LoRa T3 V1.6.1 433MHz SX1278 boards a long time ago, and gave it a shot. It seems to work, as in being able to push commands/messages across, having changed LoraConfig to 433 MHz, and this template:

{"NAME":"Lilygo T3_V1.6.1 Lora","GPIO":[1,1,1,1,1,736,1,1,1,1,1,1,1,1,10656,672,1,640,608,10688,1,544,10752,704,0,0,0,0,1,1,1,1,1,0,0,1],"FLAG":0,"BASE":1}

Board has display SSD1306 (which works), and a SD Card slot, which seems to be not configurable. The thing is that it is on a separate SPI bus, CS=13, MOSI=15, MISO=2, CLK=14.

Thus it would be nice to be able to have one of them on a 2nd SPI bus.

[dennyfmn]

Has anyone looked at the Reyax RYLR998 for connecting to remote sensors? It uses a very simple serial AT command set for control. It is a transceiver so it can send and receive. It is a simple peer-to-peer device with one-to-many and many-to-one capability. I personally think LoraWan is way too complicated for what I have in mind. Since Tasmota does such a great job integrating with Home Assistant, I think being able to use Tasmota as a gateway to the local network and Home Assistant would really be great for remote sensors. I just got two RYLR8988 modules to test using Wemos D1 Mini Pros as a transmitter and receiver and was able to get about .5 mile reception without paying much attention to line-of-sight. My use case is: one or more remote DIY sensors based on ESP32xx using the RYLR988 to communicate with a home based network running many other Tasmota based devices and Home Assistant. If a native Tasmota driver is not on the horizon, how would you approach handling the serial input data with Berry?

[dennyfmn]

You're right, there would be no benefit to using other hardware if the support is already there. Where would I go to learn about the current Tasmota Lora driver and supported hardware? I have looked on the 14.0.0 pages for supported devices, and in the Tasmota Commands page and haven't been able to find anything. Also have done Google searches for Tasmota Lora support. Thanks for your reply.

[arendst]

Look into the source code https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xdrv_driver/xdrv_73_9_lora.ino

Lines 300 and up

[dennyfmn]

Thanks! That is very interesting reading. It seems like it is very close to the bleeding edge. Do you have any idea when this might make it into the production release with some documentation and examples? I'm afraid my skill level is a little too low to use it at this point. I know you are a busy guy and really appreciate your work and patience. Thanks again for your replies.

[sfromis]

It is already included in the release versions of the source code, as an optional feature requiring a custom build.

When trying it, it was real easy to get working, configuring the relevant pins in the template (SPI pins and those starting with "LoRa". In my case tweaking the frequency in LoraConfig command/JSON to match my antenna variant.

And then there's commands LoraSend and LoraCommand which does what the name suggests. Maybe LoraOption for LoRaWanBridge if you use that, explained in the link from arendst.

Watch the console at the other end.

[arendst]

Today I default enabled lora/lorawan bridge in dev binary tasmota32.bin

[sfromis]

@arendst What about the limitation I mentioned previously, about not being able to use LoRa and a SD card at the same time, when they have separate busses? It would make sense to be able to use SPI bus 2, at least for one of the features.

[arendst]

I think it must be possible to support the second SPI bus for Lora. I will need to change the driver for it. Will need to ttest too.

TBC.

[arendst]

In addition find documentation here https://tasmota.github.io/docs/LoRa-and-LoRaWan-Bridge/

[sfromis]

With my security hat on, I came to the observation that having the LoraCommand feature is quite an open door. Anyone in reach can send a command, and if commands are already being used, the protocol for this is easily observed. Looks like just starting with 0x17 and the topic. And certain commands may be "quite inconvenient" to receive from the public....

Also noticed that the handling of commands not matching the topic is not "very clean":

15:48:30.633 LOR: Rcvd (6611805) '1778787878787878782076617232', RSSI -29.0, SNR 13.5
15:48:30.639 MQT: mylora2/tele/LORARECEIVED = {"LoRaReceived":"�xxxxxxxx var2","RSSI":-29.0,"SNR":13.5}
15:48:30.642 BRY: ERROR, bad json: {"LoRaReceived":"�xxxxxxxx var2","RSSI":-29.0,"SNR":13.5}

Maybe that feature is "too open", especially when always enabled. A safer way of handling commands could be that this is delegated to Berry code (not sure how many are using ESP8266-based devices for LoRa), and better security could be done using the cryptographic features available there.

[sfromis]

LoRaOption4 1 works, but when setting it, and having Weblog 4, I got a nuisance message:
CFG: Lora ERROR File system not ready or unable to save file
However, the changed value was saved, and I see same situation when changing LoRaConfig data.

[arendst]

Does your system have a filesystem? If not then that's why.

[sfromis]

It does have a working file system with several files, and I'm seeing the LoRaConfig data in file .drvset000, JSON object drvset73. Also, no problems doing updates via "Manage File system". That's why I only called the message a "nuisance", as the updates works. Only when having set Weblog 4 (to see details around LoRaCommand), I got a bit nervous....

[arendst]

Strange.

It should do this:

17:29:09.585-022 CMD: loraoption4 0
17:29:09.587-022 SRC: Serial
17:29:09.590-022 CMD: Grp 0, Cmd 'LORAOPTION', Idx 4, Len 1, Pld 0, Data '0'
17:29:09.599-019 MQT: stat/wemos4/RESULT = {"LoRaOption4":"OFF"}
17:29:10.890-022 CFG: Lora saved to file
17:29:10.903-022 WIF: Checking connection...
17:29:16.354-019 MQT: tele/wemos4/STATE = {"Time":"2024-05-21T17:29:16","Epoch":1716305356,"Uptime":"0T00:15:09","UptimeSec":909,"Heap":23,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Wifi":{"AP":1,"SSId":"indebuurt_IoT","BSSId":"18:E8:29:CA:17:C1","Channel":11,"Mode":"11n","RSSI":100,"Signal":-48,"LinkCount":1,"Downtime":"0T00:00:04"}}
17:29:17.159-022 CMD: loraoption4 1
17:29:17.162-022 SRC: Serial
17:29:17.165-022 CMD: Grp 0, Cmd 'LORAOPTION', Idx 4, Len 1, Pld 1, Data '1'
17:29:17.175-019 MQT: stat/wemos4/RESULT = {"LoRaOption4":"ON"}
17:29:18.151-022 CFG: Lora saved to file

[sfromis]

Yeah, something like that was what I was expecting. And I didn't see "opportunities for debugging" this weirdness.

[el-sol]

Hello!

Facing some troubles with LoRa.. I compiled the firmware (tasmota32) in PlatformIO with support for the sx1276 and sx1262 drivers, and specific pins for LoRa appeared in the configuration menu. Configured all necessary pins but when I enter LoraConfig in the console, I get the response {"Command":"Unknown"}.

Is it possible to compile tasmota w lora support for esp32-c3? For example module HT-CT62 based on esp32-c3 and sx1262 is very interesting for building nodes.

[sfromis]

Not read the specs for your replacement LoRa board, but speculatively you may be able to just pull up the tx/rx enable pins. Or maybe config as relays which you can turn on/off as you want. I can't even guess if this could actually work reasonably or not....

In your setup, I'd have used the regular broken out pins on the LilyGo board, instead of aiming for the pads from the removed module. ESP32 has a flexible gpio matrix, meaning that the pins connected to those pads are no "better" than other gpios, and in case of other components on the board affecting those pins, that might be "extra challenges".

You could even have left the old LoRa module in place, just by using different pins.

[el-sol]

I tried to solder ebyte32 to common esp32 and got this:
00:00:00.216 LOR: SX127x initialized
so everything works fine, maybe the reason was SPI CS instead of Lora CS in pin config?..

HPDTek hpd14a desoldered from TTGO also works fine with common esp32.

Not read the specs for your replacement LoRa board, but speculatively you may be able to just pull up the tx/rx enable pins. Or maybe config as relays which you can turn on/off as you want. I can't even guess if this could actually work reasonably or not...

as I understood from e32 datasheet rx - 0, tx - 1 when transmiting and rx - 1, tx -0 when recieving. Rules may be ok but how? )

[sfromis]

Depends on details of how the module operates. Simplest would to just have them high, but if you need either-or, you could have relay pins, powering on/off as appropriate, maybe with Interlock to power "the other" off when you power on the one you want.

And yes, in general you have to use a device type specific CS pin to select the chip to become active on a possibly shared SPI bus. The generic one is not meant for general usage.

[el-sol]

I want to thank Theo and everyone involved in the development of Tasmota! This firmware is very cool and has become a window into the world of IoT for me!

HT-CT62 - tested, working with LoRa correctly. There was a trouble with building firmware for esp32-c3 in VSCode on windows 10 (riscv32-esp-elf-g++: fatal error: cannot execute 'c:/..../riscv32-esp-elf/bin/as.exe), I tried everything.. Then I installed Ubuntu and tasmota32-c3 was builded successfully without any errors)))

you could have relay pins, powering on/off as appropriate, maybe with Interlock to power "the other" off when you power on the one you want

I think it will be more sophisticated to add this pins in code.. I`ll try to do it later (not c++ coder, but very interested in subj))))

[sfromis]

Yeah, what I meant with the Relay technique was mostly as a proof-of-concept, to see if such could work at all. But it could indeed make sense to enhance the driver to support such pins, for broader hardware support.