Engenharia da PoC

Arquitetura de ponta a ponta

A camada de ingestão já está implementada. Quando o ESP32 estiver montado, basta publicar no endpoint documentado abaixo para que os dados reais passem pelo mesmo motor de regras usado hoje pelo Modo Simulação.

Pipeline

Fluxo de dados

Etapa 01
Sensores
DHT22/AM2302 fornece temperatura e umidade. LDR + comparador e módulo de som/LM393 operam por limiar.
Etapa 02
ESP32
Lê os pinos, aplica os limiares digitais e monta o payload JSON da leitura.
Etapa 03
Wi-Fi
Conexão à rede local e envio HTTPS para a API da aplicação.
Etapa 04
API REST
POST /api/public/readings valida o payload e calcula a latência.
Etapa 05
Banco de dados
Tabelas readings e alerts com histórico completo e origem do dado.
Etapa 06
Motor de regras
Classifica variáveis, calcula o índice 0–100 e deriva os alertas.
Etapa 07
Dashboard e alertas
Painel em tempo real, histórico e recomendações ambientais.

Precisão declarada: o DHT22 fornece medidas numéricas de temperatura e umidade. O LDR e o sensor de som operam por limiar nesta PoC — eles indicam apenas se o limiar foi ultrapassado, e por isso a aplicação não apresenta lux nem decibéis.

Integração

Endpoint de ingestão

POST /api/public/readings — recebe uma leitura em JSON, calcula o índice de acessibilidade, grava no banco e gera os alertas correspondentes.

Campos do payload

Campo	Tipo	Descrição
device_id	string	Identificador do ESP32.
room_id	string	Identificador do ambiente (ex.: sala-01).
temperature_c	number \| null	Temperatura em °C lida pelo DHT22.
humidity_pct	number \| null	Umidade relativa em % lida pelo DHT22.
light_alert	boolean	Limiar de luminosidade ultrapassado (LDR + comparador).
noise_alert	boolean	Limiar de ruído ultrapassado (sensor de som/LM393).
timestamp	string ISO 8601	Momento da leitura no dispositivo (opcional). Usado apenas como horário do registro — nunca para latência.
sent_at_ms	number (opcional)	Epoch em milissegundos no instante do envio (firmware v2.1+). Único campo usado para calcular a latência dispositivo → API; sem ele, latency_ms fica vazio (null).

Exemplo de payload

{
  "device_id": "esp32-sala01",
  "room_id": "sala-01",
  "temperature_c": 24.6,
  "humidity_pct": 57.2,
  "light_alert": false,
  "noise_alert": true,
  "timestamp": "2026-08-31T14:32:10Z",
  "sent_at_ms": 1788006730000
}

Exemplo de chamada

curl -X POST https://SEU-DOMINIO/api/public/readings \
  -H "Content-Type: application/json" \
  -d '{"device_id":"esp32-sala01","room_id":"sala-01","temperature_c":24.6,"humidity_pct":57.2,"light_alert":false,"noise_alert":true,"timestamp":"2026-08-31T14:32:10Z"}'

Resposta

{
  "ok": true,
  "accessibility_index": 64,
  "status": "critical",
  "alerts_created": 1
}

Erros de formato retornam HTTP 400 com a lista de campos inválidos. Antes de expor o endpoint em produção, recomenda-se adicionar um segredo compartilhado no cabeçalho para autenticar o dispositivo.

Dados

Persistência e motor de regras

readings — cada leitura com dispositivo, ambiente, temperatura, umidade, eventos de luminosidade e ruído, origem (simulada ou real), índice, status e latência.
alerts — alertas gerados com tipo, severidade, mensagem, recomendação ambiental e origem. Para leituras do dispositivo, os alertas são criados por transição de estado (início do evento, mudança de nível e resolução), e não repetidos a cada envio enquanto a condição persiste.
O motor de regras é único e compartilhado entre o Modo Simulação e a API, garantindo que a classificação dos dados reais seja idêntica à demonstrada agora.