LoRa/LoRaWan "Heltec ESP32 LoRa V2" device support

[tsegula]

I am just starting with LoRa technology.
I saw there has been work done with the C018 Controller Plugin.

My first question is how do I get the LoRa TTN - RN2483/RN2903 Controller to be included with an IDE build? When I search the available controllers it is not included even though its .ino appears to be included.

It looks like it was written for the RN2483/RN2903 controllers but I was wondering if it could work with the integrated Heltec ESP32 LoRa v2 cards using the SX1276 chips?

I have also purchased a TAK7258 Gateway (with TTN and MQTT support).

Of course I purchased first and investigated later.

Long distance sensor data is certainly my first usage case. The traditional, Node(device/ESPEasy) ==> LoRa Gateway ==> TTN/MQTT ==> Automation Server path, is pretty straight forward.

However, I would also like to see a method for simple remote node control: Automation Server ==> MQTT ==> LoRa Gateway ==> Node(device/ESPEasy) ==> GPIO/Relay .
Another possibility might be: Automation Server ==> MQTT ==> ESPEasy TX node ==> P2P via LoRA ==> ESPEasy Remote Rx node ==> GPIO/Relay.

What are your thoughts on these issues. Any other suggestions?

Thanks!

[TD-er]

The C018 controller must be "enabled" in your build configuration first.
This can be done in several ways, but all end up in defining this:

Code: Select all

#define USES_C018

You can change this file: https://github.com/letscontrolit/ESPEas ... gin_sets.h
Or try building a "custom" build (this needs PlatformIO, not Arduino IDE)

A custom build can be defined in these Python files: https://github.com/letscontrolit/ESPEas ... /tools/pio
Either use the pre_custom_esp32.py or pre_custom_esp82xx.py for the right CPU.

Or you rename the included Custom-sample.h to Custom.h and change it.
Using the Custom.h file option still requires you to build using PlatformIO (and call a "custom" environment to build) as this does a few checks to see if a Custom.h file is present.
For Arduino IDE, see here what to do: https://espeasy.readthedocs.io/en/lates ... g-custom-h

Controller C018 does not support the bare SX127x chips.
The Microchip RN2483 has its own controller + included LoRaWAN stack implemented, so all the hard work is already done and you only need to talk to it via serial.
When using the SX127x chips, the complete LoRaWAN stack must be run on the ESP.

Keep in mind that LoRaWAN is not designed to work as a "remote control".
It is possible to send data back from the TTN network to a node, but that can only be done in a very small window after the node sends data.
So if a node only sends data every hour, it may take upto an hour before your message to the node is received by the node.

Apart from that, any LoRaWAN device may only send for 1% of the time. (per channel)
This rule also applies to a gateway.
So if a gateway needs to send a lot of downstream messages, it will quickly run out of this 1% limit and cannot send anymore till it has been quiet long enough.
N.B. From gateway to node is always "down", from a node to a gateway is always "up", even if the node is at an higher altitude.

[michael067]

hello,

i have activated the rn2483 controller and i send the data to the lora network but i don't understand the payload, can you explain it?

010200110100000000 : switch 0 to idx 2
010100110110270000 : switch 1 to idx 1

thanks

[TD-er]

Have you added the .js files in the misc/TTN folder to the decoder and converter settings on the TTN console?

On the TTN console, you have created an "Application" and added one or more "Devices" for it. (otherwise you cannot send stuff as you don't have the proper Application EUI, etc.)
On the page of your "Application" you have the tabs:
Overview, Devices, Payload Formats, Integrations, Data, Settings.

On the "Payload Formats" tab you have the "decoder" and "converter" parts where you need to copy/paste the .js files from the misc/TTN folder.

After saving it, you can see the decoded values on the "Data" tab where you receive the decoded values.

For example the decoded data of your second line (010100110110270000):

Code: Select all

{
  "header": {
    "IDX": 1,
    "plugin_id": 1,
    "samplesetcount": 17,
    "valuecount": 1
  },
  "name": "Switch",
  "v1": 1
}

[michael067]

thanks, i don't use ttn ( it's my second use case with my gateway ttn ) my first use case is with orange french lora network.
ok for plugin, idx, samplesetcount but why 1027 for 1 and 0000 for 0.
i create a decoder for it after my understanding.

the js file is https://github.com/letscontrolit/ESPEas ... decoder.js ?

[TD-er]

As you may have seen, I have made a generic way to post "float" values into 32 bit int.
First the value is multiplied with 10000 (to keep 4 decimals) and then turn it into an int and send it.
On the decoder side I divide it by 10000 to get the original value.

For some specific plugins, where we can make more educated guesses, like GPS and system info, the data is compressed a bit more.
For example altitude can be stored in 16 bit, HDOP in 8 bit and longitude/latitude in 24 bit where we use the full range for -180 ... +180 for longitude and -90..+90 for latitude.

The main reason it hasn't been done for all plugins is simply because it takes time to encode the RAW stream in as short message as possible.
So to just support all, I just chose a default of x10000 and convert to 32 bit int.

The header is 5 bytes as you can see in the decoder.

So it really isn't rocket science

[tsegula]

Since my initial post on this thread I have refined my approach to finding a solution for long distance 2-way communication to a remote ESPEasy node.
The ESPEasy builds cannot easily accommodate the LoRaWAN communitcation stack.
The ESP32 LoRa boards (Heltec) cannot easily accommodate the code changes to provide the flexible device configurations provided by ESPEasy.
What I would like to do is use a remote LoRa board as a gateway to a remote ESPEasy node via a generic I2C channel.
I would like to see a payload able to pass from the ESPEasy node to the LoRa node and visa versa using a simple I2C channel.
I realize sending downlink data to the LoRa node configured as a Class A device can only occur after an uplink is received but that is acceptable.
However, I could also configure the LoRa node as Class C which would leave the receiver of the LoRA node on continuously.
I have all the 2-way communication issues worked out to the remote LoRa node. I just need the final step of getting the LaRa node communicating via I2C to the ESPEasy node.

Automation Server <==MQTT==> LoRa Gateway <==LoRa (4Km)==> LoRa ESP32 Node <==I2C==> ESPEasy ESP32 Node

What would be involved in getting a generic I2C plugin for this purpose?
Is there one available? I saw some historical posts from a couple of years ago that there was some work being done on a generic I2C plugin.

[Ath]

Would it be feasible to use a serial connection for this? That's a) much easier as already possible in ESPEasy, and b) less work as I2C isn't really a generic serial protocol, but rather a push/pull device protocol. You'd need some sort of I2C slave 'controller' on the LoRa-Wan device to support that, where serial is probably already supported

[enesbcs]

Since my initial post on this thread I have refined my approach to finding a solution for long distance 2-way communication to a remote ESPEasy node.

LoRa/Sx1278 P2P controller is available in mPyEasy, if it suits your needs. Its a P2P protocol which follows the same logic as ESPEasyP2P without any gateway or Lorawan. Two peer can share dedicated Tasks and its values to each other, or can reach other peers with "loracommand,[unitnumber],[command]" - which works similarly than "sendto" in ESPEasyP2P.

I've tested it with mPyEasy and RPIEasy:
ESP32 + Sx1278 <----> ESP32 + Sx1278
ESP32 + Sx1278 <----> RaspberryPi + Sx1278
RaspberryPi + Sx1278 <----> RaspberryPi + Sx1278

In EU the 869.4-869.65Mhz range can be used at 10% duty cycle, but yes, other channels may be used with 1% or 0.1%. It may be a good approach to queue messages that do not fit inside the time window, but now it is dropped simply in my code.