Ta emot IAMMETER-energidata på din egen server

Ta emot IAMMETER-energidata på din egen server

IAMMETERs Wi-Fi-energimätare kan skicka mätdata direkt till en server, MQTT-broker eller dataplattform som kunden kontrollerar. Detta gör att utvecklare och systemintegratörer kan bygga sitt eget EMS, BMS, IoT-tjänst, databas eller övervakningsinstrumentpanel utan att använda IAMMETER-Cloud som datamål.

Denna guide närmar sig integrationen från mottagarserversidan:

• sätta upp en testmottagare;
• fånga upp det första mätarpaketet;
• identifiera mätaren och mätkanalerna;
• normalisera och lagra data;
• uppskatta inmatningsvolymen;
• förbereda mottagaren för produktionsdrift.

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

För mätarsidans fasta funktioner och adressformat, använd IAMMETER Local API och Open Interface-guiden. För arkitekturval, se Utveckla ditt eget energisystem.

1. Välj en mottagararkitektur

Mätaren kan skicka sina mätningar via flera transportprotokoll. Mottagarsystemet bör välja en primär inmatningsväg.

Transport	Mottagarkomponent	Bra utgångspunkt för
HTTP / HTTPS	Webbslutpunkt	REST-backends och den enklaste första integrationen
MQTT / MQTTS	MQTT-broker och prenumerant	Befintliga IoT-plattformar och meddelandepipelines
TCP / TLS	Sockethandler	Dedikerade insamlare och anpassade protokolltjänster

HTTP är normalt det enklaste sättet att inspektera det första paketet eftersom den officiella testmottagaren kan startas med ett litet Node.js-exempel. MQTT är ett starkt val när en broker redan ingår i systemet. TCP/TLS ger en integration på lägre nivå via socket men kräver mer ingenjörsarbete på mottagarsidan.

De säkra transportsätten och formaten med anpassad port underhålls i den aktuella firmwareguiden, snarare än att upprepas här.

2. Snabbstart: ta emot det första paketet över HTTP

IAMMETER tillhandahåller ett officiellt Node.js-HTTP-mottagarexempel för integrationstestning.

2.1 Starta testmottagaren

Ladda ner exemplet från:

• IAMMETER HTTP Server Example på GitHub

Kör:

node Server.js

Exemplet lyssnar på port 8000. När en förfrågan kommer in:

• samlar det in HTTP-förfrågans brödtext;
• skriver ut förfrågans URL;
• skriver ut den uppladdade brödtexten;
• returnerar HTTP-status 200 med ett litet JSON-svarsmeddelande.

Exemplet är medvetet minimalt. Det tillhandahåller inte autentisering, persistens, validering, hastighetsbegränsning eller produkttionssäkerhet.

2.2 Gör mottagaren nåbar

Innan mätaren konfigureras, bekräfta att:

• servern lyssnar på det förväntade gränssnittet och porten;
• brandväggen tillåter anslutningen;
• mätaren kan lösa domännamnet när ett domännamn används;
• eventuell NAT, omvänd proxy eller VPN-sökväg fungerar;
• den slutliga URL:en når den avsedda applikationssökvägen.

För ett LAN-test kan mätaren och mottagaren använda samma lokala nätverk utan internetanslutning. För en fjärrmottagare måste platsen ha en väg till servern.

2.3 Peka mätaren mot mottagaren

I den aktuella mätarens WebUI, välj HTTP-läget och ange ett mål som till exempel:

{server-address}:8000/upload

HTTPS-slutpunkter kan använda standardporten eller en anpassad port. Aktuella adressregler, inklusive https://host:port, dokumenteras i HTTP/HTTPS-firmwaresektionen.

Efter att inställningen sparats, kontrollera mottagarkonsolen för förfrågningssökvägen och den uppladdade JSON:en. Spara detta första råpaket som en testfixture för senare parser- och databastester.

3. Förstå det inkommande IAMMETER-paketet

IAMMETER använder en konsekvent kärn-JSON-struktur för mätning över de stödda push-transportsätten. Transporten ändrar hur paketet anländer, men mätningsmodellen förblir konsekvent.

Ett paket innehåller normalt fält på enhetsnivå som:

• SN — mätarens serienummer som används för att identifiera enheten;
• version — mätarens firmwareversion;
• method — meddelandemetod eller pakettyp;
• Data eller Datas — mätningsarrayer.

Data används för en enda mätkanal. Datas innehåller flera mätningsarrayer för en multikanal- eller trefasmätare.

Exempel på enkanalsstruktur:

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

Hårdkoda inte ett enda arrayantal för varje mätare. Antalet kanaler och tillgängliga fält beror på mätarmodellen och aktiverade mätfunktioner.

Använd den auktoritativa definitionen när parsern implementeras:

• IAMMETER Energy Meter JSON Data Definition

3.1 Modellspecifik bearbetning

Håll modellspecifik bearbetning skild från transportmottagaren.

Till exempel mäter WEM3046T och WEM3046TE den 5 A sekundära utgången från en extern strömtransformator. Deras värden måste konverteras med den tillämpliga CT-relationen för att få primärsidans mätning. Detta är en mätar- och CT-egenskap, inte en HTTP-, MQTT- eller TCP-skillnad.

En praktisk inmatningspipeline separerar därför:

1. transportavkodning;
2. JSON-validering;
3. mätar- och kanalidentifiering;
4. modellspecifik skalning eller normalisering;
5. lagring och affärsberäkningar.

4. Designa inmatningsdatamodellen

Lagra tillräckligt med information för att reproducera och diagnostisera den ursprungliga avläsningen.

Användbar minimimodell innehåller:

Fält	Syfte
Meter SN	Mappar paketet till en registrerad enhet
Channel or phase index	Särskiljer enfas-, split-phase- och trefasdata
Server receive time	Ger en konsekvent inmatningstidsstämpel
Voltage	Elmätning
Current	Elmätning
Active power	Ingång för realtidsimport/export eller lastberäkning
Import kWh	Kumulativ importerad energi
Export kWh	Kumulativ exporterad energi
Firmware version	Stödjer felsökning och parserkompatibilitet
Raw payload	Möjliggör uppspelning, granskning och parserkorrigering

Ytterligare fält som frekvens, effektfaktor och reaktiva mätningar bör lagras när den valda modellen och konfigurationen tillhandahåller dem.

4.1 Håll rå och normaliserad data åtskilda

För produktionssystem, överväg att hålla:

• en oföränderlig eller kortlivad post för rå inmatning;
• normaliserade kanalnivåavläsningar som används av applikationen;
• aggregerade tim-, dygns- och månadsvärden.

Detta gör det lättare att korrigera parsnings- eller CT-relationslogik utan att förlora det ursprungliga paketet.

4.2 Använd serverns mottagningstid försiktigt

Registrera den tidpunkt då servern accepterade paketet. Om affärssystemet också använder en enhets- eller källtidsstämpel, lagra båda värdena separat snarare än att ersätta det ena med det andra.

Nätverksfördröjning, återanslutningar och köad bearbetning kan göra att inmatningstiden skiljer sig från mättiden. Definiera den tidsstämpel som används av diagram, fakturering och larm före produktionsdrift.

5. Implementera de andra mottagartyperna

5.1 MQTT- eller MQTTS-mottagare

För MQTT-inmatning tillhandahåller kundsystemet:

• en nåbar MQTT-broker;
• autentiserings- och åtkomstkontrollregler;
• en prenumerant- eller konsumenttjänst;
• paketvalidering och persistens;
• övervakning av broker- och konsumenthälsa.

IAMMETER publicerar realtidsdata under ett enhetsämne som till exempel:

device/{SN}/realtime

Använd den dedikerade guiden för brokerkonfiguration, autentiseringsuppgifter, ämnen och MQTTS-överväganden:

• Publicera IAMMETER-data till din MQTT-broker

Home Assistant MQTT Discovery krävs inte för en generell integration med kundserver.

5.2 TCP-mottagare

IAMMETER tillhandahåller en minimal Node.js-TCP-lyssnare:

• IAMMETER TCP Server Example på GitHub

Exemplet lyssnar på port 8000 och skriver ut mottagen data. En TCP-mottagare för produktion måste dessutom tillhandahålla:

• hantering av anslutningens livscykel;
• paketbuffring och validering;
• säker hantering av partiella eller kombinerade socket-delar;
• enhetsidentifiering;
• persistens och felhantering;
• övervakning och kontrollerade resursgränser.

Anta inte att en enda socket-data-händelse alltid motsvarar ett komplett applikationsmeddelande.

5.3 TLS-mottagare

Det officiella TLS-exemplet visar en TLS-lyssnare med en servernyckel och ett certifikat:

• IAMMETER TLS Server Example på GitHub

Före produktionsanvändning, ersätt demonstrationscertifikat och inställningar med organisationens godkända certifikat-, nyckelhanterings- och säkerhetskonfiguration. Mottagaren bör logga TLS-fel separat från paketvalideringsfel.

Mätarsidans adressformat för TCP och TLS underhålls i firmwaregränssnittsguiden.

6. Planera uppladdningsintervall och serverkapacitet

Aktuell firmware stöder ett tredjepartsuppladdningsintervall ned till 2 sekunder. Ett kort intervall är bara användbart när mottagarsystemet, lagringen och applikationen behöver den extra upplösningen.

Ungefärliga poster som genereras per mätare:

Uppladdningsintervall	Poster per mätare per dag	100 mätare per dag	1 000 mätare 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

Dessa siffror representerar uppladdningshändelser, inte nödvändigtvis databasrader. Ett trefaspaket kan normaliseras till flera kanalposter, och index, råpaketbevarande eller replikerad lagring ökar den faktiska databasvolymen.

Kapacitetsplanering bör inkludera:

• topp samtidiga anslutningar;
• förfrågningar eller meddelanden per sekund;
• JSON-parsningskostnad;
• radmultiplikation på kanalnivå;
• databasindex och bevarande;
• instrumentpaneler och aggregeringsfrågor;
• loggar, återförsök och lagring av döda brev;
• säkerhetskopierings- och replikeringstrafik.

För en sekundstyrd styrning eller automation på samma LAN, överväg Modbus TCP istället för att använda en fjärruppladdningspipeline.

7. Hantera tillförlitlighet och datakvalitet

En produktionsmottagare bör förvänta sig nätverks- och applikationsfel.

7.1 Validera varje paket

Validera åtminstone:

• JSON-syntax;
• obligatoriska identitetsfält;
• förväntad arraystruktur;
• numeriska typer och rimliga räckvidder;
• stödd modell- eller kanalmappning;
• firmwareberoende fältvariationer.

Håll felaktiga paket i en kontrollerad diagnostisk sökväg utan att låta dem blockera giltiga enheter.

7.2 Planera för dubblerade och saknade uppladdningar

Anta inte att varje intervall producerar exakt en permanent lagrad post. Nätverksavbrott, återanslutningsbeteende, serveråterförsök eller applikationsbearbetning kan producera saknade eller upprepade inmatningshändelser.

Definiera hur affärssystemet ska:

• upptäcka dubblerade poster;
• identifiera luckor;
• skilja en tyst mätare från en trasig mottagare;
• undvika att beräkna energi genom att blint summera kumulativa kWh-register;
• stämma av kumulativ energi efter ett avbrott.

7.3 Övervaka hela datavägen

Övervaka mer än webb- eller socketprocessen. Användbara signaler inkluderar:

• senaste pakettid per mätare;
• antal ogiltiga paket;
• mottagarresponsstid och felfrekvens;
• aktiva TCP/TLS-anslutningar;
• MQTT-konsumentfördröjning;
• databasens skrivlatens;
• ködjup;
• diskanvändning och bevarandejobb.

8. Säkerställ mottagarsystemet

För en internetvänd mottagare:

• föredra ett krypterat transportsätt som stöds av driftsättningen;
• begränsa exponerade portar och nätverkskällor där det är möjligt;
• tillämpa MQTT-autentisering och ämnesauktorisering;
• skydda HTTP-slutpunkter med den omgivande nätverks- eller applikationssäkerhetsarkitekturen;
• hantera TLS-certifikat och privata nycklar säkert;
• undvik att skriva autentiseringsuppgifter eller fullständiga känsliga paket till applikationsloggar;
• hastighetsbegränsa och isolera felaktig eller missbrukande trafik;
• håll operativsystemet, körtiden och beroenden uppdaterade.

Granska det aktuella MQTTS-, TLS- och HTTPS-firmwarebeteendet i firmware- och öppet gränssnittsguiden innan en säkerhetsdesign väljs.

9. Checklista för produktionsdrift

Mätare och nätverk

• Firmwareversion registrerad och validerad
• Mätarens SN mappad till rätt plats och kanaler
• Destinationsadress och port verifierade
• DNS-, brandväggs-, NAT- eller VPN-sökväg testad
• Önskat uppladdningsintervall bekräftat

Mottagare

• Råpaket fångade från varje mätarmodell i omfattningen
• Parsertester skapade från riktiga paketfixtures
• En- och multikanalspaket hanterade
• WEM3046T/E CT-relationsbearbetning validerad där det är tillämpligt
• Felaktiga och icke-stödda paket isolerade säkert
• Mottagaren returnerar eller upprätthåller det beteende som den valda transporten förväntar sig

Lagring och drift

• Tidsstämpelpolicyn dokumenterad
• Policy för dubblerad och saknad data dokumenterad
• Databaskapacitet beräknad för enhetsantalet och intervallet
• Loggar, mätvärden och larm för senaste-sedd per mätare aktiverade
• Bevarande, säkerhetskopiering och återställning testade
• Certifikat, autentiseringsuppgifter och åtkomstregler granskade
• Nätverksavbrott och mottagaromstart testade

10. Relaterad dokumentation

• Utveckla ditt eget energisystem
• Använd IAMMETER utan internet eller IAMMETER-Cloud
• IAMMETER Local APIs och öppna gränssnitt
• MQTT-energimätarintegration
• IAMMETER mätnings-JSON-definition
• Översikt över självhostad och öppen källkods-integration

11. Äldre skärmbilder för mätarsidans konfiguration

Den ursprungliga versionen av detta dokument fokuserade på konfigurering av äldre mätarfirmware. Dessa skärmbilder behålls endast för användare som identifierar en befintlig installation. För nya integrationer, använd den aktuella WebUI:n och den senaste firmwaren.

Äldre TCP-sida

Äldre TLS-sida

Äldre HTTP/HTTPS-sida

Tidigare firmware-dokumentation använde också den lokala /api/uploadinterval-konfigurationsmetoden och beskrev ett minimum på sex sekunder. Aktuell firmware visar intervallet i WebUI:n och stöder ett dokumenterat minimum på 2 sekunder.

Senast uppdaterad: 16 juli 2026