Dois-je utiliser MQTT ou HTTP?


9

Je travaille sur un appareil qui détecte et collecte des informations sur l'environnement telles que la température, l'humidité, etc.

L'appareil n'est connecté à aucune source d'alimentation, mais il dispose d'une batterie et d'un panneau solaire pour le charger.

Il est presque en état de sommeil profond la plupart du temps, et il ne se réveille que lorsqu'il a besoin de détecter et de transférer des données. Cette opération dure environ 1 à 2 minutes, puis elle se rendort à nouveau.

Je ne suis pas un expert dans ce domaine, mais je pense que MQTT devrait être une bonne option si l'appareil doit être accessible pour recevoir des messages d'un sujet tout le temps, mais dans mon scénario, il ne lit que les capteurs et envoie des données à un serveur périodiquement.

Actuellement, j'envoie les données via HTTP, mais je me demande s'il est logique d'implémenter MQTT? Dois-je obtenir un avantage sur HTTP pour ce scénario?


1
C'est similaire, mais mon point est de comprendre si dois-je implémenter MQTT dans mon scénario: quand mon appareil sera en sommeil profond 99% du temps, et juste en train de se réveiller pour envoyer des lectures.
zephrax

1
Je ne proposerais ni l'un ni l'autre. Écrivez d'abord vos besoins et implémentez le protocole le plus simpliste. Il ne serait pas logique d'utiliser un moteur Ferrari dans une tondeuse à gazon pour couper l'herbe. Ne vous laissez pas emporter par le brouhaha des choses - Faites simplement vos recherches de base et mettez en œuvre ce qui fonctionne le mieux.
Xofo

Ce serait bien de capturer l'exigence dans le titre de la question.Généralement, vous posez des questions sur les petites valeurs de capteur peu fréquentes, je pense.
Sean Houlihane

@Xofo Je serais intéressé de voir une réponse à ce sujet et pourquoi vous pourriez suggérer d'utiliser un protocole personnalisé. Vaut-il l'effort supplémentaire de «rouler le vôtre», plus les problèmes de sécurité, etc.?
Aurora0001

Pas un protocole personnalisé ... J'ai dit d'abord définir les exigences. Certains des protocoles prescrits sont souvent trop lourds.
Xofo

Réponses:


8

Si vous stockez des données, respectez simplement HTTP. HTTP n'est qu'un signal à sens unique.

Si votre serveur ou toute autre "chose" doit réagir à un signal spécifique (basse température, ...) alors utilisez MQTT. De cette façon, de nombreux appareils peuvent souscrire à votre signal de température et réagir immédiatement sans utiliser votre serveur.


1
Il existe également une division entre une grande (http) et une petite (mqtt) quantité de données à la fois et mqtt est également plus fiable en cas de mauvaises conditions de signal.
mico

1
Le serveur ne reçoit que des données des capteurs. Le point de mon message, c'est que je ne suis pas sûr que cela ait du sens d'utiliser MQTT, car l'appareil sera 99% du temps en état de sommeil profond (tous les bus, modem, capteurs éteints) et seulement se réveille pour lire les capteurs et envoyer des données.
zephrax

Si vous stockez vos données quelque part, cela signifie que vous disposez d'une base de données et d'un moyen backend pour les interroger (serveur apache, ligne de commande SQL, ...). Si vous mettez un MQTT en plus de cela, vous aurez une autre instance et un autre port à gérer.
Goufalite

1
Je suis d'accord avec cette réponse. Si vous n'avez pas besoin d'une communication bidirectionnelle et que l'appareil dort la plupart du temps, HTTP est un choix de protocole simple et approprié.
TheMagicCow

8

Vous mentionnez un panneau solaire et une batterie en tant qu'élément de l'appareil, donc vous voulez probablement minimiser la consommation d'énergie pendant les transmissions pour vous assurer que votre appareil ne manque pas complètement d'énergie.

Par conséquent, vous voudrez peut - être envisager CoAP , la Co nstrained A pplication P rotocole, qui est spécialement conçu pour les appareils limités dans l'Internet des objets.

Dans le document Comparaison de la rentabilité de CoAP et HTTP dans les applications Web of Things , vous pouvez trouver des preuves assez convaincantes que CoAP pourrait vous faire économiser de l'énergie ici. Dans l'annexe A (page 38), vous pouvez consulter la durée de vie prévue de la batterie des appareils dans le tableau A.4. Pendant un intervalle de temps de 120 secondes, comme prévu dans votre cas d'utilisation:

t bat (HTTP), jours - 2013

t bat (CoAP), jours - 11013

Ces calculs ont été effectués sur une paire de piles AA carbone-zinc, mais vous pouvez clairement voir que CoAP utilise beaucoup moins d'énergie, donc cela pourrait valoir la peine d'être considéré. Son «mode push», tel que décrit dans l'article, semble être exactement le genre de chose que vous prévoyez de faire.

Bien que vous n'ayez pas spécifiquement posé de questions sur CoAP, je pense que cela mérite d'être mentionné, car Goufalite a déjà couvert les différences essentielles entre MQTT et HTTP. Une bonne règle de base est la suivante: prévoyez-vous de communiquer un à un ou un à plusieurs ? Si c'est le premier, HTTP et CoAP semblent être mieux adaptés. Si c'est le dernier, MQTT est probablement plus pratique.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.