O protocolo MQTT é apropriado para transmitir leituras de sensores pelo BLE?


12

Suponha que existam vários sensores fracos (por exemplo, dispositivos de nível Arduino) que dependem do BLE como meio de comunicação e que esses dispositivos estejam conectados a um gateway mais poderoso (por exemplo, nível de dispositivos Raspberry pi).

Gostaria de saber se o MQTT é considerado um protocolo apropriado para a transmissão de suas leituras (mensagens curtas e frequentes de intermitência).

Vários blogs / documentos consideram o MQTT apropriado para "aplicativos de IoT" porque é leve (er) quando comparado ao HTTP e economiza energia. No entanto, no meu entender, exige que uma conexão seja mantida aberta, o que não é o caso do BLE ou de outros protocolos de comunicação apropriados para a IoT. O BLE não mantém a conexão aberta por períodos prolongados para reservar energia. Aparentemente, o MQTT é apropriado quando um protocolo da camada MAC, como WiFi, é usado. Isso quase quebra a lógica por trás do uso do MQTT em primeiro lugar (ou seja, se o dispositivo manipular computacionalmente um protocolo como WiFi, talvez não seja necessário um protocolo como o MQTT). Você vê uma falha nessa lógica?

Existe algum protocolo de camada de aplicação alternativa para esse fim? Qual é a estrutura mais frequentemente vista desse tipo de mensagem (por exemplo, dados binários brutos, JSON, XML) quando eles se comunicam com um gateway e quando se comunicam diretamente com um servidor?


O mecanismo BLE nativo é inadequado por qualquer motivo específico?
21817 Sean Houlihane

A pergunta de Sean pode ser dividida em duas partes: A) os mecanismos nativos do protocolo BLE são viáveis ​​para o link imediato do dispositivo e B) para onde os dados precisam ir? Se a resposta para a parte B estiver além do alcance do BLE, será necessária uma ponte (pelo menos entre os formatos de rádio, mas provavelmente também os protocolos).
22817 Chris Stratton

O gateway consome as leituras brutas ou simplesmente as retransmite e, nesse contexto, pode fazer sentido encapsular o MQTT de ponta a ponta em vez de fazer a ponte do BLE nativo para o MQTT no gateway?
21717 Sean Houlihane

Respostas:


14

O MQTT precisa executar o TCP / IP (não me lembro se ele está realmente na especificação ou se foram feitas apenas suposições suficientes para fazê-lo), mas o protocolo irmão MQTT-SN pode ser executado em praticamente qualquer protocolo que possa transmitir dados , Já vi implementações em UDP e serial.

Dito isto, não tenho certeza do que você ganha ao atropelar o BLE, as Características incorporadas do BLE oferecem muito do mesmo benefício (mesmo que apenas 1 a 1) com coisas como notificação.

Acho que uma das coisas importantes a lembrar é o que o "I" significa na IoT, pois implica acesso à Internet em algum momento (mesmo que seja um dispositivo ou telefone de gateway). Nesse ponto, o MQTT pode ser muito útil, mas não significa necessariamente todo o caminho até a borda (sangrando).


Em primeiro lugar, obrigado por me informar sobre a existência do MQTT-SN. A grande maioria da literatura é um pouco enganadora, porque implica que o MQTT capacita os dispositivos de borda principalmente devido a seus atributos de economia de energia. Nesse caso, o consumo reduzido de energia não é um argumento tão real, porque em dispositivos com esse perfil simplesmente não importa. Os dispositivos devem implementar uma pilha IP completa e, como o MQTT mantém uma conexão aberta, os protocolos da camada MAC com baixo consumo de energia não são uma opção.
21417 dr.doom 19/07

1
O MQTT economiza energia em comparação com algo como HTTP, porque uma conexão TCP aberta na verdade não consome tanta energia para manter aberta quando você já estiver executando uma pilha TCP, e os pacotes keep alive são pequenos. Além disso, a sobrecarga do protocolo é muito menor que o HTTP porque um cabeçalho HTTP é enorme comparado a um cabeçalho de pacote MQTT. Uma boa parte da literatura cálculo é baseado no telefone de um aparelho celular, por exemplo
hardillb

Também a borda se desloca, ele é utilizado para estar em que o TCP / IP parado, coisas como ble e ZigBee (especialmente com lpwan) e transformadores de potência mais baixos, mesmo se moveu para dispositivos ainda mais fino
hardillb

É explicitamente não apenas TCP / IP; o único requisito é que o protocolo forneça "conexões ordenadas, sem perdas e bidirecionais". É como o segundo parágrafo do resumo do documento. O SN existe porque esse requisito é oneroso para pequenos sistemas, principalmente os baseados em rádio. Talvez seja isso que você quer dizer com "suposições suficientes para fazer isso", mas definitivamente não depende do TCP / IP.
Dave Newton

9

Indiscutivelmente, seria melhor fazer um mapeamento simples dos dados dos paradigmas do BLE para o MQTT, em vez de tentar enviar literalmente o MQTT pelo BLE.

O BLE geralmente troca dados na forma de características . Eles possuem vários mecanismos exclusivos de BLE para descobrir alterações de valor que você pode achar úteis. Mas eles têm um comprimento máximo de dados de 20 bytes .

É possível transmitir dados seriais pelo BLE, movendo 20 bytes de cada vez. Às vezes, isso é feito para implementar uma porta serial virtual e você pode encapsular o MQTT completo por meio disso.

Mas você provavelmente faria melhor em usar uma coleção de características do BLE para transportar os dados de diferentes tópicos e ter uma ponte que mapeie a identidade da característica para um tópico do MQTT e mapeie o valor para a carga útil do MQTT.

O BLE tem seu próprio senso de sessões conectadas contínuas versus sessões não conectadas. Provavelmente, você deve descobrir qual o melhor uso do BLE para seu aplicativo e, em seguida, mapeá-lo para o sentido do MQTT de manter uma conexão.

Você deve conseguir fazer isso em uma ou ambas as direções: BLE-> MQTT e MQTT-> BLE


5
Se você quer uma MQTT ponte 2 BLE você pode olhar para o meu github.com/hardillb/mqtt2ble
hardillb

Obrigado por esse link, estou vendo agora.
21417 dr.doom 19/07
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.