Mais fácil que o MQTT? MQTT / UDP

Eu queria escrever um artigo detalhado sobre esse tópico, mas, obviamente, minhas mãos não alcançam. Portanto, uma mensagem curta. Desenvolvi e implementei em várias línguas como código protótipo uma versão do protocolo MQTT sob o nome de trabalho MQTT / UDP. Para impaciente e para aqueles que já entendem tudo e, obviamente, o código no Github

Porque

Eu moro em um apartamento que é quase completamente controlado por meu próprio sistema de casa inteligente por vários anos. Luz, controle climático, sensores, automação fácil, só isso.

Durante esse período, descobri (sim, a propósito, eu já entendi isso) que a principal propriedade dos sistemas UD é a confiabilidade.

Todos os sistemas com um nó central são, por definição, não confiáveis. Daí o desejo de obter a interconexão dos componentes do sistema (e há muitos deles em uma verdadeira casa inteligente) sem usar nenhum hub central.

Ao mesmo tempo, procedemos do fato de que, em geral, o tráfego de sistemas UD é pequeno - os sensores raramente precisam ser atualizados com mais frequência do que uma vez por minuto, o restante dos dados é baseado em eventos (acenda a luz) e o tráfego é completamente insignificante. Mesmo a cada segunda atualização de todos os dados no sistema não é apenas um desastre, mas também um problema significativo.

A conclusão lógica é que o UDP Broadcast é uma ferramenta ideal.

(Sim, presumo que a rede interna do apartamento esteja fechada por um firewall.)

O que há nos profissionais:

Implementação incrivelmente simples. Um microcontrolador mínimo com pouca memória pode enviar um pacote UDP. Para o sensor, nem a recepção UDP é necessária.

Latência extremamente baixa. Não há encaminhamento no hub central, o tempo de entrega de pacotes UDP é praticamente o intervalo de tempo mínimo em um sistema moderno.

Não há ponto central de falha no hub / broker. Considere um esquema simples: dois sensores de temperatura, um controlador de piso aquecido, um controlador de bateria de aquecimento. Com o uso do MQTT / UDP, a falha de qualquer parte desse sistema não leva a uma falha do sistema como um todo.

Baixo tráfego de rede. Abaixo do nada. TCP e confirmações apenas adicionam tráfego, mas não adicionam confiabilidade. Um sensor com falha não funcionará ao receber um TCP ACK. E identificamos falhas pela ausência de atualizações.

A confiabilidade do protocolo UDP em si é insignificante - os sensores ainda atualizam os dados regularmente e o desaparecimento da contagem é completamente invisível, e o desaparecimento de um comando de, por exemplo, um switch é visualmente confirmado pela falha do sistema de destino. O que uma pessoa faz? Clica novamente. No entanto, essa é uma grande limitação na aplicabilidade do protocolo. Ideal para pesquisas recorrentes.

Nenhuma configuração do sistema é necessária. Ninguém precisa registrar o endereço de um corretor, hub, etc. No entanto, a configuração do sensor ainda é necessária - você precisa registrar o ID do sensor. Porém, ao transferir outras partes do sistema para outros servidores, a reconfiguração dos componentes de resposta não é necessária.

É particularmente interessante que esse modelo de troca de dados se encaixe bem em mídias de transmissão natural, como um canal de rádio ou RS / 485. Eu não experimentei isso, e o protocolo em tais ambientes precisa ser controlado. Aqui é lógico aplicar o CRC16 do modbus, a propósito.

As desvantagens também são óbvias: a confiabilidade da entrega é determinada apenas pelo hardware e pelo tráfego na rede. Bem, se o inimigo entrou na rede, o protocolo é derrotado imediatamente. É verdade que seremos francos, a invasão de outros protocolos típicos de residências inteligentes é uma questão de segundos, portanto, essa é uma desvantagem controversa do MQTT / UDP. Outro sinal de menos não óbvio é o máximo de um receptor por endereço IP.

O que foi feito e está no repositório de código-fonte:

• Implementações de cliente / servidor em vários idiomas. Existem C, Python e Java. Eu não dominei Lua (não consegui colocar tudo o que você precisa, como você mora nisso?) E a Codesys (não conseguiu compilar o pacote, quem inventou essa linguagem?).
• Portão mínimo para o MQTT tradicional em Python
• Uma ferramenta primitiva para exibir o tráfego MQTT / UDP em uma rede

O que eu faria se tivesse mais tempo:

• Eu escreveria um módulo para o openHUB.
• Tornaria uma variante de protocolo no JSON em outra porta e um conversor para o formato e porta principal. Ou um portão nas duas direções.
• Eu faria espaços em branco de implementação para as principais plataformas. Para o Arduino, fiz uma abordagem ao peso e realmente testei o código, mas não projetei tudo corretamente. Para o Raspberry, os casos de teste em Python são adequados.
• Assinaria e criptografaria digitalmente, mas não está claro como.
• Multicast.

Obrigado por isso, bem-vindo ao repositório

PS: Uma abordagem semelhante, mas com multicast, é descrita neste artigo.