Wi-Fi does not reach the bottom of the garden. Zigbee needs a chain of mains-powered routers to get to the shed, and there is no socket at the gate or the rain barrel. This is where LoRaWAN earns its place: a battery sensor that sends a few bytes from hundreds of metres or even kilometres away and runs for years on a pair of cells. It is not a replacement for your home network, though, and the limits are strict. This guide explains what LoRaWAN is good at, the rules you have to live with in Europe, and how to get the first sensor's data into your own MQTT broker.
What LoRaWAN is, and what it is not
LoRa is a radio modulation. LoRaWAN is the network protocol on top of it. In Europe it uses the EU868 band around 868 MHz. Three parts make up a LoRaWAN system:
- End devices: sensors, buttons, meters. They broadcast short packets.
- Gateways: receivers that pick up packets from any device in range and forward them over the internet. A gateway does not decode your data and is not paired with specific devices.
- A network server: it checks, deduplicates and decrypts the packets and hands them to your application. The Things Network (TTN) runs a free community one; ChirpStack is an open-source server you can host yourself.
Think of LoRaWAN as a way to report small readings: temperature in the greenhouse, soil moisture, water level, "mailbox opened", the pulse count from a water meter. Video, audio, firmware downloads and instant switching are not what it is built for.
The limits you have to plan around
Airtime and duty cycle
European rules (ETSI EN 300 220-2) limit how much of the time a device may transmit in each sub-band. For most LoRaWAN channels in EU868 that limit is 1%. The TTN documentation lists the sub-bands: 863-865 MHz at 0.1%, 865-868 MHz at 1%, 868-868.6 MHz at 1%, 869.4-869.65 MHz at 10%, among others. Gateways have to obey the same rules, which matters for messages sent to a device.
How much airtime a message uses depends on the spreading factor (SF7 to SF12). Higher spreading factors reach further and are received at lower signal levels (the TTN docs give -123 dBm sensitivity at SF7 and -137 dBm at SF12 at 125 kHz), but each step roughly halves the data rate. Using the standard LoRa airtime formula, the same one TTN's airtime calculator uses, a 10-byte reading (23 bytes on air with the LoRaWAN header) takes about:
| Spreading factor | Airtime | Minimum gap at 1% duty cycle |
|---|---|---|
| SF7 | about 62 ms | about 6 s |
| SF9 | about 206 ms | about 21 s |
| SF10 | about 371 ms | about 37 s |
| SF12 | about 1.48 s | about 2.5 min |
The TTN fair use policy
On The Things Network's public sandbox there is an extra rule on top of the law: each device gets 30 seconds of uplink airtime per 24 hours and 10 downlink messages per day. With the numbers above, that means roughly 480 small messages a day at SF7 but only about 20 at SF12. A sensor far from a gateway that reports every 5 minutes simply does not fit. On a private network (for example your own ChirpStack) the fair use policy does not apply, but the legal duty cycle still does.
Device classes
The specification defines three classes. Every device supports Class A: it sends when it wants, then opens two short receive windows. A message for the device can only be delivered right after it has sent something, which is why Class A runs for years on batteries and also why "turn the valve off now" can take until the next report. Class B adds scheduled receive slots synchronized by gateway beacons. Class C listens almost all the time, so it reacts fast but is usually mains powered. For home use, expect Class A sensors and treat LoRaWAN as one-way reporting with occasional configuration changes.
When it is worth it at home
Good fits:
- An allotment, a garden at the end of a long plot, a summer house or a garage block where there is no Wi-Fi.
- A water meter or rain gauge in a manhole or meter pit, where 2.4 GHz signals die quickly.
- Battery devices you do not want to visit more than once every few years.
Poor fits:
- Anything indoors that Zigbee, Thread or Bluetooth already covers.
- Lights, plugs and anything that needs a reaction within a second.
- Sensors that report every few seconds.
Step 1: check coverage or plan a gateway
Community gateways may already cover your area; TTN Mapper (ttnmapper.org) shows where real devices have been heard. Do not rely on someone else's gateway for anything important, though, because it can disappear without notice. A small indoor gateway, such as The Things Indoor Gateway, plugs into a wall socket and connects over Wi-Fi. Placed by a window facing the garden, it typically covers far more than any 2.4 GHz device in the house. If you install your own gateway, register it in the TTN console so it helps everyone around you as well.
Step 2: register the device in The Things Stack
TTN runs on The Things Stack. In the console (for Europe, the eu1 cluster):
- Create an application. It groups your devices and holds the integrations.
- Click Register end device. If the device is in the LoRaWAN Device Repository, pick the brand and model and the console fills in the frequency plan and LoRaWAN version. Otherwise choose Europe 863-870 MHz (SF9 for RX2 - recommended) and the version from the device datasheet.
- Enter the JoinEUI, DevEUI and AppKey printed on the device or its label. Use over-the-air activation (OTAA), which renews session keys on every join.
- Power on the device and watch Live data. A successful join followed by an uplink means the radio part works.
Step 3: decode the payload
Devices send raw bytes. A payload formatter turns them into readable fields. If the device came from the Device Repository, a formatter is usually set already. If not, write a JavaScript decodeUplink() function. A minimal example for a sensor that sends temperature as a signed 16-bit value in hundredths of a degree, followed by humidity in percent:
function decodeUplink(input) {
var b = input.bytes;
var raw = (b[0] << 8) | b[1];
if (raw & 0x8000) raw -= 0x10000;
return {
data: {
temperature: raw / 100,
humidity: b[2]
}
};
}
The console has a test field where you can paste a hex payload and check the result before saving. The bytes above are only an example; use the format from your sensor's documentation.
Step 4: get the data into your MQTT broker
The Things Stack has a built-in MQTT server. Under Integrations > MQTT in your application, generate an API key and copy it straight away, as it will not be shown again. On The Things Network the user name is your-app-id@ttn, and uplinks appear on:
v3/your-app-id@ttn/devices/<device-id>/up
A quick test:
mosquitto_sub -h eu1.cloud.thethings.network -p 8883 --capath /etc/ssl/certs \
-u 'garden-sensors@ttn' -P 'NNSXS.XXXXXXXX...' \
-t 'v3/garden-sensors@ttn/devices/+/up' -v
Each message is a JSON document. The decoded fields are in uplink_message.decoded_payload, next to radio data such as RSSI and SNR for each gateway. Note that the server supports MQTT 3.1.1 and QoS 0 only.
To feed this into the rest of your home, either subscribe directly from Node-RED or your automation platform, or bridge the TTN topics into your local Mosquitto so everything uses one broker. A Mosquitto bridge looks like this:
connection ttn
address eu1.cloud.thethings.network:8883
bridge_capath /etc/ssl/certs
remote_username garden-sensors@ttn
remote_password NNSXS.XXXXXXXX...
topic v3/garden-sensors@ttn/devices/+/up in 0 ttn/ ""
The in 0 ttn/ "" part pulls the remote topics in with QoS 0 under a local ttn/ prefix.
Common mistakes
- Reporting too often. Work out the airtime first. A reading every 15 minutes is a good starting point for most outdoor sensors.
- Testing next to the gateway. A device right next to a gateway can overload the receiver. Keep at least a few metres between them.
- Expecting quick commands. A downlink to a Class A device waits for its next uplink.
- Wrong frequency plan. A device bought for the US 915 MHz band will not work on EU868. Check the region before buying.
- Treating TTN as guaranteed service. The community network has no service level. For anything critical, run your own gateway, and consider your own network server.