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

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?

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).

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