Primiți datele de energie IAMMETER pe propriul dumneavoastră server

Primiți datele de energie IAMMETER pe propriul dumneavoastră server

Contoarele de energie Wi-Fi IAMMETER pot trimite datele de măsurare direct către un server, un broker MQTT sau o platformă de date controlată de client. Acest lucru le permite dezvoltatorilor și integratorilor de sisteme să își construiască propriul EMS, BMS, serviciu IoT, bază de date sau tablou de bord de monitorizare, fără a folosi IAMMETER-Cloud ca destinație a datelor.

Acest ghid abordează integrarea din perspectiva serverului receptor:

• porniți un receptor de test;
• capturați primul pachet de date al contorului;
• identificați contorul și canalele de măsurare;
• normalizați și stocați datele;
• estimați volumul de date primite;
• pregătiți receptorul pentru implementarea în producție.

IAMMETER meter
      │
      │ HTTP/HTTPS, MQTT/MQTTS or TCP/TLS
      ▼
Customer ingestion service
      │
      ├── Raw-payload log
      ├── Time-series or relational database
      ├── EMS / BMS / ERP
      └── Dashboard, report and alarm services

Pentru capacitățile firmware-ului din partea contorului și pentru formatele de adrese, consultați Ghidul API Local și Interfețe Deschise IAMMETER. Pentru alegerea arhitecturii, vedeți Dezvoltați propriul sistem de monitorizare a energiei.

1. Selectați o arhitectură pentru receptor

Contorul poate trimite măsurătorile sale folosind mai multe transporturi. Sistemul receptor ar trebui să selecteze o singură cale principală de ingerare a datelor.

Transport	Componentă receptor	Bun punct de plecare pentru
HTTP / HTTPS	Endpoint web	Backend-uri REST și cea mai simplă primă integrare
MQTT / MQTTS	Broker MQTT și abonat	Platforme IoT existente și fluxuri de mesaje
TCP / TLS	Ascultător socket	Colectoare dedicate și servicii cu protocol personalizat

HTTP este, de obicei, cea mai ușoară modalitate de a inspecta primul pachet de date, deoarece receptorul oficial de test poate fi pornit cu un mic exemplu Node.js. MQTT este o alegere bună atunci când un broker face deja parte din sistem. TCP/TLS oferă o integrare socket la nivel inferior, dar necesită mai multă muncă de inginerie în partea receptorului.

Transporturile securizate și formatele cu port personalizat sunt documentate în ghidul actual al firmware-ului, nu repetate aici.

2. Pornire rapidă: primiți primul pachet de date prin HTTP

IAMMETER oferă un exemplu oficial de receptor HTTP în Node.js pentru testarea integrării.

2.1 Porniți receptorul de test

Descărcați exemplul de la:

• Exemplu de server HTTP IAMMETER pe GitHub

Rulați:

node Server.js

Exemplul ascultă pe portul 8000. Când sosește o cerere, acesta:

• colectează corpul cererii HTTP;
• afișează URL-ul cererii;
• afișează corpul încărcat;
• returnează statusul HTTP 200 cu un mic răspuns JSON de succes.

Exemplul este în mod deliberat minimal. Nu oferă autentificare, persistență, validare, limitare a ratei sau securitate de producție.

2.2 Faceți receptorul accesibil

Înainte de a configura contorul, confirmați că:

• serverul ascultă pe interfața și portul așteptate;
• firewall-ul permite conexiunea;
• contorul poate rezolva numele de domeniu atunci când este folosit un domeniu;
• orice traseu NAT, proxy invers sau VPN funcționează;
• URL-ul final ajunge la ruta de aplicație dorită.

Pentru un test în LAN, contorul și receptorul pot folosi aceeași rețea locală, fără acces la Internet. Pentru un receptor la distanță, locația trebuie să aibă o rută către server.

2.3 Direcționați contorul către receptor

În WebUI-ul actual al contorului, selectați modul de funcționare HTTP și introduceți o destinație precum:

{server-address}:8000/upload

Endpoint-urile HTTPS pot folosi portul implicit sau un port personalizat. Regulile actuale de adrese, inclusiv https://host:port, sunt documentate în secțiunea HTTP/HTTPS a firmware-ului.

După salvarea setării, verificați consola receptorului pentru traseul cererii și JSON-ul încărcat. Păstrați acest prim pachet de date brut ca fișier de test pentru viitoarele teste ale parserului și ale bazei de date.

3. Înțelegeți pachetul de date IAMMETER primit

IAMMETER folosește o structură JSON de măsurare de bază, consistentă, pentru toate transporturile push acceptate. Transportul schimbă modul în care ajunge pachetul de date, dar modelul de măsurare rămâne consistent.

Un pachet de date include, în mod normal, câmpuri la nivel de dispozitiv, cum ar fi:

• SN — numărul de serie al contorului, folosit pentru identificarea dispozitivului;
• version — versiunea firmware-ului contorului;
• method — metoda mesajului sau tipul pachetului de date;
• Data sau Datas — tablouri de măsurători.

Data este folosit pentru un singur canal de măsurare. Datas conține mai multe tablouri de măsurători pentru un contor multi-canal sau trifazat.

Exemplu de structură cu un singur canal:

{
  "method": "uploadsn",
  "mac": "B0F8932A295C",
  "version": "i.75.98.71y",
  "server": "em",
  "SN": "12345678",
  "Data": [228.91, 1.61, 225, 15066.47, 0]
}

Nu codificați fix un singur număr de elemente de tablou pentru toate contoarele. Numărul de canale și de câmpuri disponibile depinde de modelul contorului și de funcțiile de măsurare activate.

Folosiți definiția autoritară atunci când implementați parserul:

• Definiția datelor JSON ale contorului de energie IAMMETER

3.1 Procesare specifică modelului

Păstrați procesarea specifică modelului separată de receptorul de transport.

De exemplu, WEM3046T și WEM3046TE măsoară ieșirea secundară de 5 A a unui transformator de curent extern. Valorile lor trebuie convertite cu raportul CT aplicabil pentru a obține măsurarea din partea primară. Aceasta este o caracteristică a contorului și a CT, nu o diferență HTTP, MQTT sau TCP.

Un flux practic de ingerare a datelor separă, prin urmare:

1. decodarea transportului;
2. validarea JSON;
3. identificarea contorului și a canalelor;
4. scalarea sau normalizarea specifică modelului;
5. stocarea și calculele de business.

4. Proiectați modelul de date pentru ingerare

Stocați suficiente informații pentru a reproduce și diagnostica citirea inițială.

Un model minim util include:

Câmp	Scop
Meter SN	Asociază pachetul de date cu un dispozitiv înregistrat
Channel or phase index	Distinge datele monofazate, bifazate și trifazate
Server receive time	Oferă un timestamp consistent pentru ingerare
Voltage	Măsurătoare electrică
Current	Măsurătoare electrică
Active power	Intrare în timp real pentru import/export sau calculul sarcinii
Import kWh	Energie importată cumulativă
Export kWh	Energie exportată cumulativă
Firmware version	Sprijină depanarea și compatibilitatea parserului
Raw payload	Permite redarea, auditul și corectarea parserului

Câmpuri suplimentare, cum ar fi frecvența, factorul de putere și măsurătorile de putere reactivă, ar trebui stocate atunci când modelul și configurația selectate le furnizează.

4.1 Păstrați datele brute separate de cele normalizate

Pentru sistemele de producție, luați în considerare păstrarea:

• unei înregistrări brute de ingerare, imutabile sau cu retenție scurtă;
• citirilor normalizate la nivel de canal, folosite de aplicație;
• valorilor agregate orare, zilnice și lunare.

Acest lucru face mai ușoară corectarea logicii de parsare sau a raportului CT, fără a pierde pachetul de date original.

4.2 Folosiți cu atenție timpul de recepție al serverului

Înregistrați momentul în care serverul a acceptat pachetul de date. Dacă sistemul de business folosește și un timestamp al dispozitivului sau al sursei, stocați ambele valori separat, mai degrabă decât să le înlocuiți una cu cealaltă.

Întârzierile de rețea, reconectările și procesarea în coadă pot face ca timpul de ingerare să difere de timpul de măsurare. Definiți timestamp-ul folosit de grafice, facturare și alarme înainte de implementarea în producție.

5. Implementați celelalte tipuri de receptoare

5.1 Receptor MQTT sau MQTTS

Pentru ingerarea prin MQTT, sistemul clientului furnizează:

• un broker MQTT accesibil;
• reguli de autentificare și control al accesului;
• un serviciu de abonare (subscriber) sau de consum;
• validarea și persistența pachetelor de date;
• monitorizarea stării de sănătate a brokerului și a consumatorului.

IAMMETER publică date în timp real sub un topic de dispozitiv, cum ar fi:

device/{SN}/realtime

Folosiți ghidul dedicat pentru configurarea brokerului, credențiale, topicuri și considerente MQTTS:

• Publicați datele IAMMETER pe brokerul dvs. MQTT

Home Assistant MQTT Discovery nu este necesar pentru o integrare generală client-server.

5.2 Receptor TCP

IAMMETER oferă un ascultător TCP minimal în Node.js:

• Exemplu de server TCP IAMMETER pe GitHub

Exemplul ascultă pe portul 8000 și afișează datele primite. Un receptor TCP de producție trebuie să ofere în plus:

• gestionarea ciclului de viață al conexiunilor;
• memorarea în tampon și validarea pachetelor de date;
• gestionarea sigură a fragmentelor socket parțiale sau combinate;
• identificarea dispozitivelor;
• persistență și gestionarea erorilor;
• monitorizare și limite controlate ale resurselor.

Nu presupuneți că un singur eveniment data al socket-ului corespunde întotdeauna unui mesaj complet al aplicației.

5.3 Receptor TLS

Exemplul oficial TLS demonstrează un ascultător TLS cu o cheie de server și un certificat:

• Exemplu de server TLS IAMMETER pe GitHub

Înainte de utilizarea în producție, înlocuiți certificatele și setările demonstrative cu configurația de certificate, gestionare a cheilor și securitate aprobată a organizației. Receptorul ar trebui să înregistreze eșecurile TLS separat de eșecurile de validare a pachetelor de date.

Formatele de adrese din partea contorului pentru TCP și TLS sunt documentate în ghidul de interfață al firmware-ului.

6. Planificați intervalul de transmitere și capacitatea serverului

Firmware-ul actual acceptă un interval de transmitere către terți de până la 2 secunde. Un interval scurt este util doar atunci când sistemul receptor, stocarea și aplicația au nevoie de rezoluția suplimentară.

Număr aproximativ de înregistrări generate per contor:

Interval de transmitere	Înregistrări per contor pe zi	100 de contoare pe zi	1.000 de contoare pe zi
60 seconds	1,440	144,000	1,440,000
10 seconds	8,640	864,000	8,640,000
2 seconds	43,200	4,320,000	43,200,000

Aceste numere reprezintă evenimente de transmitere, nu neapărat rânduri de bază de date. Un pachet de date trifazat poate fi normalizat în mai multe înregistrări de canal, iar indexurile, retenția pachetelor brute sau stocarea replicată cresc volumul real al bazei de date.

Planificarea capacității ar trebui să includă:

• vârful conexiunilor concurente;
• cereri sau mesaje pe secundă;
• costul parsării JSON;
• multiplicarea rândurilor la nivel de canal;
• indexuri de bază de date și retenție;
• tablouri de bord și interogări de agregare;
• jurnale, reîncercări și stocare dead-letter;
• trafic de backup și replicare.

Pentru control sau automatizare la o secundă în același LAN, luați în considerare Modbus TCP în locul unui flux de transmitere la distanță.

7. Gestionați fiabilitatea și calitatea datelor

Un receptor de producție ar trebui să se aștepte la eșecuri de rețea și de aplicație.

7.1 Validați fiecare pachet de date

Validați cel puțin:

• sintaxa JSON;
• câmpurile obligatorii de identitate;
• structura așteptată a tablourilor;
• tipurile numerice și intervalele rezonabile;
• maparea acceptată a modelului sau a canalelor;
• variațiile de câmp dependente de firmware.

Păstrați pachetele de date malformate pe o cale de diagnosticare controlată, fără a le permite să blocheze dispozitivele valide.

7.2 Planificați pentru încărcări duplicate sau lipsă

Nu presupuneți că fiecare interval produce exact o înregistrare stocată permanent. Întreruperile de rețea, comportamentul de reconectare, reîncercările serverului sau procesarea aplicației pot produce evenimente de ingerare lipsă sau repetate.

Definiți modul în care sistemul de business va:

• detecta înregistrările duplicate;
• identifica lacunele;
• distinge un contor tăcut de un receptor defect;
• evita calcularea energiei prin însumarea oarbă a registrelor kWh cumulative;
• reconcilia energia cumulativă după o întrerupere.

7.3 Monitorizați întregul flux de date

Monitorizați mai mult decât procesul web sau socket. Semnale utile includ:

• ora ultimului pachet de date per contor;
• numărul de pachete de date invalide;
• timpul de răspuns și rata de erori a receptorului;
• conexiunile TCP/TLS active;
• întârzierea consumatorului MQTT;
• latența de scriere în baza de date;
• adâncimea cozii;
• utilizarea discului și joburile de retenție.

8. Securizați sistemul receptor

Pentru un receptor expus la Internet:

• preferați un transport criptat acceptat de implementare;
• restricționați porturile expuse și sursele de rețea acolo unde este posibil;
• aplicați autentificarea MQTT și autorizarea topicurilor;
• protejați endpoint-urile HTTP cu arhitectura de securitate a rețelei sau a aplicației;
• gestionați în siguranță certificatele TLS și cheile private;
• evitați scrierea credențialelor sau a pachetelor de date sensibile complete în jurnalele aplicației;
• limitați rata și izolați traficul malformat sau abuziv;
• mențineți sistemul de operare, runtime-ul și dependențele actualizate.

Revizuiți comportamentul actual al firmware-ului pentru MQTTS, TLS și HTTPS în ghidul firmware-ului și al interfețelor deschise înainte de a selecta un design de securitate.

9. Lista de verificare pentru implementarea în producție

Contor și rețea

• Versiunea firmware-ului înregistrată și validată
• SN-ul contorului mapat la locația și canalele corecte
• Adresa și portul de destinație verificate
• Traseul DNS, firewall, NAT sau VPN testat
• Intervalul de transmitere necesar confirmat

Receptor

• Pachetul brut de date capturat de la fiecare model de contor din domeniul de aplicare
• Teste de parser create din pachete de date reale
• Pachete de date cu un singur canal și multi-canal gestionate
• Procesarea raportului CT pentru WEM3046T/E validată acolo unde este cazul
• Pachetele de date malformate și neacceptate izolate în siguranță
• Receptorul returnează sau menține comportamentul așteptat de transportul selectat

Stocare și operațiuni

• Politica de timestamp documentată
• Politica pentru date duplicate și lipsă documentată
• Capacitatea bazei de date calculată pentru numărul de dispozitive și interval
• Jurnale, metrici și alerte „last seen" per contor activate
• Retenția, backup-ul și recuperarea testate
• Certificatele, credențialele și regulile de acces revizuite
• Întreruperea de rețea și repornirea receptorului testate

10. Documentație conexă

• Dezvoltați propriul sistem de monitorizare a energiei
• Folosiți IAMMETER fără Internet sau IAMMETER-Cloud
• API-uri locale IAMMETER și interfețe deschise
• Integrarea contorului de energie prin MQTT
• Definiția JSON a măsurătorilor IAMMETER
• Prezentare generală a integrării self-hosted și open-source

11. Capturi de ecran vechi pentru configurarea contorului

Versiunea originală a acestui document se concentra pe configurarea firmware-ului mai vechi al contorului. Aceste capturi de ecran sunt păstrate doar pentru utilizatorii care identifică o instalație existentă. Pentru integrări noi, folosiți WebUI-ul actual și cel mai recent firmware.

Pagina TCP veche

Pagina TLS veche

Pagina HTTP/HTTPS veche

Documentația anterioară a firmware-ului folosea și metoda locală de configurare /api/uploadinterval și descria un minim de șase secunde. Firmware-ul actual expune intervalul în WebUI și acceptă un minim documentat de 2 secunde.

Ultima actualizare: 16 iulie 2026