From OpenHome
Contents |
Introduction
This document provides a technical overview of the ohWidget home automation system and details about the physical architecture it uses. It introduces the concepts, terminology and interactions of each component of an ohWidget system.
This document does not provide low-level technical information such as hardware specifications of the Nodes nor code examples from the ohWidget API.
ohWidget
ohWidget makes use of three distinct components: Widgets, Control Points and Nodes. This document uses these three terms heavily throughout and are defined simply as follows:
Widget
Any device in an end-user's home that can be remotely controlled. Widgets can range in complexity from simple single-service lights to multi-service audio/visual devices.
Control Point
A device used by the end-user to access the services provided by each Widget.
Node
The device used to aggregate devices and services published by Widgets, for quick and easy access by Control Points.
Together these three classes of device can be used in any number to create an ohWidget home automation system.
Node manufacturer benefits
ohWidget supports Node manufacturers by:
- providing a protocol-independent framework from which to build the communications hardware most suited to each manufacturer
- removing the tightly coupled nature of Control Points and devices that appears in other home automation systems
- allowing Widget vendors to specify the Widget requirements
- not tying Nodes directly to Widgets, and vice-versa
- providing a customizable user interface design to allow for smart and intuitive user experiences
Widget vendor benefits
Widget vendors using ohWidget benefit from how little the need to do to make their Widgets ohWidget compatible.
ohWidget supports Widget vendors by:
- allowing the easy integration of Widgets to a connected home with the addition of a tiny amount of intelligence on the Widget itself, without the necessity for a large-scale redesign of the products
- supporting managed code for driver writing in C# allowing for faster development across multiple hardware implementations
- auto-generating several essential files from one central configuration file
- defining the configuration details of the device in simple XML which is easily created and maintained
User benefits
The goal of ohWidget is to place the user at the center of their own home services by providing them an aggregated view of all the devices in their home, irrespective of the vendor.
ohWidget puts the focus on the user in their home by:
- giving users complete freedom of choice of which devices are used in their own home
- allowing existing, familiar devices to be used as the Control Point, including a choice from among smartphones and tablet PCs
- providing a system backbone that persists when in the home (removing the Control Point doesn't remove the system)
- providing a minimum set up system for home users by applying the benefits of Universal Plug and Play to all devices, independently of the communications protocol used by each device
- aggregating all Widgets in the home, regardless of vendor or protocol
- providing a truly scalable solution allowing the user to build their own smart home network as they wish
Technical Overview
A very simple view of an ohWidget connected home is shown in Figure 1 below. One Control Point accesses a single Widget by interacting with the Node:
Key:
- WAP: Wireless Access Point. A network point allowing the Control Point and Nodes to access the 802.11a/b/g/n protocol.
- PLC: Power Line Communications. Can be used to help extend ethernet connections around the home.
- LEC: Low Energy Communications. The module installed on the Node used to communicate with compatible Widgets. Examples are 6LowPan, ZigBee, Z-wave or Bluetooth LE.
- Home network: A representation of any number of routers, switches and wireless access points in the home. This also includes wired Ethernet connections, indicated in the diagram by the thick lines between the Control Point, Home network and Node.
- Wireless comms: The protocol used by the Node and Widget to communicate with each other.
{note:title=Note} The Node is shown with a broken line through it to represent the possibility of a second Node being contacted to pass the message on to the Widget. At most a message will travel from Control Point > Node > Node > Widget (this is discussed in more detail in the Node chapter). In this case, the first Node will continue to use ethernet comms (potentially augmented by PLC) to contact the second Node, and the second Node will use the LEC protocol to contact the Widget.{note}
An ohWidget network grows with no maintenance burden on the user when new Widgets are introduced. Communication between the Control Point and the Widget is key to ensuring a smart home functions efficiently as possible for users.
The view shown in the diagram above places the emphasis for this scalability and openness on the Node. Nodes treat both Widget and Control Point as abstract concepts and operate, for the most part, independently of the requirements of both. This is what stands ohWidget apart from other smart home systems.
Widgets
Widgets are any device that offer a service that can be interacted with from a Control Point. The Widget can be as complicated as an integrated audio streaming center or as simple as a light.
To be an ohWidget compatible device, a Widget needs to have the following knowledge about itself:
- State — the current status of the Widget, such as On or Off
- Service — the list of actions and options the Widget offers over the network
- Unique identifier (UID) — the value used to identify the Widget from all others
These details must be present on the Widget. This small requirement means that almost any device can be compatible with ohWidget.
The intelligence and mechanisms required to access and use these details is not stored on the Widget. ohWidget loads the intelligence on the Nodes rather than demand Widget vendors make their Widgets more complicated than they have to be.
Classifying Widgets
Some devices will already be complex in the range of function that they offer, whilst others will remain simple devices offering one or two functions at most. The simpler devices, Widgets, are supported by ohWidget's property list. These devices can have their functionality easily defined within the ohWidget framework, producing both auto-generated code for developers and intuitive user interfaces to present the Widget to the user.
Widgets in more detail
A Widget is a simple hardware device such as a light or thermometer. Widgets communicate with the Node using a low-energy communications protocol, such as Zigbee or Z-Wave. They are controlled using a device- and protocol-specific driver. Widget drivers are installed on the Node and used as required.
For example, two Widgets providing an identical service over the same communications protocol will both use the same copy of the device driver. A new Widget providing the same service as the first two but over a different communications protocol will need a new device driver. A fourth Widget offering a different service, but using the same protocol as the first two, will also need its own device driver.
A more advanced device might not have its full range of functionality supported in the set of ohWidget properties alone. These devices are called External Widgets. Their more complicated functions must be defined externally of the ohWidget properties. However, ohWidget will fully integrate an External Widget definition so that it can be presented seamlessly alongside other Widgets.
