D'après mon expérience, ReST est bon pour le transfert et le traitement de données en temps réel, mais a beaucoup de surcharge pour la simple transmission de messages. De plus, il n'y a pas de file d'attente, donc les configurations de stockage différé sont gênantes.

MQTT est un système de transport de file d'attente de messages où le message peut être placé sur le canal par l'éditeur et y restera jusqu'à ce que l'abonné le choisisse vers le haut. Vous pouvez donc avoir des capacités de stockage anticipé rudimentaires avec cela. De plus, MQTT est plus transparent et multicast, donc communiquer avec de nombreux nœuds n'est pas différent de communiquer avec un seul.

Avec cela, chacun a sa place et son utilisation et ReST est idéal pour envoyer de gros éléments (blobs JSON), envoyer données pour le calcul et la récupération, et pour la demande d'un ensemble de données spécifique. MQTT est plus pour "voici mes données de capteur chaque seconde, profitez-en".

Fondamentalement, MQTT réduit la latence là où il y a une latence relativement élevée comme le Wi-Fi en gardant la connexion TCP active afin que les données puissent être publiées et reçues très rapidement. Il utilise le port 1883 et non 80. D'après ce que je comprends, les éditeurs et les abonnés se connectent une fois au courtier puis cinglent régulièrement le courtier pour maintenir la connexion active; La fréquence à laquelle le courtier reçoit un ping dépend de la période de maintien en vie préalablement convenue. Les paquets MQTT sont également nettement plus petits que les requêtes HTTP. Si la connexion est interrompue d'une manière ou d'une autre, le client essaie à plusieurs reprises de rétablir la connexion et, en cas de succès, les abonnés se réinscrivent.

Les abonnés définissent des rappels qui sont appelés après la mise à jour d'un sujet par un éditeur. . MQTT est le meilleur pour les travaux urgents où les requêtes HTTP prendraient trop de temps et où une notification rapide des sujets modifiés est souhaitée. Je ne suis pas sûr, mais cela consommera probablement plus d'énergie, car il y a cette question d'un lien TCP constant vers le courtier.

Puisque vous n'attendez que des mises à jour de données toutes les minutes, je pense qu'il est plus judicieux de se connecter et d'obtenir les données de flux du serveur toutes les 60 secondes. Vous pouvez utiliser l'horodatage Dernière mise à jour du flux (s'il n'existe pas, créez-en un) pour vérifier si le flux a déjà été mis à jour par l'Arduino. Une technique MQTT passerait juste la plupart du temps connecté à un courtier sans raison puisque vous savez déjà que les événements de mise à jour se produisent toutes les minutes; c'est une quantité considérable de temps et d'énergie passé à attendre des données prévisibles.

Cependant, vous pouvez attendre environ 55 secondes, vous abonner au sujet et lorsque vous obtenez les nouvelles données, vous vous déconnectez puis attendez à nouveau 55 secondes, même si je ne sais pas si ce sera vraiment un amélioration par rapport à REST. Si vous utilisez cette méthode, vous pouvez également définir la période de maintien en vie à environ 10 secondes, afin que l'Arduino ait suffisamment de temps pour mettre à jour le flux avant que votre application ne soit notifiée et qu'il n'y ait pas besoin de pings réguliers.

Si vous décidez d'utiliser MQTT, consultez cette bibliothèque Arduino.

(auto-promotion éhontée) J'ai fait une conférence sur des trucs iot cette année dans notre camp de code local. Les notes sont ici: https://github.com/adbacker/bcc2016/blob/master/2016bcc-iotonthecheap.pdf

Super simplifié par mon expérience limitée: (les experts corrigent à will :-))

Protocole MQTT:

MQTT est optimisé pour l'envoi de données simples. Les coordonnées GPS seraient un bon ajustement. Je suis sûr que MQTT pourrait être utilisé pour envoyer des données complexes (c'est-à-dire: de gros objets json) mais cela ne semble pas être ce pour quoi il a été conçu.

Vous n'êtes pas vous recherchez des notifications push vers l'appareil, et vous ne maintenez pas non plus de connexion au serveur REST, donc (d'un point de vue pratique), je suppose que l'amélioration de la durée de vie de votre batterie serait minuscule au mieux pour convertir la solution en mqtt.

Adafruit a un très bon tutoriel et des bibliothèques mqtt, ainsi qu'un service bêta qui fournit des services de courtage: https://learn.adafruit.com/adafruit-io/mqtt-api

Aussi, pour les configurations IOT super-duper-faciles (qui utilisent certes un protocole personnalisé), permettez-moi de recommander blynk. (www.blynk.cc) C'est gratuit et si facile que j'ai réécrit toute ma présentation autour de lui. De plus, il existe des applications (gratuites) blynk ios et Android qui permettent de créer des tableaux de bord personnalisés qui communiquent (via le courtier blynk également gratuit) avec l'appareil de votre choix. Si vous hébergez vous-même le serveur de courtier (également gratuit), il possède sa propre API REST qui permet l'accès aux données depuis / vers votre appareil.

Dans mes applications, la plus grande consommation d'énergie est d'allumer la radio pour transmettre des données. Je garde souvent la radio éteinte, je collecte des points de données, puis j'allume la radio pour envoyer plusieurs éléments de données ensemble en une seule demande à l'aide d'un appel HTTP RESTful. Dans mon cas, RESTful HTTP est bien plus efficace car je n'ai pas besoin d'une connexion permanente.