Il protocollo MQTT

Una volta configurato, il Master effettuerà:

• la connessione al Broker MQTT
• la sottoscrizione ai Topic necessari al suo funzionamento
• l’invio di un pacchetto di dati in base:
  • alle priorità dei suoi moduli di espansione
  • alle priorità dei moduli di espansione degli Slave eventualmente a lui abbinati
  • alla ricezione di un messaggio broadcast da un Tag

Topic generici del Master

Prima di vedere i Topic dei singoli moduli vediamo i Topic generici.

Quando un Master si connette al broker anche se non ha moduli di espansione o Slave abbinati invia due messaggi nei seguenti Topic ed effettua una sottoscrizione:

Dove App_Id è il nome dell’ecosistema precedentemente attribuito e Id_Master è il MAC address del Master.

Il messaggio di Config_Req

Il messaggio di CONFIG_REQ è un messaggio inviato dal Master che descrive la sua configurazione hardware e quella degli Slave ad esso abbinati.

Lo schema del messaggio descrive:

• MAC address Master;
• gli 8 slot per i moduli di espansione;
• Mac address degli 8 Slave;
• i due slot espansione di ogni Slave.

Ovvero:

“IdMaster_slot1_slot2_slot3_slot4_slot5_slot6_slot7_slot8_IdSlave1_slot1_slot2_IdSlave2_slot1_slot2_IdSlave3_slot1_slot2_IdSlave4_slot1_slot2_IdSlave5_slot1_slot2_IdSlave6_slot1_slot2_IdSlave7_slot1_slot2_IdSlave8_slot1_slot2”

Un esempio di messaggio di CONFIG_REQ dove un Master ha un modulo di espansione aggiunto, è abbinato ad un solo Slave che possiede un modulo espansione:

“00124B00117AB407_1_0_0_0_0_0_0_0_01184B00456AN407_1_0_0000000000000000_0_0_0000000000000000_0_0_0000000000000000_0_0_0000000000000000_0_0_0000000000000000_0_0_0000000000000000_0_0_0000000000000000_0_0”

I numeri che vanno a riempire il campo slot corrispondono al tipo di modulo di espansione e sono:

• 1 = Modulo Environment
• 2 = Modulo Energy Meter
• 3 = Modulo Expansion
• 4 = Modulo Dali

Il Time Stamp

Il Master ha bisogno di un orario per determinare il proprio funzionamento. Una volta connesso alla rete Wi-Fi tenterà di raggiungere un servizio NTP online per ottenere l’ora esatta. Qualora la rete Wi-Fi non dovesse disporre di uscite verso Internet il Master automaticamente imposta un orario di partenza randomico. Per avere un corretto funzionamento del sistema ed allinearlo all’orario corretto è possibile iniettare l’orario sul Topic AppId_/TIME_STAMP. Tutti i Master alla connessione con il broker si sottoscrivono a questo Topic e alla ricezione dell’orario impostano il clock interno sul valore ricevuto. Tramite una qualsiasi applicazione è possibile manualmente o automaticamente inviare l’orario corretto ai Master. Il formato del messaggio e quindi dell’orario da inviare è UNIX time dal 1 Gen. 1970 0:00 UTC e i millisecondi.

Esempio:   1516878000000.000 

Data che corrisponde alle 12:00:00.000 del 25 Gennaio 2018.

Topic dei singoli moduli

Se un Master o uno Slave sono dotati di uno o più moduli di espansione sottoscriveranno e pubblicheranno nei corrispondenti Topic come da schema successivo:

App_ID / ID_Dispositivo/ Modulo/ Dettaglio

Dove:

• App_Id: corrisponde al nome dato all’ecosistema quando è stato creato.
• Id_Dispositivo: corrisponde al MAC address del modulo Radio.
• Modulo: corrisponde al tipo di modulo a cui il dato è riferito.
• Dettaglio: è la tipologia di dato.

Modulo Environment

Modulo Energy Meter

Modulo Expansion

Per quanto riguarda il modulo Expansion bisogna fare alcune precisazioni iniziali.

Il modulo ha due ingressi digitali che vengono letti dal microcontrollore. Lo stato High o Low del pin è possibile leggerlo al Topic APP_ID/ID_DEVICE/FLOW_1/IN. Per alcune applicazioni potrebbe essere interessante contare quante volte un pin alterna lo stato di High e quello di Low ad esempio per leggere flussometri, contatori, anemometri etc. In questo caso bisognerà pubblicare nel Topic APP_ID/ID_DEVICE/FLOW_1/MOD una delle tre ipotesi:

• UP
• 2UP
• INCREM

Tramite la modalità UP il modulo conterà gli impulsi che provengano dal pin A o dal pin B sommandoli. Tramite la modalità 2UP il modulo conterà gli impulsi in due registri separati, uno per il pin A e uno per il pin B. Nella modalità INCREM invece le pulsazioni del pin A andranno ad aumentare positivamente il contatore e gli impulsi del pin B andranno a diminuirlo. In tal modo sarà possibile gestire strumenti in quadratura. È possibile leggere il contatore all’interno del Topic TOTAL e PARTIAL. Tramite il Topic RESET è possibile riportarli a zero.

Qualora si volesse leggere un flussometro è possibile dare i comandi:

• APP_ID/ID_DEVICE/FLOW_1/SetMaxRPM tramite il quale si impostano il numero massimo di giri dello strumento collegato al modulo (andare oltre i giri indicati farà inviare un messaggio di OVERFLOW nel Topic STATUS)

• APP_ID/ID_DEVICE/FLOW_1/SetPulsRev tramite il quale si impostano gli impulsi per ogni giro dello strumento.

Sarà possibile leggere la velocità rilevata (rpm) in base a questi parametri nel Topic SPEED.

Modulo DALI

Topic di periferiche Slave

Alla ricezione di un messaggio di uno Slave, il Master inoltra al Broker un messaggio su un Topic dedicato in cui espone il MAC Address dello Slave, il valore degli RSSI rilevati, il Time Stamp e lo stato dell’alimentazione.

Topic di periferiche Tag

Alla ricezione di un messaggio di un Tag, il Master inoltra al Broker il messaggio su un Topic dedicato.

Il Tag può essere dotato o meno di modulo Environment e in base a questo cambierà il tipo di Topic ovvero:

• App_ID/Master_Id/TAG1_RSSI è il Topic dedicato al Tag senza moduli di espansione.
• App_ID/Master_Id/TAG2_RSSI è il Topic dedicato al Tag con modulo Environment.
• App_ID/Master_Id/TAG2_DATA è il Topic dedicato ai valori dei sensori del Tag con modulo Environment.

NB: nello status del Topic TAG2_DATA viene indicato con “OK” il messaggio di vitalità mentre con FAULT il superamento della soglia impostata di alert per l’accelerometro (vedi sezione “Tempi di lettura e scrittura”).

Nello specifico, il FAULT è sempre seguito da un codice che identifica il tipo di soglia superato. Seguire le indicazioni seguenti per la sua interpretazione. Il messaggio di FAULT è così rappresentato: FAULT_HHLL, dove HHLL rappresentano i bit il cui significato è il seguente:

BYTE BASSO (LL)

BYTE ALTO (HH)

Nello specifico, per interpretare i FAULT di alert di movimento esponiamo alcuni esempi di messaggio:

Topic di periferiche Bridge

Under development.