Torna a reti di sensori

Caso d’uso Zigbee

Date le particolarità della tecnologia, i casi d’uso per la rete di sensori sono quelli tipici applicazioni IoT indoor a corto/medio raggio, dove concorre con altre tecnologie di rete: WIFi, BLE e, sotto certe condizioni, LoRaWAN. Punti di forza che portano a preferire Zigbee sono essenzialmente:

alt text

Aspetti critici

Elementi critici su cui bilanciare convenienze e saper fare delle scelte argomentate sono:

Architettura di una rete di reti

Di seguito è riportata l’architettura generale di una rete di reti di sensori. Essa è composta, a livello fisico, essenzialmente di una rete di accesso ai sensori e da una rete di distribuzione che fa da collante di ciascuna rete di sensori.

alt text

Rete di distribuzione

I gateway utilizzano la rete internet e/o una LAN per realizzare un collegamento verso il broker MQTT, per cui, in definitiva, la topologia risultante è, fisicamente, quella di più reti di accesso con tecnologia e topologia differente (a maglia nel caso di zigbee) tenute insieme da una rete di distribuzione qualsiasi purchè sia di tipo TCP/IP (LAN o Internet).

Avere a disposizione una rete di distribuzione IP per i comandi e le letture è utile perchè permette di creare interfacce web o applicazioni per smartphone o tablet per:

Documentazione logica della rete (albero degli apparati attivi)

Reti di sensori federate tramite Internet

L’albero degli apparati attivi di una rete di sensori + rete di distribuzione in Internet + server di gestione e controllo che potrebbe rappresentare tre edifici distanti domotizzati tramite zigbeee e federati tramite Internet:

alt text

Il bridge zigbee (in realtà è un gateway e quindi pure un router) è normalmente anche il coordinatore della rete di sensori.

Il gateway, quando collegato direttamente ad Internet, è normalmente anche un firewall (con funzioni di NAT se si adopera IPv4), mentre se collegato alla LAN (attraverso uno SW o un HUB wiereless) ha solamente la funzioni di:

Il gateway All-In-One potrebbe essere un dispositivo con doppia interfaccia, modem UMTS per l’accesso alla rete di distribuzione su Internet, Zigbee verso la rete di sensori. Può essere utile per realizzare un gateway Zigbee da campo da adoperare:

Reti di sensori federate tramite LAN

Partizionamento e ridondanza

Per quanto riguarda il numero dei gateway in una stessa LAN, il numero minimo necessario perchè la rete zigbee funzioni è uno. Un gateway avente anche funzione di coordinatore nelle rete di sensori. Però, data la criticità di eventuali guasti su questo dispositivo (la rete di sensori diventa nel suo complesso inaccessibile), potrebbe essere opportuno prevedere:

La partizione di una rete Zigbee potrebbe essere utile anche in determinate situazioni, specialmente quando si hano un gran numero di dispositivi o se si vogliono separare i dispositivi per zone o per scopi diversi. Ecco alcune situazioni in cui potrebbe essere vantaggioso partizionare una rete Zigbee:

Per partizionare una rete Zigbee, si potrebbero creare più coordinatori Zigbee, cioè più gateway, ciascuno con la propria rete di sensori da gestire, e utilizzare una LAN (composta da più switch) per collegare le reti tra loro.

alt text

Canali di comunicazione principali in una rete di sensori

In sintesi, sono necessari almeno due canali di comunicazione che, insieme, complessivamente, realizzano la comunicazione tra sensori e gestore delle informazioni:

Broker MQTT

Il broker MQTT è solo una delle tante soluzioni possibili per realizzare un canale multicast di livello applicativo tramite cui un utente col ruolo di publisher è in grado di notificare una replica dello stesso messaggio a più subscribers. E’ utile per:

Il canale applicativo su cui vengono inviati i messaggi sono quindi i topic. Su un certo topic il dispositivo con il ruolo di output agisce come un publisher, mentre quello con il ruolo di input agisce come un subscriber.

Gli utenti, in ogni caso, si comportano tutti come client poiché sono loro che iniziano la connessione con il broker e non il viceversa.

alt text

Fasi del protocollo:

  1. Il Subscriber dichiara presso il broker il proprio interesse a ricevere notifiche riguardo ad un certo argomento (topic) effettuando una chiamata subscribe()
  2. il publisher pubblica un messaggio che riguarda un certo topic effettuando una chiamata publish()
  3. Il broker inoltra il messaggio a tutti i subscriber interessati a quel topic

L’ID MQTT è un identificativo che permette di individuare un dispositivo ma non è un indirizzo di livello 3, non individua la macchina host in base al suo IP, piuttosto è un indirizzo di livello applicativo noto solo ad un server centrale, cioè il broker. Un dispositivo IoT non è tenuto a conoscere l’IP di tutti gli altri dispositivi ma solamente quello del broker. Il broker soltanto sa gli indirizzi di tutti i dispositivi, conoscenza che acquisisce durante la fase di connessione di un client al broker, momento in cui avviene anche il recupero del’socket remoto del client.

Il broker, dal canto suo, associa ogni topic con tutti gli ID che sono registrati presso di esso come subscriber. Questa associazione è utilizzata per smistare tutti i messaggi che arrivano con un certo topic verso tutti gli ID che ad esso sono associati. Il topic diventa così un indirizzo di gruppo. La particolarità di questo indirizzo è che è gerarchico secondo una struttura ad albero, cioè gruppi di dispositivi possono essere suddivisi in sottogruppi più piccoli estendendo il nome del path con un ulteriore prefisso, diverso per ciascun sottogruppo. L’operazione può essere ripetuta ulteriormente in maniera ricorsiva.

Ad esempio, posso individuare le lampade della casa con il path luci e accenderle e spegnerle tutte insieme, ma posso sezionarle ulteriormente con il path luci/soggiorno con il quale accendere o spegnere solo quelle del soggiorno oppure con il path luci/soggiorno/piantane con il quale fare la stessa cosa ma solo con le piantane del soggiorno.

Osservando l’albero degli apparati attivi, si vede bene che, nelle reti Zigbee, il client MQTT (con il ruolo di publisher o di subscriber) è sempre il gateway che è anche il coordinator della rete Zigbee.

In generale, su reti non IP, i client MQTT (con il ruolo di publisher o di subscriber) sono sempre i gateway di confine della rete di sensori. Le uniche reti di sensori che non hanno bisogno di un gateway di confine che sia, nel contempo anche client MQTT, sono le reti IP. Esistono ancora i gateway nelle reti IP ma con scopi diversi da quello di realizzare un client MQTT. Nelle reti IP, il client MQTT è, normalmente, direttamente a bordo del dispositivo sensore dotato di indirizzo IP (MCU).

Il vantaggio del broker MQTT è quello di poter gestire in modo semplice e standardizzato lo smistamento (inoltro) delle misure e dei comandi tra i vari portatori di interesse (stakeholder) di un cluster di reti di sensori, siano essi utenti umani, interfacce grafiche, server applicativi diversi o altri dispositivi IoT.

Alternative ad MQTT

Esistono molte altre soluzioni che magari sono più semplici e graficamente accattivanti ma che passano per portali proprietari o per servizi cloud a pagamento e nulla aggiungono di didatticamente rilevante ai nostri discorsi. Normalmente sono basate su webservices realizzati con protocolli Request/Response quali HTTPS e COAP.

Server di gestione

E’ un client del broker MQTT con funzioni sia di publisher che di subscriber per:

Semantica applicativa standard

La semantica delle entità Zigbee definisce:

Si può comprendere, quindi, come una rete Zigbee non si limiti a trasmettere, tra dispositivi sensori e attuatori, dei messaggi generici di cui lo stack di protocolli non capisce il significato e non conosce la struttura ma, bensì, trasmette proprio messaggi di comando e messaggi di stato ritagliati per una certa categoria di dispositivi domotici modellata dal protocollo. Essendo parte del protocollo, questi messaggi hanno la proprietà di essere standard, per cui sono comuni a dispositivi di marca diversa purchè siano dello stesso tipo previsto dallo standard.

E’ una differenza sostanziale con una rete LoraWAN o IP:

Profili Zigbee

Ogni dispositivo Zigbee aderisce a un profilo di dispositivo specifico che descrive le sue funzionalità e capacità. Questi profili sono standardizzati per garantire che i dispositivi di produttori diversi possano funzionare insieme senza problemi. Alcuni esempi di profili di dispositivi sono:

Cluster Library

Zigbee utilizza un concetto chiamato “clusters”, che sono gruppi di attributi e comandi legati a una funzione specifica. Ad esempio, un cluster di illuminazione potrebbe includere comandi per accendere/spegnere una luce e per regolare la luminosità. Ogni cluster ha un ID univoco e può essere riutilizzato in diversi profili di dispositivo.

Endpoints

I dispositivi Zigbee possono avere uno o più “endpoints”, che sono punti di comunicazione logici che mappano le funzionalità del dispositivo. Ogni endpoint supporta uno o più cluster e ha un proprio ID univoco. Ad esempio, un dispositivo potrebbe avere un endpoint per il controllo della luce e un altro per la gestione dell’energia.

Attribute Reporting

Gli attributi all’interno dei cluster possono essere configurati per segnalare automaticamente i cambiamenti. Questo è essenziale per applicazioni in tempo reale come il monitoraggio dell’energia o la sicurezza domestica.

Binding

Il binding è un processo che collega due endpoint di dispositivi diversi, consentendo loro di comunicare direttamente tra loro. Questo è utilizzato, ad esempio, per associare un interruttore a una luce specifica senza passare attraverso un hub centrale.

Scenario d’Uso

Immaginiamo di avere un’applicazione di controllo della casa intelligente che deve interagire con una lampadina Zigbee.

Basic Cluster (0x0000):

Il Basic Cluster include informazioni generali sul dispositivo e alcune funzioni di configurazione di base.

Attributes:
  ZCLVersion (0x0000): Versione del protocollo Zigbee.
  ApplicationVersion (0x0001): Versione dell'applicazione.
  ManufacturerName (0x0004): Nome del produttore.
  ModelIdentifier (0x0005): Identificatore del modello.

Accendere la Lampadina:

Comando: On
Cluster: On/Off Cluster (0x0006)
Payload: 0x01

{
  "source_endpoint": 1,
  "destination_endpoint": 1,
  "Cluster": "0x0006",
  "Command": "0x01"
}

Impostare la Luminosità a 50%:

Comando: MoveToLevel
Cluster: Level Control Cluster (0x0008)
Payload:
  Level: 128 (50% di 255)
  TransitionTime: 10 (1 secondo)

{
  "source_endpoint": 1,
  "destination_endpoint": 1,
  "Cluster": "0x0008",
  "Command": "0x00",
  "Payload": {
    "Level": 128,
    "TransitionTime": 10
  }
}

Spegnere la Lampadina:

Comando: Off
Cluster: On/Off Cluster (0x0006)
Payload: 0x00

{
  "source_endpoint": 1,
  "destination_endpoint": 1,
  "Cluster": "0x0006",
  "Command": "0x00"
}

Gateway

Ruolo del gateway

Riassumendo, alla rete di distribuzione IP si collegano, quindi, una o più reti secondarie che servono da rete di accesso per i dispositivi sensori o attuatori con interfacce spesso di tipo non ethernet che necessitano di un gateway di confine con possibili funzioni di:

Il gateway è uno snodo nevralgico dei messaggi, per cui la sua posizione dovrebbe essere ben nota e accuratamente riportata in planimetria per permettere una sua rapida manutenzione/sostituzione.

E’ il dispositivo posto a cavallo tra la rete di accesso ai sensori e la rete di distribuzione.

Il gateway ha tante schede di interfaccia quanti sono i tipi diversi di rete a cui si collega. Inoltre il gateway deve possedere almeno una interfaccia capace di traffico ethernet (cablata o wifi) che lo colleghi alla rete di distribuzione.

Gateway come Client MQTT

In generale, su reti non IP, i client MQTT (con il ruolo di publisher o di subscriber) sono sempre i gateway di confine della rete di sensori. Le uniche reti di sensori che non hanno bisogno di un gateway di confine che sia, nel contempo anche client MQTT, sono le reti IP. Esistono ancora i gateway nelle reti IP ma con scopi diversi da quello di realizzare un client MQTT. Nelle reti IP, il client MQTT è, normalmente, direttamente a bordo del dispositivo sensore dotato di indirizzo IP (MCU).

Gateway come MCU hub di sensori

La parola gateway potrebbe talvolta portare a fraintendimenti dovuti al diverso significato nei diversi contesti in cui la si usa. Spesso, con il termine gateway si intente anche il dispositivo IoT che potrebbe essere, a sua volta, un gateway tra la il link di campo, porte analogiche/digitali o BUS, (vedi bus di campo per dettagli) e la rete di sensori (WiFi, Zigbee, LoraWAN, LAN, BLE, ecc.). Vedi (dispositivi terminali) per approfondimenti.

Gateway come router L7

Avendo più interfacce su reti di tipo diverso sia in L1 che in L2, ha anche le funzioni di router. Se la rete di distribuzione è pubblica come Internet dovrebbe possedere pure le funzioni di firewall.

Ma la funzione più importante che possiede nel contesto di una rete di dispositivi IoT è la traduzione della semantica, cioè del significato degli oggetti, dalla rete zigbee al livello applicativo MQTT che smista i messaggi nella rete IP. Questa funzione rende il gateway un bridge di traduzione di comandi da un ambiente all’altro.

Misure e comandi sono definiti due volte:

In ogni caso, per gli oggetti Zigbee, la semantica dei comandi e dello stato è standardizzata, nel senso che dispositivi di marche diverse si possono comandare allo stesso modo. Tutti i dispositivi di ugual tipo si rappresentano come uno stesso oggetto Zigbee, avente gli stessi attributi per tutti i dispositivi di quel tipo.

Gli oggetti JSON scambiati nella rete di distribuzione vanno progettati in modo tale da includere la semantica di tutti i dispositivi IoT coinvolti nelle reti di sensori collegate, che di volta in volta, poi andrà tradotta nella semantica applicativa standard prevista nello stack della rete di accesso Zigbee.

Traduzione della semantica applicativa

Zigbee2mqtt è un software open-source progettato per permettere ai dispositivi Zigbee di comunicare direttamente con un server MQTT (Message Queuing Telemetry Transport) senza la necessità di un hub proprietario.

alt text

Zigbee è uno standard di comunicazione wireless (protocollo) utilizzato per il controllo e l’automazione domestica, mentre MQTT è un protocollo di messaggistica leggero utilizzato per il trasferimento di dati tra dispositivi. Utilizzando Zigbee2mqtt, gli utenti possono integrare facilmente dispositivi Zigbee di diversi produttori in un sistema di automazione domestica basato su MQTT, con elevata flessibilità e controllo.

alt text

Il bridge zigbee2mqtt opera a livello di presentazione della pila OSI ed esegue, nell’ordine, le seguenti operazioni:

  1. sbusta tutti i messaggi provenienti dall’interfaccia Zigbee uno dopo l’altro, a partire dal livello fisico fino ad arrivare al livello di presentazione, dove Zigbee realizza la sua rappresentazione semantica dell’oggetto comandato/attuato/configurato, completa di attributi e corrispondenti valori.
  2. a questo punto traduce il payload Zigbee in un payload JSON che contiene gli stessi attributi con gli stessi valori.
  3. dopo di che smista il JSON così costruito sull’interfaccia IP del gateway, dove viene imbustato come payload del protocollo MQTT ed inviato fino al broker.

Il bridge zigbee2mqtt funge da ponte tra la rete Zigbee e il broker MQTT, consentendo agli utenti di interagire con i dispositivi Zigbee tramite messaggi MQTT.

La traduzione è resa possibile perchè le reti Zigbee definiscono per ogni dispositvo la semantica applicativa standard che abbiamo visto sopra (una lampadina ha gli stessi comandi, lo stesso stato e la stessa configurazione per tutte le lampadine Zigbee mai prodotte da chiunque). Compito del bridge zigbee2mqtt è tradurre gli oggetti standard Zigbee in JSON e inserirli in un messaggio MQTT.

Funzionamento di zigbee2mqtt

Ecco una descrizione di come funziona zigbee2mqtt:

  1. Scansione dei Dispositivi Zigbee: zigbee2mqtt esegue una scansione per rilevare dispositivi Zigbee nelle vicinanze e li aggiunge alla rete Zigbee.
  2. Connessione ai Dispositivi Zigbee: zigbee2mqtt si connette ai dispositivi Zigbee per leggere e scrivere dati. Questo include sensori, attuatori, lampadine, interruttori, ecc.
  3. Pubblicazione su MQTT: I dati letti dai dispositivi Zigbee vengono convertiti in messaggi MQTT e pubblicati su un broker MQTT. Questo può includere dati di stato, misurazioni di sensori, ecc.
  4. Sottoscrizione a Comandi MQTT: zigbee2mqtt si iscrive anche a determinati topic MQTT per ricevere comandi. Quando un comando MQTT viene ricevuto, zigbee2mqtt lo traduce in un’operazione Zigbee e lo invia al dispositivo appropriato.

Configurazione di zigbee2mqtt

Per controllare tre lampadine diverse sotto lo stesso topic stanzetta usando zigbee2mqtt, è possibile configurare un approccio che permetta di inviare comandi a tutte e tre le lampadine contemporaneamente o individualmente. Un modo efficace per farlo è usare un payload JSON che includa informazioni specifiche per ciascuna lampadina.

homeassistant: false
permit_join: true
mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://localhost'
  user: 'MQTT_USERNAME'
  password: 'MQTT_PASSWORD'
serial:
  port: '/dev/ttyUSB0'
devices:
  '0x00124b0014d2b5d2':
    friendly_name: lampadina1
  '0x00124b0014d2b5d3':
    friendly_name: lampadina2
  '0x00124b0014d2b5d4':
    friendly_name: lampadina3

Il parametro permit_join: true nella configurazione di Zigbee2MQTT permette ai nuovi dispositivi Zigbee di unirsi alla rete Zigbee. Quando questa opzione è attivata, il coordinatore Zigbee accetta nuovi dispositivi che cercano di connettersi. Mantenere permit_join attivato permanentemente non è consigliato per motivi di sicurezza, poiché potrebbe permettere a dispositivi non autorizzati di connettersi alla rete Zigbee.

Per permettere ad un sensore di comando di modificare lo stato di un attuatore, in Zigbee è sempre necessario effettuare il binding (associazione) tra i due dispositivi (in gergo endpoint).

Una volta che le lampadine sono riconosciute da Zigbee2MQTT, possono eesere configurate per accettare i comandi MQTT. La configurazione di Zigbee2MQTT si occuperà del binding automatico tra il gateway e tutte le lampadine.

Ora, configurando un singolo topic zigbee2mqtt/stanzetta/cmd per inviare comandi a tutte e tre le lampadine, possiamo usare un payload JSON per specificare lo stato desiderato di ogni lampadina.

Accendere tutte le Lampadine:

#!/bin/bash

# Accendere lampadina1
mosquitto_pub -h localhost -t 'zigbee2mqtt/lampadina1/set' -m '{"state": "ON"}'

# Accendere lampadina2
mosquitto_pub -h localhost -t 'zigbee2mqtt/lampadina2/set' -m '{"state": "ON"}'

# Accendere lampadina3
mosquitto_pub -h localhost -t 'zigbee2mqtt/lampadina3/set' -m '{"state": "ON"}'

Spegnere tutte le Lampadine:

#!/bin/bash

# Accendere lampadina1
mosquitto_pub -h localhost -t 'zigbee2mqtt/lampadina1/set' -m '{"state": "OFF"}'

# Accendere lampadina2
mosquitto_pub -h localhost -t 'zigbee2mqtt/lampadina2/set' -m '{"state": "OFF"}'

# Accendere lampadina3
mosquitto_pub -h localhost -t 'zigbee2mqtt/lampadina3/set' -m '{"state": "OFF"}'

Comandare le Lampadine Singolarmente:

#!/bin/bash

# Accendere lampadina1
mosquitto_pub -h localhost -t 'zigbee2mqtt/lampadina1/set' -m '{"state": "ON"}'

# Accendere lampadina2
mosquitto_pub -h localhost -t 'zigbee2mqtt/lampadina2/set' -m '{"state": "OFF"}'

# Accendere lampadina3
mosquitto_pub -h localhost -t 'zigbee2mqtt/lampadina3/set' -m '{"state": "ON"}'

Utilizzo dei topic

Puoi definire una gerarchia di topic MQTT per raggruppare le lampadine. Ad esempio, potresti avere un topic per ciascun ambiente della tua casa o per ciascun piano dell’edificio. Ecco un esempio di come potrebbe apparire la gerarchia dei topic:

casa/
  └── soggiorno/
      ├── lampadina1/
      │   ├── comandi
      │   └── stato
      ├── lampadina2/
      │   ├── comandi
      │   └── stato
      └── lampadina3/
          ├── comandi
          └── stato

In questo esempio, casa è il prefisso di tutti i tuoi topic MQTT. All’interno di questo prefisso, hai un sotto-topic per il soggiorno chiamato soggiorno, e all’interno di questo sotto-topic hai i sotto-topic per ciascuna delle tue lampadine, ciascuno dei quali ha due sotto-topic: cmd e stato.

mqtt:
  base_topic: casa
  server: 'mqtt://localhost'
  user: 'MQTT_USERNAME'
  password: 'MQTT_PASSWORD'
serial:
  port: '/dev/ttyUSB0'
devices:
  '0x00124b0014d2b5d2':
    friendly_name: lampadina1
    state_topic: 'soggiorno/lampadina1/stato'
    set_topic: 'soggiorno/lampadina1/comandi'
  '0x00124b0014d2b5d3':
    friendly_name: lampadina2
    state_topic: 'soggiorno/lampadina2/stato'
    set_topic: 'soggiorno/lampadina2/comandi'
  '0x00124b0014d2b5d4':
    friendly_name: lampadina3
    state_topic: 'soggiorno/lampadina3/stato'
    set_topic: 'soggiorno/lampadina3/comandi'

Accendere una lampadina del Soggiorno

mosquitto_pub -h localhost -t 'casa/soggiorno/lampadina1/cmd' -m '{"state": "ON"}'

Accendere Tutte le Lampadine nel Soggiorno

mosquitto_pub -h localhost -t 'casa/soggiorno/comandi' -m '{"state": "ON"}'

Spegnere Tutte le Lampadine nel Soggiorno

mosquitto_pub -h localhost -t 'casa/soggiorno/comandi' -m '{"state": "OFF"}'

Rete di sensori Zigbee

In alternativa, si possono sfruttare le funzionalità di creazione e gestione dei gruppi e di segmentazione della rete offerte dal protocollo Zigbee, per organizzare i dispositivi in gruppi logici all’interno di una stessa rete di sensori Zigbee.

alt text

I dispositivi ZigBee possono essere configurati in modo da realizzare diverse topologie di reti. Una topologia largamente usata è la quella mesh. Più reti possono organizzarsi in cluster con una struttura logica ad albero (spanning tree ottimo). Viene così realizzata una rete peerto-peer con un minimo overhead di routing.

alt text

Caratteristiche distintiva di questa tecnologia di rete di sensori è la topologia a maglia che comporta che:

Tipologie di nodi

Le specifiche dello standard distinguono 3 tipi di dispositivi:

Consumo energetico

Bassissimo consumo dei nodi di comando dato che, per inviare un messaggio ad un nodo attuatore posto in un luogo remoto della rete, devono spendere sempre e soltanto l’energia necessaria a raggiungere il nodo router più vicino

Per minimizzare il consumo di potenza, e quindi massimizzare la durata delle batterie, i dispositivi finali passano la maggior parte del loro tempo “addormentati” (sleep mode), si svegliano soltanto quando hanno bisogno di comunicare, e poi si riaddormentano immediatamente.

Lo standard prevede invece che i router ed il coordinatore siano collegati alla rete elettrica e siano sempre attivi. Non hanno quindi dei vincoli sul consumo di potenza

Potenza e banda di trasmissione

La potenza in trasmissione usata nella banda a 2.4GHz è compresa tra -3dBm e 10dBm con valore tipico 0dBm Nella banda 915MHz il limite massimo è di 1000 mW (30dBm). Tuttavia, i terminali costruiti secondo la tecnologia “system-onchip” limitano la potenza intorno ai 10dBm. Nella banda 868MHz il limite massimo è di circa 14dBm (25mW). La potenza minima deve essere almeno di -3dBm

In generale, la banda di frequenza usuale di Zigbee è 2,4 GHz. La specifica Zigbee definisce l’utilizzo di diverse tecniche di modulazione, tra cui Frequency-Hopping Spread Spectrum (FHSS) e Direct Sequence Spread Spectrum (DSSS):

L’utilizzo del FHSS, in particolare, permette la selezione automatica dei canali in maniera da facilitare la coesistenza con un wifi domestico selezionando i salti di frequenza a ridosso degli avvallamenti sempre presenti tra un canale wifi e l’altro.

alt text

Zigbee utilizza 16 canali (da 11 a 26) nella banda 2,4 GHz in tutto il mondo, 13 canali nella banda 915 MHz in Nord America, e un unico canale nella banda 868 MHz in Europa. Alcuni dispositivi utilizzano anche la banda 784 MHz in Cina per Zigbee.

Attraverso questi canali, ogni dispositivo Zigbee utilizza una larghezza di banda fino a 2 MHz mentre due canali diversi sono separati da una banda di guardia di 5 MHz per prevenire interferenze dovute ad altri dispositivi Zigbee. La velocità dati che può essere raggiunta nella banda da 2,4 GHz è di 250 Kbps per canale, 40 Kbps per canale nella banda 915 MHz e 20 Kbps per canale nella banda 868 MHz. Tuttavia, il throughput effettivo che può essere fornito è inevitabilmente inferiore ai valori specificati, a causa di vari fattori come il sovraccarico dei pacchetti, i ritardi di elaborazione e la latenza del canale. Le radio Zigbee generalmente forniscono una potenza di uscita di 1-100 mW su queste bande di frequenza.

Beacon

I beacon sono delle sequenze di sincronizzazione (dette preambolo) in grado sia di sincronizzare gli orologi dei dispositivi (Tx e Rx) che si accingono ad iniziare una comunicazione, ma anche di indentificare in maniera univoca i dispositivi che li emettono. Per dei dettagli vedi preambolo di sincronizzazione.

La trama dati compresa tra due beacon consecutivi viene detta supertrama (superframe) ed è generalmente divisa in due zone con politiche di accesso al canale diverse:

Nel contesto di Zigbee, un coordinatore può assumere un ruolo di coordinamento, simile a quello svolto dal PCF in una rete Wi-Fi, gestendo l’accesso al canale in modo master/slave in cui il centrale ha il ruolo di master che stabilisce quale stazione deve parlare, quando e per quanto tempo usando una politica di turnazione delle stazioni (polling).

La situazione può essere riassunta nel seguente modo:

alt text

La superframe è una trama composta di 16 slot temporali di uguale larghezza all’interno dei quali inviare i dati di una o più applicazioni. E’ delimitata da una coppia di beacons e viene spedita dal coordinatore.

alt text

I beacons sono usati per:

Il PAN coordinator può dedicare porzioni della superframe ad applicazioni a bassa latenza quali quelle multimediali. Queste porzioni sono chiamate garanteed time slot (GTS) e sono regolate in maniera deterministica frazie alla multiplazione statica TDM.

Il PAN coordinator può allocare fino 7 di questi GTS per una singola applicazione, ognuno dei quali può occupare più di un periodo di slot. Ad ogni dispositivo che sta trasmettendo in un GTS viene assicurato che la sua operazione venga completata prima dell’inizio del successivo GTS.

Tutte le transazioni basate su contesa saranno completate prima dell’inizio del CFP.

Slotted CSMA

Lo slotted CSMA (Carrier Sense Multiple Access) è un protocollo di accesso al canale utilizzato come via di mezzo tra il GTS e il CSMA/CA. E’ comunque un protocollo a contesa probabilistico e funziona seguendo questi passaggi:

In genere, per reti a stella, il CSMA/CA senza slot è migliore del CSMA/CA con slot in termini di probabilità di successo del pacchetto, consumo di energia e ritardo. Mentre CSMA/CA con slot è migliore di CSMA/CA senza slot in termini di throughput, cioè capacità complessiva di traffico.

Tipologie di servizio

Molti sistemi (wifi, zigbee, bluetooth BLE, LoRaWan, Sigfox) permettono di impostare contemporaneamente, sulla stessa interfaccia radio, un servizio sincrono mediante TDMA per le sorgenti che eseguono il polling di sensori e un servizio asincrono con ALOHA o CSMA/CA per le sorgenti che devono effettuare la notifica del comando di un pulsante di accensione di un attuatore. Ciò è ottenuto attivando sul canale la funzionalità beacon con le cosiddette superframe, divise in zone dedicate a:

Le tipologie di servizio supportate da Zigbee quindi sono:

Abilitazione ai beacon

Nelle reti abilitate ai beacon, i router Zigbee trasmettono beacon periodici per confermare la loro presenza ad altri nodi di rete. I nodi possono rimanere inattivi in stato di sleep tra un beacon e l’altro, prolungando così la durata della batteria. Gli intervalli dei beacon dipendono dalla velocità dei dati; possono variare da 15,36 millisecondi a 251,65824 secondi a 250 kbit/s, da 24 millisecondi a 393,216 secondi a 40 kbit/s e da 48 millisecondi a 786,432 secondi a 20 kbit/s. Intervalli di segnale lunghi richiedono tempistiche precise, che possono essere costose da implementare in prodotti a basso costo.

I link radio nel modo non abilitato al beacon sono regolati dal CSMA/CA e, i nodi della rete con funzioni di smistamento (router), non essendo sincronizzati a ricevere su istanti prefissati, devono rimanere costantemente accesi e quindi alimentati.

Nel caso delle reti in beacon mode, i link sono regolati in maniera probabilistica con lo slotted CSMA/CA oppure in maniera deterministica con il GTS. I router possono beneficiare dei lunghi periodi di inattività tra due beacon per risparmiare energia massimizzando la durata di una eventuale alimentazione a batteria. Questa modalità di risparmio energetico è nota come “duty cycling” o “sleeping router”.

In generale, i protocolli Zigbee riducono al minimo il tempo di accensione della radio, così da ridurre il consumo energetico. Nelle reti di beacon, i nodi devono essere attivi solo durante la trasmissione di un beacon. Nelle reti non abilitate ai beacon, il consumo energetico è decisamente asimmetrico: alcuni dispositivi sono sempre attivi (generalmente i router) mentre altri passano la maggior parte del tempo a dormire (i nodi terminali RFD).

Messaggi MQTT

Messaggi confermati

La conferma dei messaggi inviati da parte del ricevente normalmente non è necessaria nel caso dei sensori. Infatti, se un invio da parte di un sensore non andasse a buon fine, è inutile richiedere la ritrasmissione di un dato che comunque a breve arriva con una misura più aggiornata.

La conferma, invece, è prevista per funzioni di comando o configurazione. Ad esempio nel caso di pulsanti, rilevatori di transito o allarmi in cui l’invio del messaggiò avviene sporadicamente e in maniera del tutto asincrona (cioè non prevedibile dal ricevitore), potrebbe essere auspicabile avere un feedback da parte del protocollo mediante un meccanismo di conferma basato su ack. Ma non sempre ciò è possibile.

La conferma, però, potrebbe pure essere gestita soltanto dal livello applicativo (non dal protocollo) utilizzando un topic di feeedback (o stato) per inviare il valore dello stato corrente subito dopo che questo viene interessato da un comando in ingresso sul dispositivo.

Definizione di topic e payload

Sovente, nella rete di distribuzione IP è presente un server col ruolo di broker MQTT a cui sono associati:

In realtà, il topic di configurazione, pur essendo teoricamente appropriato, potrebbe anche essere incorporato nel topic di comando, magari prevedendo un livello più alto di autorizzazione rispetto ai comandi relativi alle funzioni ordinarie.

Gestione dei topic di comando

Potremmo a questo punto inserire il comando delle luci nel topic più generale delle misure ed attuazioni che chiameremo comandi e registrare i pulsanti del soggiorno al topic luci/soggiorno/comandi come pubblisher, mentre potremmo registrare le attuazioni delle lampade allo stesso topic come subscriber. Il comando potrebbe essere il JSON {"toggle":"true"}, per cui alla fine tutto intero il path diventerebbe luci/soggiorno/comandi/{"toggle":"true"}. Se volessimo selezionare un solo dispositivo sono possibili due strade alternative:

Gestione dei topic di stato

Questo canale viene utilizzato per inviare lo stato di un dispositivo a tutti coloro che ne sono interessati. L’interesse potrebbe nascere per più motivi:

Un esempio di canale MQTT di stato potrebbe essere:

Gestione dei topic di configurazione

Questo canale viene utilizzato per inviare comandi di configurazione al dispositivo da parte del server di processo. L’interesse potrebbe nascere per più motivi:

Un esempio di canale MQTT di configurazione per, ad esempio, impostare il periodo di pubblicazione automatica dello stato potrebbe essere:

Pagine correlate:

Sitografia:

Torna a reti di sensori