IoT Architecture for Decentralised Heating Control in Households

Gillian Basso, Dominique Gabioud and Pierre Roduit

Institute of Systems Engineering, University of Applied Sciences and Arts Western Switzerland,

Route du Rawyl 47, 1950 Sion 2, Switzerland

Keywords:

Demand Side Management (DSM), Demand Response (DR), Internet of Things (IoT), Smart Grid, Cloud

Computing, cloud.iO, Time Series Consumption.

Abstract:

Over the last two decades, electrical energy generation has become more sustainable (photovoltaic, wind

energy, etc.), but also more distributed, less predictable, and less controllable. Besides storage and ﬂexible

production, Demand Response (DR) offers great opportunities to help stabilizing the electrical grid. This

paper presents how the ﬂexibility of space and domestic hot water heating in existing residential buildings can

be controlled for grid services. It focuses on the Internet of Things (IoT) framework including both hardware

and software to connect existing buildings to a central Virtual Power Plant (VPP) intelligence. It also presents

ﬁeld experiments that were performed during the European FP7 SEMIAH project.

1 INTRODUCTION

Clean energy is becoming one of the most important

challenges of today’s world – as witnessed by the rati-

ﬁcation of the Paris Agreement within the United Na-

tions Framework Convention on Climate Change (Ro-

gelj et al., 2016). To address this challenge, intermit-

tent and non-dispatchable renewable generation (pho-

tovoltaic, wind energy, etc.) has grown dramatically

in Europe and elsewhere over the last few decades.

The distribution of new renewables as well as their

hard to predict intermittent behaviour pose a double

challenge to electrical grid operators:

• keeping a global balance between production and

generation,

• avoiding congestion at the local grid level.

Two categories of solutions can be envisaged: energy

storage or management of ﬂexible consuming proces-

ses. The latter solution is a priori interesting, as it re-

quires only a control infrastructure and no new power

infrastructure.

Demand Response (DR) “is the intentional modi-

ﬁcation of normal consumption patterns by end-use

customers [...]. It is designed to lower electricity use

at times of high wholesale market prices or when sy-

stem reliability is threatened”

. Space and Domes-

https://setis.ec.europa.eu/setis-reports/setis-magazine/

smart-grids/demand-response-empowering-european-

consumer

tic Hot Water (DHW) heating are appropriate pro-

cesses for DR in households, as they both involve

non-negligible energy amounts and as consumption

shifting has minimal impact on inhabitants comfort

(Ma

ıtre et al., 2015).

Section 2 presents the context of the European

FP7 SEMIAH project during which the proposed

solution was developed, deployed and tested. The

section 3 presents the most related works. The un-

derlying ICT architecture is presented in Section 4.

Finally, Section 5 describes the pilot of the project

and its impact on the electrical grid.

2 CONTEXT

The European FP7 SEMIAH project aimed “to pur-

sue a major technological, scientiﬁc and commercial

breakthrough by developing a novel and open ICT in-

frastructure for the implementation of automated De-

mand Response (DR) in households so as to ena-

ble shifting energy consumption from high energy-

consuming loads to off-peak periods with high gene-

ration of electricity from Renewable Energy Sources

(RES)”. The developed DR framework had to cope

with existing appliances and electrical installations in

households which are not designed for DR, as well

as use the domestic internet connection for commu-

nication. The project aimed to provide real-time DR

with a response time in the range of seconds. The SE-

Basso, G., Gabioud, D. and Roduit, P.

IoT Architecture for Decentralised Heating Control in Households.

DOI: 10.5220/0006692400700077

In Proceedings of the 7th International Conference on Smart Cities and Green ICT Systems (SMARTGREENS 2018), pages 70-77

ISBN: 978-989-758-292-9

Figure 1: SEMIAH architecture for DR in households.

MIAH project addressed the full chain required for

the deployment of DR services in households as illus-

trated in Figure 1:

1. a Virtual Power Plant (VPP) providing an aggre-

gated view of the controlled households for grids

and markets,

2. a Household Manager component turning an indi-

vidual building into a dispatchable unit by proces-

sing monitoring signals and generating command

signals,

3. appropriate sensors and actuators installed on the

heating and electrical infrastructure of the buil-

ding.

The VPP component used in the SEMIAH pro-

ject was IWES.vpp developed by Fraunhofer IWES.

The Household Manager was an ad-hoc component

also developed by Fraunhofer IWES. The control loop

performed by the Household Manager is illustrated in

Figure 2. Since heating appliances have their own

built-in controllers, the role of Household Managers

is limited to enable or disable power supply (or act on

the controller in the case of heat-pumps). Input para-

meters for the Household Manager were three tempe-

ratures (inside, outside and boiler) and the amount of

electrical power consumed by the heating appliance.

This article’s focus is on the distributed part of the

ICT architecture, ranging from existing appliances in

buildings to Household Managers.

Household Managers can be deployed either on

a local gateway in each building or in the cloud. A

cloud based solution is described in this article, as

well as its implementation in the trial phase of the SE-

MIAH project.

Figure 2: Control loop for DR service.

3 RELATED WORKS

The combination of cloud computing and Internet of

Things offers a new paradigm with promising topics

for both research and industry (Botta et al., 2014), es-

pecially in the domain of energy management. Nu-

merous papers present a state of the art of IoT techno-

logies. For example, (Al-Fuqaha et al., 2015) descri-

bes how low-level architectures are used to implement

IoT frameworks. (Mazhelis et al., 2013) offers anot-

her overview of the potential of IoT in business. Si-

milarly, cloud computing is detailed in several papers

such as (Srinivasan et al., 2012; Zhang et al., 2010).

The combination of IoT and cloud computing is also

detailed in a few papers. For example, (Daz et al.,

2016) presents lists of components that can be used

to combine IoT and cloud for each level in a glo-

bal architecture. Regarding energy one can mention

that, at the end of their paper, they describe three case

studies with two of those concerning energy manage-

ment. (Zhou et al., 2013) presents a novel architec-

ture combining IoT and cloud computing, including

a review of several existing architectures. This arti-

cle describes also an IoT smart-home scenario, high-

lighting how the combination of IoT and cloud com-

puting offers great opportunities for energy manage-

ment.

Multiple open-source IoT-Cloud framework exist

already with TRL 7 or above. A ﬁrst example is

the modular platform Eclipse Kapua

and its com-

panion the Eclipse Kura open-source framework to

build IoT gateways. This framework, of strong in-

dustrial relevance, is a platform for IoT-Cloud inte-

gration, based on Java OSGi and efﬁcient message

brokering. Eclipse Kapua possesses a modular ap-

proach and provides a comprehensive management of

https://www.eclipse.org/kapua/

IoT Architecture for Decentralised Heating Control in Households

IoT edge nodes, such as their connectivity, conﬁgura-

tion, and application life cycle. Finally, Eclipse Ka-

pua offers a web-based administration console and is

accessible through RESTful API for easy application

integration. cloud.iO and Eclipse Kura/Kapua imple-

ment broadly the same set of services and also share

the same messaging system for devices-cloud inter-

connection (MQTTs). Whereas Eclipse Kura/Kapua

is a standalone mature environment, with a lot of fea-

tures for conﬁguration, deployment, and supervision,

cloud.iO is made up of more scalable, ﬁeld-proven

legacy open-source frameworks, linked by a set of in-

dependent lightweight dedicated components.

The second example is FIWARE

. It is an open-

source platform promoting ”open sustainable ecosy-

stem around public, royalty-free and implementation-

driven software platform standards that will ease the

development of new Smart Applications in multiple

sectors”. The FIWARE platform provides a sim-

ple set of APIs that ease the development of Smart

Applications in multiple vertical sectors. Moreover,

an open-source reference implementation of all FI-

WARE components is publicly available so that multi-

ple FIWARE providers can emerge faster on the mar-

ket with a low-cost proposition. FIWARE focuses on

big data analysis and application dashboards. Such

applications are not part of the cloud.iO framework.

However, cloud.iO could act as a front-end platform

for FIWARE, handling device connectivity and pro-

viding an abstract and homogeneous access to ﬁeld

data.

4 DISTRIBUTED ICT

ARCHITECTURE

4.1 Overview

The control strategy requires the deployment of the

following sensors (generating monitoring signals) and

actuators (consuming command signals) in participa-

ting buildings:

• temperature sensors for space (living room, out-

door) and for hot water (boiler),

• sub-meters to measure the power consumption of

heating appliances,

• a meter to measure the household total consump-

tion,

• power relays to enable/disable power supply

to heating appliances (electric heaters and heat

pumps).

https://www.ﬁware.org

Figure 3: Distributed part of the SEMIAH ICT architecture.

These devices, together with an internet con-

nected gateway, form a wireless Home Area Network

(HAN). Wireless networking is required to limit in-

stallation costs in existing buildings (Gill et al., 2009).

The Process Image is an image, mirrored in a central

data storage solution by the gateway, of the current

status of monitoring and command signals. Four Ap-

plications interact with the Process Image, as illustra-

ted in Figure 3):

• Household Managers (considered as a single Ap-

plication),

• a supervision system, independent of the DR in-

telligence, detecting faulty conditions and genera-

ting alarms accordingly,

• a provisioning system supporting the deployment

of the DR service in new participating buildings,

• a web based interface for consumers.

4.2 The Home Area Network

The HAN is based on Zigbee, with the gateway acting

as coordinator and the sensors/actuators as devices.

Zigbee devices are compliant with the Home Auto-

mation or the Smart Energy proﬁles deﬁned by the

Zigbee Alliance.

4.3 The cloud.iO IoT Framework

4.3.1 Vision and Architecture

The cloud.iO IoT framework aims to simplify the

development of embedded and distributed “Things”

(called Endpoints in cloud.iO) and of cloud-hosted

Applications interacting with them.

The heart of cloud.iO is the Process Image, which

contains an up-to-date centralised mirror of the sta-

tus of distributed Endpoints. An Endpoint updates the

SMARTGREENS 2018 - 7th International Conference on Smart Cities and Green ICT Systems

Figure 4: cloud.iO architecture.

Process Image when the value of a monitoring signal

has changed. Applications can subscribe to monito-

ring signal updates and are notiﬁed on new values.

Applications can modify set points of command sig-

nals in Endpoints (see Figure 4). cloud.iO provides

dedicated APIs for the development of Applications

and Endpoints. The Process Image contains two data-

bases:

• the Process Database, with the current status of

the Endpoints (connection state, list of signals

with their current values) is a searchable database

containing the full information models of all End-

points.

• the History Database, storing time series for mo-

nitoring and command signals, uses the Attribute

names from the Process Database as identiﬁers to

access the time series.

4.3.2 cloud.iO Class Model and Endpoint

Information Model

The cloud.iO class model is derived from the IEC

61850 class model (Mackiewicz, 2006). IEC 61850

is the ICT standard for power utility automation.

The cloud.iO class model allows a tree-shaped

structure deﬁnition and is composed of Endpoints,

Nodes and Objects. A cloud.iO Endpoint is evidently

the equivalent of an Endpoint instance. An Endpoint

is composed of a set of Nodes themselves composed

of Objects. The tree-shaped structure appears in Ob-

jects as an Object can be composed of other Objects.

Attributes, in Objects, represent the roots of the tree.

cloud.iO allows the use of either a free informa-

tion model, without a predeﬁned structure, or a con-

strained information model (i.e. an information mo-

del compliant with some schema). Schemas are de-

ﬁned by Interfaces (similar to Logical Nodes in IEC

61850) and Classes (similar to Common Data Class

in IEC 61850). The resulting class model is presen-

ted in Figure 5. The instances of Nodes, Objects and

Attributes in an Endpoint form its information model.

To identify an Attribute (e.g. to access to its value

in the database), the whole hierarchy is used, its name

is formed according to the following pattern:

1 <E n dpo in t −UUID>/ <no d eL a b e l >/ <o b j e c t L a b e l 1 >/

. . . / <o b j e c t L a b e l N >/ <a t t r i b u t e L a b e l >

4.3.3 Messaging System

Applications, Endpoints and Databases inside the

Process Image are clients of a messaging system.

Messages are composed of a routing topic and of a

message content. Once a client has subscribed to a

topic, it receives all messages featuring that topic. Ta-

ble 1 presents the message routing concept used in

cloud.iO for an Endpoint.

Hence, an Application is notiﬁed of any change

on its subscribed monitoring Attributes. An Endpoint

can freely decide when to update its monitoring Attri-

butes in the Process Image. It is foreseen that Ap-

plications access Databases through the messaging

service, but this function is not yet implemented in

cloud.iO.

4.3.4 Security and Privacy

Endpoints, Applications and Databases connect to the

message broker using SSL/TLS with X.509 certiﬁ-

cate based client and server authentication. SSL/TLS

provides state-of-the-art conﬁdentiality, authentica-

tion and access control. cloud.iO allows managing

access rights to Attributes. An Endpoint belongs to

a User (either a person or an organisation). Users

may grant read/write access permissions on their End-

points to Applications.

4.3.5 Implementation

cloud.iO design philosophy is to take advantage of

the power and reliability of open source components,

with minimal speciﬁc code development. The central

component is the message broker RabbitMQ. It con-

nects Endpoints and Applications using respectively

the MQTTS and AMQPS protocols. The databases

can be deployed using any database management sy-

stem. In the reference implantation of cloud.iO, In-

ﬂuxDB and MongoDB are used for respectively the

IoT Architecture for Decentralised Heating Control in Households

Figure 5: The cloud.iO class model.

Table 1: Message routing for an EndPoint.

Messaging client Subscribes to topics: Generates message with topic

EndPoints /@set/<Endpoint UUID>/* /@update/<monitoring attr name>

Applications /@update/<monitoring attr name> /@set/<command attr name>

Database /* -

history database and the real-time database. If perfor-

mance is required all components can be deployed as

clusters.

4.4 The cloud.iO Framework Applied

for SEMIAH

Gateways play the role of cloud.iO Endpoints. The

Endpoint UUIDs are simply the Ethernet addresses of

the gateways. Zigbee devices correspond to cloud.iO

nodes. Zigbee devices feature their own information

model, deﬁned by the proﬁle they implement. During

deployment, the Provisioning Application elaborates

a conﬁguration ﬁle for the gateway. The ﬁle has a

section per device, and each section contains a set of

mappings between a cloud.iO Attribute and a Zigbee

information model element. The conﬁguration ﬁle it-

self is a cloud.iO Attribute that can be updated remo-

tely. Hence, a Household Manager Application dis-

poses of a logical view of a building, which is inde-

pendent of Zigbee.

5 SYSTEM DEPLOYMENT

In the framework of the European FP7 SEMIAH pro-

ject, a pilot with 200 households was in operation

between October 2016 and May 2017. The deploy-

ment was performed under the responsibility of local

Distribution System Operators (DSOs). One hund-

red households were located in Norway in the Adger

region (DSO: Adger Eneri Net) and another hundred

in Switzerland, canton of Valais (DSO: SEIC Tele-

dis and EnAlpin). Most of the participating house-

holds were single-family houses. As the domestic in-

ternet connection was used for communication, gate-

ways were typically located close to the home router.

The Zigbee devices and gateways were products

of the Develco Products company

. The heating sys-

tems in the different households had a great inﬂuence

on the installed sensors and actuators. Indoor and

outdoor air temperature were measured using battery

powered Zigbee sensors. Boiler temperature sensors

were especially developed for the project: a digital

temperature probe was ﬁxed on the boiler outer wall

and linked to a battery powered Zigbee device.

In Norway, single-phase electrical panel heaters

and water boilers are connected to standard electrical

sockets. Zigbee smart plugs were installed to moni-

tor electrical consumption and enable/disable power

supply. For decades, a DR system called Ripple Con-

trol (RC, shown in Figure 6) has been in operation in

Swiss residential buildings as a tool for peak shaving

on the distribution grid.

Every house is equipped with a RC receiver,

which is conﬁgured with a multicast address. A

RC manager generates telegrams (broadcasted using

https://www.develcoproducts.com

SMARTGREENS 2018 - 7th International Conference on Smart Cities and Green ICT Systems

Figure 6: Principle of Ripple Control (RC).

Figure 7: Real installation. The prosumer meter (top cen-

ter) has been installed and wired in the existing electrical

cabinet.

Power Line Communication) containing orders to

switch on or off relays conﬁgured with a certain mul-

ticast address. RC implements a “blind” open loop

control strategy. The SEMIAH Household Manager

drives the control input on heating appliances, hence

replacing the RC receiver. The SEMIAH control dif-

fers from RC control in two ways: The SEMIAH con-

trol is unicast (each appliance can be controlled indi-

vidually) and closed loop (temperatures and electrical

measurement are input parameters for the Household

Manager). Since the heating appliances have their

own controllers, the SEMIAH Household Managers

cannot turn them off or on but only disable or enable

power consumption. A Zigbee DIN-rail mounted re-

lay with or without power measurement replaced the

RC receiver. A further Zigbee device reads the over-

all power consumption on the ofﬁcial meter (through

the “S0 impulse interface”). In some conﬁgurations, a

Zigbee 3-way sub-meter (called prosumer meter) was

used to measure the photovoltaic production, the he-

ating consumption, the overall household consump-

tion, or the net power exchange with the grid.

Figure 7 shows an example of how the hardware

was deployed in a speciﬁc household. The wiring

work can be observed with a prosumer meter instal-

led in the electrical cabinet. Even if this picture shows

that the solution had to be installed by a professional,

there was always sufﬁcient space in the electric cabi-

nets to ﬁt the SEMIAH hardware.

5.1 System Deployment Costs

During the Swiss pilot deployment, two technicians

went to the different households to perform the in-

stallation. The ﬁrst one was an electrician, working

for the DSO in charge of the area, who did the elec-

trical wiring work. The second one was an IT speci-

alist who installed the gateway and checked the Zig-

Bee and internet connectivity. The whole cloud.iO

infrastructure was deployed and tested before the in-

stallation, to reduce the duration of the installation.

Installations were performed in about 1 hour. With

training and more experience, installations could be

done by only one technician who would do the wiring

and the IT checks. Taking into account travel costs

(∼1h), hardware costs (∼300 CHF), and labour costs

(∼200 CHF), the total cost per installation was about

500 CHF. However, in the scope of this pilot phase,

development, debugging, updates, and problem sol-

ving amounted to a much bigger amount. In a lar-

ger scale deployment, the relative importance of these

costs would proportionally decrease.

5.2 Analysis

Manual power cuts were performed through the provi-

sioning application to test the behaviour of the whole

infrastructure. They aimed at validating multiple ob-

jectives:

• verify the effective real relation between the

cloud.iO abstraction and the installed hardware

(actuators are really operated),

• evaluate the reactivity of the system (delay),

• evaluate the impact of power cuts of various du-

rations on both household temperatures and load

curves.

A series of cuts were conducted during one week,

with enough time between two consecutive cuts to en-

sure that previous cuts had no effect on the current

one. The power cuts were performed during week 8

in 2017 (February 20

to 24

Figures 8 and 9 respectively present the consump-

tion and the temperatures measured for one house-

hold. Two observations can be made based on these

Figures: It is clear that, during the cuts, the amount

of energy consumption is drastically reduced. A 4-

hour cut does not inﬂuence the temperature inside the

IoT Architecture for Decentralised Heating Control in Households

2017-02-23 00:00:00

2017-02-23 06:00:00

2017-02-23 12:00:00

2017-02-23 18:00:00

2017-02-24 00:00:00

2017-02-24 06:00:00

2017-02-24 12:00:00

2017-02-24 18:00:00

Time

1000

2000

3000

4000

5000

Power [W]

House

0.0

0.2

0.4

0.6

0.8

1.0

Figure 8: Consumption of one household during 48 hours,

with two 4-hour cuts (in red). A really short cut (test) before

the ﬁrst 4-hour cut can also be observed.

2017-02-23 00:00:00

2017-02-23 06:00:00

2017-02-23 12:00:00

2017-02-23 18:00:00

2017-02-24 00:00:00

2017-02-24 06:00:00

2017-02-24 12:00:00

2017-02-24 18:00:00

Time

−5

Temperature [C]

Indoor

Outdoor

0.0

0.2

0.4

0.6

0.8

1.0

Figure 9: Temperature of household during 48 hours, with

two 4-hour cuts (in red).

household. We can observe that the indoor tempera-

ture (blue curve in Figure 9) slightly increase during

the ﬁrst cut. This is due to the large increase of the

outdoor temperature (green curve in Figure 9).

Further analyses with a larger number of house-

holds will be realised to better prove the value of such

technology. However, it seems clear that a smart con-

trol of heating systems could have a high inﬂuence on

the energy consumption.

5.3 Installation Drawbacks

Several problems occurred during the pilot phase of

the SEMIAH project but most of them were quickly

detected and resolved soon after. However, one of the

most important remaining problem was range issues

of the ZigBee hardware. Swiss building are especi-

ally strongly built with thick walls that were damping

too much the communication signal. Being close to

the limit had two main effects. It ﬁrst increased the

communication losses and thus induced many inter-

ruption of data collection. Moreover, lost packets lead

to repeated communication at increased transmission

power, taking an heavy toll on consumption and thus

on battery life expectancy that dropped sometime to

just a few months. This problem could not be easily

solved by increasing the meshing with smart plugs,

as sometime signal dampening was already too con-

sequent through a single wall.

The installation of an innovative technology in

households did also sometimes show unpredictable

behaviours of the household inhabitants. For exam-

ple, some participants were turning off their gateway

during part of the day. Some placebo effects were also

observed, with pilot participants complaining about a

lower than usual room or hot water temperature, when

no control was yet performed on their heating appli-

ances.

6 CONCLUSION

This article presents cloud.iO, a IoT infrastructure al-

lowing an abstraction in the cloud of diverse sensors

and actuators installed in households on heating ap-

pliances. It also presents how data is stored and how

the system was deployed in real households to ma-

nage those appliances. It presents the hardware used

and how it was installed inside the households, and

demonstrates the feasibility of deploying such a solu-

tion in a large scale at a relatively low cost. Finally,

it presents effective results of power cuts performed

with this infrastructure.

The described infrastructure was thus deployed

and tested, showing that such a solution can be used

to enable controllers (such as IWES.VPP) to easily

access a big number of heating appliances located in

households.

ACKNOWLEDGMENT

This research was supported by the European FP7

research grant 619560 (SEMIAH project, Scalable

Energy Management Infrastructure for Aggregation

of Households).

REFERENCES

Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari,

M., and Ayyash, M. (2015). Internet of things: A

survey on enabling technologies, protocols, and appli-

cations. IEEE Communications Surveys & Tutorials,

17(4):2347–2376.

Botta, A., de Donato, W., Persico, V., and Pescap, A.

(2014). On the integration of cloud computing and

SMARTGREENS 2018 - 7th International Conference on Smart Cities and Green ICT Systems

internet of things. In 2014 International Conference

on Future Internet of Things and Cloud, pages 23–30.

Daz, M., Martn, C., and Rubio, B. (2016). State-of-the-

art, challenges, and open issues in the integration of

internet of things and cloud computing. Journal of

Network and Computer Applications, 67(Supplement

C):99 – 117.

Gill, K., Yang, S. H., Yao, F., and Lu, X. (2009). A zigbee-

based home automation system. IEEE Transactions

on Consumer Electronics, 55(2):422–430.

Mackiewicz, R. (2006). Overview of iec 61850 and be-

neﬁts. In Power Systems Conference and Exposi-

tion, 2006. PSCE’06. 2006 IEEE PES, pages 623–

630. IEEE.

ıtre, G., Basso, G., Steiner, C., Gabioud, D., and Roduit,

P. (2015). Distributed grid storage by ordinary house

heating variations: A swiss case study. In Digital Sy-

stem Design (DSD), 2015 Euromicro Conference on,

pages 241–249. IEEE.

Mazhelis, O., Warma, H., Leminen, S., Ahokangas, P.,

Pussinen, P., Rajahonka, M., Siuruainen, R., Okko-

nen, H., Shveykovskiy, A., and Myllykoski, J. (2013).

Internet-of-things market, value networks, and busi-

ness models: State of the art report. University of

Jyvaskyla, Department of Computer Science and In-

formation systems, Technical Reports TR-39.

Rogelj, J., Den Elzen, M., H

ohne, N., Fransen, T., Fekete,

H., Winkler, H., Schaeffer, R., Sha, F., Riahi, K., and

Meinshausen, M. (2016). Paris agreement climate

proposals need a boost to keep warming well below

2 c. Nature, 534(7609):631–639.

Srinivasan, M. K., Sarukesi, K., Rodrigues, P., Manoj,

M. S., and Revathy, P. (2012). State-of-the-art cloud

computing security taxonomies: a classiﬁcation of se-

curity challenges in the present cloud computing en-

vironment. In Proceedings of the international confe-

rence on advances in computing, communications and

informatics, pages 470–476. ACM.

Zhang, Q., Cheng, L., and Boutaba, R. (2010). Cloud com-

puting: state-of-the-art and research challenges. Jour-

nal of internet services and applications, 1(1):7–18.

Zhou, J., Leppnen, T., Harjula, E., Ylianttila, M., Ojala, T.,

Yu, C., and Jin, H. (2013). Cloudthings: A common

architecture for integrating the internet of things with

cloud computing. In Proceedings of the 2013 IEEE

17th International Conference on Computer Suppor-

ted Cooperative Work in Design (CSCWD), pages

651–657.

IoT Architecture for Decentralised Heating Control in Households