Atvainojiet, jūsu pārlūkprogramma neatbalsta JavaScript!
Pierakstīties

Saņemiet IAMMETER enerģijas datus savā serverī

Saņemiet IAMMETER enerģijas datus savā serverī

IAMMETER Wi-Fi enerģijas skaitītāji var nosūtīt mērījumu datus tieši uz serveri, MQTT brokeru vai datu platformu, ko kontrolē klients. Tas ļauj izstrādātājiem un sistēmu integratoriem izveidot savu EMS (enerģijas pārvaldības sistēmu), BMS (ēku pārvaldības sistēmu), IoT pakalpojumu, datubāzi vai uzraudzības paneli, neizmantojot IAMMETER-Cloud kā datu galamērķi.

Šī rokasgrāmata integrāciju aplūko no uztverošā servera puses:

  • izveidot testa uztvērēju;
  • notvert pirmo skaitītāja datu paketi;
  • identificēt skaitītāju un mērījumu kanālus;
  • normalizēt un glabāt datus;
  • novērtēt datu saņemšanas apjomu;
  • sagatavot uztvērēju ražošanas ieviešanai.
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

Lai uzzinātu par skaitītāja programmatūras iespējām un adrešu formātiem, izmantojiet IAMMETER vietējās API un atvērto saskarņu rokasgrāmatu. Arhitektūras izvēlei skatiet Izstrādājiet savu enerģijas uzraudzības sistēmu.

1. Izvēlieties uztvērēja arhitektūru

Skaitītājs var nosūtīt savus mērījumus, izmantojot vairākus transporta protokolus. Uztverošajai sistēmai jāizvēlas viens primārais datu saņemšanas ceļš.

Transporta protokols Uztvērēja komponents Labs sākumpunkts
HTTP / HTTPS Tīmekļa galapunkts REST aizmugursistēmām un vienkāršākajai pirmajai integrācijai
MQTT / MQTTS MQTT brokers un abonents Esošām IoT platformām un ziņojumu cauruļvadiem
TCP / TLS Ligzdas (socket) klausītājs Specializētiem datu vācējiem un pielāgotu protokolu pakalpojumiem

HTTP parasti ir vienkāršākais veids, kā aplūkot pirmo datu paketi, jo oficiālo testa uztvērēju var palaist ar nelielu Node.js piemēru. MQTT ir labs risinājums, ja brokeris jau ir daļa no sistēmas. TCP/TLS nodrošina zemāka līmeņa ligzdas integrāciju, bet prasa vairāk inženiertehnisko darbu uztvērēja pusē.

Drošie transporta protokoli un pielāgoto portu formāti ir aprakstīti pašreizējā programmatūras rokasgrāmatā, nevis atkārtoti šeit.

2. Ātrs starts: saņemiet pirmo datu paketi, izmantojot HTTP

IAMMETER nodrošina oficiālu Node.js HTTP uztvērēja piemēru integrācijas testēšanai.

2.1 Palaidiet testa uztvērēju

Lejupielādējiet piemēru no:

Palaidiet:

node Server.js

Piemērs klausās portā 8000. Kad pienāk pieprasījums, tas:

  • savāc HTTP pieprasījuma saturu;
  • izdrukā pieprasījuma URL;
  • izdrukā augšupielādēto saturu;
  • atgriež HTTP statusu 200 ar nelielu veiksmes JSON atbildi.

Piemērs ir apzināti minimāls. Tas nenodrošina autentifikāciju, datu saglabāšanu, validāciju, pieprasījumu skaita ierobežošanu vai ražošanas drošību.

2.2 Nodrošiniet uztvērēja sasniedzamību

Pirms skaitītāja konfigurēšanas pārliecinieties, ka:

  • serveris klausās paredzētajā saskarnē un portā;
  • ugunsmūris atļauj savienojumu;
  • skaitītājs var atrisināt domēna nosaukumu, ja tiek izmantots domēns;
  • darbojas NAT, reversais starpniekserveris vai VPN ceļš;
  • galīgais URL sasniedz paredzēto lietojumprogrammas maršrutu.

LAN testam skaitītājs un uztvērējs var izmantot vienu un to pašu lokālo tīklu bez interneta pieslēguma. Attālinātam uztvērējam objektam jābūt maršrutam līdz serverim.

2.3 Norādiet skaitītājam uz uztvērēju

Pašreizējā skaitītāja WebUI saskarnē atlasiet HTTP darbības režīmu un ievadiet galamērķi, piemēram:

{server-address}:8000/upload

Konfigurējiet uztverošo HTTP galapunktu pašreizējā IAMMETER WebUI saskarnē

HTTPS galapunkti var izmantot noklusējuma portu vai pielāgotu portu. Pašreizējie adrešu noteikumi, tostarp https://host:port, ir aprakstīti HTTP/HTTPS programmatūras sadaļā.

Pēc iestatījuma saglabāšanas pārbaudiet uztvērēja konsolē pieprasījuma ceļu un augšupielādēto JSON. Saglabājiet šo pirmo neapstrādāto datu paketi kā testa paraugu turpmākajiem parsētāja un datubāzes testiem.

3. Izprotiet ienākošo IAMMETER datu paketi

IAMMETER izmanto vienotu pamata mērījumu JSON struktūru visos atbalstītajos datu nosūtīšanas transporta protokolos. Transporta protokols maina to, kā datu pakete nonāk, bet mērījumu modelis paliek nemainīgs.

Datu pakete parasti ietver ierīces līmeņa laukus, piemēram:

  • SN — skaitītāja sērijas numurs, ko izmanto ierīces identificēšanai;
  • version — skaitītāja programmatūras versija;
  • method — ziņojuma metode vai datu paketes tips;
  • Data vai Datas — mērījumu masīvi.

Data tiek izmantots vienam mērījumu kanālam. Datas satur vairākus mērījumu masīvus daudzkanālu vai trīsfāžu skaitītājam.

Viena kanāla struktūras piemērs:

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

Nevajag ieprogrammēt vienu fiksētu masīva izmēru visiem skaitītājiem. Kanālu skaits un pieejamie lauki ir atkarīgi no skaitītāja modeļa un iespējotajām mērījumu funkcijām.

Ieviešot parsētāju, izmantojiet autoritatīvo definīciju:

3.1 Modeļa specifiska apstrāde

Turiet modeļa specifisko apstrādi atsevišķi no transporta uztvērēja.

Piemēram, WEM3046T un WEM3046TE mēra ārējā strāvas transformatora 5 A sekundāro izeju. To vērtības jāpārrēķina ar attiecīgo CT koeficientu, lai iegūtu primārās puses mērījumu. Tā ir skaitītāja un CT īpašība, nevis HTTP, MQTT vai TCP atšķirība.

Praktisks datu saņemšanas cauruļvads tāpēc nošķir:

  1. transporta dekodēšanu;
  2. JSON validāciju;
  3. skaitītāja un kanālu identificēšanu;
  4. modeļa specifisku mērogošanu vai normalizāciju;
  5. glabāšanu un biznesa aprēķinus.

4. Izstrādājiet datu saņemšanas datu modeli

Uzglabājiet pietiekami daudz informācijas, lai varētu reproducēt un diagnosticēt sākotnējo rādījumu.

Noderīgs minimālais modelis ietver:

Lauks Mērķis
Skaitītāja SN Saista datu paketi ar reģistrētu ierīci
Kanāla vai fāzes indekss Nošķir vienfāzes, divfāžu (split-phase) un trīsfāžu datus
Servera saņemšanas laiks Nodrošina konsekventu saņemšanas laikspiedolu
Spriegums Elektriskais mērījums
Strāva Elektriskais mērījums
Aktīvā jauda Reāllaika importa/eksporta vai slodzes aprēķina ievaddati
Importētā kWh Kumulatīvā importētā enerģija
Eksportētā kWh Kumulatīvā eksportētā enerģija
Programmatūras versija Atbalsta problēmu novēršanu un parsētāja saderību
Neapstrādātā datu pakete Ļauj atkārtoti atskaņot, auditēt un labot parsētāju

Papildu lauki, piemēram, frekvence, jaudas koeficients un reaktīvie mērījumi, jāuzglabā, ja izvēlētais modelis un konfigurācija tos nodrošina.

4.1 Turiet neapstrādātos un normalizētos datus atsevišķi

Ražošanas sistēmām apsveriet iespēju glabāt:

  • nemainīgu vai ar īsu glabāšanas laiku neapstrādātu saņemšanas ierakstu;
  • normalizētus kanālu līmeņa rādījumus, ko izmanto lietojumprogramma;
  • apkopotas stundas, dienas un mēneša vērtības.

Tas atvieglo parsēšanas vai CT koeficienta loģikas labošanu, nezaudējot sākotnējo datu paketi.

4.2 Rīkojieties piesardzīgi ar servera saņemšanas laiku

Ierakstiet laiku, kad serveris pieņēma datu paketi. Ja biznesa sistēma izmanto arī ierīces vai avota laikspiedolu, glabājiet abas vērtības atsevišķi, nevis aizstājiet vienu ar otru.

Tīkla aizkave, atkārtoti savienojumi un rindā gaidīta apstrāde var padarīt saņemšanas laiku atšķirīgu no mērījuma laika. Pirms ražošanas ieviešanas definējiet laikspiedolu, ko izmanto diagrammas, rēķini un trauksmes signāli.

5. Ieviesiet pārējos uztvērēja veidus

5.1 MQTT vai MQTTS uztvērējs

MQTT datu saņemšanai klienta sistēma nodrošina:

  • sasniedzamu MQTT brokeru;
  • autentifikācijas un piekļuves kontroles noteikumus;
  • abonenta vai patērētāja pakalpojumu;
  • datu paketes validāciju un saglabāšanu;
  • brokera un patērētāja veselības uzraudzību.

IAMMETER publicē reāllaika datus ierīces tēmā, piemēram:

device/{SN}/realtime

Brokera konfigurācijai, akreditācijas datiem, tēmām un MQTTS apsvērumiem izmantojiet īpašo rokasgrāmatu:

Vispārējai klienta-servera integrācijai Home Assistant MQTT Discovery nav nepieciešams.

5.2 TCP uztvērējs

IAMMETER nodrošina minimālu Node.js TCP klausītāju:

Piemērs klausās portā 8000 un izdrukā saņemtos datus. Ražošanas TCP uztvērējam papildus jānodrošina:

  • savienojumu dzīves cikla pārvaldība;
  • datu paketes buferizācija un validācija;
  • droša daļēju vai apvienotu ligzdas datu daļu apstrāde;
  • ierīces identificēšana;
  • datu saglabāšana un kļūdu apstrāde;
  • uzraudzība un kontrolēti resursu ierobežojumi.

Nepieņemiet, ka viens ligzdas data notikums vienmēr atbilst vienam pilnam lietojumprogrammas ziņojumam.

5.3 TLS uztvērējs

Oficiālais TLS piemērs demonstrē TLS klausītāju ar servera atslēgu un sertifikātu:

Pirms izmantošanas ražošanā aizstājiet demonstrācijas sertifikātus un iestatījumus ar organizācijas apstiprinātu sertifikātu, atslēgu pārvaldības un drošības konfigurāciju. Uztvērējam TLS kļūmes jāreģistrē atsevišķi no datu paketes validācijas kļūmēm.

Skaitītāja adrešu formāti TCP un TLS ir aprakstīti programmatūras saskarņu rokasgrāmatā.

6. Plānojiet augšupielādes intervālu un servera jaudu

Pašreizējā programmatūra atbalsta trešās puses augšupielādes intervālu līdz pat 2 sekundēm. Īss intervāls ir noderīgs tikai tad, ja uztverošajai sistēmai, glabātuvei un lietojumprogrammai ir nepieciešama papildu izšķirtspēja.

Aptuvenais ierakstu skaits, ko ģenerē viens skaitītājs:

Augšupielādes intervāls Ieraksti uz skaitītāju dienā 100 skaitītāju dienā 1 000 skaitītāju dienā
60 sekundes 1 440 144 000 1 440 000
10 sekundes 8 640 864 000 8 640 000
2 sekundes 43 200 4 320 000 43 200 000

Šie skaitļi atspoguļo augšupielādes notikumus, nevis obligāti datubāzes rindas. Trīsfāžu datu pakete var tikt normalizēta vairākos kanālu ierakstos, un indeksi, neapstrādāto datu paketes glabāšana vai replicēta glabātuve palielina faktisko datubāzes apjomu.

Jaudas plānošanā jāiekļauj:

  • maksimālo vienlaicīgo savienojumu skaitu;
  • pieprasījumus vai ziņojumus sekundē;
  • JSON parsēšanas izmaksas;
  • kanālu līmeņa rindu reizināšanu;
  • datubāzes indeksus un glabāšanas politiku;
  • informācijas paneļus un apkopošanas vaicājumus;
  • žurnālus, atkārtotus mēģinājumus un neapstrādātu kļūdu (dead-letter) glabātuvi;
  • dublēšanas un replikācijas datu plūsmu.

Vienas sekundes kontrolei vai automatizācijai tajā pašā LAN tīklā apsveriet Modbus TCP, nevis attālās augšupielādes cauruļvadu.

7. Nodrošiniet uzticamību un datu kvalitāti

Ražošanas uztvērējam jārēķinās ar tīkla un lietojumprogrammas kļūmēm.

7.1 Validējiet katru datu paketi

Validējiet vismaz:

  • JSON sintaksi;
  • obligātos identitātes laukus;
  • paredzēto masīva struktūru;
  • skaitliskos tipus un saprātīgus diapazonus;
  • atbalstīto modeļu vai kanālu kartējumu;
  • no programmatūras atkarīgās lauku variācijas.

Turiet bojātas datu paketes kontrolētā diagnostikas ceļā, neļaujot tām bloķēt derīgas ierīces.

7.2 Plānojiet dublētu un pazudušu augšupielāžu gadījumus

Nepieņemiet, ka katrs intervāls rada tieši vienu pastāvīgi glabātu ierakstu. Tīkla pārtraukumi, atkārtotas savienošanās darbība, servera atkārtoti mēģinājumi vai lietojumprogrammas apstrāde var radīt pazudušus vai atkārtotus saņemšanas notikumus.

Definējiet, kā biznesa sistēma:

  • atklās dublētus ierakstus;
  • identificēs nepilnības;
  • nošķirs klusu skaitītāju no bojāta uztvērēja;
  • izvairīsies no enerģijas aprēķināšanas, akli summējot kumulatīvos kWh reģistrus;
  • saskaņos kumulatīvo enerģiju pēc pārtraukuma.

7.3 Uzraugiet visu datu ceļu

Uzraugiet vairāk nekā tikai tīmekļa vai ligzdas procesu. Noderīgi signāli ietver:

  • pēdējās datu paketes laiku uz skaitītāju;
  • nederīgo datu paketes skaitu;
  • uztvērēja atbildes laiku un kļūdu īpatsvaru;
  • aktīvus TCP/TLS savienojumus;
  • MQTT patērētāja nobīdi;
  • datubāzes ierakstu latentumu;
  • rindas dziļumu;
  • diska izmantošanu un glabāšanas uzdevumus.

8. Nodrošiniet uztverošās sistēmas drošību

Interneta pieslēgtam uztvērējam:

  • dodiet priekšroku šifrētam transporta protokolam, ko atbalsta ieviešana;
  • ierobežojiet atvērtos portus un tīkla avotus, kur iespējams;
  • pielietojiet MQTT autentifikāciju un tēmu autorizāciju;
  • aizsargājiet HTTP galapunktus ar apkārtējo tīkla vai lietojumprogrammas drošības arhitektūru;
  • droši pārvaldiet TLS sertifikātus un privātās atslēgas;
  • neierakstiet akreditācijas datus vai pilnus sensitīvus datu paketes saturus lietojumprogrammu žurnālos;
  • ierobežojiet un izolējiet bojātu vai ļaunprātīgu satiksmi;
  • uzturiet atjauninātas operētājsistēmu, izpildes vidi un atkarības.

Pirms drošības risinājuma izvēles pārskatiet pašreizējo MQTTS, TLS un HTTPS programmatūras darbību programmatūras un atvērto saskarņu rokasgrāmatā.

9. Ražošanas ieviešanas pārbaudes saraksts

Skaitītājs un tīkls

  • Programmatūras versija ierakstīta un validēta
  • Skaitītāja SN saistīts ar pareizo objektu un kanāliem
  • Galamērķa adrese un ports pārbaudīti
  • DNS, ugunsmūra, NAT vai VPN ceļš testēts
  • Nepieciešamais augšupielādes intervāls apstiprināts

Uztvērējs

  • Neapstrādāta datu pakete notverta no katra darbības jomā esošā skaitītāja modeļa
  • Parsētāja testi izveidoti no reāliem datu paketes paraugiem
  • Apstrādātas viena un vairāku kanālu datu paketes
  • WEM3046T/E CT koeficienta apstrāde validēta, kur piemērojama
  • Bojātas un neatbalstītas datu paketes droši izolētas
  • Uztvērējs atgriež vai uztur izvēlētā transporta protokola paredzēto darbību

Glabātuve un darbība

  • Laikspiedola politika dokumentēta
  • Dublētu un pazudušu datu politika dokumentēta
  • Datubāzes jauda aprēķināta atbilstoši ierīču skaitam un intervālam
  • Žurnāli, metrika un trauksmes signāli par pēdējo redzēšanu uz skaitītāju iespējoti
  • Glabāšanas, dublēšanas un atkopšanas procesi testēti
  • Sertifikāti, akreditācijas dati un piekļuves noteikumi pārskatīti
  • Tīkla pārtraukums un uztvērēja restartēšana testēti

10. Saistītā dokumentācija

11. Vecās skaitītāja konfigurācijas ekrānuzņēmumi

Šī dokumenta sākotnējā versija bija vērsta uz vecākas skaitītāja programmatūras konfigurēšanu. Šie ekrānuzņēmumi ir saglabāti tikai lietotājiem, kuri identificē esošu instalāciju. Jaunām integrācijām izmantojiet pašreizējo WebUI un jaunāko programmatūru.

Vecā TCP lapa

Vecā IAMMETER TCP servera konfigurācija

Vecā TLS lapa

Vecā IAMMETER TLS servera konfigurācija

Vecā HTTP/HTTPS lapa

Vecā IAMMETER HTTP/HTTPS servera konfigurācija

Agrākā programmatūras dokumentācija izmantoja arī lokālo /api/uploadinterval konfigurācijas metodi un aprakstīja sešu sekunžu minimumu. Pašreizējā programmatūra parāda intervālu WebUI saskarnē un atbalsta dokumentētu minimumu — 2 sekundes.

Pēdējoreiz atjaunināts: 2026. gada 16. jūlijā

Uz augšu