From OpenHome

Revision as of 15:29, 1 March 2012

Introduction

This document is for Widget manufacturers using OpenHome to define Widget services and properties. The services and properties are defined in XML, following the schema published by OpenHome.

To help you produce your Widget Service XML file, this document provides descriptions of each element you can use in your own Widget Service XML file. A sample Widget Service XML file is used throughout the document.

Prerequisites

To begin defining your Widget Service XML you must in possession of the following items:

• technical details about the properties your Widget physically provides
• the OpenHome SDK, specifically the WidgetService.xsd file

Related documents

The XML you define is used in several areas of Widget development. Refer to the following documents to see how the XML is used:

• OpenHome Widget Driver Development

Widget Service XML

The Widget Service XML file is used to define the features that your Widget provides to users.

Each of these features is described as a property in the Widget Service XML. This may be a simple light Widget offering an on/off — or power — property, or a more complicated Widget offering volume, bass, and treble properties.

Your Widget Service XML file can contain as many properties as are necessary to describe the full range of the Widget's feature set. Your Widget Service XML must contain at least one property.

Internal structure

The Widget Service XML file is validated against an XSD. The XSD is included in the OpenHome SDK.

Snippet 1 shows an abstract hierarchy of the elements used in a Widget Service XML file.

widgetservice
  description
  version
      major
      minor
  propertylist
      property
          name
          description
          dataType
          access
          allowedValueList*
              allowedValue
          allowedValueRange*
              minimum*
              maximum*
              step*

Snippet 1: An abstract view of a Widget Service XML, showing the structure of the various elements used. Elements marked * are optional.

The structure of the XML is defined by OpenHome. You cannot change it and expect your Widget to operate on an OpenHome network. However, some of the files you generate from it can be customized.

External document dependencies

Your Widget Service XML is used in several areas of Widget development. Several files are automatically generated from this one. Driver authors and UI developers both depend heavily on the code generated from your Widget Service XML. It is therefore essential that you write a well-formed Widget Service XML, conforming to the schema defined in the WidgetService.xsd.

The diagram below shows the significance of the Widget Service XML in relation to the generated files used by other developers to define and publish your Widget on an OpenHome network:

Figure 1: The OpenHome document hierarcy, showing the files you can generate from the Widget Service XML.

The JavaScript proxies and the UI HTML and JavaScript files are used by Web UI developers to style and customize the UI that will run on an OpenHome Node.

The C# Provider is used by Widget driver authors to help them write the code required to operate the Widget.

The C# Proxy is used by developers to produce a C# control point application which can be used in place of the standard Web UI.

XML elements

The following tables explain each XML element that can appear in a Widget Service XML file. Descriptions of each element are provided alongside to explain their use. An example of the elements in use is provided in the appendix.

widgetService

The widgetService element contains the definition of a service available on the Widget.

Table 3.1. widgetService element description

The widgetService element has several child elements. They are defined as follows:

Table 3.2. widgetService child elements description

version

The version element has the following child elements:

Table 3.3. version child elements description

propertylist

Use the propertylist element to hold the list of properties you want to make available on the Widget.

The propertylist element has the following child elements:

Table 3.4. propertylist child elements description

property

Use the property element to define a single property on the Widget. A property is one part of the service the Widget provides, such as power, volume or any other single feature.

The property element has the following child elements:

Table 3.5. property child elements description

dataType

The dataType element specifies the name of the data type used to store the value of the property. The value you specify here determines that type of information the property can process. It also determines which type of control is generated in the UI's HTML.

Choosing the correct value for the dataType element is important as it ensures that the Widget can be properly controlled by users. To help you ensure you are choosing the correct value, each of the supported values are described in more detail in the table below:

Table 3.6. dataType values description

allowedValueRange

Use the allowedValueRange to restrict the upper and lower values an integer property can have.

The allowedValueRange element has the following child elements:

Table 3.7. allowedValueRange child elements description

HTML controls The use of allowedValueRange in an integer property affects whether a text box or slider control is generated.

A text box is displayed in the Web UI if you do not provide an allowedValueRange.

A text box is also displayed if you do provide an allowedValueRange, but the difference between the maximum and minimum values is too great.

A slider control is displayed only if the difference between maximum and minimum is a small enough value. This value is set by OpenHome and is currently undefined.

allowedValueList

Use the allowedValueList to restrict the values a string property can have.

The allowedValueList element has the following child elements:

Table 3.8. allowedValueList child elements description

HTML controls The use of allowedValueList affects how the control for a string property is generated.

If you provide an allowedValueList, a drop-down list is displayed in the Web UI with your defined entries in it. Users can select the value from this list.

If you do not provide an allowedValueList, a text box is displayed in the Web UI. Users can manually enter the desired value.

Primary property

A Widget's primary property is the property that users will want to access most often.

Once defined, the primary property is automatically displayed in the Web UI's summary view, along with the name of the Widget.

Figure 2. An abstract view of several Widgets' summary views, aggregated in the Node UI.

For some simple Widgets the primary property is often the power property. For a more complicated Widget you will need to consider which property you want to assign as primary.

The details of the primary property are stored in the auto-generated Provider. This means the Node has direct access to these details and can provide the summary view UI at run-time.

Assigning the primary property

You assign the primary property by adding an attribute to the chosen property in the XML. For example, if we take the On property from a Basic Light Widget we can define it as the primary property by inserting primary="true". For example:

<property primary="true">
    <description>Indicates whether the light is currently
        illuminated</description>
    <name>On</name>
    <dataType>boolean</dataType>
    <access>readWrite</access>
</property>

You must assign at most one primary property. Defining more than one property as the primary property will leave your XML unable to generate the other files used in Widget development.

For more details about the Provider, see the OpenHome Widget Driver Development document.

Naming rules

The contents of some elements in the Widget Service XML directly affect the output in the generated files.

These details are important for the developers who will use your Widget Service XML file to write drivers and UIs for the Widget.

The following sections explain how the XML you define affects the auto-generated output.

Summary view UI

The details for the summary view UI are defined by the primary property in the XML.

Those details are stored in the Provider so that the Node can always access them and generate the summary view UI at run-time.

Details view UI

HTML and UI JavaScript

The generated code used in the UI JavaScript and the HTML is based on the content of each of the elements you define in the XML.

Provider

The code generated in the C# provider presents the driver developers with a series of abstract functions they can implement. Those functions are generated using the values you provide in each property's name, dataType and access elements.

For example, the following property in the XML:

<property primary="true">
    <description>Indicates whether the light is currently
        illuminated </description>
    <name>On</name>
    <dataType>boolean</dataType>
    <access>readWrite</access>
    </property>

will produce the following auto-generated code in the Provider:

public bool SetPropertyOn(bool aValue)
{
   ...
}

public bool PropertyOn()
{
   ...
}
...
protected abstract void SetOn(uint aVersion, bool aValue);

Here we see two accessor functions and one abstract function have been created. The accessor functions allow the property's value to be read and written. The abstract function is for Widget driver writers to implement in the code they write.

Let's examine how each of the XML elements affects them.

name

The XML defines the property's <name> as On:

<name>On</name>

The generated code includes the property name in the names of each of the generated functions: Set- PropertyOn, PropertyOn and SetOn.

SetOn is the abstract function used in the Widget driver. This means that Widget driver writers will consistently use the same names throughout the code they write.

access

The XML defines the property's access as readWrite:

<access>readWrite</access>

The generated code provides two functions that meet this access setting. The first, SetPropertyOn, provides a way to write the property's value. The second, PropertyOn, provides a way to read the property's value.

If the access was defined as writeOnly, only the abstract SetOn function would be generated.

dataType

The XML defines the property's dataType as boolean:

<dataType>boolean</dataType>

The SetPropertyOn function automatically takes a bool as the parameter to use to set the new value of the property.

The PropertyOn function automatically returns a bool to report the value of the property.

The abstract SetOn function automatically takes a bool as the parameter used to set the new value of the property.

Appendix A

<widgetService>
    <description></description>
    <version>
        <major>1</major>
        <minor>0</minor>
    </version>
    <propertylist>
        <propertyprimary="true">
            <description>Indicates whether the light is currently
                illuminated</description>
            <name>On</name>
            <dataType>boolean</dataType>
            <access>readWrite</access>
            <hint>boolean-onoff</hint>
        </property>
    </propertylist>
</widgetService>

Glossary

Control Point - The device that displays the user interface which makes use of services on the network to control a UPnP device.

CPNW - Control Point, Node, Widget. The model of devices used in Openhome environments.

Node - The communications bridge between the Control Point and the Widget. Also the target for deployment of ohApps.

Node communication protocol - The custom UPnP protocol provided by Openhome to allow Nodes to communicate with each other.

Node mesh A - collection of Nodes that intercommunicate.

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.

ohOS - The Openhome Operating System. Core software for Openhome systems that runs on Nodes.

PDLP - Proxy Device List Provider. The pattern used to represent the layers of UPnP in the Openhome code. All layers except the Presentation layer are represented in this pattern.

UPnP - Universal Plug and Play. The network protocols set out by the UPnP Forum to allow networked devices to seamlessly establish connections and services.

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

Widget communication protocol - The protocol used by the Widget to advertise its availability and services to the Nodes. Widget manufacturers are responsible for choosing which protocols each Widget supports. A typical Widget supports only one Widget communication protocol.

Widget driver - The software used by the Node to communicate with the Widget.