+852 6931 0236
[email protected]
This article will describe how to connect Atomsenses Indoor LoRaWAN Gateway to ThingsBoard.
ThingsBoard is an IoT platform for data collection, processing, visualisation, and device management. The platform enables device connectivity via industry-standard IoT protocols or stream data from devices connected to existing IoT Platforms. The platform supports both cloud and on-premises deployments, combining scalability, fault tolerance, and performance so that the users’ data remains safe.
The Atomsenses indoor gateway, acting as a wireless communication base station, has the ability to simultaneously receive 8 LoRa wireless signals. It can forward wireless data to the core network through Ethernet or 4G. Additionally, it can send data from the core network to node equipment, which enables the update of node configurations and the implementation of control commands. This gateway is widely utilized in various settings such as communities and parks to provide reliable LoRa network coverage, ensuring a safe and stable LoRa network service.
After following the steps in this guide, you will have a successfully connected and configured gateway on a network server integrated with ThingsBoard. This will allow you to add devices, receive data from them, and process the data effectively.
Login the Chirpstack configuration interface, select Gateways→ Add gateway
Copy the gateway ID in the LoRa Settings screen of the gateway's WEB configuration interface
On the Add gateway page, enter the gateway name and gateway ID and select Submit.
After above steps you should have the gateway connected to ThingsBoard via Chirpstack.
After adding devices, by sending data from the device, it will appear on the corresponding device page in ThingsBoard. You can view the data in the "Entities" -> "Devices" menu or by creating a dashboard
About how to create a dashboard, please refer to : https://thingsboard.io/docs/user-guide/dashboards/
This document outlines the primary components of a LoRa network, specifically utilizing the The Things Network (TTN) environment for illustrative examples.
The focus of this discussion will be the backend architecture of the LoRa network, emphasizing the components necessary for receiving messages, distributing Over-The-Air Activation (OTAA) identifiers, routing messages to their intended destinations, and similar functionalities.
According to The Things Network's official website, the following components are integral to a LoRa network:
The design of LoRa devices (motes) is detailed in the hardware guide, and technical aspects of their construction are beyond the scope of this document. Comprehensive technical details regarding LoRa can be found in the LoRa Specification (V 1.0.1, Oct 2015).
For the architecture of the LoRa network, it is essential to understand that devices can be integrated into the network through two activation methods:
Devices must be activated on the network before the network can process the data they transmit. While gateways will forward upstream messages, subsequent components in the network will not act on data from unrecognized devices. Activation can occur through either a fixed identity (ABP) or dynamic addressing, similar to Wi-Fi, where the network router assigns a unique address.
OTAA
OTAA is the preferred method for activating devices on the TTN. This process is analogous to connecting to a Wi-Fi network; however, it differs significantly because LoRa devices, typically simple sensor nodes, cannot be manually configured in the field. Instead, each device receives a unique ID to request a temporary unique address.
During the OTAA process, the device undergoes a join procedure and must store the following information prior to this process:
The device generates a JOIN request using its DEVEUI and APPEUI. The network must be made aware of the devices wishing to join via the application code; this is facilitated through the TTN network's ttnctl tool and web interface.
Upon acceptance of the JOIN request, the network sends a downlink message containing the DevAddr (Device address) for the device's use.
ABP
To ensure security in ABP, the network prevents unauthorized devices from assuming the identity of a node by requiring the device to maintain a frame counter. This counter confirms that both parties recognize each other as legitimate communicators.
Unlike OTAA, ABP does not involve a join procedure. Instead, the LoRa device is programmed with a unique code (DevAddr) for communication, along with the AppSKey and DevSKey, which must also be stored prior to any data transmission.
Most gateways receive messages from LoRa devices and can forward them to multiple routers, referred to as uplink messages. Gateways typically utilize a UDP connection to relay these messages to the backend router/broker, commonly through port 1700.
Gateways can also facilitate downlink messages, enabling the backend to send commands back to devices. After transmitting an uplink message, the LoRa device will check for downlink messages.
It is important to note that while LoRa gateways are sophisticated devices, they lack intelligence beyond receiving and transmitting LoRa messages across various channels and speeds to designated router servers.
Single Channel Gateways
Single Channel Gateways operate on only one channel and speed, limiting their ability to receive a complete range of LoRa messages (approximately 10% of total transmitted messages). They may be useful in low-traffic areas or for private networks serving a limited set of known devices.
These gateways do not support downlink functions and cannot forward JOIN accept messages, making them suitable only for ABP addressing. While they are more cost-effective than full-fledged LoRa gateways, their use may disrupt OTAA functions in areas where both types of gateways coexist.
Future iterations of the TTN environment are expected to accept messages from single channel gateways in a staging environment for testing purposes but will not route downlink traffic to these gateways. The potential for single channel gateways in the production environment remains uncertain, as TTN aims to prioritize full gateways.
In general, the Router, Broker, and Handler functions are combined into a single program:
Router: Receives UDP messages from gateways and forwards them to brokers. The broker monitors associated gateways to ensure compliance with TTN's fair use policy.
Broker: Acts as an intermediary between the router and application handler, identifying the appropriate handler for each device based on registered information.
Handler: Delivers MQTT messages to subscribed applications, requiring knowledge of device registrations.