Como detectar anomalias em sensores de climatização usando Python e dados de BMS

Um sensor de temperatura informa que o ambiente está a 26 °C, enquanto o sistema de climatização trabalha com um setpoint de 23 °C. Isso significa que existe um defeito? Não necessariamente. Pode ser uma condição transitória de partida, uma zona com carga térmica elevada, um sensor mal posicionado, um valor desatualizado ou um comportamento que merece uma verificação técnica.

Essa distinção é importante para quem desenvolve software de monitoramento. Transformar qualquer diferença de temperatura em alarme cria ruído operacional. Por outro lado, ignorar desvios persistentes pode atrasar a descoberta de problemas reais.

Neste tutorial vamos construir, em Python, um detector simples de anomalias candidatas para dados de climatização. O objetivo não é fazer diagnóstico automático nem controlar o equipamento. É demonstrar como incorporar contexto operacional, persistência do desvio e critérios básicos de qualidade dos dados antes de emitir um alerta.

Escopo do exemplo: dados completamente simulados, sem conexão com instalações reais. Os números utilizados servem apenas para demonstrar a lógica de programação. Não são limites normativos ou parâmetros universais de aceitação para equipamentos HVAC.

1. Por que sensores de climatização precisam de contexto?

Em um prédio comercial, um sistema de automação predial, ou Building Management System (BMS), pode reunir informações de controladores, sensores, medidores e equipamentos de diferentes fabricantes. Dependendo da instalação e das interfaces disponíveis, é possível consultar temperaturas de ambiente, estados de funcionamento, pontos de ajuste, alarmes e históricos de operação.

Entretanto, o mesmo valor de temperatura pode representar situações diferentes. Um ambiente a 26 °C poderá estar em recuperação após desligamento noturno, com uma porta aberta ou exposto a um aumento temporário de ocupação. Comparar apenas 26 °C com o setpoint seria insuficiente para concluir que há uma falha.

Uma regra de software mais útil começa com perguntas concretas: o equipamento está ativo? Está em modo de resfriamento? Quanto tempo passou desde a partida? A leitura é recente? O desvio permanece durante várias amostras?

A análise também precisa reconhecer seus limites. Um dado do BMS pode ser correto e, ainda assim, não explicar a causa física. Em sistemas VRF, o conjunto de pontos disponíveis depende do fabricante, da interface de integração e do projeto de automação. Por isso, os nomes das variáveis usados aqui são uma abstração didática, não uma descrição de todas as interfaces VRF.

Figura 1 — Fluxo didático entre sensor, interface de integração, histórico de dados, análise Python e avaliação técnica.

2. Quais informações um algoritmo precisa receber?

Antes de escrever a primeira condição if, é necessário definir um contrato de dados. Para nosso exemplo, cada leitura contém cinco informações:

Em projetos reais, outros pontos podem ser indispensáveis: temperatura externa, ocupação, velocidade do ventilador, demanda de carga, estados de compressor, códigos de alarme e condições de comunicação. A lista deve nascer da arquitetura efetivamente instalada e dos objetivos do monitoramento, não de um modelo genérico copiado para qualquer obra.

O instante da amostra também importa. Um dado recebido às 14h00 pode ter sido registrado às 13h42. Se a aplicação não controla a idade da informação, corre o risco de interpretar uma medição antiga como condição atual. Nesta versão, vamos ao menos rejeitar registros fora de ordem e reiniciar a avaliação quando surgir um intervalo excessivo entre amostras.

3. Três regras simples antes de gerar um alerta

Usaremos três mecanismos que ajudam a reduzir falsos positivos sem exigir aprendizado de máquina.

Período de estabilização: após a partida, o algoritmo espera dez minutos antes de avaliar desvios. Esse tempo é apenas ilustrativo; cada aplicação real exige critérios próprios.

Persistência: um alerta só será aberto quando ocorrerem três amostras consecutivas com temperatura pelo menos 2 °C acima do setpoint. Uma amostra isolada, portanto, não basta.

Histerese: depois de acionado, o alerta permanece ativo até a diferença cair para 0,8 °C ou menos. Utilizar limites distintos para entrada e saída ajuda a evitar oscilações rápidas do estado do alarme.

O monitor também verifica dados ausentes e considera somente o modo resfriamento. Não deve ser confundido com um sistema de proteção, intertravamento ou comando de máquina. Sua saída é um indicador para análise humana.

4. Implementando o monitoramento em Python

O exemplo abaixo usa apenas a biblioteca padrão do Python. O tipo Leitura representa uma amostra; a classe MonitorClimatizacao guarda o estado da avaliação entre chamadas.

from dataclasses import dataclass from datetime import datetime, timedelta, timezone from math import isfinite @dataclass(frozen=True) class Leitura: instante: datetime equipamento_ativo: bool modo: str temperatura_c: float | None setpoint_c: float | None class MonitorClimatizacao: def __init__(self, desvio_alerta=2.0, desvio_retorno=0.8, amostras_consecutivas=3, estabilizacao_min=10): if not (0 <= desvio_retorno < desvio_alerta): raise ValueError("O limite de retorno deve ser menor") self.alerta_limite = desvio_alerta self.retorno_limite = desvio_retorno self.minimo = amostras_consecutivas self.estabilizacao = timedelta(minutes=estabilizacao_min) self.inicio = None self.ultimo = None self.contador = 0 self.em_alerta = False def analisar(self, leitura: Leitura) -> str: if leitura.instante.tzinfo is None: return "rejeitada: timestamp sem fuso" if self.ultimo is not None and leitura.instante <= self.ultimo: return "rejeitada: fora de ordem" if self.ultimo is not None and leitura.instante - self.ultimo > timedelta(minutes=10): self.inicio, self.contador, self.em_alerta = None, 0, False self.ultimo = leitura.instante valores = (leitura.temperatura_c, leitura.setpoint_c) if any(v is None or not isfinite(v) for v in valores): self.contador = 0 return "dado ausente ou inválido" ligado = leitura.equipamento_ativo and leitura.modo == "resfriamento" if not ligado: self.inicio, self.contador, self.em_alerta = None, 0, False return "equipamento fora do regime monitorado" if self.inicio is None: self.inicio = leitura.instante if leitura.instante - self.inicio < self.estabilizacao: return "estabilização após partida" diferenca = leitura.temperatura_c - leitura.setpoint_c if self.em_alerta: if diferenca <= self.retorno_limite: self.em_alerta, self.contador = False, 0 return "recuperado" return "alerta ainda ativo" self.contador = self.contador + 1 if diferenca >= self.alerta_limite else 0 if self.contador >= self.minimo: self.em_alerta = True return "anomalia candidata: verificar em campo" return "normal ou em observação" inicio = datetime(2026, 11, 2, 12, 0, tzinfo=timezone.utc) temperaturas = [27, 26, 24, 24, 24, 24, 26.1, 26.4, 26.2, 26.2, 25.6, 25.0, 24.2, 23.6, 23.5] monitor = MonitorClimatizacao() for i, temperatura in enumerate(temperaturas): leitura = Leitura(inicio + timedelta(minutes=5*i), True, "resfriamento", temperatura, 23.0) evento = monitor.analisar(leitura) if evento not in ("normal ou em observação", "alerta ainda ativo"): print(leitura.instante.strftime("%H:%M"), evento) 

Se o ambiente permanecer acima do limite após a estabilização, o programa produzirá, entre as demais mensagens, estes dois eventos:

12:40 anomalia candidata: verificar em campo 13:05 recuperado 

A primeira linha não afirma que houve defeito. Indica que a regra de desvio persistente foi satisfeita. A segunda informa que o valor observado retornou à faixa definida para encerrar o estado de alerta.

Perceba também que a sequência de temperaturas é escrita manualmente para facilitar o teste. Em um projeto real, as leituras poderiam chegar de uma base histórica, arquivo CSV ou serviço de integração autorizado. O formato e a segurança dessa conexão precisariam ser tratados separadamente.

Figura 2 — Temperatura simulada, setpoint e intervalo em que três leituras consecutivas produzem uma anomalia candidata.

5. Como interpretar o alerta sem inventar um diagnóstico

Considere o evento das 12h40. Sabemos somente que o equipamento foi informado como ativo, o modo era resfriamento, o período inicial de estabilização passou e três registros consecutivos apresentaram desvio acima do limite didático.

Isso não permite afirmar que houve falta de fluido refrigerante, defeito de compressor ou falha de instalação. A temperatura pode ter sido influenciada por carga térmica não prevista, configuração do controle, abertura de portas, erro de instrumentação ou outras condições que não aparecem nesse conjunto reduzido de dados.

Uma aplicação de engenharia precisa apresentar um contexto verificável: identificação da zona, horário, valor medido, referência, estado de operação, duração do desvio e critérios que acionaram a regra. Alertas sem essas informações são difíceis de interpretar e frequentemente geram retrabalho.

Para organizar a resposta, eu separaria cada ocorrência em três estados: detectada pelo algoritmo, em investigação e confirmada ou descartada após verificação. Essa separação preserva a diferença entre análise digital e evidência obtida em campo.

Figura 3 — Exemplo de triagem de eventos, distinguindo detecção automática, investigação e conclusão técnica.

6. O que a programação não substitui em climatização predial?

Programar um detector é apenas uma parte do trabalho. Sistemas de climatização precisam ter projeto, instalação, parâmetros de controle e procedimentos de verificação coerentes com os equipamentos existentes. Um algoritmo não confirma, por si só, se sensores foram corretamente instalados, se o fluxo de ar foi aferido ou se as condições de operação atendem ao escopo contratado.

Essa diferença fica clara quando pensamos na atuação de uma empresa de climatização em ambientes corporativos: a avaliação depende de conhecer os equipamentos, identificar as interfaces disponíveis, conferir documentação e interpretar medições dentro do contexto físico da instalação. A leitura digital é uma fonte de evidência, não a totalidade da verificação.

Também é essencial observar que procedimentos de partida, testes de comunicação, medições de campo e garantia do fabricante não são equivalentes entre si. O que precisa ser comprovado em cada etapa depende do escopo, do projeto, da tecnologia e das responsabilidades de cada profissional envolvido.

7. Onde o comissionamento entra nessa história?

Quando um sistema VRF é entregue ou submetido a uma avaliação de desempenho, a programação de alarmes deve se apoiar em informações confiáveis: equipamentos identificados, parâmetros conferidos, sequência de operação conhecida e critérios de aceitação documentados.

É nesse ponto que a telemetria pode apoiar, mas não substituir, a verificação presencial. Uma referência sobre comissionamento VRF em São Paulo apresenta o contexto de levantamento documental, testes de instalação, comunicação, registro de pendências e aceite técnico em sistemas VRF. O vínculo entre software e comissionamento está justamente na qualidade dos dados que serão monitorados depois.

Por exemplo, se uma variável do sistema estiver associada à unidade errada, nenhum algoritmo sofisticado resolverá a inconsistência de origem. Da mesma forma, se o modo de operação não estiver disponível ou estiver incorretamente mapeado, a lógica de alertas terá condições limitadas para distinguir funcionamento normal de anomalia.

Uma sequência útil é: identificar pontos → validar leituras → observar modos de operação → definir regras → registrar eventos → verificar ocorrências. A ordem evita começar pelo painel gráfico antes de resolver os fundamentos da instrumentação.

8. Como evoluir o código para um projeto real?

O exemplo é intencionalmente pequeno, mas pode crescer de maneira controlada. Antes de incluir modelos estatísticos ou inteligência artificial, eu daria prioridade a cinco melhorias:

1. Qualidade dos dados: armazenar origem da leitura, unidade, fuso horário, idade da amostra e estado de comunicação.
2. Configuração por equipamento: não aplicar os mesmos limites a todas as zonas, capacidades, modos ou fabricantes sem validação técnica.
3. Persistência temporal real: trabalhar com duração efetiva do desvio, e não apenas número de amostras, especialmente quando os intervalos são irregulares.
4. Registro rastreável: salvar a transição de estado, valores e regras vigentes para auditoria posterior.
5. Revisão operacional: comparar alertas com ocorrências verificadas para identificar falsos positivos, condições transitórias e eventos que exigiram intervenção.

Também seria necessário separar o monitoramento informativo de qualquer sistema de comando ou proteção. Se uma ação automatizada puder alterar o funcionamento do equipamento, ela exigirá análise de segurança, responsabilidades e critérios de projeto específicos — muito além do código demonstrado aqui.

9. O que observar depois da implantação?

Um monitor que gera muitos alertas não é necessariamente mais eficiente. Em alguns casos, significa que o modelo foi configurado sem considerar os estados reais do sistema.

Boas métricas de acompanhamento incluem percentual de dados ausentes, frequência de eventos por equipamento, tempo de permanência dos alertas, confirmações em campo, recorrência após correção e necessidade de ajustes nas regras. Os resultados devem ser usados para melhorar o processo de operação, não apenas para construir um painel visualmente elaborado.

O NIST publicou pesquisas sobre testes funcionais de sequências de controle HVAC, mostrando como a validação sistemática ajuda a identificar erros de implementação. Já a ASHRAE Guideline 36 trata de sequências de operação e desempenho de sistemas comuns de climatização. Essas referências apoiam a discussão geral de controles; não devem ser interpretadas como regras específicas para qualquer fabricante de VRF.

Conclusão

Antes de escolher um modelo complexo de detecção de falhas, vale construir uma cadeia básica confiável: pontos corretamente identificados, dados com qualidade conhecida, regras que respeitem o estado do equipamento e eventos que possam ser confirmados por profissionais.

O Python consegue demonstrar essa lógica com poucas dezenas de linhas. O trabalho mais importante, porém, está em decidir o que cada medida realmente significa e como uma anomalia digital se transforma em uma investigação técnica responsável.