Estudo de caso de sondas de temperatura

Este estudo de caso acompanha a construção da sonda de temperatura por trás do ProbeHarbor: por que um único termômetro externo não bastava, como foram escolhidas duas zonas DHT22 mais um resumo com a média e o que mudou entre a primeira instalação em protoboard e a revisão conectada à rede que hoje envia JSON ao vivo para este site.

O desafio

O objetivo era prático, não acadêmico: saber se uma garagem anexa à casa estava chegando perto do risco de congelamento, se a umidade estava subindo a ponto de enferrujar as ferramentas e se as condições eram diferentes perto do portão e na parede do fundo. Os apps de previsão do tempo só informam o ar externo na estação mais próxima, que pode diferir uns 5 °C (10 °F) ou mais do interior de uma garagem isolada numa tarde ensolarada de inverno.

Um único sensor esconderia as diferenças que importam. Abrir o portão basculante, estacionar um carro ainda quente ou o sol da tarde numa parede voltada para o oeste mexem com partes diferentes do espaço em velocidades diferentes. A necessidade de várias sondas ficou clara antes de soldar o primeiro fio.

O ambiente

O espaço monitorado é uma garagem anexa típica: um grande portão basculante, piso de laje de concreto, menos isolamento que a área da casa e variações sazonais causadas tanto pela insolação e pelas infiltrações de ar quanto pela temperatura externa. No verão, a zona do portão fica mais quente; no inverno, a laje e a parede norte acompanham as mínimas externas com horas de atraso.

• Zona da parede norte: muda mais devagar; útil para acompanhar a tendência das mínimas da madrugada.
• Zona do portão: dá picos quando o portão abre; denuncia entradas rápidas de ar.
• Área da bancada: representa onde o trabalho realmente acontece, na altura dos ombros.

A demo interativa de sondas simula essas três zonas para você ver como o sol e o estado do portão afastam as leituras, sem instalar hardware.

Abordagem e hardware

Cada sonda usa um sensor digital de umidade e temperatura DHT22 com um cabo curto até um Arduino Uno. O firmware lê os dois sensores em intervalos fixos, tenta de novo em caso de erros temporários no barramento, calcula um avg das sondas em bom estado e envia JSON compacto pela rede local por meio de um shield Ethernet. Um LCD de 16×2 na placa mostra os valores ao vivo para conferir no local sem notebook.

O posicionamento seguiu as regras do guia de sondas de temperatura: longe de pontos de sol direto e exaustores, mais ou menos na altura dos ombros e com montagem ventilada para o ar passar pela cabeça do sensor. Rótulos no dashboard associam as chaves JSON 0 e 1 a nomes de zona legíveis.

Linha do tempo da montagem

1. Primeiros testes na bancada: os logs na serial confirmaram as leituras do DHT22, a formatação do LCD e chaves JSON temp estáveis antes de a placa sair da mesa.
2. Revisão um na garagem: provou que as diferenças entre as sondas eram reais: a zona do portão se afastava com frequência da parede norte nos horários de ida e volta do trabalho.
3. Feed JSON pela rede: a Ethernet acabou com a necessidade de levar um notebook a cada conferência; o site podia buscar o mesmo documento que o LCD já mostrava.
4. Revisão dois: encaixe mais limpo do shield Ethernet, conectores de sonda aprimorados e lógica de reinicialização compatível com watchdog para os raros travamentos de rede.
5. Integração com o site: as páginas em Astro associam os feeds a cards; o histórico de quem está logado guarda snapshots para análise de tendências e exportação em CSV.

O que os dados mostraram

Depois de um ciclo completo de inverno e verão, as sondas valeram a pena de formas que uma única leitura teria deixado passar:

• A temperatura perto do portão podia variar de 4 a 7 °C (8–12 °F) poucos minutos depois de abrir o portão basculante, enquanto a parede do fundo mudava pouco.
• As mínimas da madrugada perto da parede norte acompanhavam o risco de congelamento com mais confiabilidade do que apenas as previsões externas.
• A umidade subia depois de períodos longos de frio, quando a laje demorava a esquentar: útil para decidir quando ligar um desumidificador.
• A média calculada suavizava o ruído nos gráficos de histórico, enquanto os cards por sonda na página inicial preservavam o detalhe de cada zona.

As leituras vão da sonda ao dashboard pelo caminho documentado em fluxo de dados de ponta a ponta. Quando foi preciso TLS na borda, um relay em Python fez cache do JSON de origem sem jogar essa complexidade para o microcontrolador.

Lições aprendidas

• Posição vale mais que o preço do sensor: um DHT22 bem instalado superou sempre um sensor premium mal posicionado.
• Nomeie as zonas no software: chaves JSON estáveis com rótulos no dashboard mantiveram firmware e site pouco acoplados.
• Conte com lacunas: reinicializações e quedas rápidas de rede criam lacunas curtas; diferencie-as de erros de configuração usando os guias de leituras desatualizadas.
• Construa pensando em iterar: a revisão um em protoboard poupou uma subida na escada quando a atribuição dos pinos mudou.

Leitura relacionada

Continue com a visão geral das sondas de temperatura, o guia de sketches de Arduino, o que faz as leituras mudarem e o uso dos dados históricos no dashboard. Código-fonte do firmware: arduino-network-json-temperature-sever.

Perguntas frequentes

Qual foi a conclusão do estudo de caso das sondas?
Sondas em várias zonas mais limites de congelamento pegam eventos de frio que sensores únicos deixam passar, principalmente perto de portas e paredes sem isolamento durante ondas de frio polar.