IoT – Configurando um MQTT broker

handshake

Representando uma nova era, a Internet das Coisas tem se apresentado nos mais diversos meios digitais, com novos hardwares menores e mais poderosos a cada dia. Claro que isso tudo necessita de gerenciamento e controle. Para tal, veremos como configurar um servidor MQTT – protocolo da Internet das Coisas.

O que é MQTT

O acrônimo MQTT significa Message Queuing Telemetry Transport; um protocolo criado pela IBM em 1999. Esse protocolo muito leve permite a comunicação bi-direcional (não como o protocolo HTTP, mas a seu modo específico) para coleta de dados e gerenciamento de dispositivos da Internet das Coisas. De modo similar, o gerenciamento de dispositivos complexos é feito com TR-069 e fico meditando a respeito; poderiam esses dispositivos (roteadores, switches, outros equipamentos de telecom) fazer parte do IoT? – Eu responderei de forma simples – uma empresa alemã já tem amplamente implementado e divulgado seu produto IoT junto aos produtos que utilizam TR-069. Ela faz parte da Broadband Forum e acredite, se eles estão apostando em IoT, podemos tomar como uma decisão acertiva introduzir-se nesse fantástico novo mundo.




Como o serviço funciona?

O protocolo utiliza uma arquitetura publish/subscribe, em contraste ao request/response do protocolo web HTTP. Desse modo é possível empurrar mensagens ao client e com uma boa implementação de lógica, fazer um belo gerenciamento dos dispositivos da sua nuvem. Uma outra característica que chama a atenção é a capacidade de buffering que, ainda que haja uma desconexão com o broker por qualquer razão, ao retormar a conexão os clients recebem as informações do tempo de indisponibilidade.

O centralizador, serviço ou server, é chamado MQTT broker – exatamente isso, um intermediário. Ele que recebe e envia mensagens para todos os clients que estabelecerem conexão e todos os dispositivos devidamente permitidos a receber interação.

mqtt-broker

É bastante simples como você pode reparar. O dispositivo publica a informação no MQTT broker. Os clientes se subscrevem no tópico que desejam receber informação e essa consulta pode ser feita através de qualquer tipo de dispositivo que comporte o protocolo de comunicação.

Conexão através de NAT

E essa é uma vantagem da utilização do MQTT, uma vez que o client inicia a conexão, portanto não há problema algum em estar por trás de uma rede com NAT.

Inicio da conexão: CONNECT

Um pacote de conexão MQTT tem vários parâmetros opcionais. Você não precisa se preocupar com esses detalhes para efetuar a configuração, ainda mais que sequer é obrigatório usuário e senha (se assim for permitido pelo broker). Vamos focar nos parâmetros utilizados no post sobre a configuração do client.

ClientID

Trata-se do identificador. Esse identificador não é o que o tema do tópico, isto é, você pode chamá-lo de “ESP_001” e se subscrever no tópico “casa/sala/temperatura”. Até um clientID vazio é permitido, mas sugiro a utilização do MAC como identificador.

Username/Password

O protocolo em sí não tem criptografia e trafega em texto plano tal qual uma mensagem SIP, por exemplo. Esse humilde exemplo de configuração de broker contempla a configuração do TLS para disponibilizar um canal seguro. De qualquer modo, o caminho mais curto é mesmo sua utilização sem outras implementações e pode ser aceitável desde que utilizado em ambientes não públicos, acesso interno na sua casa ou um laboratório de testes.

O Broker responde com CONNACK

Ao receber a mensagem de CONNECT a resposta obrigatória do Broker é a mensagem de CONNACK, contendo apenas duas entradas de dados; a Session Present Flag e o código de retorno. Esta primeira indica que o Broker já tem uma sessão persistente do cliente com interação prévia. Saber o formato dos pacotes lhe permitirá depurar qualquer problema na comunicação através da camada de rede, utilizando um sniffing sobre um conexão não criptografada. Os códigos de retorno de CONNACK são:




Pacote PUBLISH
O formato desse pacote contempla os seguintes campos:

Campo Exemplo
topicName “topico/x”
payload “temperature:28.3”
qos 1
retain 0

topicName

Essa parte me lembrou o roteamento da comunicação com PBX Asterisk (só um comentário, não considere). Ele é a rota da informação com o broker, o caminho ou estrutura a qual está relacionado. Cada client que quiser receber mensagens se subscreve em um determinado tópico e o broker entrega todas as mensagens relacionadas ao tópico solicitado pelo client, desde que ele tenha permissões. Você pode criar um tópico público, onde qualquer dispositivo não autenticado pode estabelecer uma comunicação. E você pode ter os tópicos privados, diretamente relacionados a um usuário, com senha e criptografia no canal de comunicação. Esse post trata de exemplificar todos esses recursos, veremos mais sobre tópicos adiante.

qos

Como qualquer QoS, Quality of Service, com 3 níveis (0, 1 ou 2) afim de garantir a entrega da mensagem ao ponto extremo. Vale lembrar que os tempos de entrega associados ao QoS e outros validadores podem agregar um payload alto. De imediato não posso avaliar pois não mensurei pacotes e processamento, mas certamente em um hardware bem modesto (modesto digo, uma board ARM) pode influenciar, dependendo do número de clients conectados à estrutura.

retainFlag

Determina se a a mensagem deve ser armazenada pelo Broker. Novos clients subescritos receberão instantaneamente a última mensagem retida do tópico ao qual se subescreveu.

Campo Exemplo
topic “topico/x”
qos 1

Como anteriormente citado, mas dessa vez para o efeito de consulta. Os parâmetros citados aqui não são baseados baseados nem no protocolo nem no Broker, estou focando na comunicação com o ESP8266, cujo post relacionado à comunicação utilizando MQTT pode ser visto aqui.

Clientes não fazem conexão entre sí. Tenha firme em mente que o Broker tem um conceito diferente de um server e é o que mais lembra um serviço em nuvem. Ele é apenas o intermediário entre o dispositivo e o aplicativo de consulta, para que não haja conexão direta entre as pontas e também para que não haja conexão entrante na rede dos dispositivos.

Apesar de deixar explícita sua utilização em nuvem (uma vez que trata-se de gerenciamento remoto), você pode ter um broker configurado em uma rede local dentro de uma empresa, ou até mesmo dentro de sua casa ou comércio. Para isso, sem a necessidade de sair da arquitetura IoT, pois um Raspberry Pi já seria muito mais que o suficiente para ser utilizado como broker.

Isolamento

Um ponto muito interessante é que os clients não precisam tomar ciência da existência de outros dispositivos, de forma que isso implementa um nivel extra de segurança através dessa nuvem, eles somente se comunicam através do tópico relacionado. Essa arquitetura é altamente escalável e independente dos produtores de dados e consumidores de dados.

Formato do tópico

Os tópicos são multi-nivel. Suponhamos que esteja medindo a temperatura da sala. Você pode ter o nivel mestre casa, seguido por sala e então temperatura. O client pode se subescrever para o tópico exato ao qual se deseja registrar dados ou usar um coringa para outro nível. Subescrever-se para casa/+/temperatura enviará a temperatura para todos os tópicos do segundo nível como por exemplo, casa/cozinha/temperatura. Por fim, um coringa multi-nível é a cerquilha (#). Isso permite subescrever-se para todos os níveis hierárquicos; casa/# servirá para todos os níveis contidos após casa.

Por fim, a configuração inclui autenticação e criptografia dos dados e pode ser compilado tanto para seu notebook/desktop como para qualquer board ARM rodando Linux. Iniciemos o processo!

Pacotes iniciais

Primeiramente será necessário instalar algumas ferramentas. Pode variar de caso a caso, dependendo do que você tem (ou não tem) instalado.

Compilando e instalando

Então os fontes devem ser baixados e a partir daí começa nossa diversão:




Fácil, hum? Mas calma, tem mais.

mosquitto.conf

Eu havia editado o arquivo original e descomentado linha a linha do que eu queria. Na versão do mosquitto baixada por apt-get você não terá alguns dos novos recursos da versão disponível na publicação desse post, por isso dispense a preguiça e ponha a mão-na-massa. Mas no que se refere ao arquivo, fui preguiçoso e invés de remover apenas as linhas comentadas, copiei um arquivo pronto sem comentários, fazendo apenas ajustes de níveis de diretórios.

Nos comandos a seguir uso vi como editor de texto, mas você pode usar o que quiser, desde que tenha permissões para escrever no destino (Kate no KDE, nano na linha de comando, mcedit, gedit, etc).

E o conteúdo deixei assim:

Esses são apenas alguns dos muitos parâmetros disponíveis, você pode contemplá-los (e incluí-los se desejar) chamando a página de manual:

Gerar certificados
Agora é hora de gerar certificados. Continua sendo tão simples quanto os procedimentos anteriores. PORÉM, não consegui utilizá-lo ainda. COmo no primeiro momento é fundamental que não se utilize a criptografia no canal de dados para que o sniffing seja possível e assim possa ser depurado qualquer problema na camada de rede, não fiz questão de configurar o certificado agora, mas vou fazer, prometo. Só estou ancioso em publicar esse post!

Coloque a senha que quiser. Um exemplo do processo:

…e mais

Crie o usuário mosquitto (que será o proprietário do processo) apontando /bin/false como shell padrão.

Siga todos os ritos e em seguida crie o usuário client:

Solicitará senha. Pra tudo eu utilizei a mesma.

Se desejar deletar o usuário, use

A senha criada é semelhante ao conteúdo do shadow (se você não sabe o que é, não se importe. Foi apenas um comentário).

Minha primeira ACL

Vamos começar água com açucar; estou ancioso para ver o serviço em execução. Crie um arquivo em /etc/mosquitto/jp.acl para as ACLs e digite o seguinte:

myMQTT
MQTT Client – MyMQTT

Se você vai iniciar uma configuração do zero, acredite, fazer os dois pontos de uma vez pode representar o caos. Inicie pelo Broker sem SSL associado ao uso de um aplicativo para testes. Eu recomendo o MyMQTT que funcionou de primeira sem nenhum problema. Baixe-o no google Play, podendo ser acessado através desse link (instalando pelo notebook/desktop o aplicativo será enviado para seu smartphone).

Mensagens no stdout

Devido ao nível de verbosidade, se tiver algum erro em sua configuração será possível vê-lo em stdout. Nesse momento já podemos iniciar o serviço e em seguida ver a comunicação com o dispositivo (nesse teste, o NodeMCU):

O broker cria uma base de dados descarregada em determinada periodicidade para o disco (veja lá em cima, na seção mosquitto.conf). Não se preocupe com o conteúdo, porque o gerenciamento é feito pelo broker, mas se desejar fazer backup, creio que essa seja a espinha dorsal. Se quiser fazer a persistência de outro modo como Redis ou uma base de dados MySQL etc, você pode configurar esse plugin de autenticação para Mosquitto.

Eu não experimentei, mas tem um tutorial interessante utilizando o PostGres nesse link.

Nos exemplos contidos dentro do diretório de fontes você encontra um mysql_log e um temperature_conversion. Se desejar compilar, não se esqueça de instalar o pacote libmysqld-dev; edite o arquivo mysql_log.c e configure adequadamente os parâmetros para uma base de dados, mudando os defines. Talvez eu faça outro post mostrando a configuração de alguns tipos de persistência, caso eu perceba que esse post foi bem recebido pela comunidade.

Siga-nos no Do bit Ao Byte no Facebook.

Prefere twitter? @DobitAoByte.

Inscreva-se no nosso canal Do bit Ao Byte Brasil no YouTube.

Próximo post a caminho!

Comments

comments

Djames Suhanko

Djames Suhanko é Perito Forense Digital. Já atuou com deployer em sistemas de missão critica em diversos países pelo mundão. Programador Shell, Python, C, C++ e Qt, tendo contato com embarcados ( ora profissionalmente, ora por lazer ) desde 2009.

2 comentários em “IoT – Configurando um MQTT broker

Deixe uma resposta