Sfondo generico di MQTT

Con MQTT il mittente e il ricevitore non sono a conoscenza l'uno dell'altro - il broker gestisce la messaggistica. Questo permette ai messaggi di essere separati nello spazio, nel tempo e nell'intensità. Il mittente può inviare alla velocità che vuole e al tempo che vuole. Il ricevitore può raccogliere i messaggi alla velocità che vuole e al tempo che vuole. Il mittente e il ricevitore non devono conoscersi, e non devono avere un percorso diretto tra loro (come sarebbe il caso, per esempio, di una linea telefonica). MQTT permette di progettare facilmente configurazioni multicast - dove un mittente può inviare a molti ricevitori iscritti.

• I client non sanno chi ha pubblicato il messaggio in origine - a meno che non sia chiaro dall'argomento (e possibilmente imposto sul broker da ACL), o dal contenuto del messaggio (possibilmente firmato con HMAC)
• MQTT è progettato per comunicazioni a bassa potenza e bassa latenza (HMAC ecc. potrebbe essere costoso)
• Non è possibile ottenere una lista di tutti gli argomenti da un broker. Il broker scarta i messaggi (e gli argomenti) a cui nessuno è iscritto (eventualmente solo se il flag retain non è impostato)
• Non sai chi si è iscritto a un argomento (usa le ACL per limitare le iscrizioni di clienti non autorizzati)

ultime volontà e testamento / tenere in vita

I client possono connettersi, pubblicare un messaggio e disconnettersi, o mantenere una connessione persistente al server. Nel caso di una connessione persistente, verranno inviati dei keep-alives. Se il client non invia keep-alives nel lasso di tempo che è stato concordato durante l'impostazione della connessione, il server (broker) può inviare un cosiddetto messaggio di ultima volontà e testamento, che il client ha presentato durante la creazione della connessione. Questo messaggio può essere qualsiasi cosa e può essere pubblicato su un solo argomento per connessione. Il broker lo invierà a tutti i clienti iscritti su questo argomento.

Se il client si disconnette con grazia, le ultime volontà non saranno pubblicate.

Il keep alive è particolarmente utile per i client mobili, dove la connessione potrebbe interrompersi (ad esempio per una cattiva rete, tunnel, ecc.)

Vedi anche:

http://www.steves-internet-guide.com/checking-active-mqtt-client-connections/

http://www.steves-internet-guide.com/mqtt-last-will-example/

https://owntracks.org/booklet/tech/mqtt/

ID cliente / Acquisizione del cliente

Ogni client che si connette a un broker MQTT dovrebbe avere un client id unico. I client che si connettono con lo stesso client id uccidono la connessione precedente e assumono quella nuova. Se avete due client con lo stesso client id, questo può portare ad un ping-pong di connessioni scollegate.

Messaggi conservati

Il ultimo Il messaggio conservato in un argomento viene salvato e consegnato a tutti i nuovi sottoscrittori di questo argomento. Questo può essere usato per comunicare lo stato del dispositivo / la configurazione / ecc.

Si imposta lo stato mantenuto come flag per ogni messaggio.

I messaggi conservati possono essere usati per molte cose interessanti, ad esempio per facilitare l'auto-discovery (vedi il suggerimento 4 sotto).

Qualità del servizio / QoS

Ci sono tre livelli di qualità del servizio, che determinano quanto overhead si incontra durante l'elaborazione di un messaggio. Più alto è il livello, maggiore è l'overhead.

• 0: nessuna garanzia
• 1: il messaggio sarà inviato almeno una volta (possibili duplicati)
• 2: il messaggio sarà inviato esattamente una volta (nessun duplicato possibile)

La QoS può essere impostata per ogni messaggio inviato al broker e durante la sottoscrizione. Il più basso dei due valori sarà usato per la consegna effettiva del messaggio.

Date un'occhiata a questo per maggiori dettagli:

https://www.eclipse.org/paho/files/mqttdoc/MQTTClient/html/qos.html

Argomenti

Fatti sugli argomenti

I nomi degli argomenti sono sensibili alle maiuscole e alle stringhe UTF-8. È consigliabile limitarsi ai caratteri ASCII stampabili per facilitare il debug.

I nomi degli argomenti devono essere composti da almeno un carattere per essere validi.

/

è già un nome di argomento

Il $SYS è per l'uso / statistiche del broker.

Potete scegliere se mettere le informazioni nella struttura dell'argomento o metterle nel messaggio. Una struttura JSON per il messaggio vi aiuterà a poterlo estendere con ulteriori dati.

Considerate che ad ogni chiamata al broker, ogni pubblicazione dell'argomento sarà inviata nel payload del pacchetto MQTT - quindi cercate di evitare lunghezze inutili.

Considera l'uso dei jolly

• # corrisponde a tutto per una profondità di livello arbitraria dal livello corrente (jolly multilivello, può essere inserito solo alla fine)
• + corrisponde tutto al livello corrente (jolly di livello singolo)

Ad esempio, se avete più sensori di temperatura, potreste facilmente sottoscrivere i messaggi per tutti loro se progettate correttamente il vostro albero degli argomenti.

I jolly sono solo per abbonarsi, non sono ammessi alla pubblicazione.

Puoi iscriverti a tutti gli argomenti usando #

tranne l'argomento $SYS. Usa $SYS/# per sottoscrivere tutti gli argomenti per $SYS

Forse, l'uso della parte "funzione" prima dell'identificatore del dispositivo permette di abbonarsi più facilmente a certi canali.

Per esempio, se definite i vostri percorsi come tele/camera1/sensorname1 tele/camera2/sensorname2 ecc. e stat/room1/sensorname1 stat/room1/sensorname2 abbonamenti sono possibili su:

tele/#

stat/#

Se lo fai al contrario, con sensore1/stat e sensore2/stat, ecc. si può usare

+/stat

per sottoscrivere le statistiche, ma non corrisponderà in profondità arbitraria come nell'esempio precedente. Cioè, il percorso del vostro sensore deve consistere esattamente in un componente.

In questo modo, se prefissi l'azione i tuoi percorsi saranno più coerenti.

Vedere per esempio https://stevessmarthomeguide.com/setting-up-the-sonoff-tasmota-mqtt-switch/

Non

- Non usare una barra iniziale (ad esempio /mytopics ) per iniziare il tuo albero degli argomenti - aggiunge spese generali, nessun valore

- Non usare $SYS come argomento di partenza, questo è riservato al broker

- Non usare spazi nell'argomento

- Non usare caratteri non stampabili nell'argomento

- usare un argomento MQTT per messaggi con significato diverso - creare argomenti diversi per loro

Suggerimenti / Fare

- incorporare l'id del cliente nell'albero degli argomenti

- creare argomenti specifici per l'indirizzamento individuale (ad esempio di sensori), invece di inviare tutti i valori su un argomento - questo eviterà l'invio di messaggi a destinatari che non ne hanno bisogno

- cercate di mantenere i nomi degli argomenti brevi (poiché saranno inviati su ogni pubblicazione e messaggio)

- considerare quali dati dovranno essere inviati e con quale frequenza

o p.e. considerare di separare i metadati in un proprio argomento, e pubblicarli con un flag "retain".

- separare gli argomenti comando/cmd e stato per un dispositivo - in questo modo la comunicazione bidirezionale sarà possibile, e il dispositivo non dovrà filtrare i propri messaggi.

- utilizzare un messaggio di ultima volontà per indicare una disconnessione inaspettata del cliente

Considerare la multi-tenancy e il bridging

Avete bisogno di supportare più clienti / organizzazioni / applicazioni indipendenti? C'è la possibilità di usare, per esempio con VerneMQ, diversi punti di montaggio. Un'altra alternativa è quella di includere la multi-tenancy nel tuo albero degli argomenti (usando un prefisso appropriato all'inizio dell'albero degli argomenti).

Preferisco il primo percorso, perché fornisce un ulteriore livello di separazione ACL - e meno opportunità di "rovinare le cose".

Inoltre, si potrebbe desiderare di collegare diversi broker MQTT insieme, condividendo parte dei loro alberi degli argomenti (come definito dalle loro ACL).

Vedi questo https://owntracks.org/booklet/guide/bridge/ per saperne di più sul bridging.

Considera la crittografia

MQTT può essere eseguito su reti criptate (ad esempio su websockets / TLS criptato) o su canali non criptati. Inoltre si può considerare di criptare e/o firmare il payload dei dati.

Considera la scopribilità

Considerate la possibilità di costruire argomenti che aiutino a scoprire i servizi e le capacità dei vostri dispositivi, per esempio utilizzando i messaggi trattenuti.

Considerare il feedback sui comandi

Quando si pubblica un comando, non si ha un canale di ritorno immediato. Quindi potrebbe essere utile stabilire una gerarchia per un feedback specifico su comandi specifici - se il dispositivo ha ricevuto e ha potuto eseguire il comando, per essere in grado di fornire un feedback all'utente.

Un modello che stavo pensando di applicare qui era quello di dare id unici di comando come parte del payload del messaggio, che sono referenziati nel canale di feedback con un codice di stato.

Considerare gli scenari multicast

Vuoi che diversi dispositivi reagiscano a un singolo messaggio che pubblichi? Ricorda che non puoi pubblicare su argomenti jolly, ma solo sottoscriverli. In questo caso, bisognerebbe creare degli argomenti supplementari che permettano ai client di reagire agli scenari multicast. Tutti i client / tutti i client di un particolare gruppo si iscriverebbero all'argomento multicast e reagirebbero ai messaggi.

Se combini questo con il mio suggerimento di feedback / riferimento all'id del comando sopra, viene introdotto un nuovo requisito dell'id del client come payload sul canale di feedback (generico). Un'altra possibilità è quella di far rispondere i dispositivi sui loro canali di feedback individuali - dove l'id del dispositivo è già parte del percorso. (Cioè, ricevono un comando sul percorso multicast, ma rispondono nella loro esclusiva gerarchia di argomenti dei messaggi).

Considera il traffico e la privacy, i tipi di sensori

Se state gestendo un sistema commerciale, ad esempio raccogliendo dati di sensori per gli utenti, essi potrebbero voler essere in grado di avere un buon grado di controllo su quali valori dei sensori sono pubblicati.

Inoltre, la semplice pubblicazione automatica di tutte le letture dei sensori aumenterà il traffico e il carico sui vostri server.

Pertanto, spingere semplicemente tutti i valori dei sensori disponibili al vostro broker MQTT potrebbe non essere la scelta migliore. Una possibilità è quella di creare un argomento conservato, con una configurazione che il client può sottoscrivere. Quando il client si connette, riceverà automaticamente la configurazione sull'argomento mantenuto, e può regolare i valori che pubblica in base alla configurazione. Inoltre, può reagire ai cambiamenti di configurazione reagendo a qualsiasi messaggio aggiuntivo che arriva su questo argomento di configurazione.

Inoltre, è importante considerare che esistono diversi tipi di sensori. Per esempio, per un sensore di porta sareste interessati a un cambiamento di stato (chiuso vs. aperto), mentre con un sensore di temperatura, potreste voler ricevere letture continue. È importante per il tuo progetto considerare che tipo di valori gli abbonati riceveranno quando il client responsabile delle letture del sensore si disconnette. Ricorda che puoi impostare un'ultima volontà solo su un argomento (per dispositivi multisensore). Nel caso di una disconnessione, i messaggi conservati potrebbero dare un'impressione sbagliata (ad esempio che la porta sia aperta mentre in realtà è chiusa, ma non è stata aggiornata, ecc.)

D'altra parte, se, per esempio, la vostra interfaccia web che controlla il client è collegata solo dopo che il client del sensore di porta è stato collegato per un po', e voi usate messaggi non mantenuti, il messaggio dell'ultimo aggiornamento dello stato della porta verrà perso;

Ci sono due possibilità qui:

• richiedere attivamente un aggiornamento dello stato della porta (ad esempio utilizzando il proprio argomento get)
• usare messaggi trattenuti, e usare la logica lato client dell'interfaccia web per scartare l'ultimo valore nel caso in cui il client stesso non sia collegato / segnare come stantio

In ogni caso, l'utente dovrebbe essere informato se una lettura del sensore può essere attendibile, o se è probabilmente errata a causa di un sensore-cliente disconnesso.

Vedi anche http://www.steves-internet-guide.com/mqtt-sensors-traffic-observations/

• Steve nota che combinare i dati di diversi sensori in un carico utile codificato JSON non diminuisce il traffico, ma può addirittura aumentarlo leggermente (rispetto al carico utile non codificato!)

percorso semantico vs. fisico dell'argomento

le cose significative per un umano creano la struttura dell'argomento: ("approccio semantico")

casa/bagno/umidità

i percorsi dei dispositivi (a quali dispositivi sono collegati i sensori, come sono indirizzati?) creare la struttura dell'argomento: ("approccio fisico")

pi/00000234898324734/i2c/10/pressure

(i numeri che simboleggiano rispettivamente la seriale BCM e l'indirizzo I2C).

ripubblicazione

In questa idea si combinano entrambi gli approcci, e si crea un servizio aggiuntivo che traduce tra i due mondi.

Vedere: https://tinkerman.cat/post/mqtt-topic-naming-convention

Panoramica dei suggerimenti di design online

Suggerimento 1: Lampone-Valley

da: https://raspberry-valley.azurewebsites.net/MQTT-Topic-Trees/

device-category/device-id/payload-context/payload-differentiator

• categoria del dispositivo: per esempio "pi", "arduino", ecc.
• device-id: ad esempio, seriale BCM
• payload-context: per esempio la temperatura
• payload-differentiator: per esempio front / back (aggiungendo un livello di misura per un dato contesto)

Si noti la simmetria tra device-category/device-id e payload-context/payload-differentiator (generico-> specifico; generico -> specifico)

Suggerimento 2: Steve

(Da Steve): http://www.steves-internet-guide.com/mqtt-topic-payload-design-notes/

Puoi includere i seguenti elementi nel tuo albero degli argomenti:

• dispositivi di raggruppamento degli argomenti di alto livello
• nome del sensore assegnato
• funzione (per esempio set / status / get / cmd )

L'approccio di Steve:

• utilizzare il nome dell'argomento per un singolo dispositivo (ad esempio un sensore)
• utilizzare i dati payload / JSON per gli attributi di questo sensore
• utilizzare argomenti separati per dati e comandi

Suggerimento 3: MQTT-Smarthome

Proposta MQTT Smarthome

https://github.com/mqtt-smarthome/mqtt-smarthome

un percorso si presenta così in questa proposta:

toplevelname/funzione/item

knxgateway1/status/Kitchen/Lights/Front Left

• primo livello (knxgateway1) = toplevelname, il gateway concreto che viene indirizzato
• per più gateway simili questo nome deve essere impostabile per evitare collisioni nello spazio dei nomi
• secondo livello (stato) = funzione
• terzo livello, e ulteriori livelli -> gerarchia di indirizzi individuali del particolare gateway (voce)

La parte interessante sono le funzioni e la loro posizione prima di i percorsi più profondi (considera i caratteri jolly per la sottoscrizione - in questo modo puoi sottoscrivere facilmente tutti i rapporti sullo stato dei dispositivi!)

Funzioni disponibili / definite in questa proposta:

• stato - per ottenere rapporti sullo stato
• set - per richiedere cambiamenti di stato
• get - (opzionale) per richiedere attivamente un aggiornamento di stato (per i gateway che lo supportano)
• il risultato della lettura sarà pubblicato al stato gerarchia.

Le gerarchie successive per i singoli verbi dovrebbero corrispondere l'una all'altra, in modo da indirizzare lo stesso dispositivo / nodo / parametro.

C'è un argomento speciale "collegato" per gateway, che permette al cliente di impostare un messaggio di ultima volontà e testamento

toplevelname/connected

sono definiti valori semplici per questo argomento:

• 0 = disconnesso dal broker (impostato come ultima volontà)
• 1 = collegato a MQTT, disconnesso dall'hardware
• 2 = collegato a MQTT e all'hardware (completamente operativo)

Si noti che il valore 0 non distingue tra disconnessioni volontarie o una connessione persa (dove il keep-alives è scaduto).

Ci sono anche suggerimenti per il carico utile:

La codifica JSON del carico utile è opzionale.

Nel caso della codifica JSON, il valore sarà sempre nella chiave "val". Inoltre,

ts : timestamp (timestamp, millisecondi da Epoch)

lc : ultimo cambiamento di valore (timestamp, millisecondi da Epoch)

Suggerimento 4: Tinkerman

https://tinkerman.cat/post/mqtt-topic-naming-convention

considerate se volete un approccio "semantico" (ad esempio cose significative per gli esseri umani) o un approccio "fisico" (ad esempio percorsi effettivi dei dispositivi in cui il vostro sistema è collegato).

L'approccio fisico è più adatto alle macchine.

(Si prega di notare che la comprensione di Tinkerman e la mia dei punti di montaggio e del loro uso differiscono - per me i punti di montaggio sono alberi di argomenti completamente separati, ad esempio per la multi-tenancy)

I metadati possono essere codificati come percorsi postfix.

ad esempio

/home/camera/temperatura -> 21

/home/camera/temperatura/unità -> °C

/home/bedroom/temperature/timestamp -> 2012-12-10T12:47:00+01:00

Nota: poiché è improbabile che le unità e alcuni altri metadati cambino, potrebbero essere inviati come argomenti conservati.

Una parte interessante di questo suggerimento è anche l'aggregazione (lato dispositivo):

/home/bedroom/temperature/last -> ultimo valore di temperatura

/home/bedroom/temperature/last/timestamp

/home/bedroom/temperature/last24h/max -> valore massimo nelle ultime 24h

/home/bedroom/temperature/last24h/max/timestamp -> timestamp in cui la temperatura era così alta

/home/bedroom/temperature/last24h/min

/home/bedroom/temperature/ever/max -> la temperatura più alta in assoluto mai misurata

Di nuovo, questi valori potrebbero essere impostati come argomenti conservati (specificamente "mai") per risparmiare il traffico di rete - il sistema ricevente potrebbe scartare i vecchi valori conservati (se il sensore è disconnesso, come dovrebbe essere evidente da un altro argomento - possibilmente impostato da ultimo testamento e volontà), o il sistema potrebbe mostrarli come valori "stantii".

Questo è un design interessante (per l'aggregazione), e potrebbe servire come ispirazione per permettere questo tipo di flessibilità.

Suggerimento 5: Convenzione Homie IoT

https://homieiot.github.io/

Home IoT si concentra sulla scopribilità dei nodi nell'ambito della domotica IoT. Homie non usa messaggi codificati in JSON, ma utilizza una rappresentazione diretta del carico utile per ogni nodo. Vedi questo esempio:

Homie definisce un sottoinsieme rigoroso di caratteri che ti è permesso usare per nominare i tuoi nodi, dato che i caratteri speciali (ad esempio $ e l'underscore _) sono usati per scopi speciali.

Definisce dei tipi di dati, che sono pubblicati come metadati ("attributi") (conservati) a $datatype della singola proprietà (vedi sotto per la definizione di proprietà):

• Stringa
• Integro
• Galleggiante
• Booleano
• Enum
• Colore

(notare l'uso dell'$ per marcare argomenti speciali).

Last will è usato per contrassegnare il dispositivo come perso:

homie/deviceID/$state -> perso

Homie definisce 6 possibili stati per il dispositivo:

• init -> il dispositivo si è connesso a MQTT ma non ha ancora pubblicato tutti i messaggi Homie necessari
• pronto -> il dispositivo è collegato e ha finito la configurazione - tutti i messaggi necessari sono stati inviati
• disconnesso -> il dispositivo si è disconnesso in modo pulito
• dormire -> autodescrittivo
• perso -> il dispositivo si è scollegato inaspettatamente (impostato dalle ultime volontà e dal testamento)
• avviso -> il dispositivo è collegato, ma qualcosa non va, ha bisogno di un intervento umano

Homie raccomanda di usare QoS 1 (poiché la natura di Homie lo rende sicuro per i messaggi duplicati).

Una disposizione per estensioni è fatto usando una sintassi di nome di dominio inversa, ad esempio org.mycompany.homie-extension

nodi e dispositivi

In Homie-parlance, un dispositivo è l'unità hardware di base. Per esempio, un Raspberry Pi, una macchina da caffè, una macchina.

A nodo è un'unità logica indipendente del dispositivo. Per esempio, un'automobile potrebbe avere un nodo ruote, un nodo motore e un nodo luci.

proprietà rappresentano le caratteristiche di base del nodo/dispositivo. Un'auto, per esempio, potrebbe avere una proprietà "velocità" e una "temperatura" per il nodo motore. Le proprietà possono essere mantenute e/o impostabili.

• mantenuto + non impostabile: per esempio, sensore di temperatura
• mantenuto + impostabile: il nodo può pubblicare una proprietà e ricevere comandi per la proprietà (ad es. potenza della lampada)
• non mantenuto + non impostabile: per esempio un campanello (eventi momentanei)
• non mantenuto + impostabile: il nodo può ricevere comandi per la proprietà, ad esempio preparare il caffè

attributi:

gli attributi sono importanti per l'autodiscovery di Homie, sono specificati, e iniziati con un $ per indicare il loro particolare significato / evitare collisioni. Sono usati per memorizzare e aggiornare i metadati.

Per esempio, il dispositivo pubblica un messaggio trattenuto su

homie/device ID/$nodes

con una lista separata da virgole dei nodi. Per indicare che un nodo è un array (può essere usato per raggruppare ad esempio le luci anteriori e posteriori di un'auto), il nome viene specificato con parentesi rettangolari alla fine, ad es.

luci[]

Un esempio per il sottoalbero dell'id del dispositivo:

Homie specifica diverse statistiche per il dispositivo fuori dalla scatola, la maggior parte delle quali sono opzionali (tranne il tempo di attività). Per esempio:

Con i nodi, di nuovo l'autodiscovery è possibile per le proprietà, specificandole nell'attributo $properties:

In questo modo tu, come abbonato, non devi indovinare/sottoscrivere tutti gli eventi - puoi iscriverti selettivamente a quelli che ti interessano.

In Homie, i metadati (attributi) sono pubblicati come suffisso al percorso. Ad esempio, per una particolare proprietà:

Controllo in Homie

Homie è basato sullo stato. Questo significa che non si "accende la luce", ma si imposta lo stato di alimentazione di un dispositivo su on.

allora il dispositivo aggiorna il suo stato di alimentazione per comunicare che il comando è stato eseguito:

Broadcast

alert è una scelta arbitraria - la trasmissione può essere a qualsiasi altro argomento, che i dispositivi possono filtrare. I messaggi sono trasmessi a tutti i dispositivi - i dispositivi possono reagire se vogliono.

Questa è la specifica più completa che sono riuscito a trovare nella mia ricerca online. Personalmente ritengo che sia progettato in modo molto elegante.

Leggi di più:

https://homieiot.github.io/specification/

Suggerimento 6: le proprie tracce

https://owntracks.org/booklet/tech/json/

http://owntracks.org/booklet/guide/topics/

Owntracks è un'applicazione Open Source, che permette di tracciare la propria posizione fisica, da condividere con gli amici, ecc. La posizione viene pubblicata via HTTP o MQTT, idealmente al proprio broker.

" Può anche rilevare quando si entra o si esce da una particolare regione per la quale si imposta un cosiddetto waypoint. La gente lo usa, per esempio, per controllare qualche aspetto del loro sistema di automazione domestica. (Siete tutti usciti di casa? Possiamo spegnere le luci)".

Se volete saperne di più su OwnTracks, andate su questo sito: https://owntracks.org/booklet/

Riguardo al design dell'argomento owntracks:

https://owntracks.org/booklet/guide/topics/

"I principi durante la progettazione dello schema di denominazione degli argomenti OwnTracks erano

• leggibilità umana
• minimizzazione del traffico
• controllo granulare dell'accesso

“

Nome dell'argomento di base (altri sono possibili):

owntracks/peter/iPhone

qui owntracks è un prefisso, per permettere ad altre applicazioni di non avere collisioni sul broker MQTT.

peter è il proprietario di dispositivi di tracciamento, e l'iPhone è uno dei suoi dispositivi.

i comandi ai dispositivi sono inviati su: owntracks/peter/iPhone/cmd

l'output dei comandi è pubblicato, ad esempio, su nomi di argomenti relativi passo, scaricare ecc.

vengono definiti altri argomenti (info, waypoint, evento). Gli eventi vengono pubblicati, per esempio, quando un utente entra in una zona definita.

In questo modo la sottoscrizione a owntracks/+/+/event ti permetterà di vedere (per gli utenti che sei autorizzato a vedere) quando entrano o escono da una zona definita.

Owntracks pubblica i suoi messaggi nel formato JSON:

https://owntracks.org/booklet/tech/json/

come potete vedere le funzioni sono dopo il dispositivo.

Poiché c'è una "profondità" fissa per utente/dispositivo conosciuta in anticipo, la sottoscrizione a più utenti e dispositivi può essere fatta usando i caratteri jolly:

Nel JSON, l'elemento tipo del particolare JSON viene passato nel messaggio:

Questa è una bella idea! In questo modo, puoi verificare che la tua applicazione capisca correttamente l'evento, può fare controlli di tipo, ecc.

I singoli elementi sono specificati in modo non verboso. Questo aiuta a risparmiare traffico, specialmente per i messaggi che saranno pubblicati frequentemente.

per esempio:

• acc: precisione della posizione riportata in metri (senza unità)

molti degli elementi sono opzionali.

È interessante notare che il tipo di posizione è definito per diversi dispositivi, che supportano elementi diversi.

Viene pubblicato un semplice messaggio di ultima volontà. Include semplicemente un timestamp tst, in cui il dispositivo si è collegato per la prima volta.

tst è un timestamp dell'epoca Unix.

Un aspetto interessante di questo tipo di evento / tipo di payload è che sono specificati diversi timestamp:

• wtst: Timestamp della creazione del waypoint
• tst: Timestamp in cui si è verificato l'evento.

Un waypoint è un punto di interesse, ad esempio il tuo garage - se entri o esci dal tuo garage, un evento di transizione sarà attivato:

• evento: (entrare|lasciare)

Un evento di configurazione. Se abilitato, le applicazioni accettano anche messaggi di configurazione remoti.

Questo evento include molti elementi possibili, che sono più verbosi (per esempio validatecertificatechain) - questo è ragionevole, poiché la configurazione può essere memorizzata come JSON (! -> questo può essere passato come messaggio MQTT e memorizzato!), e anche perché non viene inviato spesso, la verbosità non è un grande problema, ma piuttosto un vantaggio per gli utenti.

Per esempio, un'azione con "azione": "dump" attiverà la pubblicazione del messaggio di configurazione nel percorso relativo dump

Si possono dare dei sottoparametri opzionali per un'azione, per esempio un intervallo di tempo da considerare:

Un'altra idea di design interessante è che con una certa variazione di questo messaggio cmd si può aprire un browser verso un certo URL. Ad esempio, se si entra nel garage, si potrebbe aprire un sito di controllo del garage, ...

un array di un tipo di messaggio diverso può / deve essere passato come parametro qui.

La parte interessante di questo messaggio è che ha anche un campo per un'immagine PNG codificata in Base64:

l'idea interessante qui è che un opzionale _creatore che identifica l'entità che ha creato questi waypoint.

Notate anche che owntracks usa il trattino basso _ per i parametri "speciali".

opzionalmente tutti questi messaggi possono essere crittografato per il trasporto con una chiave simmetrica condivisa.

Il carico utile criptato (il messaggio originale) sarà nell'elemento "data", codificato in Base64.

Messaggi

Il payload del messaggio è binario e può essere qualsiasi cosa, non c'è nessun requisito che i messaggi siano UTF-8 validi.

Quindi puoi anche pubblicare dati digitali, ad esempio immagini, come payload su certi argomenti.

Molti cruscotti IoT attuali prendono dati codificati come JSON.

In generale sembrano esserci due scuole di pensiero: dove i messaggi sono effettivamente valori grezzi, e i metadati sono codificati nell'albero degli argomenti, e valori codificati in JSON che portano i metadati come carico utile.

suggerimenti

• Utilizzare il formato JSON per il carico utile del messaggio
• raggruppare gli attributi nei messaggi, invece di creare singoli argomenti per essi
• includono:
• dati del carico utile
• id del sensore/dispositivo (se non fa parte dell'albero degli argomenti)
• funzione
• timestamp

Risorse interessanti

Awesome MQTT: raccolta di link relativi a MQTT:

• https://github.com/hobbyquaker/awesome-mqtt

progetti individuali:

twitter-to-mqtt - Un demone python che utilizza la Twitter Streaming API per accedere ai tweet e ripubblicarli in un argomento MQTT.

• https://github.com/knolleary/twitter-to-mqtt

fritz2mqtt - Collega il FRITZ!Box a MQTT.

• https://github.com/akentner/fritz2mqtt

Rif:

• https://raspberry-valley.azurewebsites.net/MQTT-Topic-Trees/
• https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/
• https://homieiot.github.io/
• https://github.com/homieiot/convention
• https://github.com/mqtt-smarthome/mqtt-smarthome
• http://www.steves-internet-guide.com/mqtt/
• http://www.steves-internet-guide.com/understanding-mqtt-topics/
• http://www.steves-internet-guide.com/mqtt-topic-payload-design-notes/
• https://stevessmarthomeguide.com/setting-up-the-sonoff-tasmota-mqtt-switch
• https://tinkerman.cat/post/mqtt-topic-naming-convention
• https://github.com/mqtt-smarthome/mqtt-smarthome/blob/master/howtos/homematic.md (che mostra il flusso con Nodo ROSSO)
• https://owntracks.org/booklet/tech/json/

Ripubblicazione:

• https://lodge.glasgownet.com/2012/09/23/mqtt-republishing-itch/
• https://github.com/kylegordon/mqtt-republisher

Segnale K per uso marino (come possibile ispirazione per il formato JSON):

• http://signalk.org/specification/1.3.0/doc/signalk.pdf