6.1 Oprettelse af tredjepartskode .................................................................................................................................................................................................. 4
6.2 Tildeling af adgang til tredjepart ........................................................................................................................................................................................... 5
8.4 Statuskoder for respons ............................................................................................................................................................................................................17
10.0 Brug af snitfladen ..............................................................................................................................................................................................................................21
10.1 Udtræk af stamdata ..................................................................................................................................................................................................................23
10.1.2 M-Bus, Solvarme lille tank .........................................................................................................................................................................................26
10.1.3 M-Bus, Solvarme stor tank ........................................................................................................................................................................................28
10.1.4 ECL-log, A367.1 eksempel e .....................................................................................................................................................................................30
10.1.5 Udtræk af aflæsninger (readings) ..........................................................................................................................................................................33
10.1.6 Udlæs seneste værdier for en eller flere sensorer på en måler tilsluttet ECL regulatoren ................................................................. 33
10.1.7 Udlæsning af senest målte udendørstemperatur ............................................................................................................................................34
10.1.8 Udlæsning af Energi, Volumen, Flow-temperatur og Retur-temperatur for husets hovedmåler ...................................................35
10.1.9 Udlæs seneste værdi for en eller flere sensorer på tværs af målere tilsluttet ECL regulatoren .......................................................35
10.1.10 Udlæs en periode af historiske data for en eller flere sensorer på én måler tilsluttet ECL regulatoren .....................................35
10.2 Formatforskelle på dataudtræk ............................................................................................................................................................................................39
Dette dokument er en beskrivelse til tredjepart, til brug ved implementering af softwareklienter til udtræk af data fra ECL Comfort 296 / 310
Portal (ECL Portal).
3.0 Versionstabel
VersionDatoÆndring
1.002013-09-25Første version
1.102013-10-25Tilføjet afsnit om oprettelse af tredjepartskode, fremtidige version, tidsformater.
Tilføjet JSON eksempler for forespørgsler og svar.
1.112013-10-29Tilføjet eksempel om forskel på dataudtræk fra ECL Portal og ECL Portal-API.
Tilføjet eksempel om tidsformat i aflæsninger.
1.122014-04-01Tilføjet nogle få uddybende forklaringer og eksempler.
4.0 Begrebsoversigt
APIApplication Programming Interface. Et interface for udvekling af applicationsspecifik information.
DeviceEn enhed. Typisk brugt i forbindelse med en log-enhed.
ECL Comfort 296/310En ernvarmeregulatormodel fra Danfoss A/S.
HTTPSHyperText Transfer Protocol. En krypteret protokol til overførsel af information.
Konfigurerbar
indgang
KundeEn person, virksomhed eller kommune som vil have udlæst data fra ECL Portalen
JSONJavaScript Object Notation. Et åbent data format til udveksling af data mellem en server og et internetprogram.
M-busEn kommunikationsprotokol typisk anvendt af varme- og energimålere
PagingSideinddeling. For at undgå at overføre alt for mange information på én gang inddeles en datamænge i flere
ReadingEn aflæsning. Log-data udlæst fra web-API’et fra en log-enhed
RequestEn forespørgsel til web-API’et
ResponseSvar fra web-API serveren på en forespørgsel
RESTRepresentational State Transfer. En software arkitektur stil, der kan bruges til konstruktion af internettjenester
ServerkodeEn unik kode udstedt af Danfoss til tredjepart
SSLSecure Sockets Layer. En kryptering til sikker udveksling af information, der bl.a. anvendes på internettet (HTTPS)
StamdataGrundlæggende data for en ECL Comfort 296 / 310 regulator
Nogle sensorindgange på en ECL Comfort 296 / 310 regulator kan valgfrit konfigureres til at måle temperatur,
puls, frekvens, 0-10 V analog signal eller digital ON/OFF
sider, hvor kun én side læses af gangen.
TredjepartskodeEn kode oprettet af kunden på ECL Portalen, som kunden udleverer til tredjepart
URLUnifor Resource Locator. En internetadresse
UTCCoordinated Universal Time. En standard for tidskoordinering med udgangspunkt i Greenwich, London.
Tidszoner angives i forhold til UTC.
Web-APIEt API tilpasset internettet.
tredjepartEt eksternt firma, som en kunde får til at udvikle software til udlæsning af data fra ECL Portalen til et eksternt
De data, der er tilgængelige via ECL Portal web-API’et, afhænger af den ECL applikationsnøgle, der sidder i den pågældende ECL Comfort
296 / 310. Dvs. de tilgængelige datasæt er forskellige for hver ECL applikationstype og kan derudover også afhænge af de forskellige
eksterne dataopsamlingsapparater, såsom M-bus-målere og konfigurerbare indgange, som ECL regulatorerne kan udstyres med.
ECL Portalen hjemhenter data fra ECL regulatorerne én gang i timen kort efter klokken hel. Den indbyggede ECL-log indeholder
applikationsspecifikke signaler såsom målte temperaturer og temperaturreferencer samt eventuelt vindstyrke, tryk eller flow afhængig
af den installerede applikation. ECL-loggen indeholder data med 15 minutters mellemrum. Hvis kunden har oprettet konfigurerbare
indgange eller tilsluttet M-bus-målere, vil aktuelle værdier for disse også blive hentet én gang i timen.
Hvis det ikke er muligt at hente data fra en ECL regulator pga. kommunikationsfejl eller andet, vil ECL-loggen blive forsøgt hentet ved
næste hjemtagning næste time. Den interne ECL-log i ECL regulatoren indeholder data for de seneste 10 dage, så hvis det ikke har været
muligt at hente log fra en ECL regulator i 10 dage, vil data gå tabt på ECL portalen og vil dermed ikke være tilgængelig gennem webAPI’et.
Så snart data er tilgængelig på ECL Portalen vil de også være tilgængelige gennem ECL Portal web-API’et. Det er ikke muligt at hente data
gennem web-API’et, som ikke er tilgængelig på ECL Portalen. Hvis en kunde for eksempel sletter en ECL log eller M-bus-måler på ECL
Portalen, vil den heller ikke længere være tilgængelig gennem web-API’et.
Der gemmes ikke data for konfigurerbare indgange og M-bus-målere i ECL regulatoren, så historiske værdier vil ikke blive udlæst ved
næste loghentning, når der ikke har været kontakt til ECL Portalen.
Guides for individuelle ECL applikationer kan findes på www.ecl.doc.danfoss.com, hvis det skulle være nødvendigt for tredjepart at have
mere specifik viden om de data, der kan trækkes ud af ECL regulatorerne.
En kommunikationsbeskrivelse for ECL regulatorer kan findes her:
http://heating.danfoss.com/PCMPDF/VILGV502_ECL_Comfort_210_296_310_Communication.pdf eller ved at google ”ecl communication
description” for at finde nyeste version. Kommunikationsbeskrivelsen indeholder bl.a. en generel liste med parametre, som logges af
nogle applikationer.
6.0 Sikkerhed
Da der er tale om en ekstern snitflade mod omverdenen, er det særligt vigtigt at sikre, at man ikke kan skaffe sig adgang til andres data.
Første element i sikring af data er identifikation, så man kan validere, hvorvidt den klient, der kalder ECL Portal web-API’et, har ret til at se
de data, der efterspørges. I forespørgslerne skal man derfor altid angive:
• Serverkode. Denne udstedes af Danfoss til tredjepart eller kunde, således at åbning for datasnitfladen er en aktiv handling foretaget
af Danfoss. Her er tale om en oprettelse ved indgåelse af juridisk aftale.
• ECL serienummer. Anvendes til at identificere en ECL regulator af interesse. Serienummeret kan findes inde i ECL regulatorens menu
eller på ECL Portalen
• Tredjepartskode. Oprettes af kunden på ECL Portalen og udleveres til tredjepart
Udover, at tredjepart eller kunden skal have oplyst en serverkode og kende serienummeret, så skal kunden selv knytte tredjepartskoder
til ECL regulatoren. På den måde har kunden mulighed for selv at styre, hvilke tredjepart personer og systemer de vil lade trække på
dataene ved at tildele dem forskellige tredjepartskoder, som naturligvis også kan inddrages igen enkeltvis.
Dvs., for at få fat i data fra en given ECL regulator, skal man kende dens serienummer, have udstedt en serverkode fra Danfoss og have
tildelt sig selv, sit system eller tredjepart en ECL-specifik tredjepartskode.
Ganske som med traditionelle brugernavn/passwordkombinationer vil data kunne komme i de forkerte hænder, hvis kombinationen
kompromitteres, da en udefrakommende i så fald vil kunne gøre brug af de samme koder og foretage sine egne forespørgsler.
Sikkerheden beror således her på, hvordan kunden og tredjepart beskytter disse oplysninger.
Serverkoder udstedes til kunden/tredjepart enkeltvis og må ikke deles af flere kunder, da den i henhold til den juridiske aftale kan
afmeldes ved ophør af aftale eller ved misbrug.
Datakommunikation gennem web-API’et kræver SSL-understøttelse. Hvis en klient sender forespørgsler over HTTP, vil den blive
omdirigeret til HTTPS.
Tildel et navn til tredjepartskoden for at holde styr på alle koder og
marker ”Aktiveret” indstillingen for at gøre koden aktiv.
Koden vil nu være på listen over oprettede koder.
Tryk på linket ”ECL’er” for at komme til siden, hvor koden kan tildeles specifikke ECL regulatorer.
Man kan her tildele samme kode til flere ECL regulatorer, og man
kan tildele flere koder til samme ECL regulator, så man bedre kan
styre, hvem der har adgang til hvad.
a) Hvis kunden ikke tidligere har givet den pågældende tredjepart adgang til data for nogle ECL regulatorer, som slutkunden
administrerer, så opretter slutkunden en kode til tredjepart under menuen ECL > Tredjepartskoder.
b) Slutkunden knytter den relevante ECL regulator til den relevante tredjepartskode.
c) Slutkunden oplyser tredjepart om ECL serienummeret og tredjepartskoden.
Med disse 3 informationer (Serverkode, ECL serienummer, tredjepartskode) har tredjepart nu mulighed for at tilgå data for ECL regulatoren via web-API’et.
Her beskrives de konceptuelle snitflader, der vil blive tilgængelige via web-API’et. Med konceptuelle menes, hvad man kan spørge efter,
herunder hvilke oplysninger, der kræves for at spørge, samt hvilke informationer man får retur fra sådanne forespørgsler.
Når man henter aflæsninger for en given periode, kan det vise sig, at perioden indeholder et stort antal aflæsninger, som ikke egner sig til
at overføre via et http-request af én omgang. Derfor giver det god mening at operere med såkaldt paging. Dvs. at man i sin forespørgsel,
ud over at indikere perioden, kan indikere, hvor mange aflæsninger man ønsker at modtage ad gangen. Af det svar man får retur, kan
man så se, om man har fået alle aflæsninger med tilbage på ”første side”(/response), eller om man skal hente flere, og hvor mange man
kan forvente at skulle hente i alt. På baggrund heraf kan man så spørge om den næste side og så fremdeles. Samtidig definerer systemet
en standard sidestørrelse og en maksimal sidestørrelse, således at man ikke behøver at angive en sidestørrelse, og heller ikke risikerer, at
en klient beder om et urealistisk stort load af data i én forespørgsel.
Da en ECL regulator kan operere med flere devices (log-enheder), med forskellige log-frekvenser, er det svært at lave en logisk ”sideombrydning” i det tilfælde, at alle data ikke kan returneres på én gang. Når man henter aflæsninger, er det i forvejen relevant at vide, hvilke
devices der er tilgængelige på en ECL regulator, hvilke der er aktive, etc. Der er således brug for at kunne skaffe sig den information, når
der skal hentes aflæsninger, men også, såfremt tredjepart ønsker at lagre/synkronisere detaljer om ECL regulatorerne, devices og kanaler
– såkaldt stamdata.
Eksempel på tilgængelige devices og kanaler i en ECL Comfort 296 / 310 regulator med en given applikation, der har tilsluttet to varmemålere via m-bus:
Der vil af den grund blive foretaget en opdeling i de services web-API’et stiller til rådighed. En service, som opererer med stamdata
(masterData), og en service, som opererer med aflæsninger (readings). For at gøre overførslen af aflæsninger så optimal som mulig
mht. performance, vil disse kald kun returnere de rå værdier. For at tolke dem (f.eks. mht. enheder m.v.) skal de således holdes op mod
stamdata.
7.1 API-format
Web-API’et er et REST (REpresentational State Transfer) API via HTTPS(GET) requests, hvor argumenter udtrækkes som en kombination af
URL komponenter og URL query parametre.
Responsformatet vil altid være minimalistisk JSON pga. performance. Senere i dette dokument vises eksempler på requests i det rette
format.
Når tredjepart har modtaget serverkode, tredjepartskode og serienummer for en ECL regulator, kan de afprøve web-API’et ved at paste et
eksempel fra et senere afsnit ind i en browser såsom Chrome, hvorved de vil få et svar tilbage. JSON Viewer plug-in’et til Notepad++ kan
nemt bruges til at formatere den modtagne JSON tekst til et letlæseligt format.
7.2 Fremtidige versioner
Snitfladen er forberedt til, hvis der i fremtiden skulle ske ændringer i formatet ved, at der skal medsendes en snitfladeversion i forespørgslerne. Versionsindikatoren skal angives på formen:
https://{host}/endpoint/{version}/...
hvor {version} skal erstattes med navnet på versionsformatet. For første version er versionsnavnet ”v1”. Se eksempler i senere afsnit, hvor
det bruges. Endpoint kan være enten masterData eller readings, som bliver forklaret i senere afsnit.
Når nye versioner introduceres, vil der blive annonceret en slutdato for den gamle version, således, at tredjepartsfirmaer har en periode,
hvor de kan opdatere deres software til den nye version.
Efter slutdatoen vil den gamle version ikke længere være tilgængelig. Når en nye version er tilgængelig, vil det blive annonceret på forsiden af ECL Portalen og/eller nyhedsbrev.
{host} skal erstattes med eclwebapi.danfoss.dk for web-API’et tilknyttet den danske ECL portal på ecl.portal.danfoss.dk.
For web-API’et på den internationale ECL Portal skal {host} erstattes med eclwebapi.danfoss.com.
Det er ikke muligt at tilgå ECL regulatorer på den danske portal gennem web-API’et til den internationale portal eller omvendt.
7.3 Tidsformater
Tidsstempler i web-API’et følger ISO 8601 standarden. Det vil sige, at tidsstempler som default vil være i UTC og angives som:
2013-04-18T08:53:00.0Z
I responsbeskeder vil tidsstempler altid være i UTC og tredjepartssoftware kan derefter omregne til andre tidszoner efter behov. I stamdata for individuelle ECL regulatorer angives den tidszone, som er blevet angivet under ECL regulatorens data af ejeren/administratoren
på ECL Portalen.
Det er muligt at angive tidsstempler i andre tidszoner, når man efterspørger data ved at angive den lokale tidszone. Ovenstående
tidsstempel vil dermed udtrykkes som
2013-04-18T10:53:00.0+02:00
”+”-tegnet skal udtrykkes som ”%2B” i forespørgsler og ”-”-tegn skal udtrykkes som ”%2D”
Hvis tiden i ECL regulatoren ikke passer, eller tidszonen på ECL Portalen er forkert, kan tidsstemplerne i de udtrukne data være misvisende.
Aflæsningseksempel for ECL-log udlæst fra ECL Portal-API 2013-10-29 kl. 09:40 dansk normaltid
Den første ”from”-parameter er aktuelt tidspunkt for udlæsning, her vist med tidszone +01:00.
”timestamp” er ECL regulatorens tid for den aktuelle sample.
”receivedTime” er ECL Portalens tid på det tidspunkt, hvor den udlæste data fra ECL regulatoren. Da der udlæses data én gang i timen,
vil der typisk være 4 samples (én for hvert kvarter) med samme ”receivedTime” værdi, men hvis der har været udfald i datakommunikationen, kan der være udlæst mere data på samme tid.
Hvis der ikke er data i databasen for det givne tidspunkt i den givne retning, vil data-feltet i responset være tomt.
Aflæsningseksempel for ECL-log udlæst fra ECL Portal-API’et 2014-04-01 kl. 12:05 dansk sommertid. Her er tiden i ECL regulatoren indstillet forkert, og der er valgt en forkert tidszone (UTC+02:00 i stedet for UTC+01:00) på ECL Portalen.
Den tilhørende log udlæst som en Excel-fil fra ECL Portalen viser:
Her kan man se, at ECL regulatorens tid ved den seneste sample var 2012-10-04 05:15:00, men i dataene fra web-API’et var tiden 2012-1004 02:15:00Z. Der er således 3 timers forskel, som kommer fra tidszone (som er +2 timer) og sommertid (+1 time)
Ved at sammenligne de tre tider (from, timeStamp og receivedTime) kan man tjekke, om tiden er indstillet korrekt i ECL regulatoren, og
om den rigtige tidszone er valgt på ECL Portalen.
8.0 Stamdata service (Master Data)
Her beskrives, hvad stamdata servicen kan anvendes til.
Servicen har i denne første version kun én metode. Metoden er getEclMasterData, og henter alle relevante stamdata for en given ECL
regulator, herunder tilsluttede målere. Det omfatter også data, som er nødvendige for at tolke de aflæsninger, man kan hente. Nedenstående beskriver det konceptuelle indhold af request og response.
8.1 getEclMasterData request parametre
Parameter Beskrivelse Eksempel
serverCode Del af identifikation jf. afsnit 5 omkring sikkerhed. FirmaA
eclSerial Del af identifikation jf. afsnit 5 omkring sikkerhed. 123456792
eclAccessCode Del af identifikation jf. afsnit 5 omkring sikkerhed. Kode5
clientRequestId Valgfri tekst, som kan bruges til at implementere sporbarhed i tredjepart
systemer, der fungerer asynkront. Kan udelades, men vil ellers typisk
være en autogenereret unik ID.
Af sporbarhedsmæssige årsager kommer følgende oplysninger retur i svaret fra serveren.
ElementBeskrivelseEksempel
clientRequestId Det ID, som blev sendt med under
selve requestet for at muliggøre
sporbarhed hos tredjepart.
serverRequestId Serveren tildeler selv hver request
et unikt ID, da der ikke er krav om at
man skal medsende et unikt klient
ID på tværs af kunder. Dette ID kan
bruges, hvis man er i tvivl om serverens
håndtering af et request, da der vil
blive logget forskellige statistiske
informationer omkring hvert request
(se afsnit 5.4 omkring sporbarhed).
location:Street **Gade ECL regulatoren er placeret på
(hvis indtastet på ECL Portal)
A376.1
2013-04-18T08:53:00.0Z
Europe/Copenhagen
Solitudevej
location:StreetNumber **Husnummer ECL regulatoren er
placeret på (hvis indtastet på ECL
Portal)
location:Zip **Postnummer ECL regulatoren er
placeret i (hvis indtastet på ECL Portal)
location:City **By ECL regulatoren er placeret i (hvis
indtastet på ECL Portal)
location:Country **Land ECL regulatoren er placeret i (hvis
indtastet på ECL Portal)
name Navn (indtastet på ECL Portal) Varme i kælderen
description **Beskrivelse (hvis indtastet på ECL
Portal)
portalGroup **Gruppe anført i EP til at gruppere ECL
regulatorer
*Denne streng var oprindelig ”hardwareBuild”, men er siden rettet til det korrekte ”softwareBuild”
** Disse data medsendes kun i stamdata, hvis de er udfyldt på ECL Portalen
Desuden vil der for hver device på ECL regulatoren returneres følgende oplysninger om selve devicet.
type Angiver typen af device. Mulige udfald er ”EclLogDevice”,
”EclConfigInputDevice” og ”EclMBusDevice”
externalDeviceId Eksternt identifikationsnummer for devicet. Skal f.eks. bruges
for at kunne hente aflæsninger for devicet.
nameNavn for devicet. For ECL-log er navnet altid ”EclLog”. For andre
typer er navnet valgfrit på ECL Portalen ved oprettelse.
activeAngiver, hvorvidt device er i brug. Mulige værdier er
”false”/”true”
Kun én ECL-log device kan være aktiv ad gangen, men der kan
oprettes flere EclConfigInputDevices eller EclMBusDevices
på samme tid. Den aktive ECL-log svarer til den aktuelt valgte
portalapplikation
createdOnPortalOprettelsestidspunkt for device i ISO 8601 format2013-04-18T08:53:00.0Z
lastReadSidste aflæsningstidspunkt i ISO 8601 format2013-04-18T08:53:00.0Z
logAppNameAktuelt valgt portalapplikation. Der er mange forskellige
muligheder, så de vil ikke blive nævnt her.
Mulige værdier er:
configInputType
-0-10V ADC
-Digital
-Flow switch
-Pulse
-Frequency
Hvis det er en ukendt type returneres ”7”
Kun for EclConfigInputDevices
EclLogDevice
c0f6563e-2bd0-45149539-db2c0c700d78
EclLog
True
A376.1 example a
0-10V ADC-Pt 1000
configInputDefinedMaxValue*
configInputDefinedMinValue **
configInputCircuitCloseText
configInputCircuitOpenText
configInputSensorId
mbusAddress
mbusSerialNumber
mbusType ***Kun for EclMBusDevices. Type for M-bus-måleren. Består af
channels
* Denne parameter indikerer, hvilken faktisk værdi som 10 V repræsenterer for 0-10 V ADC input
** Denne parameter indikerer, hvilken faktisk værdi som 0 V repræsenterer for 0-10 V ADC input
*** Kendte typer er:
Kun for EclConfigInputDevices af typen 0-10 V ADC
Kun for EclConfigInputDevices af typen 0-10 V ADC
Kun for EclConfigInputDevices af typen ”Digital” eller ”Flow
switch” for tilstanden ”close”
Kun for EclConfigInputDevices af typen ”Digital” eller ”Flow
switch” for tilstanden ”open”
Kun for EclConfigInputDevices. Indikerer hvilken indgang den
konfigurerbare indgang er oprettet på
Kun for EclMBusDevices. Adressen på M-bus-netværket.
Kun for EclMBusDevices. Unikt serienummer for M-bus-måleren
fabrikantkode og typekode
Kanalinformation vises i en senere tabel nedenunder
ABB-02-02 ABB meter
ABB-06-02 ABB DBM
ABB-07-02 ABB OD
ACW-09-04 Actaris meter
ACW-0b-04 Actaris meter
ACW-0b-0c Actaris meter
ACW-0f-04 Actaris meter
ACW-14-07 Actaris meter
AXI-04-04 Axis SKS3
BHG-05-04 Brunata meter
BHG-3d-04 Brunata HGQ
BHG-3d-0c Brunata meter
BHG-3d-16 Brunata meter
DEI-14-02 Deif APM 380
DFS-01-04 Danfoss meter
DFS-01-0c Danfoss meter
DFS-20-04 Danfoss Sonometer 1100 Heat meter
DFS-20-0a Danfoss Sonometer 1100 Cooling meter
DFS-25-07 Hydrometer Hydrus
DFS-2b-04 Danfoss Sonometer 1000
DFS-2b-0c Danfoss meter
DFS-2f-04 Danfoss Sonometer 1100
DFS-41-04 Danfoss Sonometer 500
DFS-43-0c Danfoss M-Cal Compact
DFS-50-04 Danfoss Infocal 6
DFS-52-04 Danfoss Infocal 8
EMH-00-02 EMH KIZ
HYD-20-04 Danfoss Sonometer 1100 Heat meter
HYD-20-0a Danfoss Sonometer 1100 Cooling meter
HYD-20-0c Hydrometer meter
HYD-2b-04 Danfoss Sonometer 1000
HYD-2f-04 Danfoss Sonometer 1100
HYD-2f-0c Hydrometer meter
HYD-50-04 Danfoss Infocal 6
HYD-52-04 Danfoss Infocal 8
HYD-95-02 Hydrometer Hydroport
INV-40-07 Sensus HRI b1
ITR-18-04 Itron meter
KAM-01-02 Kamstrup meter
KAM-01-04 Kamstrup meter
KAM-01-0c Kamstrup Multical III
KAM-02-04 Kamstrup Multical 401
KAM-07-04 Kamstrup meter
KAM-07-0c Kamstrup meter
KAM-08-04 Kamstrup meter
KAM-08-0c Kamstrup Multical 601
KAM-0b-04 Kamstrup Multical 402
KAM-0b-0c Kamstrup meter
KAM-0f-04 Kamstrup meter
KAM-0f-0c Kamstrup Multical 801
KAM-0f-16 Kamstrup meter
KAM-11-04 Kamstrup meter
KAM-11-0c Kamstrup meter
KAM-15-04 Kamstrup meter
KAM-1b-16 Kamstrup Multical 21
KAM-1c-04 Kamstrup Multical 602
LDR-01-02 Unknown meter
LSE-10-04 Landis & Staefa electronic meter
LUG-02-04 Landis & Gyr
LUG-04-04 Landis & Gyr meter
REL-41-07 Relay meter
UNKNOWN Label for unknown M-bus meter type
SEN-0e-04 Sensus meter
SEN-52-07 Sensus meter
SVM-30-0c Svensk Värmemätning SVM meter
WZG-03-07 Neumann & Co. Wasserzähler meter
mbusChannelTypeAnvendes, for m-bus devices, til at
angive kanalens type. Afhænger af
M-bus-måler- typen, så nye målere kan
indeholde nye værdier. Mulige værdier
er:
-ENERGY
-VOLUME
-MASS
-POWER
-VOLUME_FLOW
-VOLUME_FLOW_EXT
-MASS_FLOW
-FLOW_TEMPERATURE
-RETURN_TEMPERATURE
-TEMPERATURE_DIFFERENCE
-EXTERNAL_TEMPERATURE
-PRESSURE
-DATE_TIME
-ON_TIME
-OPERATING_TIME
-VOLTAGE
-CURRENT
-DATE
-STATUS
-SUBUNIT
-TARIF
VOLUME_FLOW
* ) Navnet afhænger bl.a. af devicetypen, som forklaret herunder
For EclConfigInput devices kan navnet indtastes af ejer/administrator på ECL Portalen
For EclLog devices afhænger navnet af sensornummeret
Sensor 1 hedder S1, sensor 2 hedder S2 osv.
Referenceværdi for sensor 2 hedder RefS2, referenceværdi for sensor 3 hedder RefS3 osv.
Derudover logger nogle applikationer visse signaler, som ikke kommer direkte fra sensorerne.
Disse signaler navngives efter deres PNU/ID. For eksempel logges i A230.1 PNU’en 11098,
som er den beregnede vindstyrke. Den får derfor navnet ”11098”. Det er ikke muligt at
navngive alle loggede signaler for alle applikationer, så derfor angives simple navne.
For EclMBusDevices bliver kanalen navngivet ud fra, hvad M-bus-måleren fortæller, hvad den er.
Navnet afhænger derfor af den specifikke målertype, der er anvendt.
Mulige navne er:
-power
-return_temperature
-temperature_difference
-voltage
-volume_flow
-volume
-current
-energy
-flow_temperature
-on_time
-operating_time
-status
Listen med mulige navne kan udvides i fremtiden, hvis nye M-bus-målere påkræver det.
Da en ECL således kan have flere gamle log devices af alle typer, som ikke længere er aktive, bør ejer/administrator sørge for at slette
gamle devices på ECL Portalen, hvis der ikke længere er brug for deres dataindhold.
8.4 Statuskoder for respons
Der vil være fejlhåndtering i henhold til http-standarden, dvs. at svaret vil kunne have én af følgende http status-koder (for alle andre end
kode 200 vil svaret ikke indeholde data, men typisk en tekst, som uddyber problemet).
• 200 – Alt gik godt
• 400 – Ugyldig forespørgsel, typisk fordi en parameter mangler
• 401 – Uautoriseret – dvs. at server- eller tredjepartskode ikke er korrekte
• 404 – ECL ikke fundet
• 500 – Anden ukendt fejl
9.0 Aflæsningsservice (Readings)
Her beskrives, hvad aflæsningsservicen kan anvendes til.
Servicen har i denne første version kun én metode. Metoden er getReadings og henter aflæsninger for et device for en given periode. For
at optimere dataoverførslen, er resultatet holdt så enkelt som muligt, og man vil typisk skulle kende stamdata for ECL regulatoren for at
kunne behandle de modtagne værdier. Nedenstående beskriver det konceptuelle indhold af request og response.
serverCode Del af identifikation, jf. afsnit 5.3 om
sikkerhed.
eclSerial Del af identifikation, jf. afsnit 5.3 om
sikkerhed.
eclAccessCode Del af identifikation, jf. afsnit 5.3 om
sikkerhed.
externalDeviceId Det eksterne identifikationsnummer
for devicet (se stamdata).
Default = ”*”, hvilket betyder, at man
er interesseret i data fra samtlige
devices for ECL regulatoren. Dette er
kun tilladt, når pageSize = 1, så i alle
andre tilfælde skal man identificere et
specifikt device.
from * Starttidspunkt (inklusive) i ISO 8601
direction Om man ønsker aflæsninger fra
c0f6563e-2bd0-4514-9539db2c0c700d78
format for udlæsning fra API. Default
værdien er det aktuelle tidspunkt.
starttidspunktet og fremefter (forward)
eller bagud (reverse). Bemærk, at
sorteringen af aflæsningerne i svaret
afhænger af dette valg. Default =
”reverse”.
FirmaA
123456792
Kode5
2013-04-18T08:53:00.0Z
forward
page Angiver hvilken side man vil have. Hvis
f.eks. pageSize er 1000, og man angiver
at ville have side 2, så springer man de
første 1000 aflæsninger over (typisk
fordi man har fået dem i et tidligere
request). Default = 1. Min = 1.
pageSize Sidestørrelsen, dvs. antallet af
aflæsninger pr. side. Default = 1. Min
= 1. Max = 15.000. Bemærk, at hver
aflæsning kan have op til 16 værdier,
afhængig af antallet af kanaler for
devicet.
clientRequestId Valgfri tekst-ID, som kan bruges
til at implementere sporbarhed i
tredjeparts- systemer, der fungerer
asynkront, da det medsendes i svaret.
Kan udelades, men vil ellers typisk
være en autogenereret unik ID.
*Har man i øvrigt foretaget et nyligt udtræk af stamdata, så ved man også, hvornår man sidst har fået data (lastRead fra devicet).
Eksempel på request efter seneste aflæsning fra et bestemt device
Hvis der ikke er data i databasen for det givne tidspunkt, vil API’et levere de næstkommende data i den angivne retning (forward/reverse).
9.2 getReadings Response
Som svar på et reading request returneres et tracking objekt og et data object.
Tracking object:
Element Beskrivelse Eksempel
clientRequestId Det valgfri tekst-ID, som blev sendt med under selve requestet for at
muliggøre sporbarhed hos tredjepart.
serverRequestId Serveren tildeler selv hver request et unikt ID, da der ikke er krav
om, at man skal medsende et unikt klient ID på tværs af kunder.
Dette ID kan bruges, hvis man er i tvivl om serverens håndtering
af et request, da der vil blive logget forskellige statistiske
informationer om hvert request (se afsnit 5.4 om sporbarhed).
from Gentagelse af request-parameteren eller default værdi, så man har
styr på udgangspunktet
direction Gentagelse af request-parameteren eller defaultværdi, så man har
styr på retningen
page * Gentagelse af request-parameteren eller defaultværdi, så man har
styr på, hvor langt man har ”bladret”.
pageSize Gentagelse af request-parameteren eller defaultværdi, så man har
styr på sidestørrelsen
resultReadings Antal aflæsninger indeholdt i dette svar (denne side – typisk
pageSize med undtagelse af sidste side).
totalReadings ** Antal aflæsninger, der er tilgængelige totalt set, hvis alle sider
bladres igennem
555b7f4d-7e1a-4d76-a4f0be8fb52b7c80
9cd4df10-09cc-4ec7-8b4ec1180b21d9d9
2013-04-18T08:53:00.0Z
forward
1
1000
1000
5642
totalPages ** Antal sider i alt for at udlæse alle aflæsningerne 6
*) For at fortsætte til de næste data vil man således anvende samme request-parametre, men forøge page med én for hver læsning.
**) Angives kun i svaret for side 1, for ikke at skulle tælle rækkerne igen for hver side. Angives desuden kun hvis externalDeviceId er
forskellig fra * (da der alligevel ikke understøttes paging ved forespørgsel på flere devices samtidig).
externalDeviceId ID, der bruges til at identificere device. Se stam
data.
readingsEn samling af readings tilhørende devicetSe næste tabel for indhold
Desuden vil der for hver reading være følgende informationer i svaret.
Element Beskrivelse Eksempel
timestamp ECL regulatorens tidsstempling af aflæsningen.2013-04-18T08:53:00.0Z
receivedTime Hvornår ECL Portalen har logget aflæsningen. 2013-04-18T08:55:32.9Z
manualEntry Kun for EclConfigInput devices af typen ”Pulse”, til hvilke man kan indtaste
værdier manuelt via ECL Portalen.
value1 Værdi 1. Dvs. værdien målt for kanalen, der har readingValueIndex = 1. 41.82
… 15 øvrige value felter som ovenfor, op til value16 som er den sidste
Der er ingen afhængighed af log-frekvensen. Aflæsningerne vil blot blive listet stigende eller faldende (afhængigt af, hvad man har
forespurgt) i kronologisk rækkefølge. Dvs., at der teoretisk set kan ske et skifte i log-frekvensen over en periode.
Der vil være fejlhåndtering i henhold til http-standarden, dvs. at svaret vil kunne have en af følgende http status-koder (for alle andre end
kode 200 vil svaret ikke indeholde data, men typisk en tekst, som uddyber problemet).
• 200 – Alt gik godt
• 400 – Ugyldig forespørgsel, typisk fordi en parameter mangler eller er formateret forkert
• 401 – Uautoriseret – dvs. at server- eller tredjepartskode ikke er korrekte
Her beskrives/eksemplificeres forskellige scenarier for anvendelse af API’et.
API’et kan anvendes til at forespørge data mod en vilkårlig ECL regulator. De konkrete scenarier, som beskrives senere i dette bilag, tager
udgangspunkt i følgende setup:
Der er tale om en A367.1 example e, hvortil der er tilknyttet 3 M-bus-baserede varmemålere samt én puls-baseret vandmåler. På ECL
Portalen fremstår ECL regulatoren med følgende log-enheder (i web-API-termer kaldet devices) under ECL > Log:
Her findes to ECL-logenheder, fordi der først er blevet skiftet portalapplikation fra eksempel a til eksempel e, da ejeren syntes, at det
passede bedre til det aktuelle anlæg. Kun det ene ECL-log er aktivt (True), og det andet indeholder kun gamle data. Alle log-enheder kan
udlæses gennem web-api’et. For at udlæse en specifik log-enhed skal man bruge det korrekte externalDeviceId, som kan findes ved at
udlæse stamdata, hvor det også angives, hvilke log-enheder der er aktive.
Hver log-enhed/device har et antal kanaler, som der logges værdier for. På portalen kan disse bedst ses som en liste under Graf >
Brugerdefineret graf > Opret ny graf, og herunder ses listen, som den tager sig ud for vores eksempel ECL:
Inden man udtrækker aflæsninger for en ECL regulator, vil det være relevant at hente nyeste stamdata. At hente stamdata for
ovenstående ECL regulator sker ved at foretage ét enkelt kald til web-API’et. Det kan ske som en forespørgsel mod REST endpointet, og
svaret vil være i JSON format.
Retur kommer, som tidligere nævnt, stamdata for selve ECL regulatoren samt hver af de tilknyttede devices/log-enheder (i dette tilfælde 6
enheder, da der også returneres stamdata for inaktive devices).
Som beskrevet i afsnit 7.1 medsendes serverkode, ECL serienummer, tredjepartskode samt eventuelt et clientRequestId som parametre i
forespørgslen.
Herunder beskrives, hvilke informationer der er indeholdt i svaret fra web-API’et. Informationer, som omfatter det, man kan se i portalen
(jf. screenshots tidligere i dette bilag) samt yderligere detaljer.
Af sporbarhedsmæssige årsager kommer følgende request-ID-oplysninger retur i svaret fra serveren. Disse relaterer sig ikke til stamdata
registreret i portalen, men alene til den konkrete stamdata-forespørgsel og vil derfor ændre sig for hver forespørgsel.
Description og portalGroup er ikke udfyldt for denne ECL regulator, så de kommer ikke med. Desuden vil der for hver device/log-enhed
på ECL regulatoren returneres en række oplysninger om selve devicet og underliggende kanaler.
I dette afsnit beskrives brugen af web-API’et for at udtrække aflæsninger.
For at kunne udtrække aflæsninger for en given periode (modsat f.eks. blot seneste aflæsning) forudsætter det, at man kender devicets
eksterne ID (som fremgår af stamdataene), og under alle omstændigheder har man behov for at vide, hvilke værdier i en aflæsning, der
udgør hvad (hvilken kanal), og hvad enhed den måles i (fremgår ligeledes af stamdata).
Der er således behov for at kende stamdata af den ene eller den anden grund. Om man henter stamdata for en ECL regulator umiddelbart
forud for, at der hentes data for den, eller om man anvender cachede stamdata, beror på brugsscenariet i tredjepartsapplikationen. Der vil
dog være behov for at hente ajourførte stamdata med mellemrum, da kunden kan foretage ændringer i opsætningen uden at informere
tredjepart. Hvis der skal forespørges aflæsninger over flere sider, er det dog ikke nødvendigt at forespørge stamdata for hver side. De
følgende scenarier antager, at man har stamdata tilgængelige for ECL regulatoren, på den ene eller den anden måde, forud for hentning
af aflæsningsdata.
10.1.6 Udlæs seneste værdier for en eller flere sensorer på en måler tilsluttet ECL regulatoren
At hente seneste aflæsning (som indeholder en værdi for hver sensor/kanal) for en måler/device tilsluttet ECL regulatoren sker ved at
foretage ét enkelt kald til web-API’et. Det kan ske med en forespørgsel mod REST-endpointet, og svaret vil være i JSON-format.
Mange af inputparameterene er som udgangspunkt lagt an på udlæsning af seneste værdi, hvorfor man kun behøver at angive få
parametre i kaldet. Ud over identifikationsparameterene (serverkode, ECL serienummer og tredjepartskode) behøves alene målerens/
devicets eksterne ID (externalDeviceId) fra stamdataene at blive angivet i kaldet.
10.1.7 Udlæsning af senest målte udendørstemperatur
Udetemperaturen er målt via ECL-loggen, som har externalDeviceId = 2cc34b74-2c42-4ad1-a6c4-f27876b1c799, jf. stamdataene, hvorfor
denne værdi sendes med i forespørgslen.
Desuden kommer følgende aflæsning retur i samme svarmeddelelse:
Element Eksempel
timestamp 2013-04-29T09:00:00.0Z
receivedTime 2013-04-18T09:08:31.0Z
manualEntry False
value1 9.84
value2 192
value3 63.95
value4 65
value5 39.14
value6 65
value7 44.98
value8 50
value9 54
value10 28.48
value11 27.16
value12 32.61
value13 31.53
value14 192
Fordi stamdataene definerer, at det pågældende device har 14 kanaler, vil hver reading for dette device have 14 værdier. Af stamdata
kan det desuden ses, at Udetemperatur har readingValueIndex = 1, samt at enheden er °C, dvs. at værdien i °C skal findes som value1 (de
øvrige er i dette tilfælde uinteressante), hvilket i dette tilfælde er 9.84.
10.1.8 Udlæsning af Energi, Volumen, Flow-temperatur og Retur-temperatur for husets hovedmåler
Hovedmåleren for huset er M-bus devicet med externalDeviceId = 8dbb8b99-96a4-498c-b75b-c7453e1ad6c1. Forespørgslen foregår
således på samme måde som ovenstående, blot med et andet ID på devicet:
Det man har udtrykt interesse for her er samtlige 4 værdier, og i henhold til stamdataene er der således kl. 9:05 aflæst:
• Energi (readingValueIndex1): 1.9378E7 Wh
• Volumen (readingValueIndex2): 1546.838 m³
• Fremløbstemperatur (readingValueIndex3): 61.3 °C
• Returløbstemperatur (readingValueIndex4): 42.4 °C
10.1.9 Udlæs seneste værdi for en eller flere sensorer på tværs af målere tilsluttet ECL regulatoren
Udlæsning af seneste værdi på tværs af målere/devices foregår efter præcist det samme princip som for et enkelt device. Forskellen
i forespørgslen er, at man angiver * i stedet for et specifikt externalDeviceId. Der er stadig kun tale om en forespørgsel og et svar fra
serveren.
Forskellen i svarmeddelelsen er, at man så vil modtage ikke blot én aflæsning, men i stedet én aflæsning pr. device, hvilket i vores
eksempel vil sige 6 aflæsninger (3 x M-bus, 2 x ECL-log og 1 konfigurerbart input) i samme meddelelse.
10.1.10 Udlæs en periode af historiske data for en eller flere sensorer på én måler tilsluttet ECL regulatoren
Ganske som ved udlæsning af seneste aflæsning vil aflæsningerne i dette tilfælde også indeholde værdier for samtlige kanaler/sensorer
på måleren, såfremt flere kanaler er tilgængelige. Men ved udlæsning af data for en given periode, vil man ikke kunne forespørge på
tværs af devices på ECL regulatoren, men altid kun én log-enhed ad gangen.
Det er den samme metode, man kalder, blot med flere argumenter, og man kan komme ud for at skulle kalde metoden flere gange for at
”dække” den ønskede periode (afhængig af sidestørrelse, log-frekvens og periodens længde).
Vi tager udgangspunkt i, at man vil hente alle data for vand-hovedmåleren. Det er, jf. stamdataene, et konfigurerbart input modul
(af typen puls med externalDeviceId = 77df9535-9333-4222-b0a5-b5d6d08da1b3), som alene har 1 kanal, hvor det målte er pulser
omsat til m3. Vi kan ligeledes af stamdataene se, at nyeste data er fra 2013-04-29T09:06:00.0Z, og at den først blev kendt af portalen
2013-03-22T06:59:33.0Z. I dette eksempel antager vi, at en sidestørrelse på 500 egner sig bedst til tredjepartsklienten.
Data udtrukket gennem ECL portalen og downloadet i for eksempel Excel format vil være skaleret til kun at have én decimal, men data
udtrukket gennem ECL Portal API’et kan indeholde flere decimaler afhængig af de rådata, der ligger i databasen.
Eksempel på data downloadet via ECL Portalen:
Samme data downloadet via web-API’et:
Bemærk også, at headeren på data er forskellig, jævnfør afsnit 7.2.2 Stamdata.
Dette symbol på produktet angiver, at det ikke må bortskaffes som husholdningsaffald.
Det skal afleveres til den gældende indsamlingsordning for genbrug af elektrisk og elektronisk udstyr.
• Bortskaf produktet gennem de dertil beregnede kanaler.
• Overhold alle lokale og aktuelt gældende love og bestemmelser.