Minu kogemuste järgi on ReST reaalajas andmeedastuseks ja töötlemiseks hea, kuid sõnumite lihtsaks edastamiseks on sellel palju lisakulusid. Lisaks pole selles järjekorda, nii et poodide edastamise konfiguratsioonid on tülikad.

MQTT on sõnumijärjekordade transpordisüsteem, kus kirjastaja saab teate kanalile paigutada ja jääb sinna seni, kuni tellija selle valib. üles. Nii et teil võib olla mõned algelised edasitoimetamise võimalused. Samuti on MQTT läbipaistvam ja multisaateline, nii et paljude sõlmedega suhtlemine ei erine ühega suhtlemisest.

Sellega on mõlemal oma koht ja kasutusala ning ReST sobib suurepäraselt suurte üksuste (JSON-plekid) saatmiseks, saatmiseks andmed arvutamiseks ja nende saamiseks ning konkreetse andmekogumi taotlemiseks. MQTT on mõeldud pigem "siin on minu anduriandmed iga sekund, naudi".

Põhimõtteliselt vähendab MQTT latentsust seal, kus on suhteliselt kõrge viivitus, näiteks WiFi, hoides TCP-ühendust elus, et andmeid saaks väga kiiresti avaldada ja vastu võtta. See kasutab porti 1883, mitte 80. Nagu ma aru saan, ühendavad väljaandjad ja tellijad üks kord maakleriga ja pingutavad seejärel maaklerit regulaarselt, et ühendus püsiks elus; maakleri pingutamise sagedus sõltub eelnevalt kokku lepitud hoidmisperioodist. Ka MQTT paketid on HTTP-päringutest oluliselt väiksemad. Kui ühendus on kuidagi katki, proovib klient korduvalt ühendust taastada ja kui see õnnestub, tellivad tellijad uuesti.

Tellijad määratlevad tagasihelistamised, millele helistatakse pärast seda, kui mõni kirjastaja on teemat värskendanud. . MQTT sobib kõige paremini ajakriitiliste tööde jaoks, kus HTTP-taotlused võtaksid lihtsalt liiga kaua aega ja kus soovitakse muutunud teemadest kiiret teavitamist. Ma pole kindel, kuid tõenäoliselt tarbib see rohkem akut, sest siin on küsimus pidevas TCP-lingis maakleriga.

Kuna ootate andmete värskendusi ainult iga minut, on minu arvates mõttekam ühendada ja hankida vooandmed serverist iga 60 sekundi järel. Saate kasutada voo Viimati uuendatud ajatemplit (kui seda pole, siis looge see), et kontrollida, kas Arduino on voogu veel värskendanud. MQTT tehnika veedaks suurema osa ajast lihtsalt ilma vahendita maakleriga ühenduses, kuna teate juba, et värskendussündmused toimuvad iga minut; see on märkimisväärne hulk aega ja energiat, mis kulub prognoositavate andmete ootamisele.

Siiski võiksite oodata umbes 55 sekundit, teemat tellida ja uute andmete saamisel katkestate ühenduse ja ootate siis uuesti 55 sekundit, kuigi ma ei tea, kas sellest saab palju paranemine RESTiga võrreldes. Kui kasutate seda meetodit, saate ka elamisperioodiks seada vaid umbes 10 sekundit, nii et Arduinol oleks piisavalt aega voo värskendamiseks enne, kui teie rakendusest teavitatakse, ja pole vaja tavalisi pinge.

Kui otsustate MQTT-ga minna, vaadake seda Arduino teeki.

(häbitu enesereklaam) Ma rääkisin sel aastal meie kohalikus koodlaagris palju asju. Märkused on siin: https://github.com/adbacker/bcc2016/blob/master/2016bcc-iotonthecheap.pdf

Ülimalt lihtsustatud minu piiratud kogemuse kohta: (eksperdid parandavad teeb :-))

MQTT-protokoll:

MQTT on optimeeritud lihtsate andmete saatmiseks. GPS-koordinaadid sobiksid hästi. Olen kindel, et MQTT-i võiks kasutada keerukate andmete (st suurte JSON-objektide) saatmiseks, kuid see ei tundu olevat mõeldud selleks.

Te pole otsite tõukemärguandeid seadmesse tagasi ega hoia ühendust REST-serveriga, nii et (praktilisest vaatevinklist) arvan, et teie aku tööea paranemine oleks lahenduse mqtt-i teisendamisel kõige väiksem.

Adafruitil on päris hea mqtt-õpetus ja raamatukogud ning beetateenus, mis pakub maakleriteenuseid: https://learn.adafruit.com/adafruit-io/mqtt-api

Lubage mul soovitada blynki ka ülimalt lihtsate IOT-seadistuste jaoks (mis kasutavad kohandatud protokolli). (www.blynk.cc) See on tasuta ja nii lihtne, et kirjutasin kogu oma ettekande ümber. Lisaks on olemas (tasuta) blynk ios ja androidirakendused, mis võimaldavad luua kohandatud juhtpaneele, mis suhtlevad teie valitud seadmega (ka tasuta blynki maakleri kaudu). Kui hostite maakleriserverit (ka tasuta) ise, on sellel oma REST-api, mis võimaldab andmetele juurdepääsu teie seadmele / teie seadmest.

Minu rakendustes on suurim voolukatkestus raadio sisselülitamine andmete edastamiseks. Sageli hoian raadio välja lülitatud, kogun andmepunkte ja lülitan siis raadio sisse, et saata mitu andmekogumit ühe päringuna, kasutades RESTful HTTP-kõnet. Minu jaoks on RESTful HTTP palju tõhusam, kuna ma ei vaja alati ühenduse loomist.