Discover the possibilities offered by the integration of Unipi indoor air quality sensor featuring LoRa wireless communication.
In recent years, the popularity of low-power radio standards has been steadily growing. These technologies utilize unlicensed, freely accessible frequency bands of up to 1 GHz and are thus referred to as Sub-GHz. The characteristic feature of Sub-GHz technologies is the utilization of narrow bands, making them unsuitable for transferring large amounts of data. As such, they are used mostly in devices designed for location tracking, measuring physical quantities or collecting data from energy meters. Such applications are then collectively referred to as the Internet of Things (IoT).
Using a simple showcase project, this article demonstrates work with a wireless communication device, specifically an indoor air quality sensor. The device utilizes the LoRa standard - a typical representative of Sub-GHz radio standards.
LoRa in Unipi products
LoRa-compatible devices among Unipi products are represented by RLW-TH and RLW-THC indoor air quality sensors designed for installation in interiors of office buildings, schools, factory halls, hotels, conference rooms and other similar objects. Sensors can measure up to six parameters:
- CO2 concentration (RLW-THC only),
- volatile organic compound (VOC) concentration index,
- relative humidity,
- ambient light intensity,
- atmospheric pressure.
On Unipi IAQ sensors, the LoRa interface can be easily activated and managed using a clear web configuration interface.
In order to read data from the sensor, we need to receive them first, decode them and then provide the data to an application using a defined API. The application can take the form of a programmable logic controller, database on a remote server, or a specialised software in supervision centre. The LoRa connectivity itself can be then provided using one of the following methods:
- Public operator, ie. a commercial subject that maintains a network of LoRa gateway covering a defined area (eg. a single country). As an advantage, public operators guarantee accessibility and quality of coverage. On the other hand, your project becomes dependent on a single company and its monetary politics.
- A private network, allowing you to cover only a specific area independently on other users (eg. individual buildings and their immediate surroundings, factory halls, hotels etc.). The main advantage of this approach is the absolute independence of such a network.
- A community network of gateways run and maintained by multiple independent subjects, be it volunteers or organisations, that share a common server stack. This solution can provide coverage for both small (ie. a city district) and large (entire continents) areas. The most popular community network that includes thousands of LoRa gateways all over the globe is The Things Network (TTN).
Due to differences between individual networks, national specifics and APIs used by commercial operators, the first option will not be discussed further.
TTN community network
Community network represents an ideal method to get acquainted with LoRa. Among its main advantages are a wide user base, extensive documentation and availability of technical support provided by TTN. Naturally, there are disadvantages as well - limited coverage that usually includes only large cities of some countries. In this case, all you need to do is to install one or more gateways and register them into a community network. The main benefit here is the server (ie. LoRaWAN network server) is provided by TTN and users don’t need to operate their own servers (virtual or physical).
Integration of TTN into user application can be performed in several ways:
- SDK suited for a specific programming language (such as SDK’s for Java, Python, GO, etc.). SDK’s also include interfacing both for a two-way data communication and for application management (adding/removing gateways or end devices),
- data communication via MQTT - a widespread IoT protocol supported by a variety of tools and environments (eg. Node-RED),
- HTTP API for application management.
In the following steps, we will demonstrate how to create and start a showcase application utilizing the RLW-THC sensor.
1. Registration/subscription to TTN
The first step is to have a user account on the https://www.thethingsnetwork.org/ website. If you don’t have it, you can create one by clicking on Sign up.
2. Creating an application + sensor registration
Upon logging into your user account, you need to assign an application by clicking Console->Applications -> Add application. Then enter Application ID (will be included in a topic name for MQTT - see below) and add its brief description. Finish the application creation by clicking on Add application.
3. Registering the RLW-THC IAQ sensor
The next step is to register one or more devices into the application. Switch to the Devices tab in the created application’s detail and click on Register Device.
Then enter the following info:
- Device ID - selectable by the user, must be unique within the application,
- Device EUI - device identification generated by the device, inserted into the TTN form,
- Application EUI - application identification, generated by TTN, must be entered into the device,
- Application Key - encryption key, generated by TTN, must be entered into the device.
4. Functionality test
If you performed all previous steps correctly, the device should soon send its first message:
In order to save bandwidth, all measured values are transmitted via LoRa in a binary format that must be decoded first. TTN features an option to add a source code into the application for automatic decoding. Resulting data received by the user application is then already decoded and contains values of all measured parameters in the JSON standardized format. Decoder source code can be added by clicking on Application -> Payload Formats -> Decoder. For the Unipi sensors, the code can look like this: https://kb.unipi.technology/_media/decoder.zip.
5. Demonstration of receiving data via MQTT
The MQTT protocol is characterized by its simplicity and wide support across various programming languages, development environments and other tools. This makes it an ideal solution for IoT applications, specifically for transmitting data from end devices into control applications. MQTT utilizes a so-called producer/consumer model, in which a consumer subscribes to receive messages from one or more topics. A topic can be represented by messages containing measured data from one or more sensors, or events such as sensor registration into the network. A so-called MQTT broker then serves as an intermediate between producer and consumer.
In our case, the RLW-THC is the producer, while TTN acts as a broker. The MQTT Explorer open-source too (available on this link) is then used as the consumer.
To subscribe for MQTT messages you need to enter the following info:
Broker’s server address - in our case, we will use the EU TTN address:
Port - a default TCP port for nonencrypted connection (used in this article) is 1883,
Username - the Application ID entered during application creation (see Registering the RLW-THC sensor above),
Password - an access key bound to the application, can be found on the TTN website, section Applications -> Overview -> Access Keys. Multiple keys can be generated for a single application and can have different permission levels.
A topic filter can be also set up in the Advanced section upon entering the info listed above. The default value is the # symbol representing a so-called “wild card”. This symbol is used for the subscription to all topics published within the application.
Regarding TTN, the chain determining a specific topic has the following format:
<Application ID>/devices/<Device ID>/up
For subscription to messages with measured data from a single specific IAQ sensor, the topic will look like this:
Upon establishing a connection by clicking on Connect all incoming messages are logged. Fields containing numeric values can be then visualised in a graph.
Usage examples of LoRa sensors:
A solution based on commercial or community LoRa infrastructure and extendable by additional gateways is suitable for a wide range of applications. Below are several examples:
- Wireless data collection from residential or administrative spaces preventing the use of Wi-Fi (eg. connection is managed by individual residents or limitations of regular AP range),
- Data collection from remote objects, removing the need for connection management via the internet (public IP, VPN/IPsec tunnels etc.),
- Data collection from objects lacking any internet connectivity - when compared to GSM/LTE gateway LoRa offers significantly decreased energy requirements and operating costs,