Le protocole MQTT est-il approprié pour transmettre des lectures de capteur via BLE?

12

Supposons qu'il existe de nombreux capteurs faibles (par exemple, les appareils de niveau Arduino) qui s'appuient sur le BLE comme moyen de communication et que ces appareils sont connectés à une passerelle plus puissante (par exemple, le niveau d'appareils Raspberry pi).

Je voudrais savoir si MQTT est considéré comme un protocole approprié pour transmettre leurs lectures (messages en rafale courts et fréquents).

Un certain nombre de blogs / documents considèrent que MQTT est approprié pour les "applications IoT" car il est plus léger par rapport à HTTP et économise l'énergie. Cependant, à ma connaissance, cela nécessite qu'une connexion soit maintenue ouverte, ce qui n'est pas le cas avec le BLE ou d'autres protocoles de communication appropriés pour l'IoT. BLE ne maintient pas la connexion ouverte pendant des périodes prolongées pour réserver de l'énergie. Apparemment, MQTT est approprié lorsqu'un protocole de couche MAC tel que WiFi est utilisé. Cela rompt presque la logique derrière l'utilisation de MQTT en premier lieu (c.-à-d., Si le périphérique gère de manière calculable un protocole tel que WiFi, il pourrait ne pas avoir besoin d'un protocole tel que MQTT). Voyez-vous une faille dans cette logique?

Existe-t-il un autre protocole de couche application à cet effet? Quelle est la structure la plus fréquemment vue de ces types de messages (par exemple, données binaires brutes, JSON, XML) lorsqu'ils communiquent avec une passerelle et lorsqu'ils communiquent directement avec un serveur?

dr.doom
la source
Le mécanisme BLE natif est-il inapproprié pour une raison particulière?
Sean Houlihane
La question de Sean pourrait être mieux divisée en deux parties - A) les mécanismes du protocole BLE natif sont-ils réalisables pour la liaison immédiate depuis l'appareil, et B) où les données doivent-elles finalement aller? Si la réponse à la partie B est au-delà de la plage de BLE, alors un pont (au moins entre les formats radio mais probablement aussi les protocoles) est nécessaire.
Chris Stratton
La passerelle consomme-t-elle les lectures brutes, ou les transmet-elle simplement, et dans ce contexte peut-il être logique de tunneler MQTT de bout en bout plutôt que de relier BLE natif à MQTT au niveau de la passerelle?
Sean Houlihane

Réponses:

14

MQTT doit fonctionner sur TCP / IP (je ne me souviens pas si c'est réellement dans la spécification ou si juste assez d'hypothèses sont faites pour qu'il en soit ainsi) mais son protocole frère MQTT-SN peut être exécuté sur presque tous les protocoles qui peuvent transmettre des données , J'ai vu des implémentations en UDP et en série.

Cela dit, je ne suis pas sûr de ce que vous gagnez en exécutant BLE, les caractéristiques intégrées de BLE offrent pratiquement les mêmes avantages (ne serait-ce que sur une base de 1 à 1) avec des choses comme la notification.

Je pense que l'une des choses importantes à retenir est ce que le «je» signifie dans l'IoT, cela implique l'accès à Internet à un moment donné (même s'il s'agit d'un périphérique de passerelle ou d'un téléphone). À ce stade, MQTT peut être très utile, mais cela ne signifie pas nécessairement jusqu'au bord (saignant).

hardillb
la source
Tout d'abord merci de m'avoir informé de l'existence de MQTT-SN. La grande majorité de la littérature est quelque peu trompeuse car elle implique que MQTT renforce les périphériques périphériques principalement en raison de ses attributs d'économie d'énergie. Dans ce cas, la réduction de la consommation d'énergie n'est pas vraiment un véritable argument, car dans les appareils avec ce profil, cela n'aura tout simplement pas d'importance. Les appareils doivent implémenter une pile IP complète et puisque MQTT maintient une connexion ouverte, les protocoles de couche MAC écoénergétiques ne sont pas une option.
dr.doom
1
MQTT économise de l'énergie par rapport à quelque chose comme HTTP car une connexion TCP ouverte ne consomme pas vraiment autant d'énergie pour rester ouverte une fois que vous exécutez déjà une pile TCP, et les paquets persistants sont minuscules. De plus, la surcharge du protocole est beaucoup plus faible que HTTP car un en-tête HTTP est énorme par rapport à un en-tête de paquet MQTT. Une grande partie de la littérature sur le calcul est basée sur un appareil cellulaire, par exemple un téléphone
hardillb
De plus, le bord a bougé, c'était là que TCP / IP s'arrêtait, des choses comme ble et ZigBee (en particulier avec lpwan) et des processeurs encore plus faibles sont passés à des appareils encore plus fins
hardillb
Ce n'est explicitement pas seulement TCP / IP; la seule exigence est que le protocole doit fournir des "connexions bidirectionnelles ordonnées et sans perte". C'est comme le deuxième paragraphe du résumé du doc. SN existe parce que cette exigence est onéreuse pour les petits systèmes, en particulier les systèmes radio. C'est peut-être ce que vous entendez par «suffisamment d'hypothèses sont faites pour qu'il en soit ainsi», mais il ne dépend certainement pas de TCP / IP.
Dave Newton
9

Il serait sans doute préférable de faire un simple mappage des données des paradigmes BLE vers MQTT, plutôt que d'essayer d'envoyer MQTT sur BLE.

Le BLE échange généralement des données sous forme de caractéristiques . Ceux-ci ont divers mécanismes uniques BLE pour découvrir les changements de valeur qui peuvent vous être utiles. Mais ils ont une longueur de données maximale de 20 octets .

Il est possible de diffuser des données série sur BLE, en déplaçant 20 octets à la fois. Cela est parfois fait pour implémenter un port série virtuel, et vous pouvez tunneler le MQTT complet à travers cela.

Mais vous feriez probablement mieux d'utiliser une collection de caractéristiques BLE pour transporter les données de différents sujets, et d'avoir un pont qui mappe l' identité des caractéristiques à un sujet MQTT et mappe la valeur à la charge utile MQTT.

BLE a son propre sens des sessions connectées en cours par rapport aux sessions non connectées. Vous devriez probablement déterminer quelle utilisation de BLE est la meilleure pour votre application, puis la mapper avec le sens MQTT de maintenir une connexion.

Vous devriez pouvoir le faire dans l'une ou dans les deux directions: BLE-> MQTT et MQTT-> BLE

Chris Stratton
la source
5
Si vous voulez un pont MQTT 2 BLE, vous pouvez regarder le mien github.com/hardillb/mqtt2ble
hardillb
Merci pour ce lien, je le regarde en ce moment.
dr.doom