Automação Predial com MQTT: Como o MQTT se Encaixa ao Lado de BACnet e KNX

Uma camada MQTT na automação predial permite pegar dados presos em controladores BACnet, linhas KNX e medidores Modbus e publicá-los em um único lugar onde dashboards, ferramentas de análise e de alerta possam usá-los. Este guia explica onde o MQTT se encaixa em um sistema de gerenciamento predial (BMS), o que ele deve e o que não deve substituir, e como projetar topics, gateways e segurança para que dezenas de edifícios, como as torres comerciais de um portfólio em São Paulo ou os prédios de um campus hospitalar, compartilhem um único broker.

Por Que os Edifícios Precisam de Mais um Protocolo

A maioria dos edifícios comerciais já roda um protocolo de campo maduro. O BACnet domina o HVAC e a central de utilidades, o KNX é comum em iluminação, persianas e controle de ambientes na Europa, e o Modbus RTU ou TCP aparece em medidores de energia, chillers e inversores de frequência. Esses protocolos são bons naquilo para que foram projetados: controle determinístico em uma rede local, com modelos de objetos que os engenheiros de HVAC entendem.

O ponto fraco deles é sair do edifício. O BACnet/IP depende de broadcasts UDP e pressupõe uma LAN plana e confiável. O roteamento KNX/IP usa multicast. Nenhum dos dois atravessa um firewall com elegância, nenhum foi projetado para milhares de subscribers remotos, e expô-los à internet é um erro de segurança bem conhecido. Equipes de facilities que querem uma visão de portfólio do consumo de energia, das reclamações de conforto ou das falhas de equipamentos acabam com um front-end por prédio, cada um com seu próprio login e formato de exportação.

O MQTT preenche exatamente essa lacuna. É um protocolo publish/subscribe leve em que cada dispositivo e aplicação faz uma conexão TCP ou TLS de saída para um broker MQTT central. Gateways em cada edifício traduzem os pontos locais em topics, e quem precisa dos dados assina, sem saber onde está o gateway nem quantos prédios existem.

Onde o MQTT Fica em um Sistema de Automação Predial

Pense em um edifício em três camadas:

1. Nível de campo – sensores, atuadores, caixas VAV, botões KNX, medidores. A comunicação é BACnet MS/TP, KNX TP, Modbus RTU, DALI ou barramentos proprietários.
2. Nível de automação – controladores e estações de supervisão que executam malhas de controle, agendas e intertravamentos. Aqui ainda é BACnet/IP, KNX/IP ou Modbus TCP.
3. Nível de integração – o lugar onde os dados são normalizados e compartilhados com o restante da organização. É aqui que o MQTT entra.

A regra importante é que as malhas de controle ficam locais. Uma malha PID de temperatura do ar de insuflamento precisa continuar rodando se a conexão com a internet cair, então ela vive no controlador, não na nuvem. O MQTT leva a telemetria para cima e, com cuidado, alterações de setpoint ou sobreposições de agenda para baixo. Na prática, a camada MQTT da automação predial é uma interface northbound, não um substituto da rede de campo.

Papéis dos protocolos comparados

Gateways: Transformando Pontos em Topics

Todo edifício precisa de pelo menos um gateway. Ele lê os pontos do protocolo de campo e os publica como mensagens MQTT. Você tem três opções realistas:

• MQTT embutido no controlador ou supervisório. Muitos controladores de BMS e sistemas operacionais prediais recentes conseguem publicar MQTT diretamente. Verifique se suportam TLS e autenticação por usuário e senha antes de depender deles.
• Um pequeno gateway Linux. Um dispositivo da classe Raspberry Pi ou um PC industrial rodando um script ou um fluxo Node-RED. Nossos tutoriais de BACnet para MQTT e KNX para MQTT mostram bridges open source completas.
• Um gateway de protocolo comercial. Útil quando você precisa de comportamento BACnet certificado ou tem centenas de pontos por dispositivo.

Seja qual for a escolha, o gateway deve fazer polling ou assinar localmente (assinaturas COV do BACnet, telegramas de grupo KNX), aplicar bandas mortas para não inundar o broker com ruído e publicar JSON com timestamp, valor, unidade e um indicador de qualidade.

{
  "ts": "2026-10-16T08:15:02Z",
  "value": 13.4,
  "unit": "degC",
  "quality": "good",
  "source": "bacnet:1201/analogInput:3"
}

Incluir a referência ao objeto original em source facilita muito a solução de problemas quando alguém pergunta por que um valor no dashboard difere do front-end do BMS.

Projetando Topics para Vários Edifícios

O design de topics é a decisão com a qual você vai conviver por mais tempo. Uma hierarquia baseada na localização física funciona bem para edifícios, porque é assim que as pessoas pensam:

<org>/<site>/<building>/<floor>/<zone>/<equipment>/<point>
acme/ist01/tower-a/f12/zone-east/ahu-2/supply-air-temp
acme/ist01/tower-a/f12/zone-east/ahu-2/filter-dp
acme/ank02/hq/f03/meeting-301/occupancy/present

Isso espelha o estilo ISA-95 usado em fábricas (empresa, site, área, linha, célula), o que importa porque o ConnectMQ reconhece estruturas de topics ISA-95 e Unified Namespace e pode mostrar os dispositivos agrupados por esses níveis na visão de dispositivos. Assim, os gestores de facilities podem navegar por um portfólio por site e andar em vez de procurar em listas planas de topics. A mesma hierarquia serve de esqueleto para um gêmeo digital do edifício, em que cada andar, zona e equipamento tem um caminho estável.

Algumas regras práticas:

• Use minúsculas, hifens no lugar de espaços e nenhum nome de pessoa nos topics.
• Mantenha o nome do ponto por último para que os wildcards continuem úteis: acme/+/+/+/+/+/supply-air-temp retorna todas as temperaturas de insuflamento do portfólio.
• Publique metadados que mudam pouco (unidades, setpoints, modelo do equipamento) como mensagens retidas para que novos subscribers conheçam imediatamente o estado atual.
• Separe comandos de telemetria, por exemplo .../ahu-2/cmd/setpoint versus .../ahu-2/supply-air-temp, e permita que apenas clientes autorizados publiquem nos topics de comando.

Se você já opera plantas industriais, o mesmo raciocínio aparece em nosso artigo sobre Sparkplug B e o Unified Namespace.

Escrevendo de Volta no Edifício com Segurança

Ler dados tem baixo risco. Escrever setpoints a partir da nuvem, não. Antes que qualquer mensagem MQTT possa alterar um valor em um dispositivo BACnet ou KNX, coloque proteções no gateway:

1. Mantenha uma lista explícita de pontos graváveis. Nunca exponha um topic genérico de "escrever em qualquer objeto".
2. Valide as faixas no gateway (por exemplo, um setpoint de zona entre 18 e 26 graus Celsius).
3. No BACnet, escreva em uma prioridade definida e libere-a quando a sobreposição terminar, para que as agendas locais voltem a assumir.
4. Devolva o valor aceito em um topic de estado e registre quem o solicitou.
5. Use QoS 1 para comandos e torne o handler idempotente, porque uma mensagem QoS 1 pode chegar duas vezes. Nosso guia de níveis de QoS do MQTT explica o porquê.

Centralizando Muitos Edifícios em Um Broker

Quando todos os gateways publicam em conexões de saída, centralizar um portfólio vira uma decisão de hospedagem. Você pode rodar um broker no seu próprio data center, mas aí passa a ser responsável por patches, certificados, monitoramento e planejamento de capacidade de um sistema que as equipes de facilities esperam ver funcionando 24 horas por dia.

Um broker MQTT gerenciado elimina esse trabalho. Com o ConnectMQ, o gateway de cada edifício se conecta ao mesmo broker via TLS na porta 8883 com suas próprias credenciais geradas, e o portal oferece um explorador de topics ao vivo para inspecionar o que cada prédio publica. Regras de alerta por limite podem sinalizar condições como uma temperatura de insuflamento que permanece fora da faixa, e o log de alertas mantém um histórico de quando elas dispararam. Dashboards, fluxos Node-RED, coletores Telegraf ou serviços Python que gravam no seu banco de dados se conectam como clientes MQTT comuns e assinam com wildcards.

Checklist de dimensionamento

1. Conte os gateways por prédio mais cada aplicação consumidora; cada um é uma conexão.
2. Estime as mensagens por segundo após as bandas mortas, não as taxas brutas de polling.
3. Verifique a maior mensagem de que você precisa (um snapshot completo de um equipamento pode ser maior que um único ponto).
4. Decida se você precisa de QoS 2 ou de shared subscriptions para consumidores com balanceamento de carga.
5. Planeje o isolamento: um portfólio com separação rígida entre inquilinos pode justificar um cluster dedicado.

Pilotos pequenos cabem no plano Serverless gratuito (até 25 conexões, QoS 0 e 1, mensagens de 256 KB). Portfólios maiores migram para o nível Serverless pago (até 1.000 conexões, QoS 2, shared subscriptions) ou para um cluster Dedicated.

Considerações de Segurança Específicas de Edifícios

As redes prediais costumam ser planas, antigas e compartilhadas com terceirizados. O MQTT ajuda porque os gateways só precisam de conexões de saída, então você nunca abre portas de entrada no firewall para BACnet ou KNX. Além disso:

• Use sempre TLS (porta 8883, ou 8084 para dashboards com WebSocket seguro).
• Dê a cada gateway suas próprias credenciais, para que um dispositivo comprometido possa ser revogado sem afetar os demais. O ConnectMQ vincula client IDs às credenciais emitidas e bloqueia IPs após repetidas falhas de login.
• Mantenha o gateway em uma VLAN separada da rede de campo, apenas com as portas de que ele precisa.
• Nunca publique dados pessoais, como IDs de crachá, em topics que muitas aplicações podem ler; no Brasil, esses dados estão sujeitos à LGPD.

O checklist mais amplo de boas práticas de segurança MQTT vale tanto para edifícios quanto para fábricas.

Um Plano de Implantação Realista

Comece com um edifício e um pequeno conjunto de pontos de alto valor: temperaturas de insuflamento e retorno, pressão diferencial dos filtros, medidor principal de energia e algumas temperaturas de zona. Publique-os no servidor MQTT público (gratuito), feito para testes e protótipos, apenas se os dados não forem sensíveis e você só quiser validar os payloads; migre para um broker privado assim que endereços reais ou dados de ocupação estiverem envolvidos. Em seguida adicione alertas, depois dashboards, depois um segundo prédio. No terceiro edifício você saberá se seu esquema de topics escala. Para mais casos de uso, veja nosso guia de automação IoT e, para aplicações específicas, leia monitoramento de HVAC com sensores IoT.

Conecte Seus Edifícios ao ConnectMQ

Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito. Você recebe usuário, senha e client ID para o seu primeiro gateway em minutos, e o explorador de topics mostra os dados do seu edifício no momento em que chegam. Quando o portfólio crescer, faça upgrade do plano sem mudar o design dos seus topics.

Perguntas frequentes

O MQTT substitui o BACnet em um sistema de automação predial?

Não. BACnet e KNX continuam sendo as redes de controle dentro do edifício. O MQTT é a camada de integração que leva pontos selecionados a dashboards, ferramentas de análise e outros prédios.

Posso controlar equipamentos de HVAC via MQTT?

Sim, por meio de um gateway que escreve no controlador, mas restrinja-o a uma lista de pontos permitidos, valide as faixas e mantenha as malhas de controle locais para que o edifício continue funcionando se a conexão cair.

Que QoS a telemetria predial deve usar?

QoS 0 serve para leituras frequentes em que o próximo valor chega logo. Use QoS 1 para alarmes e comandos, e torne os handlers de comando idempotentes.

Quantas conexões um edifício precisa?

Normalmente uma por gateway mais uma por aplicação consumidora. Um edifício piloto típico com um único gateway e um dashboard precisa de apenas algumas conexões.