Modtag IAMMETER-energidata på din egen server

Modtag IAMMETER-energidata på din egen server

IAMMETER Wi-Fi-energimålere kan sende måledata direkte til en server, MQTT-broker eller dataplatform, som kunden selv kontrollerer. Det giver udviklere og systemintegratorer mulighed for at bygge deres eget EMS, BMS, IoT-system, database eller overvågningsdashboard uden at bruge IAMMETER-Cloud som datadestination.

Denne guide behandler integrationen fra modtagersiden:

• start en testmodtager;
• fang den første dataoverførsel fra måleren;
• identificér måleren og målekanalerne;
• normalisér og gem dataene;
• beregn indtagelsesvolumen;
• klargør modtageren til produktionsdrift.

IAMMETER-måler
      │
      │ HTTP/HTTPS, MQTT/MQTTS eller TCP/TLS
      ▼
Kundens indtagelsestjeneste
      │
      ├── Log over rå dataoverførsler
      ├── Tidsserie- eller relationsdatabase
      ├── EMS / BMS / ERP
      └── Dashboard-, rapporterings- og alarmtjenester

For målerens firmwarefunktioner og adresseformater, brug IAMMETER Local API and Open Interface Guide. For valg af arkitektur, se Develop Your Own Energy Monitoring System.

1. Vælg en modtagerarkitektur

Måleren kan sende sine målinger via flere transportprotokoller. Modtagersystemet bør vælge én primær indtagelsesvej.

Transport	Modtagerkomponent	Godt udgangspunkt for
HTTP / HTTPS	Web-endpoint	REST-backends og den enkleste første integration
MQTT / MQTTS	MQTT-broker og -abonnent	Eksisterende IoT-platforme og meddelelsespipeliner
TCP / TLS	Socket-lytter	Dedikerede indsamlingssystemer og brugerdefinerede protokoltjenester

HTTP er normalt den nemmeste måde at inspicere den første dataoverførsel på, fordi den officielle testmodtager kan startes med et lille Node.js-eksempel. MQTT er et stærkt valg, når der allerede er en broker i systemet. TCP/TLS giver en lavere-niveau socket-integration, men kræver mere modtager-side-udvikling.

De sikre transportprotokoller og formater med brugerdefinerede porte vedligeholdes i current firmware guide i stedet for at gentages her.

2. Hurtig start: Modtag den første dataoverførsel over HTTP

IAMMETER leverer et officielt Node.js HTTP-modtager-eksempel til integrationstest.

2.1 Start testmodtageren

Download eksemplet fra:

• IAMMETER HTTP Server Example on GitHub

Kør:

node Server.js

Eksemplet lytter på port 8000. Når en anmodning ankommer, gør det følgende:

• indsamler HTTP-anmodningens brødtekst;
• udskriver anmodningens URL;
• udskriver den uploadede brødtekst;
• returnerer HTTP-status 200 med et lille succes-JSON-svar.

Eksemplet er bevidst minimalt. Det tilbyder hverken autentificering, persistens, validering, hastighedsbegrænsning eller produktionssikkerhed.

2.2 Gør modtageren tilgængelig

Før du konfigurerer måleren, skal du bekræfte, at:

• serveren lytter på den forventede grænseflade og port;
• firewallen tillader forbindelsen;
• måleren kan opløse domænenavnet, når der bruges et domæne;
• enhver NAT-, reverse proxy- eller VPN-vej fungerer;
• den endelige URL når frem til den tilsigtede applikationsrute.

Til en LAN-test kan måleren og modtageren bruge det samme lokale netværk uden internetadgang. Til en fjernmodtager skal stedet have en rute til serveren.

2.3 Peg måleren mod modtageren

I målerens nuværende WebUI skal du vælge HTTP-kørselstilstand og indtaste en destination som f.eks.:

{server-address}:8000/upload

HTTPS-endpoints kan bruge standardporten eller en brugerdefineret port. De aktuelle adresseregler, herunder https://host:port, er dokumenteret i HTTP/HTTPS firmware section.

Når indstillingen er gemt, skal du kontrollere modtagerkonsollen for anmodningsstien og den uploadede JSON. Gem denne første rå dataoverførsel som en test-fixture til senere parser- og databasetest.

3. Forstå den indkommende IAMMETER-dataoverførsel

IAMMETER bruger en konsistent kernemålings-JSON-struktur på tværs af de understøttede transportprotokoller. Transporten ændrer, hvordan dataoverførslen ankommer, men målingsmodellen forbliver konsistent.

En dataoverførsel indeholder normalt enhedsniveau-felter som f.eks.:

• SN — målerens serienummer, der bruges til at identificere enheden;
• version — målerens firmwareversion;
• method — meddelelsesmetode eller dataoverførsels-type;
• Data eller Datas — målingsarrays.

Data bruges til en enkelt målekanal. Datas indeholder flere målingsarrays til en multikanal- 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]
}

Lav ikke en hårdkodet enkelt-array-tælling for alle målere. Antallet af kanaler og tilgængelige felter afhænger af målerens model og de aktiverede målefunktioner.

Brug den autoritative definition, når du implementerer parseren:

• IAMMETER Energy Meter JSON Data Definition

3.1 Modelspecifik behandling

Hold modelspecifik behandling adskilt fra transportmodtageren.

For eksempel måler WEM3046T og WEM3046TE den 5 A sekundære udgang fra en ekstern strømtransformator. Deres værdier skal konverteres med det relevante CT-forhold for at få den primære måling. Dette er en måler- og CT-egenskab, ikke en HTTP-, MQTT- eller TCP-forskel.

En praktisk indtagelsespipeline adskiller derfor:

1. transportafkodning;
2. JSON-validering;
3. måler- og kanalidentifikation;
4. modelspecifik skalering eller normalisering;
5. lagring og forretningsberegninger.

4. Design indtagelsesdatamodellen

Gem nok information til at kunne genskabe og diagnosticere den oprindelige aflæsning.

En nyttig minimumsmodel inkluderer:

Field	Formål
Meter SN	Knytter dataoverførslen til en registreret enhed
Channel or phase index	Adskiller enkeltfase-, splitfase- og trefasedata
Server receive time	Giver et konsistent indtagelsestidsstempel
Voltage	Elektrisk måling
Current	Elektrisk måling
Active power	Input til realtids import/eksport eller belastningsberegning
Import kWh	Kumuleret importeret energi
Export kWh	Kumuleret eksporteret energi
Firmware version	Understøtter fejlfinding og parser-kompatibilitet
Raw payload	Muliggør afspilning, revision og parser-korrektion

Yderligere felter såsom frekvens, effektfaktor og reaktive målinger bør gemmes, når den valgte model og konfiguration leverer dem.

4.1 Hold rå og normaliserede data adskilt

Til produktionssystemer bør du overveje at gemme:

• en uforanderlig eller kort-opbevaret rå-indtagelsespost;
• normaliserede kanalniveau-aflæsninger, som applikationen bruger;
• aggregerede time-, dags- og månedsværdier.

Det gør det lettere at korrigere parser- eller CT-forholds-logik uden at miste den oprindelige dataoverførsel.

4.2 Brug serverens modtagelsestid med omtanke

Registrér det tidspunkt, hvor serveren accepterede dataoverførslen. Hvis forretningssystemet også bruger et enheds- eller kildetidsstempel, skal begge værdier gemmes separat i stedet for at erstatte hinanden.

Netværksforsinkelse, genforbindelser og køet behandling kan gøre indtagelsestiden forskellig fra målingstiden. Definér det tidsstempel, der bruges i diagrammer, fakturering og alarmer, før produktionsudrulning.

5. Implementér de øvrige modtagertyper

5.1 MQTT- eller MQTTS-modtager

Til MQTT-indtagelse skal kundens system levere:

• en tilgængelig MQTT-broker;
• autentificerings- og adgangskontrolregler;
• en abonnent- eller forbrugertjeneste;
• validering og persistens af dataoverførsler;
• overvågning af broker- og forbrugerhelbred.

IAMMETER offentliggør realtidsdata under et enhedsemne som f.eks.:

device/{SN}/realtime

Brug den dedikerede guide til brokerkonfiguration, legitimationsoplysninger, emner og MQTTS-overvejelser:

• Publish IAMMETER Data to Your MQTT Broker

Home Assistant MQTT Discovery er ikke nødvendig til en generel kundeserver-integration.

5.2 TCP-modtager

IAMMETER leverer en minimal Node.js TCP-lytter:

• IAMMETER TCP Server Example on GitHub

Eksemplet lytter på port 8000 og udskriver modtagne data. En produktions-TCP-modtager skal derudover levere:

• styring af forbindelseslivscyklus;
• buffer- og validering af dataoverførsler;
• sikker håndtering af delvise eller sammenkædede socket-chunks;
• enhedsidentifikation;
• persistens og fejlhåndtering;
• overvågning og kontrollerede ressourcegrænser.

Antag ikke, at én socket-data-hændelse altid svarer til én komplet applikationsmeddelelse.

5.3 TLS-modtager

Det officielle TLS-eksempel demonstrerer en TLS-lytter med en servernøgle og et certifikat:

• IAMMETER TLS Server Example on GitHub

Før produktionsbrug skal demonstrationscertifikater og -indstillinger erstattes med organisationens godkendte certifikat-, nøgle- og sikkerhedskonfiguration. Modtageren bør logge TLS-fejl separat fra valideringsfejl på dataoverførsler.

Målerens adresseformater for TCP og TLS vedligeholdes i firmware interface guide.

6. Planlæg uploadintervallet og serverkapaciteten

Den nuværende firmware understøtter et tredjeparts-uploadinterval helt ned til 2 sekunder. Et kort interval er kun nyttigt, når modtagersystemet, lagringen og applikationen har brug for den ekstra opløsning.

Omtrentlige poster pr. måler:

Upload interval	Poster pr. måler pr. dag	100 målere pr. dag	1.000 målere pr. 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 tal repræsenterer uploadhændelser, ikke nødvendigvis databaserækker. En trefase-dataoverførsel kan normaliseres til flere kanalposter, og indekser, opbevaring af rå dataoverførsler eller replikeret lagring øger den faktiske databasevolumen.

Kapacitetsplanlægning bør inkludere:

• maksimale samtidige forbindelser;
• anmodninger eller meddelelser pr. sekund;
• JSON-parsing-omkostning;
• kanalniveau-rækkemultiplikation;
• databaseindekser og opbevaring;
• dashboards og aggregeringsforespørgsler;
• logfiler, forsøg igen og dead-letter-lagring;
• backup- og replikeringstrafik.

Til et-sekunds styring eller automatisering på samme LAN bør du overveje Modbus TCP i stedet for en fjern-upload-pipeline.

7. Håndter pålidelighed og datakvalitet

En produktionsmodtager bør forvente netværks- og applikationsfejl.

7.1 Valider hver dataoverførsel

Valider mindst:

• JSON-syntaks;
• påkrævede identitetsfelter;
• forventet arraystruktur;
• numeriske typer og rimelige intervaller;
• understøttet model- eller kanalafbildning;
• firmwareafhængige feltvariationer.

Hold fejlformede dataoverførsler på en kontrolleret diagnostisk sti uden at lade dem blokere gyldige enheder.

7.2 Planlæg for dubletter og manglende uploads

Antag ikke, at hvert interval producerer præcis én permanent gemt post. Netværksafbrydelser, genforbindelsesadfærd, serverforsøg eller applikationsbehandling kan medføre manglende eller gentagne indtagelseshændelser.

Definér, hvordan forretningssystemet skal:

• opdage dubletposter;
• identificere huller;
• skelne en tavs måler fra en defekt modtager;
• undgå at beregne energi ved blindt at summere kumulative kWh-registre;
• afstemme kumuleret energi efter en afbrydelse.

7.3 Overvåg hele datastien

Overvåg mere end blot web- eller socket-processen. Nyttige signaler inkluderer:

• sidste dataoverførsels-tidspunkt pr. måler;
• antal ugyldige dataoverførsler;
• modtagerens svartid og fejlrate;
• aktive TCP/TLS-forbindelser;
• MQTT-forbrugerforsinkelse;
• database-skrivelatens;
• kødybde;
• diskforbrug og opbevaringsjob.

8. Sikr modtagersystemet

Til en internetvendt modtager:

• foretræk en krypteret transport, som udrulningen understøtter;
• begræns eksponerede porte og netværkskilder, hvor det er muligt;
• anvend MQTT-autentificering og emneautorisering;
• beskyt HTTP-endpoints med den omkringliggende netværks- eller applikationssikkerhedsarkitektur;
• administrer TLS-certifikater og private nøgler sikkert;
• undgå at skrive legitimationsoplysninger eller komplette følsomme dataoverførsler til applikationslogfiler;
• begræns hastigheden og isolér fejlformet eller misbrugende trafik;
• hold operativsystemet, køretiden og afhængighederne opdaterede.

Gennemgå den aktuelle MQTTS-, TLS- og HTTPS-firmwareadfærd i firmware and open-interface guide, før du vælger et sikkerhedsdesign.

9. Tjekliste til produktionsudrulning

Måler og netværk

• Firmwareversion registreret og valideret
• Målerens SN afbildet til den korrekte placering og kanaler
• Destinationsadresse og -port verificeret
• DNS-, firewall-, NAT- eller VPN-vej testet
• Påkrævet uploadinterval bekræftet

Modtager

• Rå dataoverførsel fanget fra hver måler-model i scope
• Parsertests oprettet ud fra rigtige dataoverførsels-fixtures
• Enkelt- og multikanal-dataoverførsler håndteret
• WEM3046T/E CT-forholdsbehandling valideret, hvor relevant
• Fejlformede og ikke-understøttede dataoverførsler isoleret sikkert
• Modtageren returnerer eller opretholder den adfærd, som den valgte transport forventer

Lagring og drift

• Tidsstempelpolitik dokumenteret
• Politik for dubletter og manglende data dokumenteret
• Databasekapacitet beregnet ud fra enhedsantal og interval
• Logfiler, målinger og pr.-måler sidst-set-alarmer aktiveret
• Opbevaring, backup og gendannelse testet
• Certifikater, legitimationsoplysninger og adgangsregler gennemgået
• Netværksafbrydelse og modtager-genstart testet

10. Relateret dokumentation

• Develop Your Own Energy Monitoring System
• Use IAMMETER Without Internet or IAMMETER-Cloud
• IAMMETER Local APIs and Open Interfaces
• MQTT Energy Meter Integration
• IAMMETER Measurement JSON Definition
• Self-hosted and Open-source Integration Overview

11. Forældede måler-side-konfigurationsskærmbilleder

Den oprindelige version af dette dokument fokuserede på konfiguration af ældre måler-firmware. Disse skærmbilleder er kun bevaret til brugere, der identificerer en eksisterende installation. Til nye integrationer skal du bruge den aktuelle WebUI og latest firmware.

Forældet TCP-side

Forældet TLS-side

Forældet HTTP/HTTPS-side

Tidligere firmware-dokumentation brugte også den lokale /api/uploadinterval-konfigurationsmetode og beskrev et minimum på seks sekunder. Den aktuelle firmware viser intervallet i WebUI'et og understøtter et dokumenteret minimum på 2 sekunder.

Sidst opdateret: 16. juli 2026