Voltar ao portfólio

Produto

NightMare Network

Declare uma vez. Seu dispositivo entra na rede.

Todo projeto de ESP32 em rede reconstrói o mesmo encanamento: identidade, tópicos MQTT, estado retido, reconexão, comandos remotos, agendamentos. O NightMare Network cuida dessa parte. Você declara o que o dispositivo oferece, Values, Actions e Events, e o seu firmware fica com o hardware: pinos, drivers, timing e o que cada valor significa.

Framework de código aberto · alpha

SiteGitHubNightMare System

Os dispositivos que usam o framework

  • Adler

    Controle infravermelho de um ar-condicionado antigo. Cada comando só vale quando a unidade é ouvida apitando de volta.

  • Watson

    Observador acústico com microfone: publica o ventilador, o compressor e cada apito. Não decide nada.

  • NightMare Dashboard

    Painel touch de parede que não tem hardware próprio: comanda o ar e as luzes de outros dispositivos, via ESP-NOW.

  • NightMare Gateway

    Ponte ESP32-S3 entre ESP-NOW e MQTT, ela mesma um dispositivo NightMare, gerenciada como tudo que carrega.

  • Mycroft

    Nó de porta, luz e temperatura para ESP32 e ESP32-C3.

  • Sherlock

    Sensor de ambiente e luz: temperatura, umidade, tensão da placa, liga/desliga e cor do LED.

  • NightMare System

    Painel e histórico da casa: lê manifests, manda escritas e Actions, guarda o histórico dos sensores. Consome o protocolo, não faz parte dele.

De helpers repetidos a um framework

Começou como helpers que eu copiava entre os meus próprios projetos de firmware. Conforme esses dispositivos precisaram falar com os microcontroladores do mesmo jeito, os helpers viraram um resolvedor de comandos e convenções de endereçamento MQTT compartilhados.

Depois veio um padrão de request/response sobre MQTT, para que um comando de um operador, de outro dispositivo ou de um serviço siga uma gramática só. O modelo atual deixa as capacidades explícitas: Values, Actions e Events tipados, descritos em manifests. A biblioteca hoje compila com Arduino ou ESP-IDF.

O que o dispositivo recebe do framework

  • Declare uma vez

    Sem string de tópico, sem subscribe, sem lógica de reconexão. Tópicos, estado retido e inscrições ficam por conta dele, e são reanunciados a cada reconexão.

  • Estado que todo dispositivo vê

    O último valor fica retido, então um dispositivo que liga depois já vê na hora. Os outros consomem pelo nome e podem trocar a fonte em runtime.

  • Dispositivos que se chamam

    Actions são chamadas remotas tipadas, com resultado; Events são coisas que aconteceram. Os dois são roteados para você, nos dois sentidos.

  • Uma linguagem de comandos

    Os mesmos comandos funcionam pela serial, pelo console MQTT, em request/response correlacionado sobre MQTT e em jobs agendados.

  • MQTT ou ESP-NOW, com failover

    MQTT local ou remoto, ou ESP-NOW via gateway, de 5 a 8 ms por salto nos testes. Faz fallback e se recupera sozinho.

  • Docs que a sua IA lê

    Um endpoint MCP público e só leitura deixa um assistente de IA buscar nas docs, achar a API exata e ler o código atual antes de escrever um dispositivo.

O framework em resumo

Time
Sozinho, do design ao deploy
Período
2023-10 – atual
Status
v1.0.0-alpha.1, MIT
Stack
C++ em ESP32, Arduino ou ESP-IDF, MQTT, ESP-NOW

Estado, contratos e reconexão

  • Registre uma vez, participe automaticamente

    Um Resource não deveria precisar de código MQTT próprio em cada aplicação. Depois de declarado, o framework publica a descrição, mantém o estado, roteia escritas e chamadas e restaura tudo depois de uma reconexão. O custo: o layout de tópicos é do framework, e ele é o contrato da 1.0.

  • Estado retido no MQTT, não um protocolo de sync

    O estado atual mora em tópicos retidos sempre que o MQTT já dá a semântica certa. O manifest descreve; o tópico de estado diz a verdade, então um manifest faltando ou atrasado nunca invalida um valor.

  • Um fallback saudável fica onde está

    O ESP-NOW é o preferido, mas um link MQTT funcionando é mantido até o ESP-NOW ficar elegível: um anúncio retido do gateway e uma sessão segura cuja identidade bate com ele. Sondar ou um handshake que falha nunca derruba uma conexão saudável.

  • O dono é a verdade

    Um sensor remoto só leitura mostra exatamente o que o dono publicou. Um estado remoto gravável mostra o valor escrito na hora, de forma otimista, e depois cede ao estado confirmado pelo dono.

Do firmware ao MQTT

Dispositivos com NightMare Network chegam num broker MQTT por Wi-Fi ou por ESP-NOW através do gateway, que também é um dispositivo NightMare. O broker, só com TLS, roda no Stackport. O NightMare System, painel e histórico da casa, lê e escreve pelo mesmo broker.Roda NightMare NetworkESP-NOWMQTTMQTTlê · escreveDispositivoESP-NOWDispositivoWi-FiGatewayESP32-S3 · HolmesBroker MQTTTLS · StackportNightMare Systempainel · histórico
  • Uma biblioteca C++ que todo dispositivo usa: identidade, Resources, comandos, scheduler, settings, telemetria e sincronia de hora.
  • Os dispositivos chegam no MQTT por Wi-Fi, ou por ESP-NOW através do gateway, que também é um dispositivo NightMare.
  • Em produção roda num broker Mosquitto só com TLS hospedado no Stackport.
  • Os documentos do framework são MessagePack primeiro; um formato de status só cobre online, offline e Last Will.

Escopo alpha e lacunas conhecidas

  • Alpha: o contrato da 1.0 está fechado, o processo de release é novo. Fixe a tag.
  • ESP32 é a única plataforma suportada.
  • As sessões ESP-NOW usam chave pré-compartilhada, com limites conhecidos documentados.
  • Só jobs de comando por horário sobrevivem a um reboot; callbacks e jobs monotônicos não.
  • A lista completa está no site, em known gaps.