IoT architecture in layers: from sensor to dashboard
Timo Wevelsiep•Updated: 30.06.2026Editorial note: Versions, commands and prices may change. Please verify critical steps independently before production use. This guide does not replace individual consulting.
Build your IoT platform sovereignly and self-hosted? WZ-IT designs and runs vendor-neutral IoT architectures on open-source foundations - on your infrastructure. See our IoT services - IoT platform development
An IoT architecture splits cleanly into seven layers: sensor/device, connectivity, edge/gateway, platform, data storage, visualisation and integration. Each layer has a clearly defined responsibility, and for each there is a mature open-source component. Once you understand this separation, you build IoT systems that stay maintainable, can be swapped part by part and do not get stuck in a vendor cloud. This article shows which component sits where and what the full self-hosted picture looks like.
Contents
- The seven layers of an IoT architecture at a glance
- Layer 1: Sensors and devices
- Layer 2: Connectivity - LoRaWAN, MQTT and cellular
- Layer 3: Edge and gateway
- Layer 4: Platform - ThingsBoard
- Layer 5: Data storage - time-series with InfluxDB or PostgreSQL
- Layer 6: Visualisation with Grafana
- Layer 7: Integration with ERP and cloud
- The full self-hosted picture
- Build your architecture sovereignly with WZ-IT
The seven layers of an IoT architecture at a glance
Instead of thinking in terms of a single "IoT product", the layered model helps: data travels from the bottom (physical sensing) to the top (business application), and each layer only talks to the one directly above or below it. This decoupling is precisely why components can be swapped individually without rebuilding the whole system.
| Layer | Responsibility | Typical open-source component |
|---|---|---|
| 1 Sensor/device | Measure, actuate | LoRaWAN sensors (e.g. Milesight), Modbus/OPC-UA devices |
| 2 Connectivity | Transport the data | LoRaWAN, MQTT, NB-IoT/LTE-M/5G, Ethernet/Wi-Fi |
| 3 Edge/gateway | Protocol conversion, buffering | LoRaWAN gateway + ChirpStack, Node-RED, ThingsBoard Edge |
| 4 Platform | Device management, rules, tenants | ThingsBoard |
| 5 Data storage | Store time-series | InfluxDB, PostgreSQL/TimescaleDB, Cassandra |
| 6 Visualisation | Dashboards, alarms | Grafana |
| 7 Integration | Connect ERP/MES/cloud | REST, MQTT, Kafka, Node-RED |
Layer 1: Sensors and devices
At the very bottom are the physical devices: temperature, humidity, fill-level or energy meters, actuators and machine controllers. In industrial settings, existing assets often expose their values over fieldbuses such as Modbus or OPC-UA, while new radio sensors (for example from Milesight) run on batteries and send over LoRaWAN. What matters at this layer is a clean data model - which measurand, which unit, which reporting interval - because everything above is built on it.
Layer 2: Connectivity - LoRaWAN, MQTT and cellular
The connectivity layer carries readings from the device to the platform. Three paths dominate:
- LoRaWAN for low-power radio sensing over long ranges (sites, estates, agriculture). More in What is LoRaWAN?.
- MQTT as a lightweight publish-subscribe protocol for IP-capable devices and as the internal data bus. Details in What is MQTT?.
- Cellular (NB-IoT, LTE-M, 5G) for distributed single devices without local infrastructure, plus Ethernet and Wi-Fi inside buildings.
MQTT is often the connecting element here: LoRaWAN packets, cellular devices and edge nodes ultimately publish to MQTT topics that the platform subscribes to.
Layer 3: Edge and gateway
The gateway sits between radio and platform. With LoRaWAN, a LoRaWAN gateway receives the radio packets and forwards them to the network server ChirpStack, which handles decryption, deduplication and device management at the radio level (chirpstack.io). ChirpStack is open source and fully self-hostable - see What is ChirpStack? and our ChirpStack expertise.
At the edge, Node-RED does protocol conversion (Modbus/OPC-UA to MQTT), buffers data during outages and runs first-line pre-processing or threshold logic locally. For scenarios with unreliable connectivity there is also ThingsBoard Edge, which runs rules close to the machine and syncs with the central platform later.
Layer 4: Platform - ThingsBoard
The platform is the heart of the architecture. ThingsBoard handles device registration and management, a visual rule engine for processing and alarms, multi-tenancy and dashboards. The Community Edition is open source under Apache 2.0, free and usable with no device limit; the Professional Edition adds white-labelling, advanced roles (RBAC) and ready-made platform integrations. Self-managed, the PE starts at around 10 USD/month in the "Maker" plan per the price list (as of 30 Jun 2026, thingsboard.io/pricing); since version 4.3, Edge Computing and Trendz Analytics are available as modular add-ons.
More on features and editions in What is ThingsBoard? and on our ThingsBoard expertise.
Layer 5: Data storage - time-series with InfluxDB or PostgreSQL
IoT generates time-series: many writes, time-indexed, kept for the long term. ThingsBoard uses PostgreSQL for master data and can store telemetry in PostgreSQL, TimescaleDB (the time-series extension for Postgres) or Cassandra. For pure sensor time-series with a high write load - especially together with Grafana - InfluxDB is widely used; today you can choose between InfluxDB 3 Core (open source) and commercial Enterprise variants. The decision follows data rate, retention period and existing operational know-how, not fashion.
Layer 6: Visualisation with Grafana
For dashboards, trends and alerting, Grafana is the standard. It is open source under AGPLv3 (since version 8, grafana.com/licensing), free to self-host and reads directly from InfluxDB, PostgreSQL/TimescaleDB and many other sources. Grafana complements the ThingsBoard dashboards wherever historical analysis, mixed data sources or central operations monitors are needed. There is a concrete guide at Grafana IoT dashboard with InfluxDB and on our Grafana expertise.
Layer 7: Integration with ERP and cloud
At the top, the prepared data stream leaves the IoT world and feeds into business processes: consumption values into the ERP, faults into the ticketing system, KPIs into a BI tool. ThingsBoard provides a REST API, MQTT and Kafka outputs and the rule engine for this; Node-RED builds the flexible flows to ERP, MES, webhooks or databases. The key point is that only aggregated values or alarms leave the system in a controlled way, while the raw data stays on your own infrastructure.
The full self-hosted picture
Put together, the result is an end-to-end open-source stack: LoRaWAN sensors send via a gateway to ChirpStack, IP devices and edge nodes publish over MQTT, ThingsBoard manages devices and rules, InfluxDB or PostgreSQL store the time-series, Grafana visualises, and Node-RED connects ERP and cloud. Everything runs on your own infrastructure - Proxmox, Hetzner or on-prem.
The difference from managed platforms such as AWS IoT, Azure IoT or Cumulocity: you pay for servers and operations instead of licences per device and data point, you keep data sovereignty in the EU, and you can swap any layer individually. Whether that pays off against the cloud is covered in IoT platform: self-hosted vs cloud. How this stack turns into a concrete use case is shown in Predictive maintenance & retrofit.
Build your architecture sovereignly with WZ-IT
We design IoT architectures layer by layer and run them as an open-source stack on your infrastructure - from the LoRaWAN gateway over ThingsBoard and InfluxDB to Grafana and ERP integration. Vendor-neutral, without per-device licences, with honest cost accounting.
See our IoT services - IoT platform development - Book an intro call
You'd rather not run IoT yourself? WZ-IT handles setup, operations and maintenance – GDPR-compliant from Germany.
Frequently Asked Questions
Answers to the most important questions
An IoT architecture can be split into seven layers: sensor/device, connectivity (LoRaWAN, MQTT, cellular), edge/gateway, platform (e.g. ThingsBoard), data storage (time-series such as InfluxDB or PostgreSQL), visualisation (Grafana) and integration with ERP/cloud. Each layer has a clear responsibility and can be filled with an open-source component.
Connectivity and edge: ChirpStack as the LoRaWAN Network Server plus an MQTT broker such as Mosquitto or EMQX. Platform: ThingsBoard for device management, rule engine and multi-tenancy. Data storage: InfluxDB or PostgreSQL/TimescaleDB for time-series. Visualisation: Grafana. Integration and pre-processing: Node-RED. All of these are open source and run on your own infrastructure.
Both are common. ThingsBoard uses PostgreSQL for master data and can store telemetry in PostgreSQL, TimescaleDB or Cassandra. For pure sensor time-series with a high write load, InfluxDB is very popular, especially in combination with Grafana. The choice depends on data rate, retention period and the operational know-how you already have.
With LoRaWAN, yes: radio sensors only reach the platform via a LoRaWAN gateway that forwards packets to the network server (ChirpStack). IP-capable devices (Ethernet, Wi-Fi, cellular) can talk to the platform directly over MQTT. An edge gateway is still worthwhile for protocol conversion (Modbus, OPC-UA), buffering during outages and local pre-processing.
The core components are free: ThingsBoard Community Edition (Apache 2.0, unlimited devices), ChirpStack, Mosquitto, InfluxDB and Grafana OSS (AGPLv3). You pay for servers and operations, not per device. ThingsBoard Professional self-managed starts at around 10 USD/month per the price list (as of 30 Jun 2026, thingsboard.io/pricing). Managed clouds such as AWS IoT or ThingsBoard Cloud, by contrast, bill per device and data point, which scales linearly with fleet size.
Through the integration layer. ThingsBoard provides a REST API, MQTT and Kafka outputs and a rule engine; Node-RED adds flexible flows to ERP, MES, webhooks or databases. That way aggregated values or alarms flow into business systems in a controlled manner, without raw data having to leave your own infrastructure.
Sovereignty, cost control and no vendor lock-in. Self-hosted keeps data and platform in the EU and under your own control, billing is based on infrastructure rather than per-device licences, and the stack is open source and portable. Proprietary cloud platforms tie you to the vendor's pricing model and interfaces.
More on IoT
- What is LoRaWAN?
- What is MQTT?
- What is ThingsBoard?
- What is ChirpStack?
- IoT architecture in layers
- LoRaWAN vs NB-IoT vs WLAN/5G
- ThingsBoard pricing & editions
- How much does ChirpStack cost?
- ThingsBoard vs ChirpStack
- IoT platform: self-hosted vs cloud
- Open-source IoT platforms compared
- ThingsBoard vs AWS IoT Core & Azure IoT Hub
- Install ThingsBoard with Docker
- Set up ChirpStack & a LoRaWAN gateway
- Grafana IoT dashboard with InfluxDB
- ThingsBoard Rule Engine: alarms & notifications
- Milesight sensor in ChirpStack: payload decoder
- Node-RED MQTT dashboard for sensor data
- Predictive maintenance & retrofit
- Building IoT / smart building with LoRaWAN







