W5.1 Il Mondo Oltre il Wi-Fi
Il Wi-Fi è ottimo per connettere laptop e smartphone, ma non è la tecnologia giusta per ogni scenario. Un sensore di temperatura a batteria non può permettersi il consumo energetico del Wi-Fi. Un contatore del gas in campagna non ha un router Wi-Fi nelle vicinanze. Per questi casi esistono tecnologie wireless specifiche, ottimizzate per basso consumo, lunga portata o reti di sensori a maglia.
| Categoria | Portata | Banda | Consumo | Tecnologie |
|---|---|---|---|---|
| PAN (Personal Area) | 1-100 m | kbps – Mbps | Molto basso | Bluetooth/BLE, Zigbee, Z-Wave, Thread |
| LAN (Local Area) | 50-300 m | Mbps – Gbps | Medio-alto | Wi-Fi (802.11), Wi-Fi HaLow (802.11ah) |
| LPWAN (Low Power WAN) | 2-15+ km | bps – kbps | Molto basso | LoRa/LoRaWAN, Sigfox, NB-IoT, LTE-M |
| Cellulare | 1-35 km | Mbps – Gbps | Alto | 4G/LTE, 5G, NB-IoT, LTE-M |
Nessuna tecnologia wireless può avere contemporaneamente lunga portata, alta velocità e basso consumo. Puoi sceglierne al massimo due. Il Wi-Fi ha alta velocità + media portata ma alto consumo. LoRa ha lunga portata + basso consumo ma bassissima velocità. BLE ha basso consumo + velocità media ma corta portata. La scelta dipende dal caso d’uso.
W5.2 Bluetooth e BLE (Bluetooth Low Energy)
Bluetooth è la tecnologia PAN più diffusa al mondo: auricolari, smartwatch, tastiere, mouse, altoparlanti, automotive. Dal Bluetooth 4.0 (2010) è stato introdotto BLE (Bluetooth Low Energy), un protocollo separato ottimizzato per dispositivi a batteria con trasmissioni brevi e infrequenti.
- Banda: 1-3 Mbps
- Portata: ~10-100 m
- Frequenza: 2.4 GHz ISM
- Consumo: medio (~30 mA)
- Uso: audio streaming, trasferimento file, tethering
- Connessione continua (stream)
Profili: A2DP (audio), HFP (vivavoce), SPP (seriale)
- Banda: 125 kbps – 2 Mbps
- Portata: ~10-200 m (BLE 5.0+)
- Frequenza: 2.4 GHz ISM
- Consumo: molto basso (~15 µA media)
- Uso: sensori, beacon, wearable, domotica
- Trasmissioni brevi e infrequenti (burst)
Un sensore BLE può funzionare anni con una pila a bottone
BLE 5.0 (2016) ha quadruplicato la portata (fino a 200 m in campo aperto) e raddoppiato la velocità (2 Mbps). BLE 5.1 aggiunge la direction finding: il ricevitore può determinare la direzione del segnale con precisione centimetrica (indoor positioning). BLE 5.2 introduce LE Audio con codec LC3: qualità audio superiore a minor bitrate, e il broadcast audio (Auracast) per trasmettere audio a infiniti ricevitori contemporaneamente (annunci in aeroporto, traduzione simultanea).
Dal 2017, Bluetooth supporta reti mesh: i nodi BLE rilanciano i messaggi ad altri nodi, coprendo aree molto grandi senza infrastruttura centrale. Usato per l’illuminazione intelligente (ogni lampadina è un nodo mesh che rilancia i comandi alle altre), building automation e asset tracking in grandi edifici.
W5.3 Zigbee, Thread e Z-Wave
Mentre BLE è pensato per la comunicazione punto-punto o broadcast, Zigbee e Z-Wave sono nati specificamente per le reti mesh di sensori nella domotica e nell’automazione industriale.
- Banda: 250 kbps
- Frequenza: 2.4 GHz
- Portata: 10-100 m (per hop)
- Nodi: fino a 65.000
- Topologia: mesh, star, tree
- Consumo: molto basso
Philips Hue, IKEA Dirigera, sensori industriali
- Banda: 250 kbps
- Frequenza: 2.4 GHz (802.15.4)
- Portata: 10-30 m (per hop)
- Basato su IPv6 (nativo IP!)
- Topologia: mesh
- Standard aperto (Google, Apple)
Matter (protocollo unificato smart home) usa Thread come trasporto
- Banda: 100 kbps
- Frequenza: 868 MHz (EU) / 908 MHz (US)
- Portata: 30-100 m (per hop)
- Nodi: fino a 232
- Topologia: mesh (max 4 hop)
- Non compete con Wi-Fi (banda diversa)
Domotica: serrature, termostati, sensori porta/finestra
Matter (ex-CHIP, Project Connected Home over IP) è il nuovo standard promosso da Apple, Google, Amazon e Samsung per risolvere la frammentazione della smart home. Matter funziona su Thread (per sensori a bassa potenza), Wi-Fi (per dispositivi sempre accesi) e Ethernet. L’obiettivo: un dispositivo “Matter” funziona con HomeKit, Google Home e Alexa senza configurazioni diverse. Usa IPv6 end-to-end e crittografia per default.
| Aspetto | Zigbee | Thread | Z-Wave | BLE Mesh |
|---|---|---|---|---|
| Frequenza | 2.4 GHz | 2.4 GHz | 868/908 MHz | 2.4 GHz |
| IP nativo | No (serve bridge) | Sì (IPv6) | No (serve bridge) | No (serve bridge) |
| Max nodi | 65.000 | ~250 per rete | 232 | 32.000 |
| Mesh | Sì | Sì | Sì | Sì |
| Interoperabilità | Media (profili Zigbee 3.0) | Alta (Matter) | Alta (certificazione) | Media |
| Hub/Bridge | Richiesto | Border Router | Richiesto | Dipende |
W5.4 LPWAN: LoRa, LoRaWAN e Sigfox
Per i sensori IoT che devono trasmettere pochi dati a grande distanza con batterie che durano anni, le tecnologie PAN (Bluetooth, Zigbee) non bastano: la portata è troppo corta. Le reti LPWAN (Low Power Wide Area Network) risolvono questo problema.
Portata: 2-15+ km (urbano/rurale).
Velocità: da 50 bps a pochi kbps — sufficiente per leggere un sensore di temperatura o inviare una posizione GPS.
Consumo: bassissimo — batteria AA da 5-10 anni.
Frequenza: bande sub-GHz (868 MHz EU, 915 MHz US) — penetra bene edifici e terreno.
Costo: moduli da pochi euro, gateway da qualche centinaio.
LoRa è la modulazione radio (Semtech): spread spectrum a chirp, portata fino a 15 km in campo aperto.
LoRaWAN è il protocollo di rete (LoRa Alliance): architettura a stella con gateway che inoltra i dati dei nodi a un network server cloud.
- Banda: 0.3-50 kbps
- Frequenza: 868 MHz (EU)
- Bidirezionale (3 classi: A, B, C)
- AES-128 end-to-end
- Ecosistema aperto (The Things Network)
Smart city, agricoltura, monitoraggio ambientale, asset tracking
Tecnologie cellulari ottimizzate per IoT, basate sulle reti 4G/5G degli operatori mobili.
NB-IoT: bassissimo consumo, banda 200 kHz, ottimo per sensori statici (contatori, parcheggi).
LTE-M (Cat-M1): più banda (1 Mbps), supporta mobilità e VoLTE. Per wearable e tracker mobili.
- Copertura operatore (nessun gateway proprio)
- SIM card richiesta (costo abbonamento)
- Sicurezza cellulare (SIM, crittografia LTE)
Contatori smart, fleet tracking, wearable medicali
LoRaWAN se: vuoi una rete privata senza costi di abbonamento, hai bisogno di copertura in aree senza rete cellulare (montagna, campagna), devi connettere migliaia di sensori economici. NB-IoT se: preferisci affidarti alla copertura dell’operatore, non vuoi gestire gateway, hai bisogno di sicurezza cellulare e QoS garantita. In molti progetti si usano entrambi: LoRaWAN per i sensori in campo e NB-IoT come backhaul del gateway.
W5.5 Confronto Completo delle Tecnologie
| Tecnologia | Portata | Velocità | Consumo | Frequenza | Topologia | Caso d’uso principale |
|---|---|---|---|---|---|---|
| Wi-Fi 6 | 50-100 m | Gbps | Alto | 2.4/5/6 GHz | Stella (AP) | LAN, streaming, produttività |
| BLE 5.x | 10-200 m | 125k-2M bps | Molto basso | 2.4 GHz | P2P, broadcast, mesh | Wearable, beacon, sensori |
| Zigbee | 10-100 m | 250 kbps | Molto basso | 2.4 GHz | Mesh (65k nodi) | Domotica, automazione |
| Thread | 10-30 m | 250 kbps | Molto basso | 2.4 GHz | Mesh (IPv6) | Smart home (Matter) |
| Z-Wave | 30-100 m | 100 kbps | Basso | 868/908 MHz | Mesh (232 nodi) | Domotica |
| LoRaWAN | 2-15 km | 0.3-50 kbps | Bassissimo | 868 MHz | Stella (GW→cloud) | Smart city, agricoltura, ambiente |
| NB-IoT | 1-10 km | ~200 kbps | Basso | Cellulare LTE | Stella (BTS) | Contatori, tracking statico |
| LTE-M | 1-15 km | ~1 Mbps | Medio-basso | Cellulare LTE | Stella (BTS) | Wearable, tracker mobili |
W5.6 Protocolli Applicativi IoT: MQTT e CoAP
I protocolli HTTP/HTTPS che usiamo per il web sono troppo pesanti per dispositivi IoT con pochi kB di RAM e connessioni lente. Servono protocolli leggeri, ottimizzati per messaggi piccoli e frequenti.
Message Queuing Telemetry Transport. Protocollo publish/subscribe basato su TCP. Il più diffuso nell’IoT.
- Architettura: client → broker → client
- Modello: publish/subscribe su topic
- Trasporto: TCP (porta 1883, 8883 con TLS)
- Overhead: 2 byte di header minimo
- QoS: 3 livelli (0=fire&forget, 1=at least once, 2=exactly once)
- Retained messages: l’ultimo valore resta disponibile per nuovi subscriber
Broker: Mosquitto, HiveMQ, AWS IoT Core
Constrained Application Protocol. Protocollo request/response basato su UDP. Progettato per dispositivi molto limitati.
- Architettura: client ↔ server (come HTTP)
- Modello: REST (GET, PUT, POST, DELETE)
- Trasporto: UDP (porta 5683, 5684 con DTLS)
- Overhead: 4 byte di header
- Observe: il client si “iscrive” e riceve aggiornamenti automatici
- Proxy: traducibile facilmente a/da HTTP
Ideale per reti 6LoWPAN, Thread, LWM2M
MQTT: il modello Publish/Subscribe
In MQTT non c’è comunicazione diretta tra dispositivi. Tutto passa attraverso un broker centrale. I dispositivi pubblicano messaggi su “topic” (come canali tematici) e altri dispositivi si iscrivono ai topic che gli interessano.
PUBLISH
casa/soggiorno/temp
“22.5”
Mosquitto
Riceve e distribuisce
SUBSCRIBE
casa/soggiorno/temp
SUBSCRIBE
casa/#
I topic sono stringhe gerarchiche separate da /. Esempio: casa/soggiorno/temperatura, casa/cucina/umidita, ufficio/piano1/luce.
Wildcard + (un livello): casa/+/temperatura → riceve temperatura di tutte le stanze.
Wildcard # (multi-livello): casa/# → riceve tutto ciò che riguarda “casa” (tutte le stanze, tutti i sensori).
La gerarchia dei topic è la chiave per organizzare un sistema IoT scalabile.
MQTT vs CoAP vs HTTP
| Aspetto | MQTT | CoAP | HTTP |
|---|---|---|---|
| Modello | Publish/Subscribe | Request/Response (REST) | Request/Response (REST) |
| Trasporto | TCP | UDP | TCP |
| Header minimo | 2 byte | 4 byte | ~100-500 byte |
| Comunicazione | Bidirezionale asincrona | Bidirezionale (observe) | Client-initiated only |
| Sicurezza | TLS (porta 8883) | DTLS (porta 5684) | TLS/HTTPS (porta 443) |
| Ideale per | Telemetria, notifiche, comandi | Dispositivi ultra-vincolati | Web, API, cloud |
| Broker/Server | Richiede broker centrale | Server leggero o P2P | Server web standard |
W5.7 L’Architettura IoT a 3 Livelli
Un sistema IoT completo ha tipicamente tre livelli, ciascuno con le proprie tecnologie:
I sensori e attuatori sul campo. Raccolgono dati (temperatura, umidità, posizione, vibrazione) e/o eseguono azioni (accendere una luce, aprire una valvola).
Hardware: ESP32, Arduino, STM32, nRF52. Connessione: BLE, Zigbee, LoRa, Wi-Fi.
Fa da ponte tra i dispositivi edge e il cloud. Aggrega i dati, può fare pre-elaborazione locale (edge computing), traduce protocolli (LoRa→MQTT, Zigbee→IP).
Hardware: Raspberry Pi, gateway LoRaWAN, hub Zigbee. Connessione: Ethernet/Wi-Fi/4G verso cloud.
Archiviazione, analisi e visualizzazione dei dati. Dashboard, allarmi, machine learning, API per app mobile e web.
Piattaforme: AWS IoT, Azure IoT Hub, Google Cloud IoT, ThingsBoard, Node-RED, InfluxDB+Grafana.
Inviare ogni singola lettura di ogni sensore al cloud è costoso (traffico), lento (latenza) e dipende dalla connettività. L’edge computing elabora i dati localmente: il gateway filtra, aggrega e decide in tempo reale. Esempio: un sistema di monitoraggio vibrazionale invia al cloud solo gli allarmi, non le 10.000 letture/secondo. Questo riduce il traffico del 99% e permette reazioni in millisecondi anziché secondi.
W5.8 Riepilogo del Modulo
🧪 Verifica di Autovalutazione
Soluzioni
Domanda 01 — Bluetooth Classic vs BLE
Domanda 02 — Zigbee mesh
Domanda 03 — Matter
Domanda 04 — LoRaWAN
Domanda 05 — LoRaWAN vs NB-IoT
Domanda 06 — MQTT publish/subscribe
casa/soggiorno/temp). Altri dispositivi si iscrivono (subscribe) ai topic che gli interessano. Quando un sensore pubblica “22.5” su casa/soggiorno/temp, tutti i subscriber di quel topic ricevono il messaggio. Vantaggi: disaccoppiamento (publisher e subscriber non devono conoscersi), scalabilità, wildcard per pattern matching.