Etter min erfaring er ReST bra for sanntids dataoverføring og behandling, men har mye overhead for enkel overføring av meldinger. I tillegg er det ingen kø i den, så konfigurasjoner er store. " opp. Så du kan ha noen rudimentære store-forward-muligheter med dette. MQTT er også mer gjennomsiktig og multicast, så kommunikasjon til mange noder er ikke annerledes enn å kommunisere til en.

Med det har hver sin plass og bruk, og ReST er flott for å sende store gjenstander (JSON-blobs), sende data for beregning og tilbakeføring, og for å be om et spesifikt datasett. MQTT er mer for "her er sensordataene mine hvert sekund, nyt".

I utgangspunktet reduserer MQTT ventetid der det er relativt høy ventetid som Wi-Fi ved å holde TCP-tilkoblingen i live slik at data kan publiseres og mottas veldig raskt. Den bruker port 1883 og ikke 80. Slik jeg forstår det, kobler utgivere og abonnenter en gang til megleren og deretter pingler megleren regelmessig for å holde forbindelsen i live; hvor ofte megleren pinges, avhenger av den avtalt levetid. MQTT-pakker er også betydelig mindre enn HTTP-forespørsler. Hvis forbindelsen på en eller annen måte er brutt, prøver klienten gjentatte ganger å gjenopprette forbindelsen, og når den lykkes, abonnerer abonnentene på nytt.

Abonnenter definerer tilbakeringinger som blir ringt opp etter at et emne er oppdatert av noen utgivere. . MQTT er best for tidskritiske jobber der HTTP-forespørsler bare vil ta for lang tid, og hvor det er ønskelig å varsle raskt om endrede emner. Jeg er ikke sikker, men det vil sannsynligvis forbruke mer batteristrøm, siden det er saken om en konstant TCP-kobling til megleren.

Siden du bare forventer dataoppdateringer hvert minutt, tror jeg det er mer fornuftig å koble til og FÅ feeddataene fra serveren hvert 60. sekund. Du kan bruke feedets Sist oppdatert tidsstempel (hvis det ikke finnes, opprett et) for å sjekke om feedet er oppdatert av Arduino ennå. En MQTT-teknikk vil tilbringe mesteparten av tiden koblet til en megler uten grunn, siden du allerede vet at oppdateringshendelsene skjer hvert minutt; det er betydelig tid og krefter brukt på å vente på forutsigbare data.

Du kan imidlertid vente i omtrent 55 sekunder, abonnere på emnet, og når du får de nye dataene, kobler du av og deretter venter i 55 sekunder igjen, selv om jeg ikke vet om dette vil være mye forbedring i forhold til REST. Hvis du bruker denne metoden, kan du også stille levetiden til omtrent ti sekunder, slik at Arduino har nok tid til å oppdatere strømmen før appen din blir varslet, og det er ikke behov for vanlige pinger.

Hvis du bestemmer deg for å gå med MQTT, kan du sjekke ut dette Arduino-biblioteket.

(skamløs selvopprykk) Jeg holdt en snakk om iot-ting i år på den lokale kodeleiren vår. Merknader er her: https://github.com/adbacker/bcc2016/blob/master/2016bcc-iotonthecheap.pdf

Superforenklet i henhold til min begrensede erfaring: (eksperter retter på vil :-))

MQTT-protokoll:

MQTT er optimalisert for sending av enkle data. GPS-koordinater passer godt. Jeg er sikker på at MQTT kan brukes til å sende komplekse data (dvs. store json-objekter), men det ser ikke ut til å være det den er designet for.

Du er ikke på jakt etter push-varsler tilbake til enheten, og du opprettholder heller ikke en forbindelse til REST-serveren, så (fra et praktisk synspunkt) antar jeg at batterilevetidens forbedring ville være liten på det aller beste ved å konvertere løsningen til mqtt.

Adafruit har en ganske god mqtt-opplæring og biblioteker, samt en beta-tjeneste som tilbyr meglertjenester: https://learn.adafruit.com/adafruit-io/mqtt-api

Også, for super-duper-enkle IOT-oppsett (som riktignok bruker en tilpasset protokoll), la meg anbefale blynk. (www.blynk.cc) Det er gratis og så enkelt at jeg skrev om hele presentasjonen min rundt den. I tillegg er det (gratis) blynk iOS- og Android-apper som tillater oppretting av tilpassede dashbord som kommuniserer (via den også gratis Blynk-megleren) med den valgte enheten. Hvis du er vert for meglerserveren (også gratis) selv, har den sin egen REST-api som gir datatilgang til / fra enheten.

I applikasjonene mine er det største strømforsyningen å slå på radioen for å overføre data. Jeg holder ofte radioen av, samler inn datapunkter og slår deretter på radioen for å sende flere datadeler sammen som en forespørsel ved hjelp av en RESTful HTTP-samtale. For mitt tilfelle er RESTful HTTP mye mer effektiv siden jeg ikke trenger en tilkobling som alltid er på.