Roteiro da Demonstração ao Vivo¶

A seção 11 do briefing do Desafio 6 recomenda demonstrar o ciclo completo: "instalar o sensor, ligar um equipamento de alta potência, ver o alerta disparar e receber a sugestão de horário no aplicativo". Este é o roteiro ensaiável, com checklist e plano B.

1. Checklist pré-demo (véspera)¶

[ ] Medidor online — badge verde no dashboard, leituras chegando (subscriber MQTT ativo na VPS).
[ ] Modo demo dos alertas ativado no .env de produção: ANOMALY_EVAL_EVERY_N=1 e ANOMALY_COOLDOWN_MINUTES=0, seguido de docker compose -f docker-compose.prod.yml up -d web mqtt_subscriber (ver docs/alertas.md seção 4). Alternativa sem tocar no .env: rodar reset_anomaly_cooldown entre ensaios.
[ ] Limite pré-configurado no medidor da demo (ex.: 2000 W — abaixo do chuveiro, acima do consumo base). É o gatilho mais determinístico para a apresentação.
[ ] Conta da demo com WhatsApp vinculado — enviar qualquer mensagem ao bot ((48) 3058-5297) na véspera, para o número ficar registrado e o alerta chegar no celular no telão.
[ ] Tarifa branca ativa com os 3 postos cadastrados e rate_source/rate_source_date preenchidos (fonte e data de consulta dos valores — exigência da seção 6 do briefing; conferir em /tarifas/).
[ ] Aparelhos confirmados no NILM (chuveiro ao menos) — para a tela "Consumo por Aparelho" e a recomendação de horário terem conteúdo real.
[ ] Um alerta recente no histórico — garante o card "Último alerta" visível no dashboard desde o início.
[ ] Site de documentação no ar (/docs/) — a banca pode querer ver a documentação técnica.
[ ] Gerar o relatório de resultados com os números mais atuais para levar à apresentação:
```
docker compose -f docker-compose.prod.yml exec -T web python manage.py export_results > relatorio_resultados.md
```
Consolida cobertura de dados, medido vs. faturado, previsão vs. real, alertas por tipo, NILM (com evaluate_nilm anexado) e economia das recomendações.
[ ] Ensaiar o roteiro completo ao menos uma vez, cronometrado.

2. Roteiro (≈ 4 minutos, alinhado ao pitch)¶

Passo	Ação	O que a banca vê	Critério do briefing
1 (30s)	Abrir o dashboard com o medidor ao vivo	Potência instantânea, tensão, corrente, custo do ciclo atualizando	Leitura em tempo real
2 (30s)	Mostrar o sensor CT clamp instalado no quadro (foto ou ao vivo)	Instalação não invasiva, sem corte de circuito	Prototipo físico
3 (60s)	Ligar o chuveiro (ou outra carga ≥ 2000 W)	Potência salta no dashboard; alerta chega no WhatsApp (telão) e no card "Último alerta"	Alerta disparando corretamente
4 (45s)	Abrir a tela "Consumo por Aparelho"	O acionamento do chuveiro já aparece como evento pendente (detecção em tempo real), com sugestão de aparelho pré-preenchida; composição de consumo	NILM
5 (45s)	Mostrar a recomendação de horário	Melhor posto para o chuveiro com economia em R$ por uso	Sugestão de horário pela tarifa branca
6 (30s)	Perguntar ao bot no WhatsApp: "qual a previsão da minha fatura?"	Resposta em linguagem natural com valor projetado	Assistente / previsão

3. Plano B¶

Alerta não chegou no WhatsApp → o card "Último alerta" no dashboard mostra o mesmo conteúdo (a mensagem é sempre registrada); seguir por ali e conferir a Evolution API depois.
Cooldown segurou um segundo disparo (se o .env não estiver em modo demo) → docker compose -f docker-compose.prod.yml exec web python manage.py reset_anomaly_cooldown e repetir.
Chuveiro indisponível no local → o limite pré-configurado dispara com qualquer carga acima do valor; na pior hipótese, reduzir o limite para pouco acima do consumo base e ligar um aquecedor/ferro de passar.
Sem internet no telão → capturas de tela do ensaio da véspera como fallback (guardar na pasta do pitch).

4. Pós-demo¶

[ ] Reverter o .env para os valores de produção (ANOMALY_EVAL_EVERY_N=5, ANOMALY_COOLDOWN_MINUTES=30) e recriar os containers.