Vastaanota IAMMETER-energiadataa omalla palvelimellasi

Vastaanota IAMMETER-energiadataa omalla palvelimellasi

IAMMETER Wi-Fi -energiamittarit voivat lähettää mittaustietoja suoraan asiakkaan hallitsemalle palvelimelle, MQTT-välittäjälle tai data-alustalle. Tämä antaa kehittäjille ja järjestelmäintegraattoreille mahdollisuuden rakentaa oman EMS-, BMS- tai IoT-palvelun, tietokannan tai seurantakoontinäytön ilman, että IAMMETER-Cloud toimii datan vastaanottajana.

Tämä opas lähestyy integraatiota vastaanottavan palvelimen näkökulmasta:

• testivastaanottimen käyttöönotto;
• ensimmäisen mittarin hyötykuorman sieppaus;
• mittarin ja mittauskanavien tunnistaminen;
• datan normalisointi ja tallennus;
• sisäänottovolyymin arviointi;
• vastaanottimen valmistelu tuotantokäyttöä varten.

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

Mittarin laiteohjelmiston ominaisuuksista ja osoitemuodoista käytä IAMMETERin paikallisen API:n ja avoimen liittymän opasta. Arkkitehtuurin valinnasta katso Rakenna oma energianseurantajärjestelmäsi.

1. Valitse vastaanottimen arkkitehtuuri

Mittari voi lähettää mittauksiaan useilla siirtotavoilla. Vastaanottojärjestelmän tulisi valita yksi ensisijainen sisäänottopolku.

Siirtotapa	Vastaanottimen osa	Hyvä lähtökohta
HTTP / HTTPS	Verkkopäätepiste	REST-taustajärjestelmät ja yksinkertaisin ensimmäinen integraatio
MQTT / MQTTS	MQTT-välittäjä ja tilaaja	Olemassa olevat IoT-alustat ja viestiputket
TCP / TLS	Socket-kuuntelija	Erilliset keräimet ja räätälöidyt protokollapalvelut

HTTP on yleensä helpoin tapa tarkastella ensimmäistä hyötykuormaa, koska virallinen testivastaanotin voidaan käynnistää pienellä Node.js-esimerkillä. MQTT on vahva valinta, kun välittäjä on jo osa järjestelmää. TCP/TLS tarjoaa matalamman tason socket-integraation, mutta vaatii enemmän suunnittelutyötä vastaanottimen puolelta.

Suojatut siirtotavat ja räätälöityjen porttien muodot on kuvattu nykyisessä laiteohjelmisto-oppaassa, eikä niitä toisteta tässä.

2. Pika-aloitus: vastaanota ensimmäinen hyötykuorma HTTP:n kautta

IAMMETER tarjoaa virallisen Node.js HTTP -vastaanotinesimerkin integraatiotestausta varten.

2.1 Käynnistä testivastaanotin

Lataa esimerkki osoitteesta:

• IAMMETER HTTP Server Example on GitHub

Suorita:

node Server.js

Esimerkki kuuntelee porttia 8000. Kun pyyntö saapuu, se:

• kerää HTTP-pyynnön rungon;
• tulostaa pyynnön URL-osoitteen;
• tulostaa lähetetyn rungon;
• palauttaa HTTP-tilakoodin 200 ja pienen onnistumista ilmaisevan JSON-vastauksen.

Esimerkki on tarkoituksella minimaalinen. Se ei tarjoa todennusta, pysyväistallennusta, validointia, nopeusrajoitusta eikä tuotantotason tietoturvaa.

2.2 Tee vastaanottimesta tavoitettavissa

Ennen mittarin määrittämistä varmista, että:

• palvelin kuuntelee odotettua liitäntää ja porttia;
• palomuuri sallii yhteyden;
• mittari pystyy ratkaisemaan verkkotunnuksen, kun verkkotunnusta käytetään;
• NAT-, käänteisproxy- tai VPN-reitti toimii;
• lopullinen URL-osoite saavuttaa halutun sovellusreitin.

LAN-testissä mittari ja vastaanotin voivat käyttää samaa paikallista verkkoa ilman Internet-yhteyttä. Etävastaanottimen tapauksessa toimipisteessä on oltava reitti palvelimelle.

2.3 Kohdista mittari vastaanottimeen

Valitse nykyisessä mittarin WebUI:ssa HTTP-käyttötila ja syötä kohde, kuten:

{server-address}:8000/upload

HTTPS-päätepisteet voivat käyttää oletusporttia tai räätälöityä porttia. Nykyiset osoitesäännöt, mukaan lukien https://host:port, on dokumentoitu HTTP/HTTPS-laiteohjelmisto-osuudessa.

Asetuksen tallentamisen jälkeen tarkista vastaanottimen konsolista pyynnön polku ja lähetetty JSON. Säilytä ensimmäinen raakahyötykuorma testikiinnitteenä myöhempiä parsertestejä ja tietokantatestejä varten.

3. Ymmärrä saapuva IAMMETER-hyötykuorma

IAMMETER käyttää yhtenäistä ydinkoostumuksen JSON-rakennetta kaikissa tuetuissa lähetyssiirtotavoissa. Siirtotapa muuttaa sen, miten hyötykuorma saapuu, mutta mittausmalli pysyy yhtenäisenä.

Hyötykuorma sisältää tavallisesti laitetasoisia kenttiä, kuten:

• SN — mittarin sarjanumero, jolla laite tunnistetaan;
• version — mittarin laiteohjelmistoversio;
• method — viestin menetelmä tai hyötykuorman tyyppi;
• Data tai Datas — mittauslistat.

Data-kenttää käytetään yksikanavaisessa mittauksessa. Datas sisältää useita mittauslistoja monikanavaiselle tai kolmivaiheiselle mittarille.

Esimerkki yksikanavaisesta rakenteesta:

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

Älä kovakoodaa yhtä taulukon pituutta kaikille mittareille. Kanavien määrä ja käytettävissä olevat kentät riippuvat mittarimallista ja käyttöön otetuista mittausominaisuuksista.

Käytä auktoritatiivista määritelmää parsertia toteuttaessasi:

• IAMMETER Energy Meter JSON Data Definition

3.1 Mallikohtainen käsittely

Pidä mallikohtainen käsittely erillään siirtotavan vastaanottimesta.

Esimerkiksi WEM3046T ja WEM3046TE mittaavat ulkoisen virtamuuntajan 5 A:n toisiovirtaa. Niiden arvot on muunnettava sovellettavalla CT-suhteella, jotta saadaan ensiöpuolen mittaus. Tämä on mittarin ja virtamuuntajan ominaisuus, ei HTTP-, MQTT- tai TCP-ero.

Käytännöllinen sisäänottoputki erottaa siis toisistaan:

1. siirtotavan dekoodauksen;
2. JSON-validoinnin;
3. mittarin ja kanavien tunnistamisen;
4. mallikohtaisen skaalauksen tai normalisoinnin;
5. tallennuksen ja liiketoimintalaskelmat.

4. Suunnittele sisäänoton tietomalli

Tallenna riittävästi tietoa alkuperäisen lukeman toistamista ja vianmääritystä varten.

Hyödyllinen vähimmäismalli sisältää:

Kenttä	Tarkoitus
Mittarin SN	Yhdistää hyötykuorman rekisteröityyn laitteeseen
Kanava- tai vaiheindeksi	Erottaa yksivaiheisen, kaksivaiheisen ja kolmivaiheisen datan
Palvelimen vastaanottoaika	Tarjoaa yhtenäisen sisäänoton aikaleiman
Jännite	Sähköinen mittaus
Virta	Sähköinen mittaus
Pätöteho	Reaaliaikaisen tuonti-/vientilaskennan tai kuormituslaskennan syöte
TuontikWh	Kumulatiivinen tuotu energia
VientikWh	Kumulatiivinen viety energia
Laiteohjelmistoversio	Tukee vianmääritystä ja parsertin yhteensopivuutta
Raakahyötykuorma	Mahdollistaa toiston, auditoinnin ja parsertin korjauksen

Lisäkentät, kuten taajuus, tehokerroin ja loistehomittaukset, tulisi tallentaa, kun valittu malli ja konfiguraatio tarjoavat ne.

4.1 Pidä raaka- ja normalisoitu data erillään

Tuotantojärjestelmissä harkitse seuraavien säilyttämistä:

• muuttumaton tai lyhyen säilytysajan raaka-sisäänottotietue;
• normalisoidut kanavatason lukemat, joita sovellus käyttää;
• aggregoidut tunti-, päivä- ja kuukausiarvot.

Tämä helpottaa parsinta- tai CT-suhdelogiikan korjaamista menettämättä alkuperäistä hyötykuormaa.

4.2 Käytä palvelimen vastaanottoaikaa huolellisesti

Kirjaa aika, jolloin palvelin vastaanotti hyötykuorman. Jos liiketoimintajärjestelmä käyttää myös laitteen tai lähteen aikaleimaa, tallenna molemmat arvot erikseen sen sijaan, että korvaisit toisen toisella.

Verkkoviive, uudelleenyhteydet ja jonotettu käsittely voivat tehdä sisäänottoajasta erilaisen kuin mittausajasta. Määrittele kaavioissa, laskutuksessa ja hälytyksissä käytettävä aikaleima ennen tuotantokäyttöönottoa.

5. Toteuta muut vastaanotintyypit

5.1 MQTT- tai MQTTS-vastaanotin

MQTT-sisäänottoa varten asiakasjärjestelmä tarjoaa:

• tavoitettavissa olevan MQTT-välittäjän;
• todennus- ja pääsynhallintasäännöt;
• tilaaja- tai kuluttajapalvelun;
• hyötykuorman validoinnin ja pysyväistallennuksen;
• välittäjän ja kuluttajan kunnon seurannan.

IAMMETER julkaisee reaaliaikaista dataa laitekohtaisessa topicissa, kuten:

device/{SN}/realtime

Käytä erillistä opasta välittäjän konfigurointiin, tunnuksiin, topiceihin ja MQTTS-näkökohtiin:

• Publish IAMMETER Data to Your MQTT Broker

Home Assistant MQTT Discovery -toimintoa ei vaadita yleisessä asiakaspalvelinintegraatiossa.

5.2 TCP-vastaanotin

IAMMETER tarjoaa minimaalisen Node.js TCP -kuuntelijan:

• IAMMETER TCP Server Example on GitHub

Esimerkki kuuntelee porttia 8000 ja tulostaa vastaanotetun datan. Tuotantotason TCP-vastaanottimen on lisäksi tarjottava:

• yhteyksien elinkaaren hallinta;
• hyötykuorman puskurointi ja validointi;
• osittaisten tai yhdistettyjen socket-palojen turvallinen käsittely;
• laitteen tunnistaminen;
• pysyväistallennus ja virheiden käsittely;
• seuranta ja hallitut resurssirajoitukset.

Älä oleta, että yksi socketin data-tapahtuma vastaa aina yhtä täydellistä sovellusviestiä.

5.3 TLS-vastaanotin

Virallinen TLS-esimerkki esittelee TLS-kuuntelijan palvelinavaimella ja -sertifikaatilla:

• IAMMETER TLS Server Example on GitHub

Ennen tuotantokäyttöä korvaa esittelysertifikaatit ja -asetukset organisaation hyväksymällä sertifikaatti-, avaintenhallinta- ja tietoturvakonfiguraatiolla. Vastaanottimen tulisi kirjata TLS-virheet erikseen hyötykuorman validointivirheistä.

Mittarin TCP- ja TLS-osoitemuodot on kuvattu laiteohjelmiston liittymäoppaassa.

6. Suunnittele lähetysväli ja palvelinkapasiteetti

Nykyinen laiteohjelmisto tukee kolmannen osapuolen lähetysväliä aina 2 sekuntiin asti. Lyhyt väli on hyödyllinen vain, kun vastaanottojärjestelmä, tallennus ja sovellus tarvitsevat lisätarkkuutta.

Arvioidut tietuemäärät mittaria kohti:

Lähetysväli	Tietuetta mittaria kohti päivässä	100 mittaria päivässä	1,000 mittaria päivässä
60 sekuntia	1,440	144,000	1,440,000
10 sekuntia	8,640	864,000	8,640,000
2 sekuntia	43,200	4,320,000	43,200,000

Nämä luvut kuvaavat lähetystapahtumia, eivät välttämättä tietokantarivejä. Kolmivaiheinen hyötykuorma voidaan normalisoida useiksi kanavatietueiksi, ja indeksit, raakahyötykuorman säilytys tai replikoitu tallennus kasvattavat varsinaista tietokantavolyymiä.

Kapasiteettisuunnittelun tulisi sisältää:

• huippuyhtäaikaisten yhteyksien määrä;
• pyynnöt tai viestit sekunnissa;
• JSON-parsinnan kustannus;
• kanavatason rivien moninkertaistuminen;
• tietokanta-indeksit ja säilytys;
• koontinäytöt ja aggregointikyselyt;
• lokit, uudelleenyritykset ja dead-letter-tallennus;
• varmuuskopioinnin ja replikoinnin liikenne.

Yhden sekunnin ohjaukseen tai automaatioon samassa lähiverkossa harkitse Modbus TCP -käyttöä etälähetysputken sijaan.

7. Käsittele luotettavuus ja datan laatu

Tuotantovastaanottimen tulisi varautua verkko- ja sovellusvirheisiin.

7.1 Validoi jokainen hyötykuorma

Validoi vähintään:

• JSON-syntaksi;
• pakolliset tunnistekentät;
• odotettu taulukkorakenne;
• numeeriset tyypit ja järkevät alueet;
• tuettu malli- tai kanavakartoitus;
• laiteohjelmistosta riippuvat kenttävaihtelut.

Pidä virheelliset hyötykuormat hallitussa diagnostiikkapolussa, jotta ne eivät estä toimivia laitteita.

7.2 Varaudu päällekkäisiin ja puuttuviin lähetyksiin

Älä oleta, että jokainen väli tuottaa täsmälleen yhden pysyvästi tallennetun tietueen. Verkkokatkokset, uudelleenyhdistämiskäyttäytyminen, palvelimen uudelleenyritykset tai sovelluksen käsittely voivat aiheuttaa puuttuvia tai toistuvia sisäänottotapahtumia.

Määrittele, miten liiketoimintajärjestelmä:

• tunnistaa päällekkäiset tietueet;
• tunnistaa aukot;
• erottaa hiljaisen mittarin viallisesta vastaanottimesta;
• välttää energian laskemisen summaamalla sokeasti kumulatiivisia kWh-rekistereitä;
• täsmäyttää kumulatiivisen energian katkoksen jälkeen.

7.3 Seuraa koko datapolkua

Seuraa muutakin kuin verkko- tai socket-prosessia. Hyödyllisiä signaaleja ovat:

• viimeisen hyötykuorman aika mittaria kohti;
• virheellisten hyötykuormien määrä;
• vastaanottimen vasteaika ja virhesuhde;
• aktiiviset TCP/TLS-yhteydet;
• MQTT-kuluttajan viive;
• tietokannan kirjoitusviive;
• jonon syvyys;
• levytilan käyttö ja säilytysajot.

8. Suojaa vastaanottojärjestelmä

Internetiin avoimelle vastaanottimelle:

• suosi salattua siirtotapaa, jota käyttöönotto tukee;
• rajoita avoimia portteja ja verkkolähteitä, kun mahdollista;
• käytä MQTT-todennusta ja topic-valtuutusta;
• suojaa HTTP-päätepisteet ympäröivällä verkko- tai sovellustietoturva-arkkitehtuurilla;
• hallinnoi TLS-sertifikaatteja ja yksityisavaimia turvallisesti;
• vältä tunnusten tai täydellisten arkaluonteisten hyötykuormien kirjoittamista sovelluslokeihin;
• rajoita nopeutta ja eristä virheellinen tai väärinkäyttävä liikenne;
• pidä käyttöjärjestelmä, ajonaikainen ympäristö ja riippuvuudet ajan tasalla.

Tarkista nykyinen MQTTS-, TLS- ja HTTPS-laiteohjelmistokäyttäytyminen laiteohjelmisto- ja avoimen liittymän oppaasta ennen tietoturvaratkaisun valintaa.

9. Tuotantokäyttöönoton tarkistuslista

Mittari ja verkko

• Laiteohjelmistoversio kirjattu ja validoitu
• Mittarin SN yhdistetty oikeaan sijaintiin ja kanaviin
• Kohdeosoite ja -portti varmistettu
• DNS-, palomuuri-, NAT- tai VPN-reitti testattu
• Vaadittu lähetysväli vahvistettu

Vastaanotin

• Raakahyötykuorma siepattu jokaisesta soveltuvasta mittarimallista
• Parsertitestit luotu oikeista hyötykuormakiinnitteistä
• Yksi- ja monikanavaiset hyötykuormat käsitelty
• WEM3046T/E CT-suhdekäsittely validoitu tarvittaessa
• Virheelliset ja tukemattomat hyötykuormat eristetty turvallisesti
• Vastaanotin palauttaa tai ylläpitää valitun siirtotavan odottaman käyttäytymisen

Tallennus ja operatiivinen toiminta

• Aikaleimakäytäntö dokumentoitu
• Päällekkäis- ja puuttuvatietokäytäntö dokumentoitu
• Tietokantakapasiteetti laskettu laitemäärän ja lähetysvälin mukaan
• Lokit, mittarit ja mittarikohtaiset viimeksi-nähty-hälytykset käytössä
• Säilytys, varmuuskopiointi ja palautus testattu
• Sertifikaatit, tunnukset ja pääsytietosäännöt tarkistettu
• Verkkokatkos ja vastaanottimen uudelleenkäynnistys testattu

10. Liittyvät dokumentit

• Rakenna oma energianseurantajärjestelmäsi
• IAMMETERin käyttö ilman Internetiä tai IAMMETER-Cloudia
• IAMMETERin paikalliset API:t ja avoimet liittymät
• MQTT-energiamittarin integraatio
• IAMMETER-mittauksen JSON-määritelmä
• Self-hosted- ja avoimen lähdekoodin integraation yleiskatsaus

11. Vanhan mittarin konfigurointikuvakaappaukset

Tämän dokumentin alkuperäinen versio keskittyi vanhemman mittarin laiteohjelmiston konfigurointiin. Nämä kuvakaappaukset on säilytetty vain käyttäjiä varten, jotka tunnistavat olemassa olevan asennuksen. Uusissa integraatioissa käytä nykyistä WebUI:ta ja uusinta laiteohjelmistoa.

Vanha TCP-sivu

Vanha TLS-sivu

Vanha HTTP/HTTPS-sivu

Aiempi laiteohjelmistodokumentaatio käytti myös paikallista /api/uploadinterval-konfigurointimenetelmää ja kuvasi kuuden sekunnin minimin. Nykyinen laiteohjelmisto näyttää lähetysvälin WebUI:ssa ja tukee dokumentoitua 2 sekunnin minimiä.

Päivitetty viimeksi: 16. heinäkuuta 2026