21/05/2010 AU DEPARTMENT OF COMPUTER SCIENCE FACULTY OF SCIENCE AARHUS UNIVERSITY TATIONpRESEN The...

21/05/2010AU DEPARTMENT OF COMPUTER SCIENCEFACULTY OF SCIENCEAARHUS UNIVERSITY

TATIONpRESEN

The homeport systemJeppe Brønsted, Post Doc, PhdAarhus University, Computer Science DepartmentDenmark


JEPPE BRØNSTEDPOST DOC, PHD

2

motivation:sustainable energy consumption in the home› Optimize energy consumption through integration of home automation

technologies› Optimization principles

› Use less - by e.g. letting a single switch turn all lights off› Use at the optimal time of day - by e.g. using the washing machine at night› Store energy - by e.g. using floor heating at night

› Optimization points› Suboptimal energy consumption - e.g. by having lights on in empty rooms

› Mitigated by automization - e.g. by connecting the alarm system with the light control

› Wasteful consumption - e.g. by taking long showers› Mitigated by change of behavior - e.g. by visualizing energy consumption

› Prerequisite: Integration of energy consuming devices in the home

"If you cannot "If you cannot measure it, you measure it, you

cannot improve it."cannot improve it."- Lord Kelvin- Lord Kelvin



3

Home automation integration

› Home Automation consists of multiple subdomains› With different communication requirements

› Multiple standards and vendors and communication standards exists within each subdomain

› It cannot be assumed that all devices are controlled by the same entity› (would make integration task easy)

› Approaches to integration› Standardization (as in telecom)› Co-existence og protocols

› (communication through homeport) LightingLightingEntertainEntertainmentment

HVACHVAC SecuritySecurity



4

requirements› Functionality

› Connect home automation devices to achieve improved comfort, security, and optimized energy consumption

› Business requirements› The architecture should, to a large degree, support current

business models› It should not require vendors to give full access to devices

› The architecture should have no impact on existing end-product designs

› Open to newcommers - no single commercial entity should control infrastructure



5

Architectural quality requirements› Modifiability

› Newly added devices should not affect already deployed equipment

› Possible to connect newly added devices to existing applications as well as new ones

› Usability› The architecture should enable easy user configuration - zeroconf,

etc. › Scalability

› Hundreds of devices› Should scale to low end devices to ensure cost efficiency



6

LAYER VIEW

Bridgelayer relays commands to en from

devices

Service layers presents functionality through REST/HTTP interface

Service composites and controllers compose

functionaloty

End-devices connected to subsystems.

E.g. Z-wave devices



7

Use of web-technology› Motivation

› Low barrier-of-entry:› Most platforms supports› HTTP, URLs and HTML/XML/json

› Device, programming language and service independence› Easy to implement

› HTTP metods with semantics: › GET, PUT, POST, DELETE› Clients and servers only has to support those commands - little required pre-knowledge

› Has enough expressive power› Demonstrated on the web

› Enables use of mash-up technology› Implementation

› Url hierarchy› services› composites› subscriptions - push and pull (streaming)› gui

› Accept-header determines content-type of reply› XML, plain, HTML, json

› Browser can be used for inspection› XML schemas for basic types



8

Sample deployment

8

ZigBeeZigBee Z-waveZ-wave XYZXYZ

heterogeneous network

service protocol



9

DEPLOYMENT VIEW



10

Composite service - example› Simple switch-lamp composite› Composite subscribes to switch events› Use HTTP-streaming

› GET subscriptions/subscribe/services/switch

› When event is received the lamp state is toggled› PUT services/lamp ‘on’

› Composite can be reconfigured› PUT services/switch-lamp-composite/lamp ‘services/lamp-2’› PUT services/switch-lamp-composite/switch ‘services/switch-2’



11

Different types of users› End-user (normal use)

› Perceives the system only though devices (lamps, switchs outlets, panel displays, etc.)

› End-user (configuration/installation)› Access system though user-interface(PC app, web-browser, cell phone,

or similar.)› End-device vendor

› Does have to know the existence of the Homeport system› Controller/composition developer

› Use services via HTTP/REST.› Gateway developer

› Responsible for presenting device functionalty through HTTP/REST interface (have to be a sub-system expert)› Based on standard libraries



12

summary and future work› We have seen that

› Different technologies can co-exists (zwave and zigbee)› Commercial vendors are willing to partly open up systems

› as long as they remain in control› System requires no updates to end-devices › (when e.g. new devices are introduced)› Subsystem protocol updates are localized (zwave does not affect zigbee)

› Currently we are working on zeroconf service and device discovery› Focus has been on the lighting domains - needs to be expanded (currently

working on heating system)› Access policies to ensure safe operation› Energy consumption of infrastructure (currently ~5 watt per infrastructure

node)



13

thank you - Questions?

21/05/2010 AU DEPARTMENT OF COMPUTER SCIENCE FACULTY OF SCIENCE AARHUS UNIVERSITY TATIONpRESEN The...

Documents

Transcript of 21/05/2010 AU DEPARTMENT OF COMPUTER SCIENCE FACULTY OF SCIENCE AARHUS UNIVERSITY TATIONpRESEN The...