Os medidores de energia Wi-Fi IAMMETER podem enviar dados de medição diretamente para um servidor, broker MQTT ou plataforma de dados controlada pelo cliente. Isso permite que desenvolvedores e integradores de sistemas criem seu próprio EMS, BMS, serviço IoT, banco de dados ou painel de monitoramento sem usar o IAMMETER-Cloud como destino dos dados.
Este guia aborda a integração pelo lado do servidor recetor:
Medidor IAMMETER
│
│ HTTP/HTTPS, MQTT/MQTTS ou TCP/TLS
▼
Serviço de ingestão do cliente
│
├── Registo de payload bruto
├── Banco de dados temporal ou relacional
├── EMS / BMS / ERP
└── Serviços de painel, relatório e alarmes
Para capacidades de firmware do lado do medidor e formatos de endereço, utilize o Guia de API Local e Interface Aberta IAMMETER. Para seleção de arquitetura, consulte Desenvolva Seu Próprio Sistema de Monitoramento de Energia.
O medidor pode enviar suas medições usando vários transportes. O sistema recetor deve selecionar um caminho principal de ingestão.
| Transporte | Componente recetor | Bom ponto de partida para |
|---|---|---|
| HTTP / HTTPS | Endpoint web | Backends REST e a integração mais simples inicial |
| MQTT / MQTTS | Broker MQTT e subscritor | Plataformas IoT existentes e pipelines de mensagens |
| TCP / TLS | Listener de socket | Coletores dedicados e serviços de protocolo personalizados |
HTTP é normalmente a maneira mais fácil de inspecionar o primeiro payload porque o recetor de teste oficial pode ser iniciado com um pequeno exemplo em Node.js. MQTT é uma escolha forte quando um broker já faz parte do sistema. TCP/TLS fornece uma integração de socket de nível inferior, mas requer mais engenharia do lado do recetor.
Os transportes seguros e formatos de porta personalizados são mantidos no guia de firmware atual, em vez de serem repetidos aqui.
A IAMMETER fornece um exemplo oficial de recetor HTTP Node.js para teste de integração.
Baixe o exemplo em:
Execute:
node Server.js
O exemplo escuta na porta 8000. Quando uma solicitação chega, ele:
200 com uma pequena resposta JSON de sucesso.O exemplo é deliberadamente mínimo. Ele não fornece autenticação, persistência, validação, limitação de taxa ou segurança de produção.
Antes de configurar o medidor, confirme que:
Para um teste em LAN, o medidor e o recetor podem usar a mesma rede local sem acesso à Internet. Para um recetor remoto, o local deve ter uma rota para o servidor.
Na WebUI atual do medidor, selecione o modo de execução HTTP e insira um destino como:
{endereço-do-servidor}:8000/upload
Endpoints HTTPS podem usar a porta padrão ou uma porta personalizada. As regras atuais de endereço, incluindo https://host:porta, estão documentadas na seção de firmware HTTP/HTTPS.
Após salvar a configuração, verifique o console do recetor para o caminho da solicitação e o JSON enviado. Mantenha este primeiro payload bruto como um fixture de teste para testes posteriores de parser e banco de dados.
A IAMMETER usa uma estrutura JSON de medição central consistente em todos os transportes de envio suportados. O transporte altera como o payload chega, mas o modelo de medição permanece consistente.
Um payload normalmente inclui campos de nível de dispositivo, como:
SN — número de série do medidor usado para identificar o dispositivo;version — versão do firmware do medidor;method — método de mensagem ou tipo de payload;Data ou Datas — arrays de medição.Data é usado para um único canal de medição. Datas contém múltiplos arrays de medição para um medidor multicanal ou trifásico.
Exemplo de estrutura de canal único:
{
"method": "uploadsn",
"mac": "B0F8932A295C",
"version": "i.75.98.71y",
"server": "em",
"SN": "12345678",
"Data": [228.91, 1.61, 225, 15066.47, 0]
}
Não codifique uma contagem de arrays para todos os medidores. O número de canais e campos disponíveis depende do modelo do medidor e dos recursos de medição ativados.
Use a definição oficial ao implementar o parser:
Mantenha o processamento específico por modelo separado do transporte recetor.
Por exemplo, WEM3046T e WEM3046TE medem a saída secundária de 5 A de um transformador de corrente externo. Seus valores devem ser convertidos com a relação CT aplicável para obter a medição do lado primário. Esta é uma característica do medidor e CT, não uma diferença de HTTP, MQTT ou TCP.
Portanto, um pipeline prático de ingestão separa:
Armazene informações suficientes para reproduzir e diagnosticar a leitura original.
Um modelo mínimo útil inclui:
| Campo | Finalidade |
|---|---|
| SN do medidor | Mapeia o payload para um dispositivo registado |
| Índice de canal ou fase | Diferencia dados monofásicos, split-phase e trifásicos |
| Hora de receção do servidor | Fornece um timestamp de ingestão consistente |
| Tensão | Medição elétrica |
| Corrente | Medição elétrica |
| Potência ativa | Entrada para cálculo de importação/exportação ou carga em tempo real |
| kWh importado | Energia cumulativa importada |
| kWh exportado | Energia cumulativa exportada |
| Versão do firmware | Suporta troubleshooting e compatibilidade do parser |
| Payload bruto | Permite replay, auditoria e correção do parser |
Campos adicionais como frequência, fator de potência e medições reativas devem ser armazenados quando o modelo e a configuração selecionados os fornecerem.
Para sistemas de produção, considere manter:
Isso facilita a correção da lógica de parsing ou relação CT sem perder o payload original.
Registe o horário em que o servidor aceitou o payload. Se o sistema de negócio também usar um timestamp do dispositivo ou fonte, armazene ambos os valores separadamente, em vez de substituir um pelo outro.
Atraso de rede, reconexões e processamento em fila podem fazer com que o horário de ingestão seja diferente do horário de medição. Defina o timestamp usado por gráficos, faturamento e alarmes antes da implantação em produção.
Para ingestão MQTT, o sistema do cliente fornece:
A IAMMETER publica dados em tempo real sob um tópico de dispositivo como:
device/{SN}/realtime
Use o guia dedicado para configuração do broker, credenciais, tópicos e considerações MQTTS:
O MQTT Discovery do Home Assistant não é necessário para uma integração geral cliente-servidor.
A IAMMETER fornece um listener TCP Node.js mínimo:
O exemplo escuta na porta 8000 e imprime os dados recebidos. Um recetor TCP de produção deve adicionalmente fornecer:
Não assuma que um evento data de socket sempre corresponde a uma mensagem completa da aplicação.
O exemplo oficial TLS demonstra um listener TLS com chave e certificado do servidor:
Antes do uso em produção, substitua os certificados e configurações de demonstração pela configuração de certificado, gerenciamento de chaves e segurança aprovada da organização. O recetor deve registar falhas TLS separadamente das falhas de validação de payload.
Os formatos de endereço do lado do medidor para TCP e TLS são mantidos no guia de interface de firmware.
O firmware atual suporta um intervalo de envio para terceiros de até 2 segundos. Um intervalo curto é útil apenas quando o sistema recetor, armazenamento e aplicação precisam da resolução adicional.
Registos aproximados gerados por medidor:
| Intervalo de envio | Registos por medidor por dia | 100 medidores por dia | 1.000 medidores por dia |
|---|---|---|---|
| 60 segundos | 1.440 | 144.000 | 1.440.000 |
| 10 segundos | 8.640 | 864.000 | 8.640.000 |
| 2 segundos | 43.200 | 4.320.000 | 43.200.000 |
Estes números representam eventos de envio, não necessariamente linhas de banco de dados. Um payload trifásico pode ser normalizado em vários registos de canal, e índices, retenção de payload bruto ou armazenamento replicado aumentam o volume real do banco de dados.
O planejamento de capacidade deve incluir:
Para controle ou automação de um segundo na mesma LAN, considere Modbus TCP em vez de usar um pipeline de envio remoto.
Um recetor de produção deve esperar falhas de rede e de aplicação.
Valide pelo menos:
Mantenha payloads malformados em um caminho de diagnóstico controlado sem permitir que bloqueiem dispositivos válidos.
Não assuma que cada intervalo produz exatamente um registo armazenado permanentemente. Interrupções de rede, comportamento de reconexão, retentativas do servidor ou processamento da aplicação podem produzir eventos de ingestão ausentes ou repetidos.
Defina como o sistema de negócio irá:
Monitore mais do que o processo web ou socket. Sinais úteis incluem:
Para um recetor voltado para a Internet:
Revise o comportamento atual do firmware MQTTS, TLS e HTTPS no guia de firmware e interface aberta antes de selecionar um design de segurança.
A versão original deste documento focava-se na configuração de firmware de medidor mais antigo. Estas capturas de tela são mantidas apenas para utilizadores que identificam uma instalação existente. Para novas integrações, use a WebUI atual e o firmware mais recente.
A documentação anterior do firmware também usava o método local de configuração /api/uploadinterval e descrevia um mínimo de seis segundos. O firmware atual expõe o intervalo na WebUI e suporta um mínimo documentado de 2 segundos.
Última atualização: 16 de julho de 2026
Medidor de energia Wi-Fi trifásico (WEM3080T)
Medidor de energia Wi-Fi monofásico (WEM3080)
Medidor de energia Wi-Fi trifásico (WEM3046T)
Medidor de energia Wi-Fi trifásico (WEM3050T)