Oi
Como escrevi recentemente (
Primeiro pequeno artigo sobre MQTT / UDP ), o MQTT / UDP é um protocolo baseado no MQTT, mas:
- Acompanha a transmissão UDP (nenhum corretor é necessário, quase nenhuma configuração é necessária)
- É indecentemente fácil de implementar (10 linhas na pilha C + UDP / IP - e você envia dados do sensor)
- Todo mundo ouve todo mundo
De certa forma, isso é CAN, mas acima da Ethernet.
Porque
Meu apartamento está morando há vários anos sob o controle de um sistema como "a casa não é realmente oligofrênica". Seria redundante chamá-lo de inteligência, mas a luz e o clima são automatizados. Para imaginar a escala do desastre - o sistema ocupa um rack cheio de cerca de 19 polegadas de largura e dois metros de altura. Duas paredes do rack estão ocupadas quase no chão.
Quando projetei tudo isso, o problema da tolerância a falhas veio primeiro. Vários anos de operação mostraram: é verdade. Nega tudo. Mais cedo ou mais tarde. Mas os relés eletromecânicos ainda não falharam, e é neles o último escalão de proteção contra falhas.
O próximo problema após a tolerância a falhas é o zoológico. Devido ao curso natural da vida, minha curiosidade e necessidades urgentes, o Unix comum em um PC comum, Aries PLC, Raspberr + Orange PI, módulos Atmega, módulos baseados em NodeMCU (ESP8266) vivem no sistema e tudo isso se modela via modbus 485, modbus TCP, http e, ao lado, fica pendurado um corretor MQTT inquieto, como um legado de uma tentativa malsucedida de mudar para ele com um campo inteiro.
Por que a tentativa de mudar para o MQTT não teve êxito. Em primeiro lugar, para parte do ferro é pesado ou complicado. No fragmento de Pascal que está escondido no CLP CodeSys, apenas um masoquista pode escrever MQTT. Mas então você precisa depurar. Da mesma forma em atmega: você pode empinar, mas de perto. Mas este não é o problema todo.
O MQTT como ele é (e é aceitável em qualquer lugar 3.1.1) insiste em enviar um pacote PUBLISH (ou seja, nossa mensagem para o broker) a todos os destinatários, incluindo o remetente. O efeito dessa insanidade é encantador - o mesmo OpenHAB não pode enviar e receber dados no MQTT com o mesmo nome. Isso significa que é impossível organizar um barramento com base no MQTT (vários módulos que atualizam o valor do mesmo objeto e o utilizam). E é exatamente assim que a comunicação do PLC deve ser organizada, na qual reside o principal controle de luz, o OpenHAB, que controla a luz da interface da web e do aplicativo móvel, e switches inteligentes, que eu gostaria de poder adicionar aqui e aqui. Isto é, é claro, esse problema pode ser contornado, mas na verdade significa construir seu próprio protocolo SURFACE MQTT, e isso já parece ser demais.
Ao mesmo tempo, o que eu preciso? Envie uma atualização do valor do parâmetro e obtenha-a em todos os pontos de interesse. Pelo que, de fato, os avós fizeram UDP para o endereço de transmissão.
Após o último post sobre Habré, um dos leitores por um longo tempo me censurou com a falta de confiabilidade do protocolo UDP. Eu especulativamente respondi a ele que, para a IoT, o UDP é mais confiável que o TCP: com 50% de perda de pacotes em uma rede, o TCP não apenas se deita, mas geralmente, e o sensor de temperatura que envia medições pelo UDP simplesmente perde metade da contagem, o que afetará a operação do sistema de qualquer maneira. Geralmente.
Mas era especulativo. No entanto, os feriados de Ano Novo também foram dados a uma pessoa para terminar de beber champanhe e perguntar a si mesmo: colocaremos nossa LAN local em pás hoje? E não importa o quê.
Peguei o MQTT / UDP e escrevi um teste primitivo. Um lado envia pacotes consecutivos sem uma pausa entre os pacotes, tanto quanto possível. O segundo considera a velocidade e a perda de pacotes. O experimento foi simples: lançamos essa zombaria e, paralelamente, duas TVs HD mostram filmes da Internet, e o computador de mesa grava um arquivo enorme no NAS.
Classifique o resultado. Eu esperei por tudo, mas ... a perda máxima para o UDP atingiu meio por cento e as duas TVs pararam de aparecer. Então eu ainda era um pessimista. Em uma rede doméstica real, a confiabilidade da entrega UDP é quase absoluta. No entanto, provavelmente vou fazer uma versão com confirmações e reenviar pacotes. Existem poucas dificuldades, mas a questão é completamente removida.
A segunda pergunta é segurança, mas, se eles invadirem minha rede doméstica, a perda de dados dos sensores de temperatura é a última coisa que eu lamentarei. No entanto, novamente, a tarefa de assinar pacotes digitalmente no rastreador de problemas está presente e eu já entendo como expandir os pacotes MQTT para sua implementação.
Em geral, planejo que o primeiro par de dispositivos na rede doméstica mude para o MQTT / UDP outro dia.
E sugiro que você tente nos seus programas e dispositivos:
Repositório e
documentação em inglês .
O que está disponível:
Implementações bastante completas em Java, Python e C. Implementação básica em Lua. Até agora, apenas enviando para Arduino e CodeSys PLC (testado e funciona em Áries, mas deve fazer qualquer coisa).
Ferramenta GUI para analisar o que está acontecendo e intervir:
Programas para envio e recebimento de dados em Python, Lua e Java.
Conectores Python para integração com o MQTT regular e diretamente com o OpenHAB. Eles trabalham com proteção contra ciclos, proibindo a transmissão reversa da mensagem por 5 segundos após passar na direção direta. Além disso, há uma biblioteca para limitar o fluxo de dados repetidos. Ela verifica se já houve uma atualização deste tópico pelo tempo especificado e, se o fizer, ignora a nova atualização apenas se os dados foram alterados.
Eu pretendo mudar gradualmente para esse protocolo completamente, e aqui está um exemplo do que eu quero obter com os sensores:
Existem três sensores em uma sala (bem, ou na rua, isso não importa). Eles enviam amostras através do MQTT / UDP. Essas leituras são recebidas simultaneamente pelo principal sistema de casa inteligente (OpenHAB), um banco de dados histórico e um monitor de parede que exibe a temperatura para os residentes.
Todo o charme do MQTT / UDP é que, nesse esquema, a falha de qualquer bloco não cria problemas para todos os outros. E isso é com a simplicidade encantadora do protocolo.
Além disso, esquemas de controle redundantes com duplicação são facilmente implementados no mesmo esquema. O servidor de banco de dados pode ser duplicado sem nenhum problema. Será mais difícil duplicar os módulos que lidam com o gerenciamento. Por exemplo, ouvir a temperatura aciona os radiadores. Mas provavelmente esta é a próxima história. Hoje, pretendo focar na coleta de sinais de sensores e na troca entre os módulos de uma casa inteligente.