Il protocollo MQTT è appropriato per la trasmissione delle letture del sensore su BLE?

Supponiamo che vi siano numerosi sensori deboli (ad es. Dispositivi di livello Arduino) che si basano su BLE come mezzo di comunicazione e che questi dispositivi sono collegati a un gateway più potente (ad es. Dispositivi Raspberry pi di livello).

Vorrei sapere se MQTT è considerato un protocollo appropriato per trasmettere le loro letture (brevi messaggi brevi e frequenti).

Numerosi blog / documenti considerano MQTT appropriato per "applicazioni IoT" perché è leggero (er) rispetto a HTTP e risparmia energia. Tuttavia, a mio avviso, è necessario mantenere aperta una connessione che non è il caso di BLE o di altri protocolli di comunicazione appropriati per l'IoT. BLE non mantiene la connessione aperta per periodi di tempo prolungati per riservare energia. Apparentemente, MQTT è appropriato quando viene utilizzato un protocollo di livello MAC come WiFi. Questo quasi rompe la logica alla base dell'utilizzo di MQTT in primo luogo (ovvero, se il dispositivo gestisce in modo computabile un protocollo come WiFi, potrebbe non essere necessario un protocollo come MQTT). Vedi un difetto in questa logica?

Esiste un protocollo di livello applicazione alternativo a tale scopo? Qual è la struttura più frequentemente vista di questo tipo di messaggi (ad es. Dati binari non elaborati, JSON, XML) quando comunicano con un gateway e quando comunicano direttamente con un server?

mqtt power-consumption bluetooth-low-energy

— dr.doom
fonte

Il meccanismo BLE nativo è inappropriato per qualche motivo particolare?

— Sean Houlihane,

La domanda di Sean potrebbe essere meglio suddivisa in due parti: A) i meccanismi del protocollo BLE nativo sono utilizzabili per il collegamento immediato dal dispositivo e B) dove devono finire i dati? Se la risposta alla parte B va oltre l'intervallo di BLE, è necessario un bridge (almeno tra i formati radio ma probabilmente anche i protocolli).

— Chris Stratton,

Il gateway consuma le letture grezze o semplicemente le inoltra, e in quel contesto può avere senso eseguire il tunneling MQTT end-to-end anziché il bridge BLE nativo a MQTT sul gateway?

— Sean Houlihane,

Risposte:

MQTT deve funzionare su TCP / IP (non ricordo se è effettivamente nelle specifiche o se sono state fatte solo ipotesi sufficienti per renderlo tale) ma il suo protocollo affiliato MQTT-SN può essere eseguito su quasi tutti i protocolli che possono trasmettere dati , Ho visto implementazioni in UDP e seriale.

Detto questo, non sono sicuro di ciò che guadagni correndo su BLE, le caratteristiche integrate di BLE offrono molto dello stesso vantaggio (anche se solo su una base da 1 a 1) con cose come la notifica.

Penso che una delle cose importanti da ricordare sia ciò che l'io rappresenta nell'IoT, a un certo punto implica l'accesso a Internet (anche se si tratta di un dispositivo gateway o di un telefono). A quel punto MQTT può essere molto utile, ma non significa necessariamente arrivare fino al bordo (sanguinante).

— hardillb
fonte

Innanzitutto grazie per avermi informato dell'esistenza di MQTT-SN. La stragrande maggioranza della letteratura è in qualche modo fuorviante perché implica che MQTT potenzia i dispositivi periferici principalmente a causa dei suoi attributi di risparmio energetico. In tal caso la riduzione del consumo di energia non è un vero argomento perché nei dispositivi con quel profilo semplicemente non importa. I dispositivi dovrebbero implementare uno stack IP completo e poiché MQTT mantiene una connessione aperta, i protocolli di livello MAC ad alta efficienza energetica non sono un'opzione.

— dr.doom,

MQTT risparmia energia rispetto a qualcosa come HTTP perché una connessione TCP aperta non consuma così tanta energia da tenere aperta una volta che si esegue già uno stack TCP e i pacchetti keep alive sono minuscoli. Anche l'overhead del protocollo è molto più basso di HTTP perché un'intestazione HTTP è enorme rispetto a un'intestazione di pacchetto MQTT.

— Gran

Anche il limite si è spostato, era dove si erano fermati TCP / IP, cose come ble e ZigBee (specialmente con lpwan) e processori di potenza ancora più bassa si sono spostati su dispositivi ancora più sottili

— hardillb

E 'esplicitamente non solo il protocollo TCP / IP; l'unico requisito è che il protocollo deve fornire "connessioni ordinate, senza perdita di dati, bidirezionali". È come il secondo paragrafo dell'abstract del documento. SN esiste perché tale requisito è oneroso per i piccoli sistemi, in particolare quelli basati su radio. Forse è questo che intendi con "sono state fatte abbastanza ipotesi per renderlo tale", ma sicuramente non dipende da TCP / IP.

— Dave Newton,

Probabilmente, sarebbe meglio fare una semplice mappatura dei dati dai paradigmi BLE a MQTT, piuttosto che provare a inviare letteralmente MQTT su BLE.

BLE generalmente scambia dati sotto forma di caratteristiche . Questi hanno vari meccanismi unici di BLE per scoprire la variazione di valore che potresti trovare utili. Ma hanno una lunghezza massima dei dati di 20 byte .

È possibile eseguire lo streaming di dati seriali su BLE, spostando 20 byte alla volta. A volte questo viene fatto per implementare una porta seriale virtuale, e puoi tunnelare MQTT completo attraverso questo.

Ma probabilmente faresti meglio a utilizzare una raccolta di caratteristiche BLE per trasportare i dati di diversi argomenti e disporre di un ponte che mappa l' identità caratteristica su un argomento MQTT e mappa il valore sul payload MQTT.

BLE ha il suo senso delle sessioni connesse in corso rispetto a quelle non connesse. Probabilmente dovresti capire quale sia l'uso migliore di BLE per la tua applicazione, quindi associarlo al senso MQTT di mantenere una connessione.

Dovresti essere in grado di farlo in una o entrambe le direzioni: BLE-> MQTT e MQTT-> BLE

— Chris Stratton
fonte

Se vuoi un bridge MQTT 2 BLE puoi guardare il mio github.com/hardillb/mqtt2ble

— hardillb

Grazie per quel link lo sto guardando proprio ora.

— dr.doom,