Arquitetura prática: ESP32 sensor, ESP32 gateway e aplicativo cliente
Agora podemos montar uma visão mais próxima de um sistema real. Em vez de pensar no mDNS apenas como uma forma de acessar esp32-sensor.local pelo navegador, vamos enxergá-lo como parte de uma arquitetura IoT local, composta por três elementos: um ESP32 sensor, um ESP32 gateway e um aplicativo cliente, que pode ser um app mobile, uma aplicação web local ou um software rodando em um computador da rede.
O ESP32 sensor tem uma função simples: coletar dados do ambiente. Ele pode medir temperatura, umidade, luminosidade, corrente elétrica, vibração, presença ou qualquer outra grandeza física. Esse dispositivo conecta-se ao Wi-Fi, inicializa o mDNS, define um hostname como esp32-temp-01.local e anuncia um serviço próprio, por exemplo _sensor._tcp. Assim, ele não precisa ter IP fixo nem ser cadastrado manualmente no gateway.
O ESP32 gateway atua como concentrador. Ele também se conecta à mesma rede local, mas, em vez de apenas anunciar sua presença, ele executa consultas mDNS procurando dispositivos que ofereçam _sensor._tcp. Quando encontra sensores, ele lê os registros TXT, verifica informações como device_type=sensor, fw_version=1.0.0 e api=/api/v1, e então passa a consultar a API HTTP desses sensores.
O aplicativo cliente pode acessar diretamente o gateway, por exemplo em:
http://esp32-gateway.local
Nesse modelo, o usuário não precisa conhecer todos os sensores da rede. Ele acessa apenas o gateway, e o gateway se encarrega de descobrir os nós sensores, coletar os dados e apresentar uma visão consolidada.
A arquitetura conceitual pode ser representada assim:
Nesse fluxo, cada sensor anuncia algo semelhante a:
Host: esp32-temp-01.local
Serviço: _sensor._tcp
Porta: 8080
TXT:
device_type=sensor
sensor=temp_humidity
fw_version=1.0.0
api=/api/v1
O gateway consulta a rede, encontra esse serviço, lê a porta e os metadados, e então acessa o sensor usando HTTP:
http://esp32-temp-01.local:8080/api/v1/readings
Ou, se a consulta mDNS já retornou o IP, o gateway pode acessar diretamente o endereço resolvido:
http://<ip_do_sensor>:8080/api/v1/readings
A vantagem de usar o hostname .local é a legibilidade. A vantagem de usar o IP retornado pela consulta mDNS é evitar uma segunda resolução de nome. Em produtos mais robustos, o gateway pode guardar temporariamente o IP descoberto, mas deve estar preparado para redescobrir o dispositivo caso ele reinicie ou mude de endereço.
Um exemplo de resposta da API do sensor poderia ser:
{
"device": "esp32-temp-01",
"type": "temp_humidity",
"temperature_c": 28.4,
"humidity_percent": 61.2,
"uptime_s": 4380
}
O gateway poderia manter uma tabela interna de dispositivos descobertos:
typedef struct {
char hostname[64];
char instance_name[64];
char device_type[32];
char api_base[32];
uint16_t port;
bool online;
} sensor_node_t;
Esse tipo de estrutura permite que o gateway organize os sensores encontrados. O campo hostname guarda algo como esp32-temp-01. O campo instance_name pode guardar o nome amigável anunciado pelo serviço. O campo device_type ajuda a classificar o nó. O campo api_base indica a rota principal da API. A porta informa onde o serviço está disponível. O campo online permite marcar se o dispositivo respondeu recentemente.
Do ponto de vista de projeto embarcado, essa arquitetura tem uma vantagem importante: ela reduz configuração manual. Em vez de gravar no firmware do gateway uma lista fixa de IPs, deixamos que a rede informe quais sensores estão disponíveis. Isso torna a instalação mais simples e facilita manutenção. Se um sensor for trocado, basta que o novo dispositivo anuncie o mesmo tipo de serviço.
Mas também existem limites. O mDNS não deve ser tratado como mecanismo de segurança, autenticação ou autorização. Um dispositivo mal configurado, ou até um dispositivo indevido dentro da mesma rede, poderia anunciar um serviço com o mesmo tipo. Por isso, o gateway deve validar os dispositivos encontrados. Essa validação pode incluir versão de API, chave pública conhecida, token de pareamento, lista de dispositivos autorizados ou algum procedimento de provisionamento.
Uma estratégia prática é usar o mDNS apenas para descoberta inicial e depois exigir uma etapa de confirmação na aplicação. Por exemplo, o gateway encontra _sensor._tcp, acessa /api/v1/info, verifica o modelo, a versão do firmware e um identificador único do dispositivo. Só depois disso ele passa a aceitar dados daquele sensor.
A arquitetura também pode ser expandida. O gateway pode anunciar seu próprio serviço, por exemplo _gateway._tcp, permitindo que o aplicativo cliente encontre automaticamente o concentrador local. Assim, o app não precisa saber o IP do gateway nem o IP dos sensores. Ele apenas procura gateways compatíveis na rede.
O fluxo completo fica assim:
1. Sensores anunciam _sensor._tcp.
2. Gateway consulta _sensor._tcp e descobre sensores.
3. Gateway valida os sensores encontrados.
4. Gateway coleta dados via HTTP, MQTT local ou outro protocolo.
5. Gateway anuncia _gateway._tcp.
6. Aplicativo cliente descobre o gateway.
7. Aplicativo consome os dados consolidados.
Esse modelo é muito útil em laboratórios, automação residencial, pequenas redes industriais, bancadas didáticas e protótipos IoT. Ele permite que os dispositivos formem uma rede local mais flexível, onde a descoberta acontece dinamicamente e a aplicação não depende tanto de endereços fixos.
