Thinking about bringing IoT into your business? Choosing between MQTT, CoAP, HTTP, or figuring out if you need a gateway or edge device is not straightforward. Get the architecture wrong, and costs skyrocket while data never arrives. We deal with these problems every day, having integrated sensors and actuators for industrial and agricultural clients in Sicily since 2017. IoT is not just a gadget: it's a lever to reduce waste, monitor remotely, and make real-time decisions. But without solid foundations, it becomes a resource drain. This guide gives you the fundamentals: architecture, protocols, real cases. No abstract theory.
IoT Architecture: The Three Layers You Must Know
Every IoT system breaks down into three macro-layers. Understanding them means not being sold unnecessary devices.
Layer 1 — Perception (Sensors and Actuators)
Here you collect data from the physical world: temperature, humidity, vibration, power consumption, presence. Real examples: DHT22 sensors for greenhouses, encoders on conveyor belts, smart switches for lights. The most common problem? Sensors sampling too frequently, saturating the network or draining batteries in days instead of years. We always recommend designing the duty cycle based on the use case: a greenhouse doesn't need a reading every second, but every 15 minutes.
Layer 2 — Network (Gateways and Protocols)
Data must travel from sensors to a concentrator (gateway) and then to the cloud. This is where the project's fate is decided. Use WiFi everywhere, and power consumption explodes. Use LoRaWAN in a metal warehouse, and the signal dies. The gateway acts as a translator: it takes data from a Zigbee sensor and converts it to MQTT over TCP/IP. A common mistake is thinking sensors talk directly to the Internet. They don't: you need a gateway (hardware or software) to handle the domain shift.
Layer 3 — Application (Cloud, Edge, Dashboards)
Data arrives and needs processing. You can send it to the cloud (AWS IoT, Azure IoT Hub, or an open-source platform like ThingsBoard) or process it locally (edge computing). Edge computing is often the right choice for SMEs: it reduces latency and transfer costs. Example: a vibration sensor on an industrial pump. If analysis must trigger an alarm within 50ms, you can't wait for the cloud. You process locally on the gateway. Only historical trends go to the cloud. We at Meteora Web implemented edge solutions on Raspberry Pi with Node-RED for a ceramics client: it cut connectivity costs by 70%.
IoT Protocols: Which One to Choose and Why
There is no universal protocol. Every context has its own. Here are the most common, with when and why.
MQTT — The King of IoT
A publish/subscribe protocol over TCP. Lightweight, with three QoS levels. Ideal for low-power sensors on IP networks. The broker (e.g., Mosquitto) routes messages. We use it in 90% of IoT projects. Practical example: a temperature sensor publishes to topic workshop/temperature/01, the dashboard subscribes and receives updates. Python code with paho-mqtt:
import paho.mqtt.client as mqtt
client = mqtt.Client()
client.connect("broker.example.com", 1883)
client.publish("room/boiler/temperature", "45.2")
client.loop(2)Attention: MQTT does not encrypt by default. For production use MQTT over TLS (port 8883) and authentication with username/password or certificates.
CoAP — REST over UDP
Similar to HTTP but over UDP, designed for resource-constrained devices. Uses GET/PUT/POST/DELETE, tiny messages. Perfect for sensors that only need to send state or receive commands. Example: an irrigation actuator that receives an ON/OFF command. CoAP also supports observation (subscribe via observe).
LoRaWAN — Long Range, Ultra-Low Power
For open-field applications: agriculture, container monitoring, parking lots. Range up to 15 km line-of-sight. The sensor talks to a LoRa gateway that forwards to a network server (The Things Network, ChirpStack). Cost: a few euros per sensor, no SIM card needed. We use it for soil moisture monitoring in Sicilian wineries.
Zigbee and Z-Wave — Home automation and industrial mesh
Short-range mesh protocols. Each device repeats the signal. Zigbee is open, Z-Wave proprietary but simpler. Perfect for smart buildings: lights, blinds, presence sensors. Limitation: they require a coordinator (hub) that acts as a gateway to the Internet.
Real-World Use Cases — From Field to Factory
Let's look at three concrete applications we've followed or built.
Precision Agriculture — Automated Greenhouse
Temperature, air and soil humidity, pH sensors. Every 15 minutes data travels via LoRaWAN to a gateway, then via MQTT to ThingsBoard. Result: 30% reduction in water consumption, thanks to valve actuators controlled by threshold rules. Total system cost: about €2,000 per hectare of greenhouse. Recovered in one season.
Predictive Maintenance in Industry
A ceramics client had recurring failures on hydraulic presses. We installed ADXL345 accelerometers on ESP32 nodes, sending data via MQTT to a local broker. Edge computing with Node-RED calculated vibration averages over 10-second windows. If a threshold was exceeded, an alarm triggered. In 6 months we prevented 3 production stoppages, saving an estimated €50,000.
Smart Building — Energy Consumption Monitoring
In a 500 sqm office, current sensors on each electrical panel (Shelly EM modules) sent kW consumption via MQTT to an InfluxDB database. A Grafana dashboard showed real-time consumption by department. Result: identified a defective air conditioner consuming double the normal. Replaced, saving €1,200/year.
IoT Security — The Weak Point for SMEs
IoT devices are the new entry point for attacks. Often they have non-updatable firmware, hard-coded passwords, unencrypted communications. We start with three rules:
- change all default credentials
- use isolated VLANs for IoT devices
- if the device doesn't support TLS or DTLS, don't expose it to the Internet — keep it on the LAN and expose only the gateway with strong authentication
A common mistake: making the MQTT broker publicly accessible without a password. One of our clients did that — within two weeks they received a DDoS attack. We fixed it by limiting IP addresses and adding authentication.
In a Nutshell — What to Do Now
- Map your use case: how many sensors? frequency? where are they installed? power source? These answers determine protocol and architecture.
- Choose the right protocols: MQTT for IP-ready, LoRaWAN for long range, Zigbee for indoor mesh. Don't mix protocols without a gateway that translates them.
- Design security from the start: VLANs, TLS, unique credentials, edge processing for sensitive data.
- Calculate ROI: an IoT system doesn't justify itself. Estimate energy savings, downtime reduction, efficiency gains before buying hardware.
- Test with an MVP: one sensor, one gateway, one dashboard. If it works, scale.
IoT is not an IT project: it's an investment that pays off if done smartly. We at Meteora Web help businesses get started on the right foot. To dive deeper, check our guides on Blockchain Fundamentals (for distributed security of IoT data) and Open Source (platforms like ThingsBoard and Node-RED).
Sponsored Protocol
