Temp. + Humidity LoRaWAN
Overview
Order number: 8000004
The Lobaro LoRaWAN Humidity Sensor AM2305-LoRaWAN is a battery-powered radio transmitting sensor device that takes measurements at configurable intervals. Because of its low power consumption it can operate for multiple years with standard AA batteries. The LoRa radio technology allows it to take measurements in places that are hard to reach, and in its waterproof casing it can be installed outdoors.
The device uses an AM2305 digital relative humidity and temperature sensor probe (also known as RHT05 or DHT44). It is powered by the base device and communicates via a one-wire connection.
The Device
Operating the Humidity Sensor
The RHT05 sensor probe must be attached to the device on the external socket. Insert two 1.5V AA batteries into the slots. When the device starts, its LED flashes once. If it does not start, check that your batteries are still good and inserted the correct way. You can refer to the picture above to check that everything is connected as it should be.
When the device is set up correctly and running, put the lid on the base and fasten it from the back using the supplied screws. Watch out that the cables are safe inside the box and do not get stuck in the casing, or you might damage the cables and allow water to enter the casing. This can cause damage to the device!
Always close the lid so that the socket for the probe is on the opposing side of the antenna (picture above, sensor probe on the left, antenna on the right). This way there will be less interference on the antenna and you will get the best connection possible.
Batteries
The LoRaWAN Humidity Sensor default power supply consists of two series-connected off-the-shelf 1.5V AA-sized batteries. Be sure to get the polarity right — see the + symbol on the board. In general only AA cells of the types Alkali-Manganese (1.5V, LR6) and Lithium-Iron-Sulphide (1.5V, FR6) are allowed to be inserted in the device. Lobaro recommends the use of FR6 batteries like the Energizer Ultimate Lithium over LR6 types because of the higher capacity and better discharge properties.
On request, we can supply custom product variants with special housings powered by even bigger batteries. For example a 3.6V C sized mono cell typically has a capacity of 9Ah which leads to a 3x increased battery life compared to the standard AA-cells. With D sized cells of typically 19Ah capacity this value can be doubled once again (6x). Options with permanent external power supply (230V, 9-24V, 5V USB) are also available on request.
Installation
The device must be fixed on a flat surface using the lateral mounting holes of the case. Alternatively we offer as accessory a mounting clip for a standard 35mm DIN rail. The device can then easily be snapped on such rails. It can therefore be added to a variety of racks alongside other devices.
For optimal RF performance (e.g. LoRa range) any metal obstacles near the internal antenna should be avoided. In this case 'near' is defined as a keep-out distance of about 3-5 centimeters around the antenna. The internal helix antenna can be identified by the winding PCB traces near the white printed encircled 'connectivity' symbol. In any case a device mounting directly on top of a metal surface is not advisable since it will degrade the possible RF range. Stone walls, wood or plastic standoffs are perfectly ok. In case of challenging installation locations (e.g. in basements) or unavoidable long distances to the next LoRaWAN gateway, Lobaro offers on request a custom product variant equipped with a 'SMA' connector to support an external antenna connection.
Work Cycle
Initial Phase
This is the phase that is executed after the device is started or restarted. The LED flashes once and the configuration is evaluated. If successful, the LoRaWAN Join phase is executed next.
LoRaWAN Join Phase
If the device is configured to use over the air activation (OTAA), the OTAA Join is performed at this point. The device will repeatedly try to join its LoRaWAN network until the process is successful. It then enters the Data Collection Phase. If the device is configured to use ABP instead of OTAA, this phase is left immediately and the Data Collection Phase is entered.
Data Collection Phase
During the Data Collection Phase the device activates the sensor probe and reads measured humidity and temperature. There will be up to three attempts to get a correct reading. The communication contains a checksum value to detect data corruption between the probe and the main device. After data collection, the probe is deactivated again to save power. The device then enters the Data Transfer Phase.
Data Transfer Phase
During the Data Transfer Phase the device uploads the sensor values to the LoRaWAN network. The message contains the information if the measurement was successful. In addition to the register data, the device sends a status packet once a day during this phase. The status packet will always be transmitted prior to any data packets.
Sleep Phase
After transferring all data packets the device enters the Sleep Phase. During this it is completely inactive to avoid wasting power. It remains sleeping until the cron expression given in the configuration triggers. When that happens, it enters the Data Collection Phase again.
Configuration
The Lobaro Maintenance Tool
The initial device configuration can be done very comfortably from your PC via the serial configuration interface. Beside the needed Lobaro USB to UART adapter the Lobaro Maintenance Tool needs to be installed. This tool is freely available for various operating systems including Windows, Linux, Mac and Linux-ARM (e.g. Raspberry-PI) and works with all Lobaro sensors. Technically this software opens a webserver on port 8585 that runs in a background console window. The actual user interface can be accessed normally using a standard web browser at address http://localhost:8585. Normally your default browser should be opened with this URL automatically after tool startup. Even remote configuration and log observation over the Internet is possible, e.g. having a Raspberry PI via USB connected to the Lobaro device and accessing the maintenance tool from a remote machine's browser over the Internet. Additionally to the device setup the tool can also be used for firmware updates ('Firmware Tab'), watching real-time device diagnostic output ('Logs Tab') and initiating device restarts.
Please note that the device might be restarted each time the configuration has been changed!
Connecting the USB Config Adapter
For configuration and firmware updates we provide a special serial-USB adapter that can be connected as shown in the picture. The corresponding connector on the PCB is marked with the word 'Config'. The USB adapter will add a virtual serial 'COM' port to your system. Your operating system needs the CP210x USB to UART bridge driver installed. A download link is provided next to the 'Connect' button when you start the Maintenance Tool. While the config adapter is connected, the device will be powered from the USB port with a regulated voltage of 3.3V. It is not necessary — although it would be no problem — to have batteries inserted or a different supply connected while using the config adapter. All configuration parameters will be kept non-volatile regardless of the power supply.
System Parameters
After being successfully connected to the hardware using the Lobaro Maintenance Tool you can press 'Reload Config' in the 'Configuration' tab to read the current configuration from the device. For every parameter a default value is stored non-volatile inside the hardware to which you can revert using the 'Restore default' button in case anything got misconfigured. All LoRaWAN & other firmware parameters are explained in the following.
LoRaWAN Parameters
The connection to the LoRaWAN network is defined by multiple configuration parameters. These need to be set according to your LoRaWAN network and the way your device is supposed to be attached to it, or the device will not be able to send any data.
There are two different methods to attach a device to a LoRaWAN network: Over-the-air-activation (OTAA) and Activation-by-personalisation (ABP). Depending on which method you are using you will have to set different values.
Several values are a number of bytes, that need to be entered as hexstrings (without 0x-prefix). So e.g. the DevEUI is a value of 8 bytes encoded in hex will be 16 hexdigits long. A sample value would be 0123456789abcdef.
| Name | Used | Type | Description |
|---|---|---|---|
OTAA | both | bool | true = use OTAA, false = use ABP |
DevEUI | OTAA | hexbyte[8] | Unique 8-byte device identifier. Default is hardware-preset; only change if required by the network provider. |
AppEUI | OTAA | hexbyte[8] | ID defining the application in the LoRaWAN network. |
AppKey | OTAA | hexbyte[16] | Key used to encrypt communication with the LoRaWAN network. |
AppSKey | ABP | hexbyte[16] | Application Session Key to be synced with the LoRaWAN network. |
NetSKey | ABP | hexbyte[16] | Network Session Key to be synced with the LoRaWAN network. |
DevAdr | ABP | hexbyte[4] | Device Address used to identify device in the LoRaWAN network. |
SF | both | int | Initial LoRa spreading factor (7–12). May change during operation if ADR is enabled. |
ADR | both | bool | true = use adaptive data rate, false = don't. |
Sensor Configuration Parameters
| Name | Type | Description |
|---|---|---|
MeasureCron | string | Cron expression defining when a measurement is taken. See Introduction to CRON expressions. |
Cron Expressions
Cron expressions are used to define specific points in time and regular repetitions of them. The schedule for data collecting phases is defined using the CRON format which is a very powerful format to define repeatedly occurring events.
If needed by the target application Lobaro can deliver on request special hardware support for keeping data acquisition intervals based on a real time clock which stays in sync with the real time. Please contact Lobaro directly if you need such a custom product variant.
A cron expression consists of 6 values separated by spaces:
- Seconds (0-59)
- Minutes (0-59)
- Hours (0-23)
- Days (1-31)
- Month (1-12)
- Day of Week (SUN-SAT = [0,6])
Examples of CRON definitions:
| Expression | Description |
|---|---|
0 5 * * * * | hourly at minute 5, second 0 (at 00:05:00, 01:05:00, ...) |
0 1/10 * * * * | every 10 minutes from minute 1, second 0 (minutes 1, 11, 21, ...) |
0 0 6 * * * | daily at 6:00:00 |
0 0 13 1,15 * * | 1st and 15th day of every month at 13:00:00 |
0 0 9 1-5 * * | every month daily from day 1 till 5 at 9:00:00 |
Configuration and Battery Life
The time the LoRaWAN Humidity Sensor can operate on one set of batteries depends on the configuration of the device. Most of the time, the sensor remains in a sleep state, during which very little power is consumed (approximately 20 μA). Most power is used for sending messages via LoRa.
One set of batteries lasts for approximately 30,000 messages (depending on spreading factor and transmission power). You can estimate the battery life using the following formula:
Battery life (days) = 30,000 / messages per day
For example, with hourly updates the device sends 25 messages per day (including the daily status message), resulting in a battery life of slightly over 3 years.
LoRaWAN Data Upload Formats
After reading from the sensor probe, the device starts uploading data via LoRaWAN. There exist two data formats that are transmitted over different LoRaWAN ports.
As LoRaWAN can only transmit very short messages, the message formats contain only data bytes. The meaning of a byte is determined by its position within a message. The following describes the package formats used by the Humidity Sensor.
Multi-byte integers are transmitted as big-endian. Values that would require decimal places are transmitted in smaller units (e.g. mV instead of V). Since data packets sent over LoRa can be lost, a timestamp is added to every data packet. Timestamps are encoded as signed 40-bit big-endian integers and express the number of seconds passed since 00:00:00 January 1st, 1970 (UNIX timestamp). Timestamps are according to the device's internal clock, which might be set to an incorrect value. The timestamp always indicates the begin of the corresponding measurement phase.
We provide a JavaScript reference implementation of a decoder for this status packet on GitHub, which can be used directly for decoding in The Things Network.
Status Packet (Port 1)
In order to provide some information about the health of the device itself, the device sends a status update on a daily basis. The status packet is sent on the first upload phase after activation of the device (after reboot) and then repeatedly in every upload phase that takes place a day or longer after the previous status packet. It has a fixed length of 14 bytes.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| version | uint8[3] | 0–2 | Firmware version | 1, 0, 4 ≡ v1.0.4 |
| fl | uint8 | 3 | Status flags (internal use) | 0 |
| temp | int16 | 4–5 | Temperature inside device in 1/10 °C | 246 ≡ 24.6 °C |
| v_bat | uint16 | 6–7 | Battery voltage in mV | 3547 ≡ 3.547 V |
| timestamp | int40 | 8–12 | Internal date/time at packet creation | 1533055905 |
| mod | uint8 | 13 | Operation mode | 1 |
Data Packet (Port 2)
The data packet is used to transmit the measured environmental values. It includes a timestamp and the information if the measurement was successful. The data packet has a fixed length of 10 bytes. Please remember that the timestamp is always in reference to the device's internal clock, which normally does not know the real time — it is still usable to put data points into real time context if you take one reference and calculate the offset of the device's clock to real time.
| Name | Type | Bytes | Description | Example |
|---|---|---|---|---|
| timestamp | int40 | 0–4 | UNIX timestamp for measurement | 1533055905 |
| err | uint8 | 5 | Error indicator: 0 = success, 1 = error | 0 |
| humidity | uint16 | 6–7 | Relative humidity in 1/10 % | 318 ≡ 31.8 % |
| temperature | int16 | 8–9 | Temperature in 1/10 °C | -105 ≡ -10.5 °C |
Sensor Specification
Technical Characteristics
| Property | Value |
|---|---|
| Product | |
| Type name | AM2305-LoRaWAN |
| Description | LoRaWAN Humidity Sensor |
| RF Transceiver | |
| Chipset | Semtech SX1272 |
| Frequency range | 863–870 MHz |
| TX power | ≤ 14 dBm |
| Typical RF range | ≤ 2 km |
| Ideal RF range | ≤ 10 km (free line of sight) |
| LoRa Communication | |
| LoRaWAN protocol | LoRaWAN 1.0.1, Class A, EU868 |
| Activation method | OTAA / ABP |
| Encryption | AES128 |
| Power | |
| Power supply | 2× AA battery, 1.5 V, LR6/FR6 |
| Supply voltage | U_nom = 3.0 V, U_min = 2.2 V, U_max = 3.7 V |
| Capacity | ~30,000 LoRaWAN messages @ SF11 |
| Humidity Sensor (Probe) | |
| Range | 0–100 % rH |
| Accuracy | ±2 % rH (max ±5 % rH) |
| Resolution | 0.1 % rH |
| Temperature Sensor (Probe) | |
| Range | -40 °C to 80 °C |
| Accuracy | ±0.3 °C |
| Resolution | 0.1 °C |
| Mechanical Dimensions | |
| Size (box) | 114.3 mm × 59.3 mm × 26.8 mm |
| Size (probe) | 100 mm × 16 mm |
| Housing material | ABS plastic |
| Environmental Requirements | |
| Operating temperature | -20 °C to +55 °C |
| Max. installation height | 2 m |
| Conformity | |
 |
Target Measurement / Purpose
Temperature and relative humidity measurements with external probe and LoRaWAN.
PDF Documentation
Parser
The Things Network (JavaScript)
/**
* TTN-compatible data decoder for the Lobaro LoRaWAN Humidity Sensor.
*/
function readVersion(bytes) {
if (bytes.length < 3) {
return null;
}
return "v" + bytes[0] + "." + bytes[1] + "." + bytes[2];
}
function int40_BE(bytes, idx) {
bytes = bytes.slice(idx || 0);
return bytes[0] << 32 |
bytes[1] << 24 | bytes[2] << 16 | bytes[3] << 8 | bytes[4] << 0;
}
function signed(val, bits) {
if ((val & 1 << (bits - 1)) > 0) {
var mask = Math.pow(2, bits) - 1;
val = (~val & mask) + 1;
val = val * -1;
}
return val;
}
function int16_BE(bytes, idx) {
bytes = bytes.slice(idx || 0);
return signed(bytes[0] << 8 | bytes[1] << 0, 16);
}
function int16_BE_1c(bytes, idx) {
bytes = bytes.slice(idx || 0);
var v = (bytes[0] & 0x7f) << 8 | bytes[1] << 0;
if (bytes[0] & 0x80) {
return -v;
} else {
return v;
}
}
function port1(bytes) {
return {
"port": 1,
"version": readVersion(bytes),
"flags": bytes[3],
"temp": int16_BE(bytes, 4) / 10,
"vBat": int16_BE(bytes, 6) / 1000,
"timestamp": int40_BE(bytes, 8),
"operationMode": bytes[13]
};
}
function port2(bytes) {
return {
"port": 2,
"timestamp": int40_BE(bytes, 0),
"error": !!(bytes[1] & 0x01),
"humidity": int16_BE(bytes, 6) / 10.0,
"temperature": int16_BE_1c(bytes, 8) / 10.0
};
}
function Decoder(bytes, port) {
switch (port) {
case 1:
return port1(bytes);
case 2:
return port2(bytes);
}
return {"error": "invalid port", "port": port};
}