¿El protocolo MQTT es apropiado para transmitir lecturas de sensores a través de BLE?

Suponga que hay numerosos sensores débiles (por ejemplo, dispositivos de nivel Arduino) que dependen de BLE como medio de comunicación y que estos dispositivos están conectados a una puerta de enlace más potente (por ejemplo, dispositivos de nivel Raspberry pi).

Me gustaría saber si MQTT se considera un protocolo apropiado para transmitir sus lecturas (mensajes cortos y frecuentes).

Varios blogs / documentos consideran que MQTT es apropiado para "aplicaciones IoT" porque es más ligero en comparación con HTTP y conserva energía. Sin embargo, a mi entender, requiere que se mantenga abierta una conexión, que no es el caso con BLE u otros protocolos de comunicación apropiados para IoT. BLE no mantiene la conexión abierta durante períodos prolongados de tiempo para reservar energía. Aparentemente, MQTT es apropiado cuando se usa un protocolo de capa MAC como WiFi. Esto casi rompe la lógica detrás del uso de MQTT en primer lugar (es decir, si el dispositivo maneja de manera computacional un protocolo como WiFi, entonces podría no necesitar un protocolo como MQTT). ¿Ves un defecto en esta lógica?

¿Existe algún protocolo alternativo de capa de aplicación para ese propósito? ¿Cuál es la estructura más frecuente de este tipo de mensajes (por ejemplo, datos binarios sin procesar, JSON, XML) cuando se comunican con una puerta de enlace y cuando se comunican directamente con un servidor?

mqtt power-consumption bluetooth-low-energy

— Dr. Doom
fuente

¿El mecanismo BLE nativo es inapropiado por alguna razón en particular?

— Sean Houlihane

La pregunta de Sean podría dividirse mejor en dos partes: A) ¿los mecanismos de protocolo BLE nativos son viables para el enlace inmediato desde el dispositivo y B) a dónde deben ir los datos? Si la respuesta a la parte B está más allá del rango de BLE, entonces se necesita un puente (al menos entre formatos de radio pero probablemente también protocolos).

— Chris Stratton

¿La puerta de enlace consume las lecturas sin formato, o simplemente las retransmite, y en ese contexto puede tener sentido hacer un túnel MQTT de extremo a extremo en lugar de unir BLE nativo a MQTT en la puerta de enlace?

— Sean Houlihane

Respuestas:

MQTT tiene que ejecutarse a través de TCP / IP (no recuerdo si realmente está en la especificación o si se hacen suficientes suposiciones para hacerlo), pero su protocolo hermano MQTT-SN se puede ejecutar en casi cualquier protocolo que pueda pasar datos , He visto implementaciones en UDP y en serie.

Habiendo dicho que no estoy seguro de lo que gana al ejecutar BLE, las características integradas de BLE ofrecen el mismo beneficio (aunque solo de 1 a 1) con cosas como notificación.

Creo que una de las cosas importantes para recordar es lo que significa "I" en IoT, implica acceso a Internet en algún momento (incluso si es un dispositivo de puerta de enlace o un teléfono). En ese punto, MQTT puede ser muy útil, pero no necesariamente significa todo el camino hasta el borde (sangrante).

— hardillb
fuente

En primer lugar, gracias por informarme sobre la existencia de MQTT-SN. La gran mayoría de la literatura es algo engañosa porque implica que MQTT potencia los dispositivos de borde principalmente debido a sus atributos de ahorro de energía. En ese caso, el consumo de energía reducido no es un argumento real porque, en dispositivos con ese perfil, simplemente no importará. Los dispositivos deben implementar una pila de IP completa y dado que MQTT mantiene una conexión abierta, los protocolos de capa MAC de bajo consumo no son una opción.

— dr.doom

MQTT ahorra energía en comparación con algo como HTTP porque una conexión TCP abierta en realidad no consume tanta energía para mantenerse abierta una vez que ya está ejecutando una pila TCP, y los paquetes de mantener vivo son pequeños. Además, la sobrecarga del protocolo es mucho menor que HTTP porque un encabezado HTTP es enorme en comparación con un encabezado de paquete MQTT. Gran parte de la literatura sobre computación se basa en un dispositivo celular, por ejemplo, un teléfono

— hardillb

También el borde se ha movido, lo que solía ser en TCP / IP se detuvo, cosas como ble y ZigBee (especialmente con lpwan) y los procesadores de potencia aún más bajos se han trasladado a los dispositivos aún más delgado

— hardillb

Es explícitamente no solo TCP / IP; el único requisito es que el protocolo debe proporcionar "conexiones ordenadas, sin pérdidas y bidireccionales". Es como el segundo párrafo del resumen del documento. SN existe porque ese requisito es oneroso para sistemas pequeños, particularmente los basados en radio. Tal vez eso es lo que quiere decir con "se hacen suficientes suposiciones para hacerlo", pero definitivamente no depende de TCP / IP.

— Dave Newton

Podría decirse que sería mejor hacer un mapeo simple de los datos de los paradigmas BLE a MQTT, en lugar de intentar enviar literalmente MQTT sobre BLE.

BLE generalmente intercambia datos en forma de características . Estos tienen varios mecanismos únicos de BLE para descubrir el cambio de valor que puede serle útil. Pero tienen una longitud máxima de datos de 20 bytes .

Es posible transmitir datos en serie a través de BLE, moviendo 20 bytes a la vez. Esto a veces se hace para implementar un puerto serie virtual, y podría hacer un túnel MQTT completo a través de esto.

Pero probablemente sea mejor usar una colección de características BLE para transportar los datos de diferentes temas, y tener un puente que asigne la identidad característica a un tema MQTT y asigne el valor a la carga útil de MQTT.

BLE tiene su propio sentido de sesiones conectadas continuas frente a sesiones no conectadas. Probablemente debería averiguar qué uso de BLE es mejor para su aplicación y luego asignarlo al sentido MQTT de mantener una conexión.

Debería poder hacer esto en una o ambas direcciones: BLE-> MQTT y MQTT-> BLE

— Chris Stratton
fuente

Si quieres un puente MQTT 2 BLE puedes mirar el mío github.com/hardillb/mqtt2ble

— hardillb

Gracias por ese enlace, lo estoy echando un vistazo ahora mismo.

— dr.doom