mirror of
https://github.com/letscontrolit/ESPEasy.git
synced 2026-09-12 09:36:59 +00:00
Gijs Noorlander
022ca8a6ec
For LoRa, it may take a while to send out samples of different plugins. This makes it hard to match samples belonging to the same set after receiving them. The Sample Set Initiator is a task index which should always be considered as the first of a set samples sent to the controller. For example when triggering to send a set of samples from rules, its order can be always the same. Setting the initiator to the first one of the sequence, the same sample set counter will be sent along with the samples.
158 lines
6.1 KiB
ReStructuredText
158 lines
6.1 KiB
ReStructuredText
.. include:: _controller_substitutions.repl
|
|
|
|
.. _C018_page:
|
|
|
|
|C018_typename|
|
|
==================================================
|
|
|
|
|C018_shortinfo|
|
|
|
|
Controller details
|
|
------------------
|
|
|
|
Type: |C018_type|
|
|
|
|
Name: |C018_name|
|
|
|
|
Status: |C018_status|
|
|
|
|
GitHub: |C018_github|_
|
|
|
|
Maintainer: |C018_maintainer|
|
|
|
|
Change log
|
|
----------
|
|
|
|
.. versionadded:: 2.0
|
|
...
|
|
|
|
|added|
|
|
2019/08/13 First occurrence in the source.
|
|
|
|
Description
|
|
-----------
|
|
|
|
`The Things Network (TTN) <https://www.thethingsnetwork.org/>`_ is a global open LoRaWAN network.
|
|
LoRaWAN allows low power communication over distances of several km.
|
|
|
|
A typical use case is a sensor "in the field" which only has to send a few sample values every few minutes.
|
|
Such a sensor node does broadcast its message and hopefully one or more gateways may hear the message and route it over the connected network to a server.
|
|
|
|
The data packets for this kind of cummunication have to be very short (max. 50 bytes) and a sender is only allowed to send for a limited amount of time.
|
|
On most frequencies used for the LoRa networks there is a limit of 1% of the time allowed to send.
|
|
|
|
Such a time limit does also apply for a gateway. This implies that most traffic will be "uplink" data from a node to a gateway.
|
|
The analogy here is that the gateway is often mounted as high as possible while the node is at ground level ("in the field")
|
|
|
|
There is "downlink" traffic possible, for example to notify some change of settings to a node, or simply to help the node to join the network.
|
|
|
|
In order to communicate with the gateways in the TTN network, you need a LoRa/LoRaWAN radio module.
|
|
|
|
The radio module does communicate via the LoRa protocol. On top of that you also need a layer for authentication, encryption and routing of data packets.
|
|
This layer is called LoRaWAN.
|
|
|
|
There are several modules available:
|
|
|
|
- RFM95 & SX127x. These are LoRa modules which needs to have the LoRaWAN stack implemented in software
|
|
- Microchip RN2384/RN2903. These are the modules supported in this controller. They have the full LoRaWAN stack present in the module.
|
|
|
|
|
|
Nodes, Gateways, Application
|
|
----------------------------
|
|
|
|
A typical flow of data on The Things Network (TTN) is to have multiple nodes collecting data for a specific use case.
|
|
|
|
Such a use case is called an "Application" on The Things Network.
|
|
For example, a farmer likes to keep track of the feeding machines for his cattle.
|
|
|
|
So let us call this application "farmer-john-cattle".
|
|
|
|
For this application, a number of nodes is needed to keep track of the feeding machines in the field.
|
|
These nodes are called "Devices" in TTH terms.
|
|
For example a device is needed to measure the amount of water in the water tank and one for the food supply.
|
|
|
|
Such a device must be defined on the TTN console page.
|
|
|
|
There are two means of authenticating a device to the network (this is called "Join" in TTN terms):
|
|
- OTAA - Over-The-Air Authentication
|
|
- ABP - activation by personalization
|
|
|
|
With OTAA, a device broadcasts a join request and one of the gateways in the neighborhood that received this request,
|
|
will return a reply with the appropriate application- and network- session keys to handle further communication.
|
|
|
|
This means the device can only continue if there is a gateway in range at the moment of joining.
|
|
It may happen that a gateway does receive the join request, but the device is unable to receive the reply.
|
|
When that's happening, the device will not be able to send data to the network since it cannot complete the join.
|
|
Another disadvantage of OTAA authenticating is the extra time needed to wait for the reply.
|
|
Especially on battery powered devices the extra energy needed may shorten the battery life significantly.
|
|
|
|
With OTAA, the device is given 3 keys to perform the join:
|
|
|
|
- Device EUI - An unique 64 bit key on the network.
|
|
- Application EUI - An unique 64 bit key generated for the application.
|
|
- App Key - A 128 bit key needed to exchange keys with the application.
|
|
|
|
The result of such an OTAA join is again a set of 3 keys:
|
|
|
|
- Device Address - An almost unique 32 bit address of your device.
|
|
- Network Session Key - 128 bit key to access the network.
|
|
- Application Session Key - 128 bit key to encrypt the data for your application.
|
|
|
|
|
|
The other method of authenticating a device is via ABP.
|
|
ABP is nothing other than storing the last 3 keys directly on the device itself and thus skipping the OTAA join request.
|
|
This means you don't need to receive data on the device and can start sending immediately, and even more important, let your device sleep immediately after sending.
|
|
|
|
A disadvantage is the deployment of the device. Every device does need to have an unique set of ABP keys generated and stored on the device.
|
|
|
|
Updating session keys may also be a bit hard to do, since it does need to ask for an update and must also be able to receive that update.
|
|
|
|
|
|
|
|
Hybrid OTAA/ABP
|
|
---------------
|
|
|
|
TODO TD-er.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Configure LoRaWAN node for TTN
|
|
------------------------------
|
|
|
|
A LoRaWAN device must join the network in order to be able to route the packets to the right user account.
|
|
|
|
Prerequisites:
|
|
|
|
- An user account on the TTN network.
|
|
- A TTN gateway in range to send data to (and receive data from)
|
|
- Microchip RN2384 or RN2903 LoRaWAN module connected to a node running ESPeasy. (UART connection)
|
|
|
|
On the TTN network:
|
|
- Create an application
|
|
- Add a device to the application, either using OTAA or ABP.
|
|
|
|
In order to create a new device using OTAA, one must either copy the hardware Device EUI key from the device to the TTN console page,
|
|
or generate one and enter it into the controller setup page in ESPeasy.
|
|
The Application EUI and App Key must be copied from the TTN console page to the ESPeasy controller configuration page.
|
|
|
|
Using these steps, a device address is generated.
|
|
Such an address looks like this: "26 01 20 47"
|
|
Also the Network Session Key and Application Session Key can be retrieved from this page and can even be used as if the device is using ABP to join the network.
|
|
But keep in mind, these 3 keys will be changed as soon as an OTAA join is performed.
|
|
|
|
Device configuration with solely an ABP setup are more persistent.
|
|
|
|
|
|
Decoding Data
|
|
-------------
|
|
|
|
|
|
Controller Settings
|
|
-------------------
|
|
|
|
|
|
|