Els comptadors Wi-Fi d'IAMMETER poden enviar les dades de mesura directament a un servidor, un broker MQTT o una plataforma de dades controlada pel client. Això permet als desenvolupadors i integradors de sistemes crear el seu propi EMS, BMS, servei IoT, base de dades o panell de control sense fer servir IAMMETER-Cloud com a destí de les dades.
Aquesta guia aborda la integració des del costat del servidor receptor:
Comptador IAMMETER
│
│ HTTP/HTTPS, MQTT/MQTTS o TCP/TLS
▼
Servei d'ingestió del client
│
├── Registre de payloads en brut
├── Base de dades de sèries temporals o relacional
├── EMS / BMS / ERP
└── Panell de control, informes i serveis d'alarmes
Per a les capacitats del firmware del comptador i els formats d'adreça, consulteu la Guia d'API local i interfície oberta d'IAMMETER. Per a la selecció d'arquitectura, vegeu Desenvolupeu el vostre propi sistema de monitoratge energètic.
El comptador pot enviar les seves mesures mitjançant diversos transports. El sistema receptor hauria de seleccionar una via d'ingestió principal.
| Transport | Component receptor | Bon punt de partida per a |
|---|---|---|
| HTTP / HTTPS | Punt final web | Backends REST i la primera integració més senzilla |
| MQTT / MQTTS | Broker MQTT i subscriptor | Plataformes IoT existents i pipelines de missatges |
| TCP / TLS | Listener de sockets | Col·lectors dedicats i serveis de protocol personalitzats |
HTTP és normalment la manera més fàcil d'inspeccionar el primer payload, perquè el receptor de prova oficial es pot iniciar amb un petit exemple de Node.js. MQTT és una opció sòlida quan el broker ja forma part del sistema. TCP/TLS ofereix una integració de sockets de més baix nivell, però requereix més enginyeria al costat del receptor.
Els transports segurs i els formats de port personalitzats es mantenen a la guia de firmware actual, en lloc de repetir-los aquí.
IAMMETER proporciona un exemple oficial de receptor HTTP en Node.js per a proves d'integració.
Descarregueu l'exemple de:
Executeu:
node Server.js
L'exemple escolta al port 8000. Quan arriba una petició:
200 amb una petita resposta JSON d'èxit.L'exemple és deliberadament mínim. No ofereix autenticació, persistència, validació, limitació de velocitat ni seguretat de producció.
Abans de configurar el comptador, confirmeu que:
Per a una prova en LAN, el comptador i el receptor poden utilitzar la mateixa xarxa local sense accés a Internet. Per a un receptor remot, el lloc ha de tenir una ruta cap al servidor.
A la WebUI actual del comptador, seleccioneu el mode d'execució HTTP i introduïu una destinació com ara:
{server-address}:8000/upload
Els punts finals HTTPS poden utilitzar el port per defecte o un port personalitzat. Les regles d'adreça actuals, inclòs https://host:port, estan documentades a la secció de firmware HTTP/HTTPS.
Després de desar la configuració, comproveu a la consola del receptor la ruta de la petició i el JSON carregat. Conserveu aquest primer payload en brut com a fixture de prova per a proves posteriors del parser i de la base de dades.
IAMMETER utilitza una estructura JSON de mesura central coherent en tots els transports de pujada suportats. El transport canvia la manera com arriba el payload, però el model de mesura es manté coherent.
Un payload normalment inclou camps a nivell de dispositiu com ara:
SN — número de sèrie del comptador, utilitzat per identificar el dispositiu;version — versió del firmware del comptador;method — mètode del missatge o tipus de payload;Data o Datas — matrius de mesures.Data s'utilitza per a un sol canal de mesura. Datas conté múltiples matrius de mesures per a un comptador multicanal o trifàsic.
Exemple d'estructura d'un sol canal:
{
"method": "uploadsn",
"mac": "B0F8932A295C",
"version": "i.75.98.71y",
"server": "em",
"SN": "12345678",
"Data": [228.91, 1.61, 225, 15066.47, 0]
}
No codifiqueu de manera fixa un únic comptador de matriu per a tots els comptadors. El nombre de canals i els camps disponibles depenen del model de comptador i de les funcions de mesura activades.
Utilitzeu la definició autoritzada a l'hora d'implementar el parser:
Mantingueu el processament específic del model separat del receptor de transport.
Per exemple, el WEM3046T i el WEM3046TE mesuren la sortida secundària de 5 A d'un transformador de corrent extern. Els seus valors s'han de convertir amb la relació CT aplicable per obtenir la mesura del costat primari. Això és una característica del comptador i del CT, no una diferència entre HTTP, MQTT o TCP.
Un pipeline d'ingestió pràctic, per tant, separa:
Emmagatzemeu prou informació per reproduir i diagnosticar la lectura original.
Un model mínim útil inclou:
| Camp | Finalitat |
|---|---|
| SN del comptador | Assigna el payload a un dispositiu registrat |
| Índex de canal o fase | Diferencia les dades monofàsiques, bifàsiques i trifàsiques |
| Hora de recepció del servidor | Proporciona una marca de temps d'ingestió coherent |
| Tensió | Mesura elèctrica |
| Corrent | Mesura elèctrica |
| Potència activa | Entrada per al càlcul de càrrega o importació/exportació en temps real |
| Import kWh | Energia importada acumulada |
| Export kWh | Energia exportada acumulada |
| Versió del firmware | Dona suport a la resolució de problemes i a la compatibilitat del parser |
| Payload en brut | Permet la repetició, l'auditoria i la correcció del parser |
Camps addicionals com la freqüència, el factor de potència i les mesures reactives s'han d'emmagatzemar quan el model i la configuració seleccionats els proporcionin.
Per a sistemes de producció, considereu mantenir:
Això facilita la correcció de la lògica d'anàlisi o de relació CT sense perdre el payload original.
Enregistreu l'hora en què el servidor va acceptar el payload. Si el sistema de negoci també utilitza una marca de temps del dispositiu o de la font, emmagatzemeu tots dos valors per separat en lloc de substituir-ne un per l'altre.
El retard de xarxa, les reconnexions i el processament en cua poden fer que el temps d'ingestió difereixi del temps de mesura. Definiu la marca de temps utilitzada pels gràfics, la facturació i les alarmes abans del desplegament en producció.
Per a la ingesta MQTT, el sistema del client proporciona:
IAMMETER publica dades en temps real en un tema del dispositiu com ara:
device/{SN}/realtime
Utilitzeu la guia dedicada per a la configuració del broker, les credencials, els temes i les consideracions MQTTS:
L'Home Assistant MQTT Discovery no és necessari per a una integració general client-servidor.
IAMMETER proporciona un listener TCP mínim en Node.js:
L'exemple escolta al port 8000 i imprimeix les dades rebudes. Un receptor TCP de producció ha de proporcionar a més:
No assumiu que un esdeveniment data d'un socket sempre equival a un missatge d'aplicació complet.
L'exemple TLS oficial demostra un listener TLS amb una clau de servidor i un certificat:
Abans de l'ús en producció, substituïu els certificats i paràmetres de demostració per la configuració de certificats, gestió de claus i seguretat aprovada per l'organització. El receptor ha de registrar els errors TLS per separat dels errors de validació del payload.
Els formats d'adreça del costat del comptador per a TCP i TLS es mantenen a la guia d'interfície del firmware.
El firmware actual admet un interval de pujada a tercers de fins a 2 segons. Un interval curt només és útil quan el sistema receptor, l'emmagatzematge i l'aplicació necessiten la resolució addicional.
Registres aproximats generats per comptador:
| Interval de pujada | Registres per comptador i dia | 100 comptadors al dia | 1.000 comptadors al dia |
|---|---|---|---|
| 60 segons | 1.440 | 144.000 | 1.440.000 |
| 10 segons | 8.640 | 864.000 | 8.640.000 |
| 2 segons | 43.200 | 4.320.000 | 43.200.000 |
Aquestes xifres representen esdeveniments de pujada, no necessàriament files de base de dades. Un payload trifàsic es pot normalitzar en diversos registres de canal, i els índexs, la retenció de payloads en brut o l'emmagatzematge replicat augmenten el volum real de la base de dades.
La planificació de la capacitat ha d'incloure:
Per a control o automatització d'un segon a la mateixa LAN, considereu Modbus TCP en lloc d'utilitzar un pipeline de pujada remot.
Un receptor de producció ha d'esperar errors de xarxa i d'aplicació.
Valideu com a mínim:
Conserveu els payloads mal formats en una via de diagnòstic controlada sense permetre que bloquegin dispositius vàlids.
No assumiu que cada interval produeix exactament un registre emmagatzemat permanentment. Les interrupcions de xarxa, el comportament de reconnexió, els reenviaments del servidor o el processament de l'aplicació poden produir esdeveniments d'ingestió absents o repetits.
Definiu com gestionarà el sistema de negoci:
Monitoritzeu més que el procés web o de sockets. Els senyals útils inclouen:
Per a un receptor exposat a Internet:
Reviseu el comportament actual del firmware MQTTS, TLS i HTTPS a la guia de firmware i interfície oberta abans de seleccionar un disseny de seguretat.
La versió original d'aquest document se centrava a configurar firmware més antic del comptador. Aquestes captures es conserven únicament per als usuaris que identifiquen una instal·lació existent. Per a noves integracions, utilitzeu la WebUI actual i el firmware més recent.
La documentació del firmware anterior també utilitzava el mètode local de configuració /api/uploadinterval i descrivia un mínim de sis segons. El firmware actual exposa l'interval a la WebUI i admet un mínim documentat de 2 segons.
Última actualització: 16 de juliol de 2026
Comptador d'energia Wi-Fi trifàsic (WEM3080T)
Comptador d'energia Wi-Fi monofàsic (WEM3080)
Comptador d'energia Wi-Fi trifàsic (WEM3046T)
Comptador d'energia Wi-Fi trifàsic (WEM3050T)