This documentation is for 1.6 Version of OZW. If you are looking for the instructions for 1.4 Version, please use this page instead

All the devices that are present in the OpenZWave Device Database are community contributed, meaning we rely on users to send patches to us to add the device. We receive on average 2-3 requests for new devices each week. If we were to spend out limited time researching and adding devices, then OZW would not improve as far as code and bug fixes go. Also bear in mind that the OZW developers do not have every single Z-Wave device on the market, nor do we have access to them. (Donations are always welcome though!).

If you have a device that does not appear in the OpenZWave Device Database (manufacturer_specific.xml file), in 99% of cases, the device will still work flawlessly with OpenZWave. This is because OpenZWave utilizes the "discovery" features of the Z-Wave Protocol to discovery what capabilities the device has (ie, is it a switch, or dimmer, how many channels it supports etc)

When OZW runs in this mode, the following applies:

1. the Name (and possibly Manufacturer) will appear as the hexadecimal ID's rather than product names. There is no loss of functionality here.
2. Device Configuration Variables will not be available (as this is about the only part of Z-Wave that doesn't support any sort of discovery)
3. If the device has non-standard implementation of the protocol or Command Classes, some functionality might be buggy. (this applies to maybe 2-3% of devices in the database currently, as with more recent devices, Z-Wave Alliance and Sigma have improved the certification testing to catch these types of problems - so its becoming less of a issue now days).

Regardless, the following sections will provide information on how to add a new device to the manufacturer_specific.xml file and in the case of point 2 & 3 above, how to create configuration files for that device.

[TOC]

The first thing to do is see if the Device already exists in our database, but for a different region. You can look at the manufacturer_specific.xml file or at http://www.openzwave.com/device-database/ to see if it exists. If it does, then the changes are simple:

Navigate the the line in the manufacturer_specific.xml file that contains the product, and copy the line. Change the id and type fields to the same as your region, and leave everything else as is (including the path to the config file).

The result should look like this:

 <Product type="4349" id="3130" name="ZCS101 Serial Interface" config="manufacturer/ZCS101.xml" />
 <Product type="4350" id="3130" name="ZCS101 Serial Interface" config="manufacturer/ZCS101.xml" />

You then need to modify the configuration file itself to specify the MetaData that is specific to your region.

If the device does not exist in our device database, then you will have to create a new configuration file and entry for this.

Your going to need some information to create a new configuration file. Before starting please find the following information

1. The Product Manual that contains information about what Configuration Parameters are available on the device. Some vendors release this information in a "Technical Specifications" or "Engineering Document" instead of the main manual. If this information is not publicly available, you can contact the vendors support and request this information.

2. The Manufacturer ID, Product Type and Product ID. These are the identifiers that Z-Wave uses to identify devices. Most vendors will use a Different Product Type, or Different Product ID to identify the different regions a device supports. This information is usually contained in the Product Manual or Technical Specifications.

3. You should try searching https://products.z-wavealliance.org/ for the Products. Again, try to find all the URL's for each region the manufacturer releases the Product for. Occasionally, you may find duplicate entries for the device in the same region. Please use the latest version of the entry (usually has a higher number in the URL - https://products.z-wavealliance.org/products/1710 - in this case, 1710)

4. ideally, a Image of the product. We try to keep standard sizes here, so 200x200 and PNG format. Often the images on the https://products.z-wavealliance.org/ are good enough. If the size is too big/small, its ok, we will resize it for you.

Adding a config file takes a few steps outlined below:

1. Add a entry to the manufacturer_specific.xml file

2. Create the Config File

3. add a Product Image.

We will go through each step below:

This step requires you to obtain the Manufacturer ID, Product type and Product ID. These values can be found in the device manual. You can verify that the values match what OpenZWave sees by comparing the ones you find to the values in the ozwcache*.xml config file or your application GUI

• Manufacturer ID - first, check if the Manufacturer is already defined in the manufacturer_specific.xml file. This would indicate that we already have added that manufacturer to the database, and thus nothing else is required. We try to keep the file organised alphabetically by Manufacturer, so just scrolling through should reveal it quick.

A Manufacturer entry looks like this:

 <Manufacturer id="002a" name="3e Technologies">
     ...
 </Manufacturer>

If the manufacturer does not exist, create a new entry for that manufacturer as shown above.

• Product Type and Product ID - These two numbers identify the specific product. A Basic Product Entry looks like this:

 <Product type="4349" id="3130" name="ZCS101 Serial Interface"/>

Specify name with the format "<Product Identifier> <Product Description>".

The Product Identifier value defined by the manufacturer to identify the device (e.g. the model number, product code etc).

The Product Description is a short description of the product used by the manufacturer. In the example above, ACT use ZCS101 as the product code, and they describe the device as a "Serial Interface".

Please try to keep the entry as short as possible, as longer entries will not format so well on application/gui screens. Also, we currently only accept English entries.

For Example, if you had a new device from Aeon Labs (Say a ABC001 Z-Wave Widget), with a Manufacturer ID of 0086, Product Type of 12AB and Product ID of 45EF, you would add the following to the manufacturer_specific.xml file in the Aeon Labs Section:

 <Manufacturer id="0086" name="Aeon Labs">
    <Product type="12AB" id="45EF" name="ABC001 Z-Wave Widget"/>
 </Manufacturer>

Remember to add the product to the existing Manufacturer section if one already exists.

• NOTE: The manufacturer ID, Product Type and Product ID are entered as hexadecimal values, so please ensure you do the right conversion if the documentation provides them as decimal. The Calculator Apps on Windows and OSX can be used to convert between Decimal/Hex

Unfortunately the Z-Wave Protocol only introduced the capability to discover what configuration variables the manufacturer might allow a user to change recently, and most devices do not currently support this feature yet (ZWave+ Version 2 will make it mandatory). Regardless, the information we can discover with newer devices is limited, and will still require a configuration file in most cases.

While some variables are specified by the CommandClasses, device specific configuration variables are not, and the protocol allows the manufacturer to implement specific configuration variables for each device. These variables often allow the user to modify the behaviour of a device, or change the default command classes that a device might advertise.

These variables are usually documented in the device manual, so to add them to OZW, you must interpret them and create a device configuration file.

Device Configuration files are placed under the config directory, in subdirectories according to a the manufacturer name. If no subdirectory for a manufacturer exists, there is no strict naming guideline, other than it should be short and easy to determine which manufacturer it represents.

Likewise, the naming of a configuration file is also not important, but general guideline is to use the Product Code a manufacturer might use to identify their device. (in the example above, it would be ABC001.xml in the aeon_labs subdirectory)

A empty configuration file template is available in the config/config-template.xml for you to get started. At a high level, its split into at least 3 sections as seen below:

1 <?xml version="1.0" encoding="utf-8"?>
2 <Product Revision="1" xmlns="https://github.com/OpenZWave/open-zwave">
3   <MetaData>
4     ...
5   </MetaData>
6   <CommandClass id="112">
7     ...
8   </CommandClass>
9   <CommandClass id="133">
10     <Associations num_groups="1">
11      ...
12    </Associations>
13  </CommandClass>
14 </Product>

Description:

• Line 1 - Specify the Encoding for the xml file.
• Line 2 - Specify this is a Product Configuration Block. We will talk about the Revision Number Below
• Line 3 to Line 5 - MetaData Stores information such as Product Manual, and basic help for the device
• Line 6 to Line 8 - A entry for CommandClass 112 - Which in this case is the Configuration CommandClass. This Section will contain information about what parameters are available on the device
• Line 9 to Line 13 - A entry for CommandClass 133 - in this case, the Association CommandClass.
• Line 10 to LIne 12 - Allows you to assign friendly names to Association Groups present on the device (normally the device identifies Association groups by numbers. num_groups specifies the number of groups the device supports

After creating the configuration file, you need to associate it with a device. Edit the manufacturer_specific.xml file, and locate the Product line that is applicable to your device (or you added in the step above) and modify it so it points to the config file:

<Product type="0002" id="001c" name="Home Energy Meter G2" config="aeon_labs/hemg2.xml"/>

In the above example, we added a entry called "config" that points to the relative location of the config file we are creating

The Metadata block contains information about the device that is useful to users. Things such as basic help on including/excluding/waking up the device, links to Product Manuals/Support Sites or Discussion forums as well as Product Images etc. It also contains a "ChangeLog" that details what changes have been made on the Configuration File between revisions

The MetaData Block looks like:

1  <MetaData>
2    <MetaDataItem name="Name">...</MetaDataItem>
3    <MetaDataItem name="Description">...</MetaDataItem>
4    <MetaDataItem name="OzwInfoPage">http://www.openzwave.com/device-database/XXXX:YYYY:ZZZZ</MetaDataItem>
5    <MetaDataItem name="ProductPage">...</MetaDataItem>
6    <MetaDataItem name="ProductSupport">...</MetaDataItem>
7    <MetaDataItem name="ProductPic">...</MetaDataItem>
8    <MetaDataItem name="ProductManual">...</MetaDataItem>
9    <MetaDataItem name="WakeupDescription">...</MetaDataItem>
10   <MetaDataItem name="InclusionDescription">...</MetaDataItem>
11   <MetaDataItem name="ExclusionDescription">...</MetaDataItem>
12   <MetaDataItem name="ResetDescription">...</MetaDataItem>
13   <MetaDataItem id="XXXX" name="ZWProductPage" type="XXXX">...</MetaDataItem>
14   <MetaDataItem id="YYYY" name="ZWProductPage" type="YYYY">...</MetaDataItem>
15   <MetaDataItem id="XXXX" name="FrequencyName" type="XXXX">...</MetaDataItem>
16   <MetaDataItem id="YYYY" name="FrequencyName" type="YYYY">...</MetaDataItem>
17   <MetaDataItem id="XXXX" name="Identifier" type="XXXX">...</MetaDataItem>
18   <MetaDataItem id="YYYY" name="Identifier" type="YYYY">...</MetaDataItem>
19   <ChangeLog>
20     <Entry author="XXXXX - joe@gmail.com" date="01 May 2019" revision="1">...</Entry>
21     <Entry author="XXXXX - joe@gmail.com" date="08 May 2019" revision="2">...</Entry>
22   </ChangeLog>
23 </MetaData>

Description:

• Line 1 - Start of the MetaData Block
• Line 2 - This is the name of the Product. It should be the same as what is used in the manufacturer_specific.xml file (minus the product identifier)
• Line 3 - A Description of the Device. Can be copied from the vendors website or product manual.
• Line 4 - A Link the the OpenZWave Website for this product. You should update XXXX with the Manufacturer ID, YYYY with the Product ID and ZZZZ with the Product Type
  • If this is a initial configuration file you are creating, just pick the ID and Type for the product you are using. If you are update the config file, please do not change this (so that the same device for different regions all point to a single page)
• Line 5 - A Link to the Product Page on the Vendors Website
• Line 6 - A Link to the Product Support page on the Vendors Website
• Line 7 - the pathname from the config folder to the Product Picture. See Below for more info.
• Line 8 - A weblink to the Product Manual. Either hosted on the vendors website, or the https://products.z-wavealliance.org/ site
• Line 9 - A short description on how to wake up the device. Can usually be found in the product manual
• Line 10 - A short description on how to include this device in a Z-Wave Network.
• Line 11 - A short description on how to exclude this device from a Z-Wave Network
• Line 12 - A short description on how to factory reset this device.
• Lines 13 to 18 allow us to specify information for devices from different regions. If you are creating this config for the first time, you should duplicate each entry with the Product Type and Product ID for that specific device and of course the region specific information.
• Line 13/14 - A Link to the https://products.z-wavealliance.org/ page for this device, specific to the region that the Type/ID represent. (the same device can have different entries on the alliance page depending upon the regions it has been certified for)
• Line 15/16 - The Frequency/Region this device is configured for. Please see the table below for allowed values.
• Line 17/18 - The Product Code/Identifier/Part Number a vendor might assign for the device. (may be unique for each region, or the same for all regions)
• Line 19 to Line 22 - ChangeLog Entries. See below.

Most of this information can be found on the https://products.z-wavealliance.org/ website for certified devices, but in some cases, you may need to find the information elsewhere, such as the Vendors website or support contacts.

Changelog Entries allow us to communicate what has changed between revisions of a Config File. If you are creating a new configuration file, you should add a Single Entry line with your name (and optionally email), the date in DD - Month - YY format, and the file revision number along with a entry along the lines of "Initial Creation of config file etc" or any other information you think might be relevant, such as the firmware version of the device you tested this config file with.

If you are updated a configuration file to fix a bug, or add additional regions to it, please indicate what you changed in the Changelog, so other users are aware of the changes you made.

Note - The Revision Number in the Entry must point to the latest version of the Config file. If you are creating a new config file, the revision number will be 1, if you are updating a config file, you would increment the Revision Number in the "Product" block above and add a entry for the new revision in the Changelog Block

The OZW database includes small pictures of each device to aid GUI applications display pictures of the devices. The images are stored in config/images//.xml

When submitting new devices, please include a picture of the device. Often the pictures from the http://products.z-wavealliance.com/ site are acceptable.

The Image's we are accept are:

• Maximum Size is 200x200px. If you have to scale them, please maintain any aspect ratios.
  • If your original picture is less than 200x200, please ensure it looks acceptable when scaled up.
• PNG format.

You may use the tools/imagedownload.pl script to download and resize the images for you:

tools/imagedownload.pl https://products.z-wavealliance.org/ProductImages/Index?productName=ZC10-19056468

The image will be saved as productimage.png and you just need to copy it into the images// directory and reference it in the ProductPic entry for MetaData above.

In Z-Wave, there are several different types of variables that can be added. At the most basic level, its either integer or list based. The following section will describe in more detail the different types, and some guidance on using them.

The actual types are:

• bool - The bool type is a Boolean type, or simply either true/false, on/off or 1/0
• byte - A byte can represent a number from 0 to 255 (or 0x00 to 0xFF)
• decimal - A decimal is a fractional number, eg, 25.5. Could also be referred to as a float or double.
• int - A integer can represent a number from 0 to 4294967295
• list - A list of possible string values, with each string value identified by a number
• short - A Short can represent a number from 0 to 65535
• bitset - usually a group of "bool" values that turn on/off features/functionality.
• string - A String - Not often used for Config Variables.
• raw - The value, represented as a series of bytes. Unbounded by the OZW in length, but the device might impose some upper limits. Should not be used unless advised by a developer.

When creating a new configuration value, you will have to determine the correct type to use by consulting the device documentation. Often a incorrect type will mean that the variable will not work. (either setting it, or reading it) so some testing might be required.

A number of parameters need to be provided when adding a new configuration variable.

For all types except list, the syntax of a configuration variable is as follows:

1    <Value type="A" index="B" genre="config" label="C" units="D" min="E" max="F" value="G">
2      <Help>
3        H
4      </Help>
5    </Value>

Description:

• Line 1 - This defines the Variable Parameters as follows:
  • type This is the variable type as defined above.
  • index This is the position of the Variable on the device. The device manual should specify the variable index
  • genre This will always be config
  • label a Short descriptive name for the Variable
  • units a short description of what the variable represents. Examples might be "watts" for a energy meter, or "%" if it represents a percentage. If there is no logical unit for the variable, you can specify it as blank (eg, "")
  • min The minimum value that is accepted
  • max the maximum value that is accepted
  • value the default value of the variable.
• Line 2 to 4 - This is help text that describes what the Configuration Item does. in most cases, you should copy verbatim from the device manual (assuming its in English) but sometimes you should also add additional information about how to structure a value if needed (see below for more info)

To create a variable type of List, the following syntax is used:

1    <Value type="list" index="B" genre="config" label="C" units="D" min="E" max="F" value="G" size="H">
2      <Help>
3      ...
4      </Help>
5      <Item label="I" value="J" />
6      <Item label="K" value="L" />
7      ...
8    </Value>

Description:

• Line 1 - This defines the Variable Parameters as follows:
  • type is always "list"
  • index This is the position of the Variable on the device. The device manual should specify the variable index
  • genre This will always be config
  • label a Short descriptive name for the Variable
  • units a short description of what the variable represents. Examples might be "watts" for a energy meter, or "%" if it represents a percentage. If there is no logical unit for the variable, you can specify it as blank (eg, "")
  • min The minimum value that is accepted
  • max the maximum value that is accepted. Max should be equal to the largest value specified in the Item block.
  • value the default value of the variable. Should equal a valid value in the Item Block
  • size Specify the size of the value in bytes.
• Line 2 to 4 - This is help text that describes what the Configuration Item does. in most cases, you should copy verbatim from the device manual (assuming its in English) but sometimes you should also add additional information about how to structure a value if needed (see below for more info)
• Lines 5 to 7 - Each Item entry specifies a individual option and its corresponding value. Value must be a numerical digit, who's size would not exceed the storage space specified in the size parameter. label is a string, and you should keep this as short as possible.

To create a variable type of BitSet, the following syntax is used:

1    <Value type="bitset" index="B" genre="config" label="C" units="D" min="E" max="F" bitmask="G" value="H" size="I">
2      <Help>
3      ...
4      </Help>
5      <BitSet id="J">
6        <Label>K</Label>
7        <Help>L</Help>
8      </BitSet>
7      ...
8    </Value>

Description:

• Line 1 - This defines the Variable Parameters as follows:
  • type is always "bitset"
  • index This is the position of the Variable on the device. The device manual should specify the variable index
  • genre This will always be config
  • label a Short descriptive name for the Variable
  • units a short description of what the variable represents. Examples might be "watts" for a energy meter, or "%" if it represents a percentage. If there is no logical unit for the variable, you can specify it as blank (eg, "")
  • min The minimum value that is accepted
  • max the maximum value that is accepted. Max should be equal to the largest value specified in the Item block.
  • value the default value of the variable. Should equal a valid value in the Item Block
  • size Specify the size of the value in bytes. (note - 1 Byte contains 8 bits)
  • bitmask Specifies what Bits are able to be set by the user
• Line 2 to 4 - This is help text that describes what the Configuration Item does. in most cases, you should copy verbatim from the device manual (assuming its in English) but sometimes you should also add additional information about how to structure a value if needed (see below for more info)
• Lines 5 to 7 - Each Item entry specifies a individual Bit that can be turned on/off and its corresponding Label and Help Text. We work from right to left (LSB to MSB) with regards to Bits, so 1st bit on the right hand side is always id = 1, and as you move left we increment, so 2, 3 4 etc.

As the BitSet is a complicated ValueID, lets take a real life example from a vendors product manual as a demonstration:

In this case, we have 8 "options" that can be set via a single parameter (48) on the device. To create a BitSet Value, it would look like this:

<Value genre="config" index="48" label="Enable/disable to send a report on Threshold" size="1" type="bitset" bitmask="255" units="" value="0">
      <Help>Enable/disable to send a report when the measurement is more than the upper limit value or less than the lower limit value.
Note:
If USB power, the Sensor will check the limit every 10 seconds. If battery power, the Sensor will check the limit when it is waken up.
      </Help>
      <BitSet id="1">
        <Label>Lower Temperature</Label>
        <Help>Lower Temperature Threshold</Help>
      </BitSet>
      <BitSet id="2">
        <Label>Lower Humidity</Label>
        <Help>Lower Humdity Threshold</Help>
      </BitSet>
      <BitSet id="3">
        <Label>Lower Luminance</Label>
        <Help>Lower Luminance Threshold</Help>
      </BitSet>
      <BitSet id="4">
        <Label>Lower Ultraviolet</Label>
        <Help>Lower Ultraviolet Threshold</Help>
      </BitSet>
      <BitSet id="5">
        <Label>Upper Temperature</Label>
        <Help>Upper Temerature Threshold</Help>
      </BitSet>
      <BitSet id="6">
        <Label>Upper Humidity</Label>
        <Help>Upper Humdity Threshold</Help>
      </BitSet>
      <BitSet id="7">
        <Label>Upper Luminance</Label>
        <Help>Upper Luminance Threshold</Help>
      </BitSet>
      <BitSet id="8">
        <Label>Upper Ultraviolet</Label>
        <Help>Upper Ultraviolet Threshold</Help>
      </BitSet>
    </Value>

The bitmask is calculated by adding together all the available options in Binary, and converting to decimal. In this case, all bits are valid, so 1+2+4+8+16+32+64+128 = 255. (You can use a calculator to help with his). If we took another example where only every 2nd Bit was valid, the BitMask would be 2 + 8 + 32 + 128 = 170

If you had multiple Configuration Variables to add, you would just repeat the above snippet inside the <CommandClass id="112"> block of the configuration file.

Some additional options you can specify in a Value Block:

• read_only - True/False - If the value is a read only value (meaning the user can't change it.)

<Value type="list" index="144" genre="config" label="WallSwipe" units="" min="0" max="1" size="1" value="0" read_only="true">

• write_only - true/false - if the value is not readable. A example might be a "reset to defaults" configuration value.

<Value type="list" index="144" genre="config" label="WallSwipe" units="" min="0" max="1" size="1" value="0" write_only="true">

If we take the Manual for a Aeon Labs Home Energy Meter (Here) as a example, Section 5.2 Lists the configuration Variables. Parameter's number 3 and 4 would look like:

    <Value type="list" index="3" genre="config" label="Power changed" units="" min="0" max="1" value="0" size="1">
      <Help>
        Automatic report only when power is changed.
      </Help>
      <Item label="Disable" value="0" />
      <Item label="Enable" value="1" />
    </Value>
    <Value type="short" index="4" genre="config" label="Wattage Threshold" units="watts" value="50">
      <Help>
        Threshold change in wattage to induce a automatic report (whole HEM).
      </Help>
    </Value>

For Parameter 3 (index 3) we could have also implemented it as a bool type as well, but doing as a list was also valid.

(The entire config file for this device can be viewed Here)

Association groups are a fundamental part of Z-Wave that allow automatic reporting of state changes back to OZW, or to allow one device to control another device. A proper understanding of Association Groups is a good idea (but outside the scope of this document). In essence, a device will usually have at least one association group. When the state changes on that device, it sends a "Report" message to all nodes listed in the relevant Association Group.

The Configuration File allows you to specify:

1. A Name to each association group the device supports
2. a option to enable OZW to automatically add the Controller Node to that particular Association Group to receive updates.

An Example is below:

1    <CommandClass id="133">
2      <Associations num_groups="2">
3        <Group index="1" max_associations="5" label="Door Sensor" />
4        <Group index="2" max_associations="5" label="PIR Sensor" auto="true" />
5      </Associations>
6    </CommandClass>

Description:

• Line 1 - Specifies the Following Block is for CommandClass 133 (Association CC)
• Line 2 - The following option is available:
  • num_groups is the number of Association Groups the device supports. There should be a equal number of Group Entries.
• Line 3 to 4 - This is a list of each Group.
  • index indicates the group number
  • max_associations is the maximum number of Nodes that can be added to this group.
  • label a friendly description of the Group
  • auto if the Controller Node should automatically be added to this group for reporting. For Group 1, we default to true, so there is no need to add auto="true" for any Group1, for other Groups, you you should set this to true only if the group reports additional information that would not be present in Group1.

If the device had a Generic Group (that was not at position 1) where all state changes are reported to, then you would set auto equal to true. If it had further groups where only specific events (that are already sent in the generic group) are reported, you should not set auto to true here, otherwise OZW will recieve 2 messages (one from each group) when a state change happens.

In some cases, some devices have firmware bugs, or the manufacturer has implemented a feature in a "non-standard" way. Where possible, we have implemented workarounds for these issues and they sometimes need to be enabled for individual devices.

In these cases, after creating a Device Configuration, but things do not appear to be working correctly, you can ask for help on the mailing list. Should we determine its a non-standard implementation, we will advise you what to add to the Config file to test.

You can also do some testing of your own if you are encountering strange behaviour on a device. Please refer to the CommandClass Compatibility Flags page for more info.

After you have made your changes to the manufacturer_specific.xml file, and any device specific configuration file, to test your changes work you can do the following:

1. run make xmltest from the top level directory. This will just check the syntax of the configuration files is correct and you do not have any formating errors.
2. remove (or backup) any zwcfg_*.xml file and restart your application.
3. after its restarted, check each configuration value you added, to ensure you can change a value, and the device responds appropriately. If you had added additional Association Groups, you should also check if the group names are reflected, as well as if the Controller has been added if auto is equal to true.

Finally, after you have tested your changes, and would like to submit the new device configuration to us, you can perform the following steps:

1 Assuming you had forked a copy of our OZW repository on GitHub, you can submit a pull request with the changes to us for inclusion into the main repository.

2 Before submitting a pull request, please do the following:

• run "make xmltest" from the top level directory to confirm you changes do not contain any syntax errors
• run "make dist-update" from the top level directory if you had added any files

3 if you had downloaded a copy of our stable/snapshot releases, then just create a new issue on our bug tracker, listing the Manufacturer, Product Type, Product ID, Product Name, and email any configuration file you had created to our mailing list

We will review your config file, and possibly make some minor changes. we might ask you to perform some additional testing with your device if we had to fix anything up, and the whole community would be grateful for your testing.

If you have any additional questions, you can always post them to our mailing list