Danfoss ECL Portal API Operating guide

Operating Guide

ECL Portal API
Web interface for ECL Portal databases

1.0 Contents

1.0 Contents ..............................................................................................................................................................................................................................................1

2.0 Introduction ........................................................................................................................................................................................................................................ 2

3.0 Version table ....................................................................................................................................................................................................................................... 2

4.0 Glossary .............................................................................................................................................................................................................................................. 2

5.0 General ..............................................................................................................................................................................................................................................3

6.0 Security ..............................................................................................................................................................................................................................................3

6.1 Creating third party code ..................................................................................................................................................................................................... 4

6.2 Assigning access to a third party .......................................................................................................................................................................................5

7.0 Interfaces .............................................................................................................................................................................................................................................. 6

7.1 API format ................................................................................................................................................................................................................................... 7

7.2 Future versions ..........................................................................................................................................................................................................................7

7.3 Time formats .............................................................................................................................................................................................................................. 7

8.0 Master data service ........................................................................................................................................................................................................................ 9

8.1 getEclMasterData request parameters.............................................................................................................................................................................9

8.1.1 Examples of getEclMasterData request parameters .................................................................................................................................... 10

8.2 getEclMasterData response ...............................................................................................................................................................................................10

8.2.1 Example of getEclMasterData response ............................................................................................................................................................ 10

8.2.2 Master data ...................................................................................................................................................................................................................11

8.3 getEclMasterData response ...............................................................................................................................................................................................11

8.4 Status codes for response ...................................................................................................................................................................................................17

9.0 Readings ...........................................................................................................................................................................................................................................17

9.1 getReadings Request ............................................................................................................................................................................................................18

9.2 getReadings Response .........................................................................................................................................................................................................19

10.0 Using the interface .......................................................................................................................................................................................................................21

10.1 Extracting master data .......................................................................................................................................................................................................23

10.1.1 M-bus, Main meter house .................................................................................................................................................................................25

10.1.2 M-bus, Solar heating, small tank ....................................................................................................................................................................26

10.1.3 M-bus, Solar heating, large tank .....................................................................................................................................................................28

10.1.4 ECL log, A367.1 example e ................................................................................................................................................................................30

10.1.5 Extracting readings .............................................................................................................................................................................................33

10.1.6 Read the latest values for one or more sensors on a meter connected to the ECL controller .................................................33

10.1.7 Reading the most recently measured outdoor temperature ...............................................................................................................34

10.1.8 Reading of Energy, Volume, Flow temperature and Return temperature for the house’s main meter ................................35

10.1.9 Read the latest value for one or more sensors across meters connected to the ECL controller .............................................35

10.1.10 Read a period of historical data for one or more sensors on one meter connected to the ECL controller .........................35

10.2 Format differences in data extracted ............................................................................................................................................................................39

© Danfoss |2021.01

AQ131886471802en-010301 | 1

Operating guide ECL Portal API

2.0 Introduction

This document is a description for a third party for use when implementing software clients to extract data from the
ECL Comfort 296 / 310 Portal (ECL Portal).

3.0 Version table

Version Date Change

1.00 25/09/2013 First version.

1.10 25/10/2013 Section added about the creation of third party code, future version, time formats.
JSON examples added for requests and responses.

1.11 29/10/2013 Example added of difference in data extraction from ECL Portal and ECL Portal API.
Example added of time format in readings.

1.12 01/04/2014 A few detailed explanations and examples added.

4.0 Glossary

API Application Programming Interface. An interface for the sharing of application-specific information.

Device A device. Typically used in connection with a log device.

ECL Comfort 296 / 310 A district heating controller model from Danfoss A/S.

HTTPS HyperText Transfer Protocol. An encrypted protocol used to transfer information.

Configurable input Some sensor inputs on an ECL Comfort 296 / 310 controller can be adjusted as an option to measure

temperature, pulse, frequency, 0-10 V analogue signal or digital ON/OFF

Customer A person, company or municipality that wants data extracted from the ECL Portal.

JSON JavaScript Object Notation. An open data format for sharing data between a server and an Internet program.

M-bus A communication protocol typically used by heat and energy meters.

Paging Division into pages. In order to avoid too much information being transferred at one time, a volume of data is

divided into a number of pages, only one of which is read at a time.

Reading A reading. Log data extracted from the web API from a log device.

Request A request to the web API.

Response Response from the web API server to a request.

REST Representational State Transfer. A software architecture style that can be used to design Internet services.

Server code A unique code issued by Danfoss to a third party.

SSL Secure Sockets Layer. Encryption for the secure sharing of information used, for example on the Internet

(HTTPS).

Master data Base data for an ECL Comfort 296 / 310 controller.

Third party code A code created by the customer in the ECL Portal, which the customer issues to a third party.

URL Uniform Resource Locator. An Internet address.

UTC Coordinated Universal Time. A standard for coordinated time based in Greenwich, London. Time zones are

expressed with reference to UTC.

Web API An API adapted for the Internet.

Third party An external company engaged by a customer to develop software to extract data from the ECL Portal to an

external system. Can be the customer.

2 | © Danfoss| 2021.01

AQ131886471802en-010301

Operating guide ECL Portal API

5.0 General

The data that is available via the ECL Portal web API depends on the ECL application key installed in the ECL Comfort 296 / 310 in
question. I.e. the data set available is different for each ECL application type and can also depend on the various external data collection
devices, such as M-bus meters and configurable inputs with which ECL controllers can be fitted.

The ECL Portal retrieves data from the ECL controllers once an hour just after the top of the hour. The integrated ECL Log contains
application-specific signals such as temperatures measured and temperature references, as well as wind speed, pressure or flow,
depending on the application installed. The ECL log contains data recorded at 15-minute intervals. If the customer has set up
configurable inputs or connected M-bus meters, the current values of these will also be retrieved once an hour.

If it is not possible to retrieve data from an ECL controller because of a communication error or for some other reason, an attempt will be
made to retrieve the ECL log when the next collection takes place one hour later. The internal ECL log in the ECL controller contains data
for the last ten days, so if it has not been possible to retrieve the log from an ECL controller for ten days, data will be lost from the ECL
portal and will thus not be available through the web API.

As soon as data is available on the ECL Portal, it will also be available through the ECL Portal web API. It is not possible to retrieve data
through the web API that is not available on the ECL Portal. If, for example, a customer deletes an ECL log or M-bus meter on the ECL
Portal, it will no longer be available through the web API either.

Data is not saved for configurable inputs and M-bus meters in the ECL controller, so historical values will not be read when the logs are
next retrieved if there has been no contact with the ECL Portal.

Guides for individual ECL applications are available at www.ecl.doc.danfoss.com, if it is necessary for a third party to have more specific
knowledge of the data that can be extracted from the ECL controllers.

A description of communication for ECL controllers may be found here:
http://heating.danfoss.com/PCMPDF/VILGV502_ECL_Comfort_210_296_310_Communication.pdf or by Googling “ecl communication
description” to find the latest version. The communication description contains, among other things, a general list of parameters that are
logged by some applications.

6.0 Security

As this is an external interface from the ECL Portal server to the outside world, it is particularly important to make sure that it is not
possible to gain access to other parties’ data.

The first element in securing data is identification, so that you can validate whether the client that is calling the ECL Portal web API is
authorised to view the data being requested. You must therefore always specify the following in requests:

• Server code. This is issued by Danfoss to a third party or customer, so that the opening of the data interface is an active process
performed by Danfoss. This involves a setup in connection with the conclusion of a legal contract.

• ECL serial number. Used to identify an ECL controller of interest. The serial number may be found inside the ECL controller’s menu or
at the ECL Portal

• Third party code. Created by the customer in the ECL Portal and issued to a third party.

Not only must the third party or customer have stated a server code and know the serial number, but the customer himself must link third
party codes to the ECL controller. This provides the customer with the possibility of controlling which third party people and systems they
wish to allow to extract the data by assigning them various third party codes, which can of course also be revoked individually.

This means that in order to obtain data from a given ECL controller, you must know its serial number, have a server code issued from
Danfoss and have assigned yourself, your system or third party an ECL-specific third party code.

Just as with traditional user name/password combinations, data will only be able to fall into the wrong hands if the combination is
compromised, as in such an eventuality an external party would only be able to use the same codes and perform his own requests.
Security is thus dependent in this scenario on how the customer and the third party protect this information.

Server codes are issued to the customer/third party individually and may not be shared by a number of customers, as under the legal
contract such party may be cancelled when the contract expires or in the event of abuse.

Data communication through the web API requires SSL support. If a client sends requests via HTTP, it will be redirected to HTTPS.

AQ131886471802en-010301

© Danfoss | 2021.01 | 3

Operating guide ECL Portal API

6.1 Creating third party code

Use the “Third party codes” menu.

Give a name to the third party code in order to keep track of all
codes, and select the setting “Enabled” to render the code active.

The code will now appear in the list of codes created.

Click on the “ECLs” link to go to the page where the code can be
assigned to specific ECL controllers.

You can assign the same code here to several ECL controllers, and
you can assign several codes to the same ECL controller, so that
you can better control who has access to what.

4 | © Danfoss| 2021.01

AQ131886471802en-010301

Operating guide ECL Portal API

6.2 Assigning access to a third party

a) If the customer has not previously provided the third party in question with access to data for some ECL controllers administered by

the end customers, the end customer sets up a code for the third party under the menu item ECL > Third party codes.
b) The end customer links the relevant ECL controller to the relevant third party code.
c) The end customer notifies the third party of the ECL serial number and the third party code.

With these three pieces of information (server code, ECL serial number, third party code), the third party now has the ability to access data
for the ECL controller via the web API.

The conceptual interfaces that will be accessible via the web API are described here. Conceptual means what you can request, including
which items of information are required in order to request, as well as which items of information you receive in return from such requests.

When you retrieve readings for a given period, it may be the case that the period includes a large number of readings, which is not suitable
for transfer via an HTTP request in one action. It is therefore a good idea to operate using what is known as paging, i.e. when you make
your request, in addition to indicating the period, you can indicate how many readings you wish to receive at a time. From the responses
you receive in return, you can then see whether you have received all readings on the “first page” (/response) or whether you have to
retrieve more, and how many you can expect to have to retrieve in total. On the basis of this you can then request the next page, and so
on. At the same time, the system defines a default page size and a maximum page size, so you do not need to specify a page size, and nor do
you run the risk that a client will ask for an unrealistically large load of data in one single request.

As an ECL controller can operate with several log devices and at different log frequencies, it is difficult to create a logical “page break”
in the event that not all data can be returned at one time. When you retrieve readings, it is good to know in advance which devices are
accessible on an ECL controller, which ones are active, etc. There is thus a need to be able to obtain this information when readings are to
be retrieved, but also if a third party wishes to store/synchronise details of the ECL controllers, devices and channels – what is known as
master data.

Examples of accessible devices and channels in an ECL Comfort 296 / 310 controller with a given application, which has connected two
heat meters via M-bus:

AQ131886471802en-010301

© Danfoss | 2021.01 | 5

Operating guide ECL Portal API

7.0 Interfaces

Device type Channels Description

EclLogDevice S1 These channels belong to sensors and reference

values used by the application.

S2

S3

S4

S5

S6

S7

RefS3

RefS4

RefS5

RefS9

RefS10

EclConfigInputDevice S9 This input is not used by the application and

therefore be used as a configurable inpu

EclConfigInputDevice S10 This input is not used by the application and

therefore be used as a configurable input

EclConfigInputDevice S11 This input is not used by the application and

therefore be used as a configurable input. Requires ECA
32 module in ECL Comfort 296 / 310.

EclConfigInputDevice S12 This input is not used by the application and

therefore be used as a configurable input. Requires ECA
32 module in ECL Comfort 296 / 310

EclConfigInputDevice S13 This input is not used by the application and

therefore be used as a configurable input. Requires ECA
32 module in ECL Comfort 296 / 310

EclMBusDevice volume_flow

flow_temperature

volume

These channels are accessible in the relevant
meter, which is connected via M-bus.

t.

.

.

.

can

can

can

can

can

heat

EclMBusDevice volume_flow

flow_temperature

volume

energy

return_temperature

6 | © Danfoss| 2021.01

These channels are accessible in the relevant
meter, which is connected via M-bus.

AQ131886471802en-010301

heat

Operating guide ECL Portal API

For this reason, there will be a division of the services that the web API makes available. One service that operates with master data and
one service that operates with readings. To make the transfer of readings as optimal as possible in terms of performance, these calls will
only return the raw values. In order to interpret them (e.g. in terms of units, etc.), they must then be aligned with master data.

7.1 API format

The web API is a REST (REpresentational State Transfer) API via HTTPS(GET) requests, in which the argument is extracted as a combination of
URL components and URL query parameters.

The response format will always be minimalist JSON due to performance. Later in this document there are examples of requests in the
correct format.

When the third party has received the server code, third party code and serial number for an ECL controller, they can test the web API by
pasting an example from a later section into a browser such as Chrome, after which they will receive a response. The JSON Viewer
Notepad++ can easily be used to format the JSON text received into an easily readable format.

7.2 Future versions

The interface is prepared for any changes in the future in the format, as an interface version must accompany the requests. The version
indicator must be specified in the following form:

https://{host}/endpoint/{version}/...

plug-in for

in which {version} must be replaced by the name of the version format. The version name for the first version is “v1”. See examples where
this is used in a later section. The endpoint can be either master data or readings, as described in subsequent sections.

When new versions are introduced, an end date will be announced for the old version, so that third party companies have a period during
which they can update their software to the new version.

The old version will no longer be available after the end date. When a new version is available, this will be announced on the front page of
the ECL Portal and/or the newsletter.

{host} must be replaced by eclwebapi.danfoss.dk for the web API linked to the Danish ECL Portal at ecl.portal.danfoss.dk.
For the web API on the international ECL Portal, {host} must be replaced by eclwebapi.danfoss.com.
It is not possible to access ECL controllers at the Danish portal through the web API for the international portal, or vice versa.

7.3 Time formats

Time stamps in the web API follow the ISO 8601 standard. This means that time stamps will be in UTC by default and will appear as:

2013-04-18T08:53:00.0Z

Time stamps in response messages will always be in UTC, and third party software may then convert to other time zones as required.
In master data for individual ECL controllers, the time zone stated is the one that was specified under the ECL controller’s data by the owner/
administrator on the ECL Portal.

It is possible to specify time stamps in other time zones, when you request data by specifying the local time zone. The above time stamp
will then be expressed as

2013-04-18T10:53:00.0+02:00

The “+” symbol must be expressed as “%2B” in requests and the “-” symbol must be expressed as “%2D”

If the time in the ECL controller does not match, or the time zone in the ECL Portal is incorrect, the time stamps in the data extracted may
be misleading.

Sample reading for ECL log taken from the ECL Portal API on 29/10/2013 at 09:40 Danish standard time.

AQ131886471802en-010301

© Danfoss | 2021.01 | 7

Operating guide ECL Portal API

{
“tracking”: {
“serverRequestId”: “0af3a240-0a36-45ae-b8af-9e24f52103eb”,
“from”: “2013-10-29T09:40:45.318+01:00”,
“direction”: “reverse”,
“page”: 1,
“pageSize”: 1000,
“resultReadings”: 1000,
“totalReadings”: 69346,
“totalPages”: 70
},
“data”: [{
“externalDeviceId”: “cfbd9943-9e49-4d19-a052-6424de7041e8”,
“readings”: [{

“id”: 124280485,
“timestamp”: “2013-10-29T07:45:00.0Z”,
“receivedTime”: “2013-10-29T08:00:04.55Z”,
“manualEntry”: false,
“value1”: 192,
“value2”: 48.09,
“value3”: 90,
“value4”: 192,
“value5”: 28.5,
“value6”: 192,
“value7”: 50,
“value8”: 192,
“value9”: 0,
“value10”: 0
},
{
“id”: 124280484,
“timestamp”: “2013-10-29T07:30:00.0Z”,
“receivedTime”: “2013-10-29T08:00:04.52Z”,
“manualEntry”: false,
“value1”: 192,
“value2”: 48.09,
“value3”: 90,
“value4”: 192,
“value5”: 28.5,
“value6”: 192,
“value7”: 50,
“value8”: 192,
“value9”: 0,
“value10”: 0
} ]
}]
}

The first “from” parameter is the current reading time, here shown with the time zone +01:00.
“timestamp” is the ECL controller’s time for the sample in question.
“receivedTime” is the time in the ECL Portal at the point in time when it extracted data from the ECL controller. As data is extracted once
an hour, there will typically be four samples (one for each quarter of an hour) with the same “receivedTime” value, although if there has
been a failure in data communication, more data may have been extracted at the same time.

If there is no data in the database for the specified time in the specified direction, the data field in the response will be empty.

Sample reading for ECL log extracted from the ECL Portal API on 01/01/2014 at 12:05 Danish Summer Time. The time in the ECL controller
has been wrongly set here, and an incorrect time zone has been selected (UTC+02:00 instead of UTC+01:00) in the ECL Portal.

8 | © Danfoss| 2021.01

AQ131886471802en-010301

Operating guide ECL Portal API

{
“tracking”: {
“serverRequestId”: “07c49346-aa90-4e45-9f20-610931d5887e”,
“from”: “2014-04-01T12:05:32.430+02:00”,
“direction”: “reverse”,
“page”: 1,
“pageSize”: 1,
“resultReadings”: 14
},
“data”: [{
“externalDeviceId”: “5a84dbcc-a9c0-474f-9c12-5db4884fc6ed”,
“readings”: [{
“id”: 79779710,
“timestamp”: “2012-10-04T02:15:00.0Z”,
“receivedTime”: “2014-04-01T10:00:52.293Z”,
“manualEntry”: false,
“value1”: -1.25,
“value2”: -9.46,
“value3”: 26.17,
“value4”: 26.66,
“value5”: -24.21,
“value6”: 45.84,
“value7”: 17.8,
“value8”: 40.24,
“value9”: 10,
“value10”: 50.83,
“value11”: 30,
“value12”: 0
}]
}]
}

The associated log extracted as an Excel file from the ECL Portal shows:

You can see here that the ECL controller’s time at the last sample was 2012-10-04 05:15:00, while the time in the data from the web API
was 2012-10-04 02:15:00Z. There is thus a three-hour difference, which comes from the time zone (which is +2 hours) and summer time
(+1 hour)
By comparing the three times (from, timeStamp and receivedTime), you can check whether the time has been set correctly in the ECL controller,
and whether the correct time zone has been selected in the ECL Portal.

8.0 Master data service

This section describes what the master data service can be used for.
In this first version, the service has only one method. The method is getEclMasterData, and it retrieves all relevant master data for a given
ECL controller, including connected meters. It also includes data that is necessary to interpret the readings that can be retrieved. Below is
a description of the conceptual content of request and response.

8.1 getEclMasterData request parameters

Parameter Description Example

serverCode Part of identification cf. section 5 on security. CompanyA

eclSerial Part of identification cf. section 5 on security. 123456792
eclAccessCode Part of identification cf. section 5 on security. Code5
clientRequestId Optional text that can be used to implement traceability in third party

systems that function asynchronously. Can be omitted, but would otherwise
typically be an auto-generated unique ID.

555b7f4d-7e1a-4d76-a4f0­be8fb52b7c80

AQ131886471802en-010301

© Danfoss | 2021.01 | 9

Operating guide ECL Portal API

8.1.1 Examples of getEclMasterData request parameters

Examples with version=v1, serverCode=CompanyA, eclSerial=123456792, eclAccessCode= Code5.

https://{host}/masterdata/{version}/{eclSerial}?serverCode={serverCode}&eclAccessCode={eclAccessCode}

https://eclwebapi.danfoss.dk/masterdata/v1/123456792?serverCode=FirmaA&eclAccessCode=Kode5

8.2 getEclMasterData response

The following information is returned in the response from the server for reasons of traceability.

Element Description Example

clientRequestId The ID that was sent during the actual

request in order to permit traceability
in the third party.

serverRequestId The server itself assigns a unique ID to

each request, as there is no requirement
that you must send a unique client ID
across customers. This ID can be used if
you are in any doubt about the server’s
handling of a request, as various pieces
of statistical information will be logged
about each request (see section 5.4 on
traceability).

8.2.1 Example of getEclMasterData response

Master data is described in greater detail in the next section.

{
“tracking”: {
“serverRequestId”: “d4b86aa4-f4a0-4ce8-9f14-3c7bd3cc3c80”
},
“masterData”: {
“application”: “A376.1”,
“applicationVersion”: “4.00”,
“hardwareModel”: “ECL 296 / 310, 230 V”,
“hardwareVersion”: “A”,
“softwareBuild”: “7232”,
“hardwareProductionTime”: “3.2010”,
“firmwareVersion”: “1.48”,
“serialNumber”: “123456792 ”,
“createdOnPortal”: “2012-09-07T08:16:53.543Z”,
“timezone”: “Europe/Copenhagen”,
“location”: {
“street”: “Solitudevej”,
“streetNumber”: “13A”,
“city”: “Andeby”
},
“name”: “ECL name”,
“portalGroup”: “Test ECL controllers”,
“devices”: [List of log devices has been moved in this example]
}
}

555b7f4d-7e1a-4d76-a4f0­be8fb52b7c80

9cd4df10-09cc-4ec7-8b4e­c1180b21d9d9

10 | © Danfoss| 2021.01

AQ131886471802en-010301

Operating guide ECL Portal API

8.2.2 Master data

The following basic master data is also returned with the response for the actual ECL controller.

8.3 getEclMasterData response

The following information is returned in the response from the server for reasons of traceability.

Element Description Example

application Which application the ECL controller

is running.

applicationVersion Version of the application 4.00

hardwareModel Hardware model number ECL 296 / 310, 230 V

hardwareVersion Hardware version A

softwareBuild * Software build number 7232

hardwareProductionTime Hardware production time 3.2010

firmwareVersion Firmware version number 1.48

serialNumber Serial number 123456792

createdOnPortal Date when the ECL controller was

created on (first linked to) the portal

timezone Time zone in which ECL controller is

located (selected on ECL Portal)

location:Street ** Street in which ECL controller is

located (if entered on ECL Portal)

location:StreetNumber ** House number at which ECL controller

is located (if entered on ECL Portal)

A376.1

2013-04-18T08:53:00.0Z

Europe/Copenhagen

Solitudevej

13A

location:Zip ** Postcode at which ECL controller is

located (if entered on ECL Portal)

location:City ** Town/city in which ECL controller is

located (if entered on ECL Portal)

location:Country ** Country in which ECL controller is

located (if entered on ECL Portal)

name Name (entered on ECL Portal) Heating in basement

description ** Description (if entered on ECL Portal) Basement

portalGroup ** Group set up in EP to group ECL

controllers

* This string was originally “hardwareBuild”, but has since been corrected to “softwareBuild”.
** This data is only sent with master data if it has been entered in the ECL Portal.

Furthermore, for every device on the ECL controller, the following information about the actual device will be returned.

AQ131886471802en-010301

6400

Andeby

Denmark

Group1

© Danfoss | 2021.01 | 11

Operating guide ECL Portal API

Element Description Example

type Specifies the type of device. Possible results are “EclLogDevice”,

“EclConfigInputDevice” and “EclMBusDevice”.

externalDeviceId External ID number for the device. Must be used, for example,

to be able to retrieve readings for the device.

name

active Denotes whether the device is in use. Possible values are

createdOnPortal Creation time for device in ISO 8601 format. 2013-04-18T08:53:00.0Z

lastRead Time last read in ISO 8601 format. 2013-04-18T08:53:00.0Z

logAppName Portal application currently selected. There are many different

configInputType

Name of the device. For an ECL log, the name is always “EclLog”. For
other types, any name can be used when created on the ECL Portal

“false”/“true”.
Only one ECL log device may be active at a time, although several
EclConfigInputDevices or EclMBusDevices can be created at the
same time. The active ECL log corresponds to the portal application
currently selected.

possibilities, so they will not be mentioned here.
Possible values are:

-0-10V ADC

-Digital

-Flow switch

-Pulse

-Frequency
If it is an unknown type, “7” is returned.
For EclConfigInputDevices only.

EclLogDevice

c0f6563e-2bd0-4514­9539-db2c0c700d78

EclLog

.

True

A376.1 example a

0-10V ADCPt 1000

configInputDefinedMaxValue* For EclConfigInputDevices of the type 0-10 V ADC only. 4

configInputDefinedMinValue ** For EclConfigInputDevices of the type 0-10 V ADC only. 2

configInputCircuitCloseText For EclConfigInputDevices of the type “Digital” or “Flow switch”

for status “close” only.

configInputCircuitOpenText For EclConfigInputDevices of the type “Digital” or “Flow switch”

for status “open” only.

configInputSensorId For EclConfigInputDevices only. Indicates at which input the

configurable input has been created.

mbusAddress For EclMBusDevices only. The address of the M-bus network. 15

mbusSerialNumber

mbusType *** For EclMBusDevices only. Type of M-bus meter. Consists of

channels Channel information is shown in a later table below.

* This parameter indicates which actual value 10 V represents for 0-10 V ADC input.
** This parameter indicates which actual value 0 V represents for 0-10 V ADC input.
*** Known types are:

For EclMBusDevices only. Unique serial number for the M-bus meter

manufacturer code and type code.

. 06120815

Signal OK

No signal

S9

KAM-08-0c

12 | © Danfoss| 2021.01

AQ131886471802en-010301