ZWave Product Database OH2

This page describes the XML product database used within HABmin for defining the Z-Wave devices. The database itself is not part of HABmin, but is linked into the Z-Wave binding to ensure that it is version controlled - errors in the database can cause problems with the device or binding operation. Modifications therefore need to be made to the database, and the binding recompiled.

Adding devices to the database

You are encouraged to add your devices to the database and submit a pull request. If you are not comfortable submitting a PR, then please generate the XML files and raise an issue, pasting the XML into the issue.

Database Structure

The database uses the standard ESH format - this document describes the customisation employed withing the ZWave binding to define ZWave devices.

Label Conventions

HTML Short first line

Thing Properties

defaultAssociationGroups

Channel Properties

Channels provide the interfaces into the ZWave devices functionality. They allow (for example) definition of a dimmer or switch, or metering data, temperatures etc. Channels could be defined for parameters associated with the configuration class, but this should be limited to the situation where such parameters are needed in a UI which is normally not the case.

Channels are defined as follows.

<properties>
<property name="endpoint">0</property>
<property name="commandClass">SWITCH_MULTILEVEL,BASIC</property>
<property name="commandClass:restoreLastValue">true</property>
</properties>

Property Name	Description
endpoint
commandClass	Defines the applicable ZWave command classes for this channel. It should be noted that multiple command classes can be defined if necessary, in which case they should be separated by a comma. Note that the order is important because the binding will use the first named class for sending any command. In the above example SWITCH_MULTILEVEL,BASIC means that messages from both the SWITCH_MULTILEVEL and BASIC command classes will be used to set the state, but when sending commands to the device, the SWITCH_MULTILEVEL class will be used.
commandClass:arg	Defines an argument to be passed into the command class converter. Arguments specific to each command class are defined below. The following arguments are defined for all (or most!) command classed. getSupported: true or false - defaults to true. Used to stop polling for devices that do not respond when polling a specific command class.

Command Classes

The following table defines the command classes supported within the binding that are available to be bound to channels. Additional command classes are supported internally within the binding for internal use within the binding (eg to get the manufacturer information) however these can not be directly bound to a channel.

Command Class	Description
ALARM
BASIC	Provides basic SET and GET of the default node value
CONFIGURATION
METER	Used to get measurements from a node. Options: meterCanReset (default: false) meterType Meter Types: E_KWh: Electricity watt hours E_KVAh: Electricity kilowatt hours E_W: Electricity Watts E_V: Electricity Volts E_A: Electricity Amps E_Pulses: Electricity pulse counter E_Power_Factor: Electricity power factor G_Cubic_Meters: Gas use in cubic meters G_Cubic_Feet: Gas use in cubic feet G_Pulses: Gas pulse counter W_Cubic_Meters: Water use in cubic meters W_Cubic_Feet: Water use in cubic feet W_Gallons: Water use in Gallons W_Pulses: Water pulse counter
SENSOR_ALARM
SENSOR_BINARY	Used to bind to a sensor.
SENSOR_MULTILEVEL	Used to bind to a sensor.
SWITCH_BINARY	Used to bind directly to a SWITCH
SWITCH_MULTILEVEL	Used to bind directly to a DIMMER. Options: invertPercent invertState
THERMOSTAT_FAN_MODE
THERMOSTAT_FAN_STATE
THERMOSTAT_MODE
THERMOSTAT_OPERATING_STATE
THERMOSTAT_SETPOINT

Configuration Parameters

Defaults should be usable defaults - not just what the manufacturer sets!

The description of configuration parameters is described in the ESH documentation. This section describes additional conventions that should be used within the ZWave binding to ensure that we have a consistent look and feel, and so the binding can know how things are defined.

The binding defines two parameter groups (as below) to group configuration parameters and association groups. The XML definition needs to use these groups to ensure they are displayed correctly.

			<parameter-group name="configuration">
				<context>setup</context>
				<label>Configuration Parameters</label>
				<description></description>
			</parameter-group>
			<parameter-group name="association">
				<context>link</context>
				<label>Association Groups</label>
				<description></description>
			</parameter-group>

Configuration parameters are defined as follows -:

			<parameter-group name="configuration">
				<context>setup</context>
				<label>Configuration Parameters</label>
				<description></description>
			</parameter-group>

Association group definitions are defined as follows -:

			<parameter name="group_2" type="integer" multiple="true"
				groupName="association">
				<label>Momentary hold</label>
				<description><![CDATA[Triggered through a momentary switch hold]]></description>
				<multipleLimit>16</multipleLimit>
			</parameter>