You have an indoor air quality sensor like the Milesight AM307 on an office wall, but no network server of your own and maybe not even a gateway. You still want the CO2, temperature and humidity readings to end up somewhere you can work with them. That is exactly what The Things Network, or TTN, is for. It is a public LoRaWAN network built by a community of individuals, universities, clubs and companies. You create a free account, register your sensor in the web console, and as soon as any TTN gateway within range hears its radio message, the data arrives in your application, for example over MQTT or a webhook.
How many messages your device may send, whether there is any coverage on your street, and when running your own network server makes more sense all decide whether TTN fits your project. Here are straight answers with real numbers.

How does The Things Network work?
Like any LoRaWAN network, TTN has devices that send short radio messages and gateways that pass them over the internet to a network server. What differs is who owns the pieces. Community members set up the gateways, on rooftops, in offices or in a living room window. The server side is run by the Dutch company The Things Industries. The software behind it is called The Things Stack, and the public instance TTN runs on has been named The Things Stack Sandbox since late 2023 (it was previously the Community Edition). There are regional clusters for Europe (eu1), North America (nam1) and Australia (au1). By its own count, the project has around 249,000 registered members in 153 countries.
One point is key to understanding it: a sensor is not paired with a particular gateway. It simply transmits, and every TTN gateway within earshot forwards the packet, no matter who owns it. The network server removes duplicates, checks integrity and hands the message to your application. LoRaWAN encrypts the payload end to end with a key that only your device and the application server know. A gateway owner can see that a packet arrived and how strong the signal was, but not your readings.
That leads to the sharing principle. If you register a gateway on TTN, it serves not only your own sensors but every TTN device nearby. In return, you benefit from gateways other people have installed.
Is there TTN coverage near you?
Your first stop is the gateway map on the TTN website. It shows registered gateways whose owners chose to make them public. TTN Mapper is often more telling: community members log every spot where a mobile sensor’s packets were received, so you see where packets actually got through.
Both maps are a good start, but neither is a guarantee. A gateway can have been offline for months and still appear on the map, and TTN Mapper mostly measures outdoors, while your sensor may sit in a basement or behind a reinforced concrete wall. As a rough guide, expect a few hundred meters to several kilometers in a city, and considerably more in open countryside with a clear line of sight.
The most reliable test is a practical one. Register a sensor, take it to the planned location and check in the console whether its messages arrive and at what signal strength. If nothing arrives reliably, the classic TTN answer is to set up a gateway yourself. That solves your problem and improves coverage for everyone in your neighborhood along the way.
How to add a LoRaWAN gateway to The Things Network
Here is how registration works with the RAKwireless RAK7268V2, an eight-channel indoor gateway for EU868. It connects over Ethernet or Wi-Fi and is set up through its WisGateOS 2 web interface. The dashboard shows the gateway EUI, a 16-character hex identifier.
In the TTN console, choose the eu1 cluster, click “Register gateway” and enter the EUI. Then pick a gateway ID (lowercase letters, digits and hyphens only) and select the frequency plan “Europe 863-870 MHz (SF9 for RX2 – recommended)”. A wrong frequency plan is one of the most common reasons a gateway shows as connected yet fails to deliver packets properly.
There are two ways to connect the gateway to the server. The older one is the Semtech UDP packet forwarder: in the gateway, set eu1.cloud.thethings.network with port 1700 as the server, and you are done. It is quick but unencrypted and unauthenticated. The recommended option is LoRa Basics Station. Here you enter wss://eu1.cloud.thethings.network:8887 as the LNS address and add the root certificate plus an API key that you generate for the gateway in the console. The key is shown only once, so copy it right away.
After a few seconds, the console should list the gateway as connected. The RAK7268V2 variant sold here runs from a 12 V power adapter, so plan for an outlet at the spot you choose.
How to register a device in The Things Network
TTN organizes sensors in applications. Create an application first, for example “office-air-quality”. Inside it, click “Register end device”. The easiest route goes through the LoRaWAN Device Repository: you choose the vendor, model, hardware and firmware version, and the frequency band. The Milesight AM307 is listed there. The console then fills in the LoRaWAN version, the device profile and, most usefully, a ready-made payload formatter.
Next, you enter three identifiers: the JoinEUI (formerly AppEUI), the device’s DevEUI and the AppKey. Depending on the manufacturer, they are on the device label, in the documentation, or readable through the vendor’s configuration app. The AppKey must match exactly on device and server. A single swapped character and the join fails without the console telling you why. Use over-the-air activation (OTAA). The older ABP method with fixed session keys causes more trouble on a public network than it saves.
Then power on the sensor or trigger a restart. The live view first shows a join request, then a join accept and finally the first uplink. The payload formatter is a small JavaScript function that turns the raw bytes into readable fields such as temperature, humidity and CO2. One tip from the TTN forum: formatters in the repository are updated from time to time, and field names can change in the process. If your application depends on specific names, paste the formatter into your application as custom code once, so it only changes when you change it.

The Things Network MQTT integration: how do you get your data?
The Things Stack comes with its own MQTT broker, so you do not need to run a server just to collect the data. Your application, a Node-RED flow or Home Assistant connects as a client to eu1.cloud.thethings.network, encrypted on port 8883 (or unencrypted on 1883, which you should only use for testing). The username is the application ID with “@ttn” appended, for example office-air-quality@ttn. The password is an API key you create in the console under “Integrations → MQTT”.
A device’s uplinks appear on the topic v3/office-air-quality@ttn/devices/am307-room-1/up. Subscribing to v3/+/devices/+/up gives you every device in the application. Each message is a JSON document. The readings sit under uplink_message.decoded_payload, alongside the receive time, the signal strength and the gateways that heard the packet.
Note that the broker supports QoS 0 only and buffers nothing for you. If your client is offline, the messages from that period are gone as far as it is concerned. Two features help. The Storage Integration keeps uplinks, but only for 24 hours on the Sandbox. A webhook sends every message as an HTTP POST to an address you choose, which is more robust when the receiving end is a web server or a cloud function. The reverse direction works too: publishing to the …/down/push topic queues a downlink, for example to change a sensor’s reporting interval. It is delivered only after the device’s next uplink, because Class A devices listen just briefly after transmitting.
TTN fair use policy: how many messages can you send?
Because all devices share the radio channels, TTN limits usage per device: at most 30 seconds of uplink airtime per 24 hours, and at most 10 downlinks per day, acknowledgments included. How many packets that buys depends on the spreading factor, meaning how slowly and robustly the device transmits. A distant device needs a high spreading factor, and each step roughly doubles the airtime.
The table below works this out for a message with 30 bytes of payload, a size a multi-sensor device reaches quickly. The last column shows the daily airtime at a ten-minute reporting interval, which is the AM307’s factory default.
| Spreading factor | Airtime per message | Messages per day within 30 s | Airtime at a 10-minute interval |
|---|---|---|---|
| SF7 | approx. 87 ms | approx. 340 | approx. 13 s |
| SF8 | approx. 164 ms | approx. 180 | approx. 24 s |
| SF9 | approx. 288 ms | approx. 100 | approx. 41 s |
| SF10 | approx. 535 ms | approx. 56 | approx. 77 s |
| SF12 | approx. 2.1 s | approx. 14 | approx. 308 s |
With a good connection (SF7 or SF8), a ten-minute interval fits comfortably within the budget. From SF9 on you exceed it, and at SF12 by a factor of ten. If your sensor sits far from the nearest gateway, stretch the interval to 20 or 30 minutes, or improve the link with a gateway of your own. Keep Adaptive Data Rate (ADR) enabled so the server sets the device as fast as reception allows. Also avoid confirmed uplinks: every acknowledgment is a downlink and uses up one of the ten daily slots. Separately from TTN, the legal duty cycle limit in the 868 MHz band still applies, usually 1 percent of airtime per hour.
Is The Things Network free?
Yes, using the network costs nothing. The account, the console, the MQTT broker, webhooks and payload formatters are all free. You pay only for hardware: the sensor and, if there is no coverage in your area, a gateway. An indoor gateway like the RAK7268V2 costs somewhere in the low three figures and then serves many of your sensors within range at once.
Free does not mean TTN is meant for everything, though. The Things Industries explicitly describes the Sandbox as an environment for non-commercial, small-scale testing and experimentation. There is no uptime guarantee, occasional outages can happen. TTN’s getting-started page calls it unsuitable for businesses because of the fair use policy. That is fine for a home lab or a prototype, but not for heating control in an apartment building.
For commercial use, The Things Industries offers The Things Stack Cloud, a paid version with an uptime commitment. The alternative is a network server of your own, which brings us to the last big question.
TTN vs ChirpStack: public network or your own network server?
ChirpStack is an open-source LoRaWAN network server that you run yourself: on a small Linux computer, in a Docker container or on a rented server. There is no fair use policy beyond the legal duty cycle, no dependence on a cloud cluster, and no question of whether data leaves the building. The price is work: you handle updates, backups, certificates and monitoring. ChirpStack also receives only through your own gateways, so TTN’s community coverage no longer helps you.
The comparison below sums up the practical differences.
| Criterion | The Things Network | ChirpStack (self-hosted) |
|---|---|---|
| Setup | Create an account, ready right away | Install and maintain a server |
| Coverage | All community gateways | Your own gateways only |
| Usage limits | 30 s airtime, 10 downlinks per device per day | Legal duty cycle only |
| Availability | No guarantee | As good as your own operations |
| Intended for | Testing, hobby use, prototypes | Continuous and commercial deployments |
For a single site, there is also a middle path: the RAK7268V2 has a built-in network server and can work with no external server at all. The gateway then publishes the data over MQTT itself. A common sequence: test sensors and range on TTN, which takes an hour. When the project moves into continuous operation, move to ChirpStack, the built-in network server or a commercial service. You keep the gateway and sensors and simply register them again.
Where can you buy LoRaWAN devices for The Things Network?
The most important rule comes first: in Europe you need devices for the EU868 frequency band, or not a single TTN gateway will hear you. For sensors, check whether the model is listed in the LoRaWAN Device Repository. If it is, you get the device profile and payload formatter without writing any code. Look for an adjustable reporting interval so you can stay within the 30-second fair use budget on a weak link, and for a way to set the JoinEUI, DevEUI and AppKey.
If you need your own gateway, location and backhaul decide. Indoor gateways with Ethernet or Wi-Fi are enough for a building, while outdoor sites and large areas call for a weatherproof model. Support for LoRa Basics Station is a plus because the connection to TTN is then encrypted. A built-in network server keeps the door open for a later move away from TTN.
If you are looking for sensors or a gateway for The Things Network, you will find suitable models in our LoRaWAN category.
The Things Network FAQ
Do you need your own gateway for The Things Network?
Not necessarily. If another member’s TTN gateway reliably receives your sensor, an account and a registered device are all you need. If coverage is missing, adding your own gateway is the usual answer.
What is The Things Stack?
The Things Stack is the network server software from The Things Industries that The Things Network runs on. The public, free instance is called The Things Stack Sandbox. There are also paid versions, as a cloud service or for self-hosting, aimed at commercial users.
Can you get data from The Things Network with a webhook?
Yes. In the console, set up a webhook under integrations and enter an HTTPS address. TTN then sends every uplink message there as JSON via HTTP POST. That suits web servers and cloud functions that should not hold a permanent MQTT connection.