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