Today, I can present you a diamond: The Farm Data Relay System.
A network using LoRa and ESPnow that does not rely on infrastructure like TTN.
And it is not only for farms.
It is universal.
Grüezi YouTubers.
Here is the guy with the Swiss accent.
With a new episode and fresh ideas around sensors and microcontrollers.
Remember: If you subscribe, you will always sit in the first row.
Timm is a farmer, and he had to solve a problem: He had to monitor different greenhouses on
the farm he worked.
Some of these sensors were close and others further away.
That is why he built a new network consisting of LoRa sensors for the long-range and ESPnow
sensors for the short-range.
And he added an MQTT gateway to the internet as well as repeaters to extend range.
And he did this in a very flexible way.
This is why it can cover most of our network needs.
Without TTN and Wi-Fi access points.
How cool is that?
So let’s start with a short introduction to LoRa and ESPnow.
Then we will see the advantages of this setup over a LoRaWAN like TTN or Helium or Wi-Fi
with access points.
And then, I will show you a typical network setup.
Finally, we will configure the nodes and test them
LoRa is a slow but long-range protocol.
It can easily bridge many kilometers if there is a line of sight.
It is often used in LoRaWAN configurations.
These networks need expensive gateways and are very limited in the number of messages
you are allowed to transfer.
FDRS has no such limitations or costs.
It works with standard LoRa boards.
ESPnow is a Wi-Fi protocol invented by Espressif.
It is peer-to-peer and does not need access points or the internet.
Its range is similar to Wi-Fi and, therefore, is much shorter than the LoRa range . Because
all ESP chips have it built-in, it is very cheap.
To show you the capabilities of FDRS, I will implement this network: Two sensors, one using
LoRa and the other ESPnow, are connected to a gateway.
The ESPnow node via a repeater extending its range.
The gateway transfers its messages via an MQTT gateway to node-red.
The ESPnow repeater runs on an old ESP8266 and the MQTT gateway on an ESP-01 to show
you how cheap it can be done.
Nodes can be mixed and matched with ESP8266 and ESP32s.
And as we see, it is a star network, not a mesh, which could easily be extended with
more sensors, LoRa to ESPnow gateways, and LoRa to LoRa repeaters.
Repeaters extend the range, and gateways change the mode of transport.
They use the same code.
So the whole network consists of only two node types: Sensors and gateways/repeaters.
How can this be done?
Timm uses a simple model: If the needed hardware is available, all nodes can use LoRa, ESPnow,
Wi-Fi, and Serial as in- and output.
These “channels” can be mixed and matched.
That is all.
Extremely modular.
What do we need in addition?
Two things: First, a numbering scheme for the whole network.
Currently, each node gets a unique 8-bit number.
And second: FDRS works with standard sensor types, similar to BLE.
Currently, these are the definitions.
But they can and for sure will be extended.
First, we have to get the code.
I suggest you use the example files because they are already preconfigured for the network
I will use in this video.
Download or fork the FDRS project and go to the examples folder.
Then move the FDRS_install folder into your Arduino libraries folder and edit these files
in your libraries folder according to your needs with your Wi-Fi credentials, LoRa frequency,
etc.
Never edit them in the downloaded location!
Now you can open the individual ino files, choose the node's platform, and upload it.
I always open the files with another instance of the IDE.
Then I can define the board and the port independently for every node.
So let’s assume we uploaded all five nodes to five boards.
Now we can follow a message from the LoRa sensor to node-red.
The sensor sketch is simple.
The setup is one line, and the loop consists of a few more.
A humidity sensor is read and “loaded” to FDRS.
You see, Timm is a farmer and loads things on trailers!
Then an optional second value.
I always propose transferring battery voltage if the sensor is battery-operated.
You could also add a third or a fourth value.
Then the message is transferred, and the node goes to deep sleep.
That is all.
If debug is on, we see that it transmits messages from time to time.
Please do not forget the connection between GPIO16 and RST if you use an ESP8266 like
me.
I had to remember when it stopped working because lately, I mainly use ESP32s.
The main sketch does not have to care about the transport method or which address the
message should go to.
This is done in the sensor_setup.h file.
Here we can assign a nodeID and define to which gateway the message will be transferred.
We also can choose LoRa or ESPnow as a transport protocol.
And we have to define the pins for the LoRa module if available.
Other, more common definitions like the frequency or the Spreading Factor can be made in the
fdrs_default.h file in the libraries folder.
These settings are the same for all nodes.
Otherwise, they would not communicate.
For our second sensor, we chose ESPnow, and the target gateway has UNIT_MAC #03.
So let’s have a look at the sketch of the repeater which receives the ESPnow message
and transmits it as an ESPnow message: Its sketch is a bit more complicated.
But fortunately, we do not have to bother with it.
We only have to adjust the configuration.
And now we come to Timm’s “invention”: These defines create the modularity.
A gateway receives messages on ESPnow or LoRa or both, and, as soon as a message arrives,
it executes an action.
If an ESPnow message arrives, the action is this one.
And here, we define where the message has to be sent.
Because this is an ESPnow repeater, it transmits all received ESPnow messages via ESPnow to
the next gateway with the number 0x04.
Precisely as drawn in the diagram.
This board has no LoRa module, BTW.
To get used, we have a glimpse of the definition file of the next gateway: Its UNIT_MAC is
0x04 and it receives ESPnow and LoRa messages and transfers both to Serial.
And on the serial connection, we connected the MQTT gateway, which transfers the messages
to Node-Red.
ESP32 boards use Serial2 with the pins of the config file.
The ESP8266 uses Serial because it has only one serial interface.
So debugging has to be switched off for the ESP8266 using Serial.
Why did Timm choose one node to receive ESPnow messages and one to transfer them to Wi-Fi?
ESPnow and Wi-Fi work on the same frequencies, and I am unsure if both work in parallel on
one board without restrictions.
And Timm’s way of using two boards also has an advantage: Modularity.
And such an ESP-01 does not cost an arm and a leg.
The setup of the MQTT gateway is here: It receives Serial messages and sends them via
MQTT.
So what do we expect if we switch all the nodes and sensors on?
We expect the fake sensor values from the two nodes to be transferred to node-red.
The only thing we have to do is to create this simple flow, add our MQTT broker, and
define the data topic.
Because the data come in JSON format, we convert them here.
And now we see the messages coming—one from sensor #1 and one from sensor #2.
One via LoRa and the other via ESPnow and a repeater.
Cool.
I hope you see the potential of this project: Connect several remote sensors via ESPnow
to a LoRa repeater for the long haul back to your building, for example.
Or another viewer's use case: Time-keeping with distributed nodes over a few 100 meters.
Here we could use T-beams with a GPS module to measure precise time and transfer it back
via LoRa.
Or another viewer who asked about a solution for their e-car chargers.
He wants to build a display to show free chargers.
Maybe he can use a combination between LoRa and ESPnow?
What is your idea?
Let’s discuss this in the comments.
This project has two caveats: Currently, it is only a sensor network and cannot transmit
commands.
The second is that there is no message confirmation and retransmitting.
But Timm is working on it, and I am sure he will succeed.
And maybe after this video, he gets some help?
After watching video #425, you should have enough know-how to fork his project and create
pull requests.
This was all for today.
As always, you find all the relevant links in the description.
I hope this video was useful or at least interesting for you.
If true, please consider supporting the channel to secure its future existence.
Thank you!
Bye