OhWidget Technical Overview - Revision history

Openhome: /* Glossary */

2012-03-01T15:08:18Z

Glossary

← Older revision		Revision as of 15:08, 1 March 2012
Line 415:		Line 415:
	ohApp - An application that runs inside ohOS.		ohApp - An application that runs inside ohOS.

-	ohNet - Library for discovering, eventing and controlling services on a network. Includes a full implementation of the UPnP stack.	+	[[ohNet\|ohNet]] - Library for discovering, eventing and controlling services on a network. Includes a full implementation of the UPnP stack.

-	~~ohOS~~ - The Openhome Operating System. Core software for ohWidget systems that runs on Nodes.	+	[[ohOs\|ohOs]] - The Openhome Operating System. Core software for ohWidget systems that runs on Nodes.

	Widget - The physical device installed in the user's home to provide them with a service. Typical Widgets are lights, speakers, temperature controls.		Widget - The physical device installed in the user's home to provide them with a service. Typical Widgets are lights, speakers, temperature controls.

Openhome: /* Widget class driver */

2012-03-01T15:06:55Z

Widget class driver

← Older revision		Revision as of 15:06, 1 March 2012
Line 353:		Line 353:
	===Widget class driver ===		===Widget class driver ===

-	Each class of Widget, and each Widget using a different communications protocol within that class (i.e. two Widgets, both in the binary light class, one of which communicates with Bluetooth LE and the other with [http://www.zigbee.org Zigbee]), has its own driver. Widget drivers are installed on the Node. Each driver contains code to allow the Widget to accept actions and report events.	+	Each class of Widget, and each Widget using a different communications protocol within that class (i.e. two Widgets, both in the binary light class, one of which communicates with [http://www.bluetooth.com Bluetooth LE] and the other with [http://www.zigbee.org Zigbee]), has its own driver. Widget drivers are installed on the Node. Each driver contains code to allow the Widget to accept actions and report events.

	An action is a message sent from the Control Point to the Widget, instructing the Widget to change its state in a particular way. Actions are initiated by the user from the UI, such as someone pressing the on button. An event is a message sent to the Control Point from the Widget, updating the Control Point about a change in the Widget's state. Events are initiated at the Widget, such as someone physically turning a light off.		An action is a message sent from the Control Point to the Widget, instructing the Widget to change its state in a particular way. Actions are initiated by the user from the UI, such as someone pressing the on button. An event is a message sent to the Control Point from the Widget, updating the Control Point about a change in the Widget's state. Events are initiated at the Widget, such as someone physically turning a light off.

Openhome: /* Widget service access */

2012-03-01T15:05:45Z

Widget service access

← Older revision		Revision as of 15:05, 1 March 2012
Line 338:		Line 338:
	The details that Nodes do require are stored in separate Widget drivers. The Node operates independently of the content of each Widget driver and, therefore, independently of the function of each Widget. See Widget class driver below for more details of drivers.		The details that Nodes do require are stored in separate Widget drivers. The Node operates independently of the content of each Widget driver and, therefore, independently of the function of each Widget. See Widget class driver below for more details of drivers.

-	Widget vendors have direct control over how much functionality each Widget exposes entirely independently of any conventions, consortium or forum. See the [[ohWidget ~~Widget~~ Driver Development\|ohWidget ~~Widget~~ Driver Development]] document for more details about writing Widget drivers.	+	Widget vendors have direct control over how much functionality each Widget exposes entirely independently of any conventions, consortium or forum. See the [[ohWidget Driver Development\|ohWidget Driver Development]] document for more details about writing Widget drivers.

	This clear separation of responsibility allows Node manufacturers to be concerned only with the communications protocol they want to use, and the hardware implications of that choice. Widget vendors are solely responsible for providing the required details to allow Nodes access to the Widget.		This clear separation of responsibility allows Node manufacturers to be concerned only with the communications protocol they want to use, and the hardware implications of that choice. Widget vendors are solely responsible for providing the required details to allow Nodes access to the Widget.

Openhome: /* Widget service access */

2012-03-01T15:05:10Z

Widget service access

← Older revision		Revision as of 15:05, 1 March 2012
Line 338:		Line 338:
	The details that Nodes do require are stored in separate Widget drivers. The Node operates independently of the content of each Widget driver and, therefore, independently of the function of each Widget. See Widget class driver below for more details of drivers.		The details that Nodes do require are stored in separate Widget drivers. The Node operates independently of the content of each Widget driver and, therefore, independently of the function of each Widget. See Widget class driver below for more details of drivers.

-	Widget vendors have direct control over how much functionality each Widget exposes entirely independently of any conventions, consortium or forum. See the ohWidget Widget Driver Development document for more details about writing Widget drivers.	+	Widget vendors have direct control over how much functionality each Widget exposes entirely independently of any conventions, consortium or forum. See the [[ohWidget Widget Driver Development\|ohWidget Widget Driver Development]] document for more details about writing Widget drivers.

	This clear separation of responsibility allows Node manufacturers to be concerned only with the communications protocol they want to use, and the hardware implications of that choice. Widget vendors are solely responsible for providing the required details to allow Nodes access to the Widget.		This clear separation of responsibility allows Node manufacturers to be concerned only with the communications protocol they want to use, and the hardware implications of that choice. Widget vendors are solely responsible for providing the required details to allow Nodes access to the Widget.

Openhome: /* Protocol independent communication */

2012-03-01T15:04:34Z

Protocol independent communication

← Older revision		Revision as of 15:04, 1 March 2012
Line 308:		Line 308:
	* power consumption increases with each new piece of hardware added to the Node		* power consumption increases with each new piece of hardware added to the Node
	* practical issues such as shielding one protocol from another in a single Node		* practical issues such as shielding one protocol from another in a single Node
		+

	However, minimizing the list of supported protocols by preventing communications by one or more of the available methods is against the goal of OpenHome. Rather than attempt to support some at the risk of alienating others, OpenHome provides Node software that is completely protocol independent with software to support whatever hardware is implemented in the Nodes.		However, minimizing the list of supported protocols by preventing communications by one or more of the available methods is against the goal of OpenHome. Rather than attempt to support some at the risk of alienating others, OpenHome provides Node software that is completely protocol independent with software to support whatever hardware is implemented in the Nodes.

Openhome: /* Familiar Devices */

2012-03-01T15:02:55Z

Familiar Devices

← Older revision		Revision as of 15:02, 1 March 2012
Line 214:		Line 214:
	* personal computer		* personal computer
	* laptop		* laptop
		+

	A typical modern home has at least one of these devices (and in a lot of cases often more than one of each type) readily available to perform the function of Control Point in a smart home.		A typical modern home has at least one of these devices (and in a lot of cases often more than one of each type) readily available to perform the function of Control Point in a smart home.

Openhome: /* User Interface */

2012-03-01T14:59:10Z

User Interface

← Older revision		Revision as of 14:59, 1 March 2012
Line 195:		Line 195:
	{{Noteboxend}}		{{Noteboxend}}

-	This operation is carried out at compile time, before the Widget is shipped~~. For more details on the ohWidget UI see the [[ohWidget UI Development\|ohWidget UI Development]] documents~~.	+	This operation is carried out at compile time, before the Widget is shipped.

	See the [[External Widget Application Development\|External Widget Application Development]] document for more information on writing custom details view UIs for External Widgets.		See the [[External Widget Application Development\|External Widget Application Development]] document for more information on writing custom details view UIs for External Widgets.

Openhome: /* External Widgets in more detail */

2012-03-01T14:58:20Z

External Widgets in more detail

← Older revision		Revision as of 14:58, 1 March 2012
Line 162:		Line 162:
	== External Widgets in more detail ==		== External Widgets in more detail ==

-	An External Widget is a complex hardware or software device that cannot have its controls and interface easily presented as a Widget. An External Widget will typically communicate over a network using TCP/IP, but can also use the same protocols as a Simple Widget (such as [http://www.zigbee.org Zigbee] or Z-Wave). External widgets are hosted in separate apps. These apps have the ability of being displayed and controlled through the ohwidget user interface. For more details refer to the [[External Widget Application Development\|External Widget Application Development]] document.	+	An External Widget is a complex hardware or software device that cannot have its controls and interface easily presented as a Widget. An External Widget will typically communicate over a network using TCP/IP, but can also use the same protocols as a Simple Widget (such as [http://www.zigbee.org Zigbee] or [http://www.z-wave.com/modules/ZwaveStart/ Z-Wave]). External widgets are hosted in separate apps. These apps have the ability of being displayed and controlled through the ohwidget user interface. For more details refer to the [[External Widget Application Development\|External Widget Application Development]] document.

	== User Interface ==		== User Interface ==

Openhome: /* Widgets in more detail */

2012-03-01T14:57:36Z

Widgets in more detail

← Older revision		Revision as of 14:57, 1 March 2012
Line 117:		Line 117:

	A Widget is a simple hardware device such as a light or thermometer. Widgets communicate with the		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 [http://www.zigbee.org Zigbee] or Z-Wave. They are controlled using	+	Node using a low-energy communications protocol, such as [http://www.zigbee.org Zigbee] or [http://www.z-wave.com/modules/ZwaveStart/ Z-Wave]. They are controlled using
	a device- and protocol-specific driver. Widget drivers are installed on the Node and used as required.		a device- and protocol-specific driver. Widget drivers are installed on the Node and used as required.

Openhome: /* Widget class driver */

2012-03-01T14:51:41Z

Widget class driver

← Older revision		Revision as of 14:51, 1 March 2012
Line 351:		Line 351:
	===Widget class driver ===		===Widget class driver ===

-	Each class of Widget, and each Widget using a different communications protocol within that class (i.e. two Widgets, both in the binary light class, one of which communicates with Bluetooth LE and the other with ~~[[http://www.zigbee.org [http://www.zigbee.org~~ [http://www.zigbee.org Zigbee~~]]]~~]), has its own driver. Widget drivers are installed on the Node. Each driver contains code to allow the Widget to accept actions and report events.	+	Each class of Widget, and each Widget using a different communications protocol within that class (i.e. two Widgets, both in the binary light class, one of which communicates with Bluetooth LE and the other with [http://www.zigbee.org Zigbee]), has its own driver. Widget drivers are installed on the Node. Each driver contains code to allow the Widget to accept actions and report events.

	An action is a message sent from the Control Point to the Widget, instructing the Widget to change its state in a particular way. Actions are initiated by the user from the UI, such as someone pressing the on button. An event is a message sent to the Control Point from the Widget, updating the Control Point about a change in the Widget's state. Events are initiated at the Widget, such as someone physically turning a light off.		An action is a message sent from the Control Point to the Widget, instructing the Widget to change its state in a particular way. Actions are initiated by the user from the UI, such as someone pressing the on button. An event is a message sent to the Control Point from the Widget, updating the Control Point about a change in the Widget's state. Events are initiated at the Widget, such as someone physically turning a light off.