Devo usare MQTT o HTTP?


9

Sto lavorando su un dispositivo che rileva e raccoglie informazioni dall'ambiente come temperatura, umidità, ecc.

Il dispositivo non è collegato a nessuna fonte di alimentazione, ma ha una batteria e un pannello solare per caricarlo.

È quasi in uno stato di sonno profondo per la maggior parte del tempo e si sveglia solo quando è necessario rilevare e trasferire i dati. Questa operazione richiede circa 1-2 minuti, quindi torna a dormire.

Non sono un esperto in questo settore, ma penso che MQTT dovrebbe essere una buona opzione se il dispositivo deve essere accessibile per ricevere messaggi da un argomento in ogni momento, ma nel mio scenario legge solo i sensori e invia i dati a un server periodicamente.

Attualmente sto inviando i dati tramite HTTP, ma mi chiedo se abbia senso implementare MQTT? Dovrei ottenere qualche vantaggio su HTTP per questo scenario?


1
È simile, ma il mio punto è capire se devo implementare MQTT nel mio scenario: quando il mio dispositivo sarà in modalità deep-sleep il 99% delle volte, e mi sveglio solo per inviare letture.
zephrax,

1
Non suggerirei nessuno dei due. Innanzitutto scrivi le tue esigenze e implementa il protocollo più semplice. Non avrebbe senso usare un motore Ferrari in un tosaerba per tagliare l'erba. Non lasciarti coinvolgere dalla confusione delle cose: fai solo le tue ricerche di base e attua ciò che funziona meglio.
Xofo,

Sarebbe bello catturare il requisito nel titolo della domanda, in generale, mi stai chiedendo di valori del sensore piccoli e rari, credo.
Sean Houlihane,

@Xofo Sarei interessato a vedere una risposta in merito e perché potresti suggerire di utilizzare un protocollo personalizzato. Vale la pena lo sforzo aggiuntivo di "creare il proprio", oltre ai problemi di sicurezza, ecc.?
Aurora0001

Non un protocollo personalizzato ... Ho detto prima di definire i requisiti. Alcuni dei protocolli prescritti sono spesso troppo pesanti.
Xofo,

Risposte:


8

Se si stanno archiviando dati, è sufficiente attenersi a HTTP. HTTP è solo un segnale a senso unico.

Se il tuo server o qualsiasi altra "cosa" dovrebbe reagire a un segnale specifico (bassa temperatura, ...) allora usa MQTT. In questo modo molti dispositivi possono abbonarsi al segnale di temperatura e reagire immediatamente senza utilizzare il server.


1
Inoltre, esiste una divisione tra grande (http) e piccola (mqtt) quantità di dati contemporaneamente e anche mqtt è più affidabile in condizioni di cattivo segnale.
mico,

1
Il server riceve solo dati dai sensori. Il punto del mio post è che non sono sicuro che abbia senso usare MQTT, perché il dispositivo sarà il 99% delle volte in stato di sonno profondo (tutti i bus, modem, sensori spenti) e solo si sveglia per leggere i sensori e inviare i dati.
Zephrax,

Se memorizzi i tuoi dati da qualche parte, questo significa che hai un database e un modo back-end per interrogarli (server Apache, riga di comando SQL, ...). Se metti un MQTT in cima a questo avrai un'altra istanza e porta da gestire.
Goufalite,

1
Sono d'accordo con questa risposta. Se non hai bisogno di comunicazione bidirezionale e il dispositivo dorme per la maggior parte del tempo, HTTP è una scelta di protocollo semplice e adatta.
TheMagicCow

8

Si menziona un pannello solare e una batteria come parte del dispositivo, quindi probabilmente si desidera ridurre al minimo il consumo di energia durante le trasmissioni per assicurarsi che il dispositivo non si esaurisca completamente.

Pertanto, si potrebbe prendere in considerazione COAP , il Co nstrained A pplicazione P ROTOCOLLO, che è specificamente progettato per i dispositivi vincolati in Internet delle cose.

Nel documento Confronto dell'efficienza in termini di costi di CoAP e HTTP nelle applicazioni Web of Things , puoi trovare alcune prove convincenti del fatto che CoAP potrebbe farti risparmiare energia qui. Nell'Appendice A (pagina 38), puoi dare un'occhiata alla durata prevista della batteria dei dispositivi nella Tabella A.4. Per un intervallo di tempo di 120 secondi, come previsto nel caso d'uso:

t bat (HTTP), giorni - 2013

t bat (CoAP), giorni - 11013

Questi calcoli sono stati eseguiti su un paio di batterie AA carbonio-zinco, ma puoi vedere chiaramente che CoAP consuma molta meno energia, quindi potrebbe valere la pena considerare. La sua "modalità push", come descritto nel documento, sembra esattamente il tipo di cosa che hai intenzione di fare.

Anche se non hai chiesto specificamente di CoAP, penso che valga la pena menzionarlo, poiché Goufalite ha già coperto le differenze essenziali tra MQTT e HTTP. Una buona regola empirica è: pensi di comunicare uno a uno o uno a molti ? Se è il primo, HTTP e CoAP sembrano adattarsi meglio. Se è quest'ultimo, MQTT è probabilmente più conveniente.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.