Estudos de engenharia

NightMare · 15 min · Estudo de engenharia

O que o som do ar-condicionado permite observar

Construí o Watson, um sensor acústico com ESP32 que informa atividade do ventilador, do compressor e bipes curtos de um ar-condicionado existente. Um microfone poderia fornecer realimentação útil sem modificar o aparelho? As primeiras gravações animaram. Fala, um alarme e seis segundos de falso compressor mostraram o que o detector inicial não havia previsto.

ESP32 clássico, um microfone INMP441 e uma instalação com Consul CCN07GB. As avaliações históricas aparecem separadas abaixo. O espectrograma foi derivado agora de uma gravação original; os gráficos de avaliação reproduzem resultados salvos.

  • O resultado implementado são três observações independentes entregues pelo NightMare Network. O controlador completo de recuperação automática de estado do Adler ainda está sendo reconstruído.
  • As melhorias úteis vieram da análise de falhas específicas: variação temporal para o ventilador, uma faixa mais estreita para o compressor e temporização preservada para os bipes. Cada mudança trouxe um custo que precisou de avaliação própria.
Voltar ao NightMare

Três observações de um microfone

O Adler enviava comandos infravermelhos, mas outro controle ou os botões do aparelho podiam alterar o AC sem atualizar seu registro. O papel do Watson era observar o funcionamento por fora. O hardware era um ESP32 e um microfone I2S INMP441 perto do AC; a aquisição usava áudio mono a 16 kHz.

O ventilador pode funcionar com o compressor desligado. Um bipe curto de confirmação é outro tipo de evidência. A interface final separa presença do ventilador, presença do compressor e um evento transitório de bipe. O Watson publica essas observações; o Adler as combina com o histórico de comandos. Um tom detectado sozinho não identifica a ação solicitada nem a temperatura resultante.

Fontes e evidências: [1] · [2]

Os primeiros 99,3% escondiam um erro útil

O replay controlado inicial usou 18 gravações: três de cada estado OFF, FAN e COMPRESSOR, tanto em condições limpas quanto com fala. O relatório registrou 99,3% de decisões corretas em 15.656 janelas de análise com decisão, com 17 de 18 arquivos perfeitos. Eram muitas decisões sobrepostas de um conjunto controlado pequeno.

Na gravação imperfeita, o AC estava desligado enquanto alguém falava. Parte da fala foi classificada como ventilador. Isso importava mais que a pontuação agregada: a atividade normal do quarto podia ocupar as mesmas faixas do som procurado. A faixa ampla do compressor parecia limpa nesse piloto, mas ainda não havia encontrado a interferência de baixa frequência que depois a enganaria.

O espectrograma abaixo é uma visualização nova de uma gravação original com AC desligado e fala. Ele mostra por que um limiar de energia precisa de mais evidências: a fala leva energia relevante às faixas do ventilador. É um trecho ilustrativo, não uma afirmação de que esses oito segundos reproduzem o erro do classificador histórico.

A fala ocupa as faixas do ventilador

Deslize na horizontal para examinar todo o intervalo de tempo.

0k1k2k3k4k0s2s4s6s8sFrequência (Hz) · Tempo (s)
−100 dBFS−25 dBFS

Região tracejada: faixas de 500–2.000 Hz do ventilador. As células somam quatro bins da FFT e usam escala de cores fixa. O trecho ilustra a interferência; não reavalia a pontuação do piloto histórico.

Derivado dos primeiros 8 s de 2026-09-30_104340_off_talking_01.wav: PCM a 16 kHz, janelas Hamming de 1.024 pontos. Visualização nova de uma gravação original.

Baixar dados e proveniência (JSON)

Fontes e evidências: [3] · [12]

A constância do ventilador ajuda a separá-lo da fala

A fala podia superar o nível do ventilador justamente nas faixas usadas na detecção. Apertar o limiar também removia o som real do motor. Comparar a variação da energia no tempo ofereceu uma distinção melhor. No exemplo inicial de falha, a variação móvel em 500–1.000 Hz foi relatada em torno de 1,4 dB para o ventilador e 9,8 dB para a fala, com histórico de dois segundos. Eram exemplos, não limites universais.

A regra revisada exige energia nas faixas média e alta junto de variação temporal limitada. Pelo menos um segundo de histórico é necessário para avaliar a constância; uma espera separada de dois segundos é exigida antes de publicar o candidato. Um histórico minúsculo pode parecer artificialmente constante, enquanto a espera verifica se o candidato dura o suficiente. Uma verificação não substitui a outra.

No conjunto revisado de 88 eventos, falsos ventiladores caíram de 3.010 para 1.544 janelas. As perdas de ventilador subiram de 336 para 1.265. Uma televisão junto ao ventilador ligado podia tornar a mistura variável demais; um evento revisado de TV sobre ventilador perdeu as 872 janelas avaliadas. Máquinas com som constante ainda podiam se parecer com o ventilador. A mudança melhorou uma falha e expôs outra.

Menos falsos ventiladores, mais perdas
  • v1
  • v2
Ver dados do gráfico
Ver dados do gráfico
Janelas de análisev1v2
Falsa detecção de ventilador3.0101.544
Atividade do ventilador não detectada3361.265

88 eventos revisados; 53.014 janelas; 63 grupos temporais. Ventilador ausente: 19.748 janelas; presente: 33.266. v1 também teve 36 janelas presentes ainda sem publicação. v1/v2 identificam iterações do detector.

Baixar dados e proveniência (JSON)
Regra do ventilador e alternativas exploratórias

A base documentada usa mediana em 500–1.000 Hz ≥ −62 dBFS, mediana em 1.000–2.000 Hz ≥ −65 dBFS, variação temporal em 1.000–2.000 Hz ≤ 6 dB, pelo menos um segundo de histórico, mediana de meio segundo e espera de publicação de dois segundos. Os rótulos v1/v2 se referem a iterações do algoritmo.

Regressão logística, árvores pequenas e florestas aleatórias também foram exploradas. Pontuações iniciais de validação cruzada em gravações relacionadas não eram evidência suficiente para publicar um modelo. A regra escolhida permaneceu explícita e barata; uma substituição ainda precisava demonstrar melhora relevante em avaliação por grupos.

Fontes e evidências: [3] · [4] · [1]

O alarme que parecia uma confirmação

A revisão operacional de 2 de outubro encontrou 25 detecções verdadeiras e 41 falsas entre 66 eventos de bipe revisados. Trinta e cinco dos falsos eventos estavam associados a um alarme. A frequência do alarme se concentrava em 4.058–4.062 Hz, enquanto os bipes reais ficavam perto de 4.117–4.125 Hz. As durações se sobrepunham. Aumentar apenas o limiar de duração ou volume não os separava de forma confiável.

Uma faixa retrospectiva de 4.115–4.128 Hz preservou 24 de 25 bipes verdadeiros e nenhum dos 41 falsos nesse conjunto revisado. Era uma hipótese útil, testada nos mesmos exemplos que a sugeriram. Não estabelecia uma futura taxa de alarmes falsos, e uma faixa estreita podia rejeitar um tom real fraco ou deslocado.

Os metadados salvos do incidente também registram experimentos de execução com faixas mais estreitas. A base versionada do ESP32 clássico manteve uma busca mais ampla, de 4.050–4.180 Hz, com verificações de contraste e tempo. Separar essas versões impede que um ajuste operacional promissor vire uma configuração “final validada” que nunca existiu.

O que os eventos de bipe revisados continham
  • Contagem
Ver dados do gráfico
Ver dados do gráfico
Eventos revisadosContagem
Bipe real do AC25
Falso: alarme35
Falso: outro som6

Revisão operacional histórica: 66 detecções revisadas de 67 eventos de bipe disparados. As contagens descrevem esse conjunto; não medem bipes perdidos ou uma futura taxa de alarmes falsos.

Baixar dados e proveniência (JSON)

Fontes e evidências: [5] · [1] · [7]

Seis segundos de um compressor que não ligou

Dois eventos salvos, COMPRESSOR_ON às 11h52min20s e COMPRESSOR_OFF às 11h52min26s, captaram um único episódio falso de cerca de 6,3 segundos. As duas revisões dizem que o compressor permaneceu desligado. A energia em 30–80 Hz subiu o suficiente para passar pelo limiar e pela espera do detector, mas o som era diferente.

A análise histórica identificou uma componente em torno de 37,1 Hz e outra perto de 74,2 Hz, contra cerca de 58,6 Hz do compressor real. Uma faixa ampla misturava essas formas diferentes. Separá-la em faixas inferior, principal e superior expôs a diferença: o compressor real tinha energia forte em 52–65 Hz; o episódio falso não.

Esses níveis aproximados de exemplos motivaram um atributo principal mais estreito. Não eram distribuições de todas as condições de operação. Preservei diagnósticos das faixas vizinhas para investigação, tratando uma regra de rejeição por essas faixas como outra hipótese, que precisava avaliar suas próprias rejeições indevidas.

A interferência e o compressor tinham formas espectrais diferentes
  • Compressor real
  • Episódio falso

Deslize na horizontal para comparar todos os níveis das faixas.

-60-50-40-30-2030–45 HzReal: ≈ -52 dBFSFalso: ≈ -31 dBFS52–65 HzReal: ≈ -33 dBFSFalso: ≈ -57 dBFS65–80 HzReal: ≈ -57 dBFSFalso: ≈ -42 dBFSdBFS
Comparar energia por faixa (dBFS)
Comparar energia por faixa (dBFS)
HzCompressor realEpisódio falso
30–45≈ -52≈ -31
52–65≈ -33≈ -57
65–80≈ -57≈ -42

Níveis aproximados de duas amostras históricas, não distribuições populacionais. Os arquivos do incidente estão identificados nos dados para download. O gráfico compara medições relatadas, não espectros reconstruídos.

Baixar dados e proveniência (JSON)

Fontes e evidências: [5] · [12] · [6]

Uma medição diferente exige um novo limiar

A regra antiga do PC somava a potência em 30–80 Hz e comparava com −38 dB. O novo atributo somava apenas 52–65 Hz. A potência somada muda quando bins são removidos, mesmo com o mesmo som físico. Copiar −38 para o novo atributo implementaria outra regra de decisão.

A calibração usou 117 arquivos rotulados: 27.830 janelas com compressor ligado e 47.541 desligado, em 87 grupos temporais. As medianas da faixa principal eram −32,6 dBFS com compressor ligado e −59,1 dBFS desligado. A cauda do estado desligado na faixa ampla carregava muito mais interferência. Essas distribuições deram base à busca de limiares.

Fontes e evidências: [6]

Escolher uma região estável antes da queda de sensibilidade

A varredura abaixo inclui todos os limiares inteiros relatados de −52 a −35 dBFS. A escolha prática foi −43 dBFS: perto da melhor acurácia balanceada, dentro de um platô amplo e longe da perda abrupta de sensibilidade acima de −41. Em −38 na nova faixa, a sensibilidade caiu para 71,57%; em −43 foi 96,21%. As taxas de falsos positivos correspondentes foram 0,91% e 1,02% sobre 47.541 janelas desligadas.

A seleção deixando um grupo de fora por vez, em 87 grupos temporais, escolheu limites de −44 a −42 dBFS, com acurácia balanceada de 0,9743 nos grupos excluídos. Isso apoiou a escolha de uma região, em vez de tratar o ótimo da busca fina, −42,5, como constante física. A proteção opcional por faixas vizinhas permaneceu desligada: parte dos falsos exemplos se sobrepunha ao compressor real, e rejeitar suas caudas também podia rejeitar operação legítima.

Por que −43 dBFS, e o que acontece em −38
60%80%100%0%2%4%Falsos positivos · outra escala-52-48-43-38-35Limiar (dBFS)60%80%100%0%2%4%Falsos positivos · outra escala-52-43-35Limiar (dBFS)
  • Sensibilidade
  • Acurácia balanceada
  • Falsos positivos
Sensibilidade96,21%Falsos positivos1,02%Acurácia balanceada97,59%

Sombreado: região próxima do ótimo, −50 a −41 dBFS. Padrão: −43 dBFS. São os 18 limiares inteiros do relatório; sem interpolação ou nova execução do classificador.

Ver os 18 limiares
Ver os 18 limiares
dBFSSensibilidadeFalsos positivosAcurácia balanceada
-5296,6%3,47%96,57%
-5196,44%2,48%96,98%
-5096,34%2,04%97,15%
-4996,31%1,8%97,25%
-4896,3%1,64%97,33%
-4796,29%1,52%97,38%
-4696,29%1,41%97,44%
-4596,29%1,38%97,45%
-4496,28%1,29%97,49%
-4396,21%1,02%97,59%
-4296,1%0,91%97,6%
-4195,9%0,91%97,49%
-4093,06%0,91%96,08%
-3984,7%0,91%91,9%
-3871,57%0,91%85,33%
-3767,7%0,91%83,39%
-3667,64%0,91%83,37%
-3567,64%0,91%83,37%

117 arquivos rotulados; 27.830 janelas com compressor ligado e 47.541 desligado; 87 grupos temporais. Fonte: relatório salvo de derivação do compressor.

Baixar dados e proveniência (JSON)

Fontes e evidências: [6]

Portar a FFT mudou quais bipes eram preservados

A detecção de bipes usava atributos espectrais sem suavização, contraste com faixas vizinhas, duração, estabilidade de frequência e intervalos curtos. A mediana de meio segundo usada para os motores apagaria um tom de cerca de 150 ms; os eventos precisavam de processamento próprio.

A FFT embarcada cresceu de 1.024 para 2.048 amostras. A 16 kHz, isso dobrou a janela física de 64 para 128 ms, mantendo o avanço de 512 amostras, ou 32 ms. Substituir os 128 ms diretamente na temporização encurtava as durações estimadas e unia bipes próximos. O espectro podia parecer correto enquanto os eventos resultantes mudavam.

Uma calibração de 21 arquivos de eventos revisados comparou durações efetivas. Manter 64 ms reproduziu as 69 detecções de referência do PC sem extras. Usar 128 ms reproduziu 44. As regiões externas fracas da janela Hamming ajudam a explicar por que a duração efetiva do detector não precisa ser igual à duração nominal da janela.

Era um resultado de equivalência com o detector de referência nesses arquivos. Não estabelecia que todo bipe real seria detectado. Estabelecia que a implementação precisava preservar a semântica temporal junto dos cálculos no domínio da frequência.

A temporização muda quais bipes são preservados
  • Reproduzidas / 69
Ver dados do gráfico
Ver dados do gráfico
Detecções de referência reproduzidasReproduzidas / 69
64 ms69
80 ms63
96 ms57
128 ms44

21 arquivos de eventos revisados; 69 detecções de referência. Zero detecções extras nas quatro configurações. Mede equivalência com o detector de referência nos arquivos gravados.

Baixar dados e proveniência (JSON)

Fontes e evidências: [8] · [9]

Três verificações diferentes para confiar na implementação

Primeiro, equivalência numérica: a comparação documentada de 112 arquivos no computador verificou os cálculos compilados do firmware contra uma referência float64. Os níveis das faixas concordaram em cerca de 0,001 dB e a variação do ventilador em aproximadamente 0,0001 dB. Essas tolerâncias verificavam o cálculo, não a precisão da classificação acústica.

Segundo, equivalência comportamental: a mesma comparação verificou candidatos, mudanças publicadas e eventos de bipe. Relatou nenhuma divergência nos candidatos de ventilador/compressor e correspondência nas transições e eventos publicados. Um pequeno erro numérico perto do limiar pode alterar uma transição inteira; só comparar atributos não bastaria.

Terceiro, verificações no dispositivo: quatro janelas gravadas de referência passaram pela FFT/FPU do ESP32 real. A maior diferença relatada foi 0,018 dB para tolerância de 0,05 dB. Um teste separado no microfone apresentou cinco tons de 4.118 Hz e observou cinco eventos transitórios. Isso exercitou hardware e transporte em uma amostra controlada pequena.

Fontes e evidências: [1] · [10]

O que o replay rotulado mostrou — e onde ainda falhou

Um replay separado de 117 arquivos comparou o firmware recalibrado com a configuração anterior do PC v2, avaliando janelas após publicação. O compressor melhorou bastante nessa comparação. A sensibilidade do ventilador ficou próxima e sua taxa de falsos positivos piorou um pouco. A mudança incluía calibração de atributos e limiares; a melhora do compressor não pode ser atribuída apenas ao processador.

O relatório usa totais avaliados diferentes porque o aquecimento e a publicação diferem: ventilador com 75.344 janelas no firmware / 75.576 no PC; compressor com 75.371 / 75.299. A sensibilidade é calculada nas janelas positivas e a taxa de falsos positivos nas negativas. Esses totais identificam a avaliação; não são o denominador de ambas as taxas.

Os resultados agregados ainda escondiam falhas por interferência. No relatório separado de derivação do compressor, o subconjunto com TV continha 680 janelas ligadas e 376 desligadas e teve sensibilidade de 0,500 e taxa de falsos positivos de 0,500. Esse subconjunto pequeno e correlacionado pede mais gravações com TV; não estabelece uma taxa universal de 50% de falha perto de televisões.

Replay de 117 arquivos: sensibilidade / taxa de falsos positivos
ObservaçãoPC v2 anteriorFirmware
Ventilador96,7% / 5,8%96,8% / 6,6%
Compressor76,9% / 1,2%96,1% / 1,2%

Fontes e evidências: [11] · [6]

Manter os conjuntos de evidências separados

O piloto de 18 gravações, a comparação de 88 eventos do ventilador, a revisão operacional de 201 eventos disparados, a derivação do compressor em 117 arquivos, a calibração de bipes em 21 arquivos e a equivalência em 112 arquivos respondem perguntas diferentes. Contagens e percentuais dessas etapas não podem ser somados em uma única precisão. Revisões de eventos disparados também deixam de fora sons que nunca geraram captura.

Janelas FFT adjacentes se sobrepõem, e a suavização acrescenta dependência. A avaliação salva excluiu o aquecimento e ambiguidades próximas das transições, agrupou eventos dentro de 120 segundos e usou verificações de limiar por grupos. Rótulos históricos de estado único foram convertidos em rótulos de ventilador/compressor com uma hipótese: compressor ligado implica ventilador ligado nesse aparelho. É uma limitação da evidência antiga, não prova de referência independente para o ventilador.

Para esta publicação, conferi as contagens nos CSVs originais do ventilador, as linhas dos limiares, o relatório de calibração dos bipes e as duas revisões do incidente. O novo espectrograma foi derivado do trecho WAV identificado. As estatísticas históricas do conjunto de alarmes e os níveis aproximados das faixas continuam atribuídos ao relato de engenharia salvo; não viraram novos resultados de replay.

Fontes e evidências: [3] · [12] · [5]

Entregar observações úteis em um dispositivo limitado

O firmware separa aquisição, análise e publicação com filas limitadas. A perda de um bloco reinicia o contexto dependente de FFT/histórico, em vez de unir amostras separadas em um sinal contínuo fictício. Ventilador e compressor têm suas próprias esperas de publicação; bipes permanecem eventos transitórios, sem reprodução após reconexão.

As medições documentadas do ESP32 clássico colocaram a análise perto de 3,5 ms por avanço de 32 ms, cerca de 11% de um núcleo. Com o broker conectado, havia aproximadamente 35 KB de heap interno livre, com maior bloco em torno de 24 KB. São medições daquela configuração. Rede, streaming de diagnóstico e escrita em flash disputam recursos; OTA é uma operação de manutenção durante a qual a aquisição é suspensa.

Desconectar o microfone não pode virar “AC desligado”. Os sensores preservam informações de conexão, e o NightMare transporta disponibilidade e validade temporal junto das observações. Essa semântica permite usar o nó acústico em um controlador sem fingir que todo valor ausente é uma transição física.

Fontes e evidências: [1]

O que isso estabelece e quais testes seriam úteis agora

O resultado é um nó de observação acústica implementado, calibrado e avaliado em torno de um aparelho e uma posição de microfone. Ele fornece evidências de atividade alterada fora dos comandos do Adler. Não lê todo modo ou temperatura configurada, e o controlador de reconciliação de nível mais alto ainda está sendo reconstruído.

As próximas gravações precisam atacar as condições frágeis: períodos longos desligado e sem comandos, TV sobre ventilador ligado, alarmes próximos ao tom do AC, transições verificadas do compressor e posições variadas de microfone em dias separados. Grupos independentes de sessões devem ficar de fora antes do ajuste. Um novo arranjo de hardware precisaria de suas próprias gravações pareadas e avaliação.

Reprodução e material de origem

O repositório contém extração de atributos, revisão de eventos, avaliação por grupos, equivalência do firmware e autoteste. O script build-watson-evidence.py desta apresentação extrai um recorte das pastas originais de áudio, relatórios versionados e registro histórico, gravando hashes SHA-256. Ele gera as células do espectrograma e verifica as contagens dos gráficos; não reexecuta todos os benchmarks dos detectores.

O JSON para download contém valores dos gráficos, métodos, nomes de arquivos e hashes. Gravações e notas privadas de revisão ficam fora do pacote do site. A reprodução completa exige o conjunto de gravações, rótulos, configurações e versão de código descritos em cada relatório.

Fontes e evidências: [12] · [10] · [1]

Fontes e evidências

Os detalhes da implementação e os relatórios de avaliação estão vinculados a versões específicas do código.

  1. Arquitetura do firmware, limites de recursos e validação documentada
  2. Observações independentes de ventilador/compressor
  3. Piloto de 18 gravações e avaliação de 88 eventos
  4. Regra de constância do ventilador e justificativa do limiar
  5. Revisão histórica de 2 de outubro: conjunto de alarmes e medições aproximadas do episódio falso, preservados no recorte de evidências
  6. Derivação do compressor em 117 arquivos: distribuições, varredura completa e seleção por grupos
  7. Detector de eventos de bipe
  8. Calibração de duração efetiva em 21 arquivos
  9. Cálculos dos atributos espectrais e temporais
  10. Verificação de equivalência entre firmware e referência
  11. Relatório de replay rotulado de firmware/PC em 117 arquivos
  12. Valores dos gráficos, dados visuais derivados da gravação, métodos e proveniência SHA-256 (JSON)