Motta IAMMETER-energidata på din egen server

Motta IAMMETER-energidata på din egen server

IAMMETER Wi-Fi-energimålere kan sende måledata direkte til en server, MQTT-megler eller dataplattform som kunden kontrollerer. Dette lar utviklere og systemintegratorer bygge sitt eget EMS, BMS, IoT-tjeneste, database eller overvåkingsdashboard uten å bruke IAMMETER-Cloud som datadestinasjon.

Denne veiledningen går til integrasjonen fra mottakerserver-siden:

• sett opp en testmottaker;
• fange den første nyttelasten fra måleren;
• identifisere måleren og målekanalene;
• normalisere og lagre dataene;
• anslå inntaksvolumet;
• klargjøre mottakeren for produksjonsdistribusjon.

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

For målersidens fastvarefunksjoner og adresseformater, bruk IAMMETER Local API og Open Interface-veiledningen. For valg av arkitektur, se Utvikle ditt eget energiovervåkingssystem.

1. Velg mottakerarkitektur

Måleren kan sende målingene sine via flere transportprotokoller. Mottakersystemet bør velge én primær inntakskanal.

Transport	Mottakerkomponent	Godt utgangspunkt for
HTTP / HTTPS	Nettsluttsnitt (web endpoint)	REST-backender og den enkleste første integrasjonen
MQTT / MQTTS	MQTT-megler og abonnent	Eksisterende IoT-plattformer og meldingspipelines
TCP / TLS	Sokkellytter (socket listener)	Dedikerte samlere og tilpassede protokolltjenester

HTTP er normalt den enkleste måten å inspisere den første nyttelasten på, fordi den offisielle testmottakeren kan startes med et lite Node.js-eksempel. MQTT er et sterkt valg når en megler allerede er en del av systemet. TCP/TLS gir en integrasjon på lavere nivå via sokler, men krever mer ingeniørarbeid på mottakersiden.

De sikre transportene og formatene for egendefinerte porter vedlikeholdes i gjeldende fastvareveiledning, i stedet for å gjentas her.

2. Hurtigstart: Motta den første nyttelasten over HTTP

IAMMETER tilbyr et offisielt Node.js HTTP-mottakereksempel for integrasjonstesting.

2.1 Start testmottakeren

Last ned eksemplet fra:

• IAMMETER HTTP-servereksempel på GitHub

Kjør:

node Server.js

Eksemplet lytter på port 8000. Når en forespørsel kommer inn:

• samler inn HTTP-forespørselens body;
• skriver ut forespørsels-URL-en;
• skriver ut den opplastede body-en;
• returnerer HTTP-status 200 med et lite JSON-svar om vellykket mottak.

Eksemplet er bevisst minimalt. Det gir ikke autentisering, varig lagring, validering, rate-begrensning eller produksjonssikkerhet.

2.2 Gjør mottakeren tilgjengelig

Før du konfigurerer måleren, må du bekrefte:

• at serveren lytter på det forventede grensesnittet og porten;
• at brannmuren tillater tilkoblingen;
• at måleren kan løse domenenavnet når et domene brukes;
• at eventuell NAT-, omvendt proxy- eller VPN-vei fungerer;
• at den endelige URL-en når frem til den tiltenkte applikasjonsruten.

For en LAN-test kan måleren og mottakeren bruke samme lokale nettverk uten Internett-tilgang. For en ekstern mottaker må stedet ha en rute til serveren.

2.3 Pek måleren mot mottakeren

I målerens gjeldende WebUI velger du HTTP-kjøremodus og angir en destinasjon som:

{server-address}:8000/upload

HTTPS-endepunkter kan bruke standardporten eller en egendefinert port. Gjeldende adresseregler, inkludert https://host:port, er dokumentert i HTTP/HTTPS-fastvaredelen.

Etter at innstillingen er lagret, sjekker du mottakerkonsollen for forespørselsbanen og den opplastede JSON-en. Ta vare på denne første rånyttelasten som testfixture for senere parser- og databasetester.

3. Forstå den innkommende IAMMETER-nyttelasten

IAMMETER bruker en konsistent kjernestruktur for måle-JSON på tvers av de støttede push-transportene. Transporten endrer hvordan nyttelasten kommer frem, men målingsmodellen forblir konsistent.

En nyttelast inneholder normalt felt på enhetsnivå som:

• SN — målerens serienummer, brukt til å identifisere enheten;
• version — målerens fastvareversjon;
• method — meldingsmetoden eller nyttelasttypen;
• Data eller Datas — målingsmatriser.

Data brukes for en enkelt målekanal. Datas inneholder flere målingsmatriser for en flerkanals- eller trefasemåler.

Eksempel på enkeltkanalsstruktur:

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

Ikke hardkod ett enkelt matriseantall for alle målere. Antallet kanaler og tilgjengelige felt avhenger av målerens modell og aktiverte målefunksjoner.

Bruk den autoritative definisjonen når du implementerer parseren:

• IAMMETER-definisjon av energimåler-JSON-verdier

3.1 Modellspesifikk behandling

Hold modellspesifikk behandling atskilt fra transportmottakeren.

For eksempel måler WEM3046T og WEM3046TE 5 A-sekundærutgangen fra en ekstern strømtransformator. Verdiene må konverteres med gjeldende CT-forhold for å få målingen på primærsiden. Dette er en egenskap ved måleren og strømtransformatoren, ikke en forskjell mellom HTTP, MQTT eller TCP.

En praktisk inntakspipeline skiller derfor mellom:

1. transportavkoding;
2. JSON-validering;
3. identifisering av måler og kanal;
4. modellspesifikk skalering eller normalisering;
5. lagring og forretningsberegninger.

4. Utform inntaksdatamodellen

Lagre nok informasjon til å reprodusere og diagnostisere den opprinnelige avlesningen.

En nyttig minimal modell inkluderer:

Felt	Formål
Måler-SN	Knytter nyttelasten til en registrert enhet
Kanal- eller faseindeks	Skiller enkeltfase-, delt-fase- og trefase-data
Mottakstid på serveren	Gir et konsistent tidsstempel for inntak
Spenning	Elektrisk måling
Strøm	Elektrisk måling
Aktiv effekt	Sanntids import/eksport eller inndata til lastberegning
Import kWh	Kumulert importert energi
Eksport kWh	Kumulert eksportert energi
Fastvareversjon	Støtter feilsøking og parserkompatibilitet
Rånyttelast	Muliggjør avspilling, revisjon og parserkorrigering

Ytterligere felt som frekvens, effektfaktor og reaktive målinger bør lagres når den valgte modellen og konfigurasjonen leverer dem.

4.1 Hold rå og normaliserte data atskilt

For produksjonssystemer bør du vurdere å oppbevare:

• en uforanderlig eller kortvarig lagret råinntakslogg;
• normaliserte avlesninger på kanalnivå som applikasjonen bruker;
• aggregerte time-, døgn- og månedsverdier.

Dette gjør det enklere å korrigere parser- eller CT-forholdslogikk uten å miste den opprinnelige nyttelasten.

4.2 Bruk mottakstiden på serveren med omhu

Registrer tidspunktet da serveren godtok nyttelasten. Hvis forretningssystemet også bruker et tidsstempel fra enheten eller kilden, lagre begge verdiene hver for seg i stedet for å erstatte den ene med den andre.

Nettverksforsinkelser, gjenkoblinger og købehandling kan gjøre inntakstiden forskjellig fra måletiden. Definer hvilket tidsstempel som brukes av diagrammer, fakturering og alarmer før produksjonsdistribusjon.

5. Implementer de andre mottakertypene

5.1 MQTT- eller MQTTS-mottaker

For MQTT-inntak må kundens system tilby:

• en tilgjengelig MQTT-megler;
• autentisering og regler for tilgangskontroll;
• en abonnent- eller forbrukertjeneste;
• nyttelastvalidering og lagring;
• overvåking av megler- og forbrukerhelse.

IAMMETER publiserer sanntidsdata under et enhetstema som:

device/{SN}/realtime

Bruk den dedikerte veiledningen for meglerkonfigurasjon, legitimasjon, temaer og MQTTS-overveielser:

• Publiser IAMMETER-data til din MQTT-megler

Home Assistant MQTT Discovery er ikke nødvendig for en generell kundeserverintegrasjon.

5.2 TCP-mottaker

IAMMETER tilbyr en minimalistisk Node.js TCP-lytter:

• IAMMETER TCP-servereksempel på GitHub

Eksemplet lytter på port 8000 og skriver ut mottatte data. En TCP-mottaker for produksjon må i tillegg tilby:

• administrasjon av tilkoblingers livssyklus;
• bufring og validering av nyttelast;
• trygg håndtering av delvise eller sammenslåtte sokkeldeler;
• enhetsidentifikasjon;
• lagring og feilhåndtering;
• overvåking og kontrollerte ressursgrenser.

Ikke anta at én socket-data-hendelse alltid tilsvarer én komplett applikasjonsmelding.

5.3 TLS-mottaker

Det offisielle TLS-eksemplet viser en TLS-lytter med en server nøkkel og sertifikat:

• IAMMETER TLS-servereksempel på GitHub

Før produksjonsbruk må du erstatte demonstrasjonssertifikater og -innstillinger med organisasjonens godkjente sertifikat-, nøkkelhåndterings- og sikkerhetskonfigurasjon. Mottakeren bør logge TLS-feil atskilt fra feil i nyttelastvalideringen.

Adresseformatene på målersiden for TCP og TLS vedlikeholdes i fastvaregrensesnittveiledningen.

6. Planlegg opplastingsintervall og serverkapasitet

Gjeldende fastvare støtter et tredjepartsopplastingsintervall ned til 2 sekunder. Et kort intervall er bare nyttig når mottakersystemet, lagringen og applikasjonen trenger den ekstra oppløsningen.

Omtrentlig antall poster generert per måler:

Opplastingsintervall	Poster per måler per dag	100 målere per dag	1,000 målere per dag
60 sekunder	1,440	144,000	1,440,000
10 sekunder	8,640	864,000	8,640,000
2 sekunder	43,200	4,320,000	43,200,000

Disse tallene representerer opplastingshendelser, ikke nødvendigvis databaserader. En trefasenyttelast kan normaliseres til flere kanalposter, og indekser, oppbevaring av rånyttelast eller replikert lagring øker det faktiske databasevolumet.

Kapasitetsplanlegging bør inkludere:

• topp samtidige tilkoblinger;
• forespørsler eller meldinger per sekund;
• kostnaden for JSON-tolking;
• multiplisering av rader på kanalnivå;
• databaseindekser og oppbevaring;
• dashboard og aggregeringsspørringer;
• logger, forsøk på nytt og dead-letter-lagring;
• backup- og replikeringstrafikk.

For ettsekunds styring eller automasjon på samme LAN bør du vurdere Modbus TCP i stedet for å bruke en ekstern opplastingspipeline.

7. Håndter pålitelighet og datakvalitet

En produksjonsmottaker bør forvente nettverks- og applikasjonsfeil.

7.1 Valider hver nyttelast

Valider minst:

• JSON-syntaks;
• obligatoriske identitetsfelt;
• forventet matrisestruktur;
• numeriske typer og rimelige verdiområder;
• støttet modell- eller kanalkartlegging;
• fastvareavhengige feltvariasjoner.

Hold ugyldige nyttelaster i en kontrollert diagnostisk prosess uten å la dem blokkere gyldige enheter.

7.2 Planlegg for duplikat- og manglende opplastinger

Ikke anta at hvert intervall produserer nøyaktig én permanent lagret post. Nettverksavbrudd, gjenkoblingsatferd, serverforsøk på nytt eller applikasjonsbehandling kan føre til manglende eller gjentatte inntakshendelser.

Definer hvordan forretningssystemet skal:

• oppdage duplikatposter;
• identifisere hull;
• skille en stille måler fra en defekt mottaker;
• unngå å beregne energi ved å summere kumulative kWh-registre blindt;
• avstemme kumulert energi etter et avbrudd.

7.3 Overvåk hele databanen

Overvåk mer enn bare nett- eller socket-prosessen. Nyttige signaler inkluderer:

• tidspunkt for siste nyttelast per måler;
• antall ugyldige nyttelaster;
• mottakerens svartid og feilrate;
• aktive TCP/TLS-tilkoblinger;
• MQTT-forbrukerforsinkelse;
• skrivelatens i databasen;
• kødybde;
• diskbruk og oppbevaringsjobber.

8. Sikre mottakersystemet

For en mottaker som er eksponert mot Internett:

• foretrekk en kryptert transport som støttes av distribusjonen;
• begrens eksponerte porter og nettverkskilder der det er mulig;
• bruk MQTT-autentisering og temaautorisasjon;
• beskytt HTTP-endepunkter med den omkringliggende nettverks- eller applikasjonssikkerhetsarkitekturen;
• håndter TLS-sertifikater og private nøkler sikkert;
• unngå å skrive legitimasjon eller komplette sensitive nyttelaster til applikasjonslogger;
• begrens hastigheten på og isoler ugyldig eller misbrukende trafikk;
• hold operativsystemet, kjøretiden og avhengighetene oppdatert.

Gå gjennom gjeldende MQTTS-, TLS- og HTTPS-fastvareatferd i fastvare- og åpne grensesnittveiledningen før du velger en sikkerhetsutforming.

9. Sjekkliste for produksjonsdistribusjon

Måler og nettverk

• Fastvareversjon registrert og validert
• Måler-SN kartlagt til riktig anlegg og kanaler
• Destinasjonsadresse og -port verifisert
• DNS-, brannmur-, NAT- eller VPN-vei testet
• Nødvendig opplastingsintervall bekreftet

Mottaker

• Rånyttelast fanget inn fra hver måler-modell som omfattes
• Parsertester opprettet fra ekte nyttelastfixtures
• Enkelt- og flerkanalsnyttelaster håndtert
• WEM3046T/E CT-forholdsbehandling validert der det er aktuelt
• Ugyldige og ustøttede nyttelaster isolert trygt
• Mottakeren returnerer eller opprettholder atferden den valgte transporten forventer

Lagring og drift

• Tidsstempelpolicy dokumentert
• Policy for dupliserte og manglende data dokumentert
• Databasekapasitet beregnet for enhetsantallet og intervallet
• Logger, beregninger og varsler om siste observasjon per måler aktivert
• Oppbevaring, backup og gjenoppretting testet
• Sertifikater, legitimasjon og tilgangsregler gjennomgått
• Nettverksavbrudd og omstart av mottakeren testet

10. Relatert dokumentasjon

• Utvikle ditt eget energiovervåkingssystem
• Bruk IAMMETER uten Internett eller IAMMETER-Cloud
• IAMMETER lokale API-er og åpne grensesnitt
• MQTT-energimålerintegrasjon
• IAMMETER-definisjon av måle-JSON
• Oversikt over selv-hostet og åpen kildekode-integrasjon

11. Eldre skjermbilder av målerkonfigurasjon

Den opprinnelige versjonen av dette dokumentet fokuserte på å konfigurere eldre målerfastvare. Disse skjermbildene beholdes kun for brukere som identifiserer en eksisterende installasjon. For nye integrasjoner, bruk gjeldende WebUI og nyeste fastvare.

Eldre TCP-side

Eldre TLS-side

Eldre HTTP/HTTPS-side

Tidligere fastvaredokumentasjon brukte også den lokale /api/uploadinterval-konfigurasjonsmetoden og beskrev et minimum på seks sekunder. Gjeldende fastvare viser intervallet i WebUI og støtter et dokumentert minimum på 2 sekunder.

Sist oppdatert: 16. juli 2026