LoRa/TTN controller for ESPeasy (preview)

I’m relatively new here, only lurking. But I got addicted to LoRaWAN/TTN already.
One of the things that was bothering me is that you do need to go through quite a steep learning curve to really understand the concept of this wonderful technology and really be able to get data in and out of it.

As developer on ESPeasy, I spent the last week to make a new controller for ESPeasy.
For those that don’t know ESPeasy first a short introduction:
ESPeasy is an open source firmware for ESP8266/ESP32. A bit like Tasmota only different approach of processing data.

The main parts in ESPeasy are:

  • A plugin, interface with a sensor-device and output 1…4 sample values from that device. These values can be sent to up-to 3 controllers.
  • A controller, receiving data from a plugin and send it somewhere. (e.g. Domoticz HTTP/MQTT, OpenHAB, Generic HTTP URL, etc)
  • Rules, a scripting language to perform tasks triggered by events (e.g. time based, new sample, input change, boot, wifi connected etc.)

So I wrote a new controller for sending data from ESPeasy to TTN.

@kersing told me to go with the RN2384, so that’s what I did, but I will also add a controller using the SX127x using LMIC.

The settings section by section:

Controller Port: The port on the TTN.
This controller can send all data to the same port, the decoder.js is just looking at the first byte of the message to see what plugin is sending the data and decode it according to how the plugin has encoded the data.

Controller Queue
This part is a queuing mechanism present for all controllers in ESPeasy.
A number of plugins may send data in a short burst, but the receiving end of a controller may not be able to keep up with that. This is especially true for LoRa, where sending a single packet may take several seconds and the duty cycle rules may prevent bursting data.

Support both OTAA and ABP.
Since the RN2384 has a HW DevEUI, setting the DevEUI value is optional.

Connection Configuration
I have not added all frequency plans yet and only allow to set the spread factor.
Maybe later I will also add ADR and the option to limit the output power.
First let’s keep it simple :slight_smile:

Serial Port Configuration
Reset pin support is not implemented yet, but all other settings can be used.
As can be seen in the screenshot, Software Serial is also supported and I’ve been running it for about a week now with not really a lot of issues.
Sometimes I noticed strange characters in the HW DevEUI, so I may need to add some extra checks in the code to check replies from the RN2384.
It should run fine on HW serial too, as long as you use a PNP transistor on GPIO-15 if Serial0-swapped is being used.
I have not yet tested on ESP32, but I see no reason why it should not work on ESP32.

Device Status
Just like the text suggests :slight_smile:

I changed the way how the module does a join to prevent unneeded OTAA join requests.
The module is assumed to be connected, unless an attempt to send returns a “not_joined” reply. Then perform a join.
As long as the RN2384 remains powered, it will does not need to join again.
So the ESP node can crash/reboot or even receive a new firmware and still remain joined.

I still have to implement sleep mode on the module to support deep sleep cycles too.

This was the sending part, but the data also has to be decoded.
I got ‘inspiration’ from the ESP32-pax counter project after making a few PRs on it too get to know TTN.
Based on the decoder of that project I wrote one for ESPeasy.
Right now, all plugins are supported and decoded.
Some plugins can output more than 4 values, but in ESPeasy a user must chose which ones to output. Such choices are impossible to decode, or you need to send along the choices. This extra data can also be used just to send all data.
For now 2 plugins (sysinfo and GPS) can output a packed data stream of their data, which can be decoded on the TTN decoder part.

For example the sysinfo plugin:
“IDX”: 123,
“freeheap”: 19776,
“freestack”: 2960,
“ip”: “”,
“ip1”: 192,
“ip2”: 168,
“ip3”: 1,
“ip4”: 142,
“load”: 31.25,
“name”: “Sysinfo”,
“plugin_id”: 26,
“rssi”: -58,
“samplesetcount”: 6,
“uptime”: 5,
“valuecount”: 11,
“vcc”: -1,
“web”: 318

is decoded from: 1A 7B 00 06 0B 05 00 00 40 4D 00 C6 00 50 C0 A8 01 8E 3E 01 00 90 0B

I will add this packed form for more plugins to make sending data more efficient and also allow to send more than 4 values per plugin output.

The code is not yet included in the nightly builds, since it is still in development and I am still changing things.
See here for the decoder part: https://github.com/letscontrolit/ESPEasy/tree/mega/misc/TTN
For those that want to test it, you have to include C018 in the build.

This is just a preview, so please let me know if I do things completely wrong here, or if things can be improved.
Like I said, it is still new to me and I’m still on the steep learning curve.
Let’s hope this controller can make it easier for newcomers to start using LoRaWAN/TTN without having to know it all before starting.


nice! cool way to integrate more

Hi TD-er,
Great to see you here on TTN ! I have a few switches and power sockets on ESPeasy and really enjoy the limitless possibilities (and breaking free from vendor controlled cloud apps). I was trying to switch some lights way back in the garden and there things quickly become troublesome with wifi in terms of range (or putting expensive equipment on the outside of the house). So a LoRA controlled relay (a la Sonoff Basic) sounds like a great next step for ESPeasy. Best of luck and thank you for the hard work !! Peter

Thanks for enjoying ESPeasy as much as I do :slight_smile:
I think switching relays is just the one use case LoRaWAN/TTN is not really good for.
It is possible to get data back to the node in the field, but only as piggy back on a reply on a message sent by the node to the gateway.
So the latency for getting a command to a node depends on how often a node does send data to the gateway and also the node must be able to ‘hear’ the gateway.

However, if you place a weather station or some watering sensor for the plants in the back of your garden, then this controller to send the sensor data to the gateway would be well suited.
You could maybe even let the node know there are some updates on the rules.
These rules could be “tonight will be people in the garden, so let’s switch on the lights when it gets dark and play some music and don’t turn on the watering installation”.

But switching on demand via remote control over LoRaWAN is not really the best way I guess.

Oh and “receiving” is not yet implemented in the controller, apart from OTAA join.

This is a really great enhancement. ESPEasy made ESP’s available to a lot broader audience. Although I could have missed recent developments in the TTN area at least in the early days I recognize the steep learning curve you mention. So it seems like a very nice step forward increasing accessibility.