1 / 13

The homeport system

The homeport system. Jeppe Brønsted, Post Doc, Phd Aarhus University, Computer Science Department Denmark. "If you cannot measure it, you cannot improve it." - Lord Kelvin. motivation: sustainable energy consumption in the home.

likens
Download Presentation

The homeport system

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The homeport system • Jeppe Brønsted, Post Doc, Phd • Aarhus University, Computer Science Department • Denmark

  2. "If you cannot measure it, you cannot improve it." - Lord Kelvin 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

  3. HVAC Security Entertainment Lighting 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)

  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. Service composites and controllers compose functionaloty Service layers presents functionality through REST/HTTP interface Bridgelayer relays commands to en from devices LAYER VIEW 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. Z-wave ZigBee Sample deployment service protocol 8 heterogeneous network XYZ

  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?

More Related