openzwave/open-zwave

a C++ library to control Z-Wave Networks via a USB Z-Wave Controller.

Last Updated: 17 November 2022

---

NOTICE: This project is no longer being maintained. ⚠️

openzwave has no more maintainers, are there any motivated to continue the development of the library?

Introduction

Our goal is to create free software library that interfaces with Z-Wave controllers, allowing anyone to create applications to control devices on a Z-Wave network, without requiring in-depth knowledge of the Z-Wave protocol. OpenZWave is not about creating Z-Wave devices (nodes). The project consists of the main library, written in C++ and wrappers and supporting projects, to interface different languages and protocol(s).

This software is currently aimed at Application Developers who wish to incorporate Z-Wave functionality into their applications.

Our Homepage is at http://www.openzwave.net and our Github Organization is located at https://github.com/OpenZWave/. There are several repositories at that location. This is the README of the main project (often called "the library" or "OpenZWave" or "open-zwave"), located at https://github.com/OpenZWave/open-zwave.

The current version of the main library is called OpenZWave 1.6, it is the master branch of the open-zwave repository and tagged "1.6". The previous version was 1.4 (same branch name and tag), and 1.5 was a development branch. The older versions are no longer maintained. The Dev branch is experimental and is not recommend unless someone specifically asks you to try it.

OpenZWave 1.6 was released on March the 5th, 2019, when the Dev branch was merged into master and the 1.6 tag was created. The OpenZWave Wiki 1.6 Release Notes summarizes changes.

Getting Started

There is an example application based on the library, it is called MinOZW and it is part of the open-zwave repository. This currently offers a minimal example. There are also plenty of other examples on the Internet that you can research.

On Linux, macOS, BSD run "make" to build the library and MinOZW. Optionally, run "make install" to install the library, header and config files system-wide. Run "BUILD=DEBUG make" to make a debug build.

Online Developers documentation is generated from source comments by Doxygen. If you do "make install" and have Doxygen on your system, a description of the api will be in open-zwave/docs/api/html/index.html

On Windows, install "Visual Studio" then open "open-zwave/cpp/build/windows/vs2010/OpenZWave.sln" to build the library or "open-zwave/cpp/examples/windows/MinOZW/vs2010/MinOZW.sln" to build both library and sample application.

Getting Help

If you are using a Application based on OpenZWave, and you have an issue, you should check:

1. If you are an end user, check the Forum and Issue Tracker of your product based on OpenZWave. As this is a library used by dozens of large open source home automation applications, we can not support application related issues here.
2. The OpenZWave Mailing List for general discussion of issues and contacting peers and developers.
3. The OpenZWave Wiki for main library information.
4. The Issue Tracker of the sub-project, for example the Zwave2Mqtt Issue Tracker
5. The OpenZWave Issue Tracker for main library issues and "things being worked on". See "Opening or Contributing to an Issue on Github" if you think the problem is related to the OpenZWave main library.

Opening or Contributing to an Issue on Github

Please check both closed and open Issues before reporting. If you're still having problems, you should generate a (debug) log file and upload that to the OpenZWave Log Analyzer on our homepage, which will check for common issues, and provide some basic recommendations. Please follow the instructions on that page to ensure your log file contains the relevant information.

If you think you have found a bug, ZIP the OZW_log.txt and your ozwcache*xml file and "drag and drop" the resulting archive on the github issue or comment you create on GitHub. Please do not paste as text.

Please always provide an OZW_Log.txt file. Z-Wave is a reasonably complex protocol, and thus, it is almost always necessary for us to review that log file to understand what is going on.

Language Wrappers

A number of members of the community have developed wrappers for OpenZWave for other languages. Those actively maintained wrappers can be found at the OpenZWave Github Organization

If you have developed a wrapper for another language, and would like to publish it under the OpenZWave Organization (and gain access to things like CI, Distribution Build Servers etc) please contact Fishwaldo on our mailing list.

Device Database and Supporting New Devices

If your device is not recognized by OpenZWave, it should still work as long as its compliant with the Z-Wave specifications. Our Device database is mainly based on community contributions, so please consult the wiki page on Adding Devices on how to add the Device to the manufacturer_specific.xml file and generate a Configuration xml file for it.

When OpenZWave 1.6 starts, it checks the version of several related files configuration files and downloads the latest revision. This behavior can be changed by changing the AutoUpdateConfigFile configuration in options.xml. Config options are explained on the wiki page on Config-Options

You can have a look at the current device database for OpenZWave 1.6 by browsing to the Online Device Database

Please note device configuration files for 1.6 and 1.4 are different. If your application is based on OpenZWave version 1.4, the older database is still available but unmaintained at: OpenZWave 1.4 branch, config folder

Contributing to OpenZWave

We are happy to accept Pull Requests via GitHub. A few things to follow when preparing a Pull Request.

1. If you have added or changed any of the configuration files (eg, adding a new device) please run "make xmltest" from the root directory to ensure your XML is well formed. Also run "make dist-update" if you have added files.
2. Please add a entry to the ChangeLog describing the change you made.
3. If you want to change OpenZWave code, please discuss your plan through the Mailing List or on Github prior to starting your work. Z-Wave is complex and there are lots of corner cases as far as proper support of the various (non-standard) devices out there. While it might sometimes seem (overly) complicated, it most likely is there for a reason.
4. Finally, if you have signed a NDA with Sigma Designs, and your proposed changes are covered by that NDA, we are unable to accept your changes. OZW is developed by reverse engineering and consulting publicly available information. We do not want users to infringe upon their agreements. The OpenZWave organization has not signed a NDA with Sigma.
5. Parts of the spec have been released as the Public Z-Wave Specification, and the radio protocol is know as G.9959. There may be more public resources, but please do check the terms and conditions of every part before posting for compatibility with "Open Source Software"

Trivia

Prior to Sept, 2016, OpenZWave was developed by mainly reverse engineering the protocol as well as consulting various public information on the Internet.

In September 2016, Sigma Designs released a large portion (not all) of the Z-Wave Protocol Specifications into the public domain.

On April 18, 2018, Silabs acquired Sigma Design's Z-Wave business, they now host the official Z-Wave Support Resources

In 2005 the Z-Wave Alliance was established. OpenZWave is an Affiliate Member of the Z-Wave Alliance.

License

OpenZWave is an open source program that is LGPL licensed. This does allow commercial applications to utilize the OpenZWave library, but we ask that you support us by either contributing any changes back to the community, or consider a donation of Z-Wave hardware to the developers so we can continue to ensure openzwave works well with the z-wave ecosystem. (You should also be aware that of the Z-Wave restrictions about selling software that implements this public standard. Please consult the Z-Wave Alliance and Z-Wave Support Resources for further info.

Of course, for Open Source applications, as long as you abide by our License (LGPL) we would love to welcome you the OpenZWave community!

Contributors

Code Contributors

This project exists thanks to all the people who contribute. [Contribute].

Financial Contributors

Become a financial contributor and help us sustain our community. [Contribute]

Individuals

(We also have many users that support us via Github Sponsors program!)

Organizations

Support this project with your organization. Your logo will show up here with a link to your website. [Contribute]

Sponsors

The Following Organisations Sponsor OpenZWave Development by donating hardware for testing and support

open-zwave's Issues

Compile issue on 64 Bits systems

I upgraded my domotiga system to 64 Bits Linux, and ran into a compile issue, 
fixed it too, see below.

What steps will reproduce the problem?
1. Download on a 64 Bit Linux system
2. $ cd open-zwave-read-only/cpp/build/linux
3. $ make

What is the expected output? What do you see instead?
g++ -o libdomozwave.so -g DomoZWave.o open-zwave/cpp/lib/linux/openzwave.a 
-lxmlrpc -lxmlrpc_client -lxmlrpc_xmlparse -lxmlrpc_util -lxmlrpc_xmltok  
-pthread -shared -ludev
/usr/bin/ld: open-zwave/cpp/lib/linux/openzwave.a(Log.o): relocation 
R_X86_64_32 against `.text' can not be used when making a shared object; 
recompile with -fPIC
open-zwave/cpp/lib/linux/openzwave.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libdomozwave.so] Error 1

What version of the product are you using? On what operating system?
Latest revision on Ubuntu Maverick 64Bit

Please provide any additional information below.

Solution:
/open-zwave-read-only/cpp/build/linux/Makefile:

Add -fPIC to CFLAGS:
DEBUG_CFLAGS    := -Wall -Wno-format -g -DDEBUG -DLOG_STDERR -fPIC
RELEASE_CFLAGS  := -Wall -Wno-unknown-pragmas -Wno-format -O3 -fPIC

Original issue reported on code.google.com by ron%[email protected] on 25 Mar 2011 at 7:23

Options::ParseOptionsString may crash when compiled with sizeof(size_t) > sizeof(uint32)

What steps will reproduce the problem?
1. Build open-zwave library
2. Build and run example MinOZW for Mac OS X 10.6


What is the expected output? What do you see instead?

I expect the example to run without getting aborted by an exception originating 
from Options::ParseOptionsString.


What version of the product are you using? On what operating system?

I used revision 288 on Mac OS X 10.6.8.


Please provide any additional information below.

The exception in Options::ParseOptionsString is caused by improper branching. 
When checking for the position of "--" in line 333, the result will receive a 
narrowing conversion on a platform with 64 bit size_t. The narrowed value will 
no longer match std::string::npos and an inappropriate and unsafe execution 
path will be taken from the decision point in line 334.

Using size_t for the position-related variables would be one solution for this 
issue.

string::npos == pos in line 323.

Original issue reported on code.google.com by [email protected] on 29 Jul 2011 at 5:48

Attachments:

• Options.cpp.patch

Compilation error on revision 351

When compilling with Visual Studio 2010 

1>..\..\..\src\Node.cpp(1259): warning C4800: 'int32' : forcing value to bool 
'true' or 'false' (performance warning)

1>..\..\..\src\Driver.cpp(288): error C3861: 'time': identifier not found
1>..\..\..\src\Driver.cpp(325): error C3861: 'time': identifier not found

Original issue reported on code.google.com by [email protected] on 20 Oct 2011 at 8:41

ApplicationCommandHandler Received Before Node is Initialized.

In case a node was asleep and was never initialized (for example a door 
sensor). When this door sensor changes state (opens, closes) it will send 
an application command handler request, which will definitely fail 
(Invalid command class) since the node info has not been receieved yet.

Wouldn't it be good to queue the request till the setAwake and node info 
has been initialized, so as not to lose the event.

For exmaple

void Driver::HandleApplicationCommandHandlerRequest
(
    uint8* _data
)
{
    uint8 nodeId = _data[3];
    SetNodeAwake( nodeId );

    if( m_nodes[nodeId] )
    {
            //Call the command handler only if the node has been 
initialized before
        if (m_nodes[nodeId]->m_nodeInfoReceived)
        m_nodes[nodeId]->ApplicationCommandHandler(_data );
        else
            // do something here to queue the command until 
Node::UpdateNodeInfo has finished.
    }
}

thanks

Original issue reported on code.google.com by [email protected] on 16 Mar 2010 at 11:52

Remove node from network does not appear to be working.

I haven't tested in for about a week, but I could not get remove node to 
function in the base code last time I checked. Addnode worked. 

Tried three times. Maybe it's working now, it needs to be verified.

Original issue reported on code.google.com by [email protected] on 14 Apr 2010 at 3:55

Latest project build failing due to ValueID.cpp missing

What steps will reproduce the problem?
1. Sync with latest bits. 
2. Build with VS2010
3. Linker failed with can find ValueID.cpp

What is the expected output? What do you see instead?


I saw it was deleted in the repository, but not sure.

Original issue reported on code.google.com by [email protected] on 11 Feb 2010 at 10:04

Patch for /trunk/dotnet/examples/OZWForm/src/MainForm.cs

Set the poll interval up so larger networks don't crash and burn

Original issue reported on code.google.com by [email protected] on 13 Jul 2011 at 2:47

Attachments:

• MainForm.cs.patch

Compilation problem for mips toolchain target board routerpro

What steps will reproduce the problem?

Firstly am a newbie in this.. so please be patient with me

1.compile a toolchain for mips -> target board routerstation pro -> openwrt

2.compile libudev under the above toolchain using patch from
https://forum.openwrt.org/viewtopic.php?id=25488

3.manually replace the gcc , g++ , ld , in makefile for the linux build for 
openwave.
CC     
:=/home/prash/openwrt/backfire/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc
-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-gcc
CXX    
:=/home/prash/openwrt/backfire/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc
-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++
LD     
:=/home/prash/openwrt/backfire/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc
-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++
AR     
:=/home/prash/openwrt/backfire/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc
-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-ar rc
RANLIB 
:=/home/prash/openwrt/backfire/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc
-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-ranlib

point to libudev.h  manually as well

The lib compiles fine

What is the expected output? What do you see instead?

However when trying to compile the openzwave linux example (makefile pointing 
to mips toolchain) I see this..

/home/prash/openwrt/backfire/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0
.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -o test -g Main.o 
../../../lib/linux/openzwave.a -pthread -ludev
../../../lib/linux/openzwave.a(SerialControllerImpl.o): In function 
`OpenZWave::SerialControllerImpl::FindUSB(std::basic_string<char, 
std::char_traits<char>, std::allocator<char> >&)':
SerialControllerImpl.cpp:(.text+0x2e8): undefined reference to `udev_new()'
SerialControllerImpl.cpp:(.text+0x2f8): undefined reference to 
`udev_enumerate_new(udev*)'
SerialControllerImpl.cpp:(.text+0x30c): undefined reference to 
`udev_enumerate_add_match_subsystem(udev_enumerate*, char const*)'
SerialControllerImpl.cpp:(.text+0x318): undefined reference to 
`udev_enumerate_scan_devices(udev_enumerate*)'
SerialControllerImpl.cpp:(.text+0x324): undefined reference to 
`udev_enumerate_get_list_entry(udev_enumerate*)'
SerialControllerImpl.cpp:(.text+0x354): undefined reference to 
`udev_list_entry_get_name(udev_list_entry*)'
SerialControllerImpl.cpp:(.text+0x360): undefined reference to 
`udev_device_new_from_syspath(udev*, char const*)'
SerialControllerImpl.cpp:(.text+0x374): undefined reference to 
`udev_device_get_parent_with_subsystem_devtype(udev_device*, char const*, char 
const*)'
SerialControllerImpl.cpp:(.text+0x388): undefined reference to 
`udev_device_get_sysattr_value(udev_device*, char const*)'
SerialControllerImpl.cpp:(.text+0x398): undefined reference to 
`udev_device_get_sysattr_value(udev_device*, char const*)'
SerialControllerImpl.cpp:(.text+0x3b8): undefined reference to 
`udev_device_get_sysattr_value(udev_device*, char const*)'
SerialControllerImpl.cpp:(.text+0x3d8): undefined reference to 
`udev_device_unref(udev_device*)'
SerialControllerImpl.cpp:(.text+0x3e8): undefined reference to 
`udev_list_entry_get_next(udev_list_entry*)'
SerialControllerImpl.cpp:(.text+0x3fc): undefined reference to 
`udev_enumerate_unref(udev_enumerate*)'
SerialControllerImpl.cpp:(.text+0x404): undefined reference to 
`udev_unref(udev*)'
SerialControllerImpl.cpp:(.text+0x478): undefined reference to 
`udev_device_get_sysattr_value(udev_device*, char const*)'
SerialControllerImpl.cpp:(.text+0x494): undefined reference to 
`udev_device_get_devnode(udev_device*)'
SerialControllerImpl.cpp:(.text+0x4ac): undefined reference to 
`udev_device_get_devnode(udev_device*)'
collect2: ld returned 1 exit status

if change back to gcc it all compiles and run fine....

offcourse I did use yum on fedora to get libudev.

can anyone help ? might be just my stupidity


What version of the product are you using? On what operating system?

cross compiling on fedora 15 for openwrt backfire

current trunk for openzwave



Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 6 Oct 2011 at 2:40

Figure out how to support F/C in thermostats

We need a way to support multiple unit types for a particular value such as F/C 
in thermostat temperature settings.

Original issue reported on code.google.com by glsatz on 21 Oct 2011 at 3:58

Save precision of floating point value into the ValueDecimal object

Actually we do know what precision to use, because it's reported in
the message along with the value.  If you look in
CommandClass::ExtractValue, we use it to put the decimal point in the
right place.  We just need to store the precision in ValueDecimal, I
guess.

Mal

Original issue reported on code.google.com by [email protected] on 21 Oct 2011 at 5:29

Cross compilation for Asus RT-N16

I have Asus RT-N16 (running on Broadcom 47xx, linux). Trying to cross-compile 
the library on Ubuntu 10.04 (thru VMWare Player).

What steps will reproduce the problem?
1. Download toochain from 
http://code.google.com/p/wl500g/downloads/list?can=3&q=hndtools-mipsel-uclibc-4.
4.6-K26&colspec=Filename+Summary+Uploaded+Size+DownloadCount
2. Add that to the path:
PATH=$PATH:/home/user/hndtools-mipsel-uclibc-4.4.6-K26/bin/
3. Install subversion:
sudo apt-get install subversion
4. Checkout all needed files:
svn checkout http://open-zwave.googlecode.com/svn/trunk/ open-zwave
5. Add to /open-zwave/cpp/build/linux/Makefile
CROSS_COMPILE = mipsel-linux-
6. Try to make
user@ubuntu1004desktop:~/open-zwave/cpp/build/linux$ make
...
../../hidapi/linux/hid.c:40:26: error: linux/hidraw.h: No such file or directory
../../hidapi/linux/hid.c:42:21: error: libudev.h: No such file or directory
../../hidapi/linux/hid.c:62: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'kernel_version'
...
7. Replace gcc with mipsel-linux-gcc, g++ with mipsel-linux-g++ at 
/home/user/open-zwave/cpp/hidapi/linux/Makefile
8. Try to make HIDAPI:
user@ubuntu1004desktop:~/open-zwave/cpp/hidapi/linux$ make
It returns a lot of errors.

Original issue reported on code.google.com by [email protected] on 5 Sep 2011 at 6:24

Need ValueID application string interface

The bit I missed is dealing with the storage and reuse of value IDs by
the application itself - we should provide an interface for that
(probably to/from a string, maybe json formatted).

Original issue reported on code.google.com by glsatz on 21 Oct 2011 at 3:52

HSM-100 reporting over 100 groups when powering up sometimes

What steps will reproduce the problem?

1.Build a debug version of the bits with VS2008/10
2.Press blue button on device and wait 5 seconds
3.Start up application and wait till device query done
4.Wave hand in front of sensor as a basic test to make sure node is 
associated.
5. Press blue button on side about 5-10 times and watch the network data 
being queried each time. When you see a massive hex dump go by, that is 
the bug.

What is the expected output? What do you see instead?
Most of the time is reads the classes from each node properly, but about 1 
in 4 times after pushing the blue button, the group reports back over 
hundred groups and then queries each of them for the next 20 seconds. This 
has happened to be two months ago, but didn't know what I was seeing.

Two thoughts here: One is that it looks like the hsm-100 can't be 
interrupted at all during the querying process so perhaps another node 
broadcast will throw off the state machine. (my Leviton light switch puts 
out a fair amount of chatter)

Or, I'm seeing a lot of data from the hsm-100 that I don't understand and 
I suspect the receiver is tripping up. I see a lot of temperature stuff 
reading like 8434.00 degrees, then a few lines later I see 72.1 degrees??

At any rate, this never seemed to happen to me when I was running the code 
in the debugger with vs2010. I have noticed the timing is much different.

Attached is an error where I start the network, hit the blue button once, 
then I get a big dump of bogus groupings.

I did see this massive grouping issue serveral weeks ago, but could not 
pin it down.

Original issue reported on code.google.com by [email protected] on 25 Mar 2010 at 6:30

Attachments:

• [fresh start- one button click and then tons of data.txt](https://storage.googleapis.com/google-code-attachments/open-zwave/issue-12/comment-0/fresh start- one button click and then tons of data.txt)

Door Sensor Log

Attached is the log file for Aeon Labs door sensor to show the basic 0x20 
messages being received upon open/close and how an instant requestState 
after open/close can update the Sensor with the right value.
Note: Group 1 has node 1 associated.

Original issue reported on code.google.com by [email protected] on 20 Mar 2010 at 11:31

Attachments:

• doorsensor.txt

Openzwave Open serial port hangs on newest kernels

What steps will reproduce the problem?
1. Run the test program and it hangs after Open serial port /dev/ttyUSB0

I am running Fedora 14. Another user reported the same issue with the latest 
'Ubuntu Maverick kernel'.

It appears the newer kernels will block on the open waiting for a
carrier detect (DCD) to be asserted. To solve, I added a O_NDELAY to the open. 
However that implies nonblocking, so once I open it, I switch the socket to 
BLOCKING mode which open-zwave requires.

Here is the patch to get it to work:

===================================================================
--- SerialControllerImpl.cpp    (revision 215)
+++ SerialControllerImpl.cpp    (working copy)
@@ -75,7 +75,10 @@
 {
        Log::Write( "Open serial port %s",
_SerialControllerName.c_str() );

-       m_hSerialController = open( _SerialControllerName.c_str(),
O_RDWR | O_NOCTTY, 0 );
+       m_hSerialController = open( _SerialControllerName.c_str(),
O_RDWR | O_NOCTTY | O_NDELAY, 0 );
+       int flags;
+       flags = fcntl(m_hSerialController, F_GETFL);
+       fcntl(m_hSerialController, F_SETFL, flags & (~O_NONBLOCK));

        if( -1 == m_hSerialController )
        {

Original issue reported on code.google.com by [email protected] on 14 Feb 2011 at 3:15

Compile on Ubuntu 10.04 (32bit)

Try to compile library on Ubuntu 10.04:
user@ubuntu1004desktop:~/open-zwave/cpp/build/linux$ make

and get a lot of errors:
g++ -c -Wall -Wno-format -Werror -g -DDEBUG -DLOG_STDERR -I ../../src -I 
../../src/command_classes/ -I ../../src/value_classes/ -I ../../src/platform/ 
-I ../../src/platform/unix -I ../../tinyxml/ -I ../../hidapi/hidapi/ -o 
tinystr.o ../../tinyxml/tinystr.cpp
g++ -c -Wall -Wno-format -Werror -g -DDEBUG -DLOG_STDERR -I ../../src -I 
../../src/command_classes/ -I ../../src/value_classes/ -I ../../src/platform/ 
-I ../../src/platform/unix -I ../../tinyxml/ -I ../../hidapi/hidapi/ -o 
tinyxml.o ../../tinyxml/tinyxml.cpp
g++ -c -Wall -Wno-format -Werror -g -DDEBUG -DLOG_STDERR -I ../../src -I 
../../src/command_classes/ -I ../../src/value_classes/ -I ../../src/platform/ 
-I ../../src/platform/unix -I ../../tinyxml/ -I ../../hidapi/hidapi/ -o 
tinyxmlerror.o ../../tinyxml/tinyxmlerror.cpp
g++ -c -Wall -Wno-format -Werror -g -DDEBUG -DLOG_STDERR -I ../../src -I 
../../src/command_classes/ -I ../../src/value_classes/ -I ../../src/platform/ 
-I ../../src/platform/unix -I ../../tinyxml/ -I ../../hidapi/hidapi/ -o 
tinyxmlparser.o ../../tinyxml/tinyxmlparser.cpp
gcc -c -Wall -Wno-format -Werror -g -DDEBUG -DLOG_STDERR -I ../../src -I 
../../src/command_classes/ -I ../../src/value_classes/ -I ../../src/platform/ 
-I ../../src/platform/unix -I ../../tinyxml/ -I ../../hidapi/hidapi/ -o hid.o 
../../hidapi/linux/hid.c
../../hidapi/linux/hid.c:42:21: error: libudev.h: No such file or directory
cc1: warnings being treated as errors
../../hidapi/linux/hid.c:76: error: ‘struct udev_device’ declared inside 
parameter list
../../hidapi/linux/hid.c:76: error: its scope is only this definition or 
declaration, which is probably not what you want
../../hidapi/linux/hid.c: In function ‘copy_udev_string’:
../../hidapi/linux/hid.c:80: error: implicit declaration of function 
‘udev_device_get_sysattr_value’
../../hidapi/linux/hid.c:80: error: assignment makes pointer from integer 
without a cast
../../hidapi/linux/hid.c: In function ‘get_device_string’:
../../hidapi/linux/hid.c:164: error: implicit declaration of function 
‘udev_new’
../../hidapi/linux/hid.c:164: error: assignment makes pointer from integer 
without a cast
../../hidapi/linux/hid.c:173: error: implicit declaration of function 
‘udev_device_new_from_devnum’
../../hidapi/linux/hid.c:173: error: assignment makes pointer from integer 
without a cast
../../hidapi/linux/hid.c:177: error: implicit declaration of function 
‘udev_device_get_parent_with_subsystem_devtype’
../../hidapi/linux/hid.c:180: error: assignment makes pointer from integer 
without a cast
../../hidapi/linux/hid.c:182: error: assignment makes pointer from integer 
without a cast
../../hidapi/linux/hid.c:192: error: implicit declaration of function 
‘udev_device_unref’
../../hidapi/linux/hid.c:195: error: implicit declaration of function 
‘udev_unref’
../../hidapi/linux/hid.c: In function ‘hid_enumerate’:
../../hidapi/linux/hid.c:214: error: assignment makes pointer from integer 
without a cast
../../hidapi/linux/hid.c:221: error: implicit declaration of function 
‘udev_enumerate_new’
../../hidapi/linux/hid.c:221: error: assignment makes pointer from integer 
without a cast
../../hidapi/linux/hid.c:222: error: implicit declaration of function 
‘udev_enumerate_add_match_subsystem’
../../hidapi/linux/hid.c:223: error: implicit declaration of function 
‘udev_enumerate_scan_devices’
../../hidapi/linux/hid.c:224: error: implicit declaration of function 
‘udev_enumerate_get_list_entry’
../../hidapi/linux/hid.c:224: error: assignment makes pointer from integer 
without a cast
../../hidapi/linux/hid.c:227: error: implicit declaration of function 
‘udev_list_entry_foreach’
../../hidapi/linux/hid.c:227: error: expected ‘;’ before ‘{’ token
../../hidapi/linux/hid.c:209: error: unused variable ‘cur_dev’
../../hidapi/l

what is wrong there?

Original issue reported on code.google.com by [email protected] on 4 Sep 2011 at 2:33

"double free or corruption"

I ran into a crash in a modified OZW example. I don't think glibc debugging was 
properly enabled (supposedly by linking with "-lc_g"?), so I don't know how 
useful the crash report is, but I've attached the full log in case it helps.

Original issue reported on code.google.com by [email protected] on 20 Jul 2010 at 5:33

Attachments:

• OZW_crash.log

USB HID support not finished

Just a place holder to follow USB HID support.

In particular we also need a way to remove an added HID driver. AddDriver 
supports USB HID devices but RemoveDriver does not.

Original issue reported on code.google.com by glsatz on 23 Feb 2011 at 9:14

Feature request: provide configure file with sources

I would like to compile application (as well as examples) for my NAS - Synology 
DS210j. Configure files included into sources will help me and other users to 
compile your application for different devices.
Thanks in advance.

Original issue reported on code.google.com by [email protected] on 7 Jul 2010 at 4:38

No good provision for empty ValueLists

This was discussed extensively on the mailing list:

http://groups.google.com/group/openzwave/t/fbed5040df868265

In summary:

It's possible to get ValueList items that have no items in them, either because 
of an incomplete query, or manual editing.  This will later fail with the 
vector lookup in ValueList.h.  There's no provision in the current structure of 
the code to return a failure here.

An immediate work around is to return a dummy Item in this case.

In addition, we don't do good range checking on some CommandClasses which make 
use of lists, so it's possible to get a supported value/bitset from a device, 
which doesn't map to a list item.  Some fixes for this have already been done 
in ThermostatFanMode for example.

Original issue reported on code.google.com by [email protected] on 17 Oct 2011 at 10:40

• Blocking: #381

Driver::ControllerCommand_ReceiveConfiguration isn't recognized as a controller command

Driver::ControllerCommand_ReceiveConfiguration isn't recognized as a controller 
command when queued to the serial port. So it is added to the back of the 
output queue instead of the front. As a result the command is never sent out 
because the code shuts down output thinking a controller command was sent when 
in fact it is still sitting on the queue.

The issue appears in Driver::SendMsg at:

    if( IsControllerCommand( _msg->GetExpectedReply() ) )
        // give priority to controller commands by putting at front of queue (right behind the current message)
        m_sendQueue.push_front( _msg );
    else
        // everything else goes to back of queue
        m_sendQueue.push_back( _msg );

I updated isControllerCommand to recognize the underlying Z-Wave packet that is 
used by ReceiveConfiguration. However it appears that _msg->GetExpectedReply() 
is never set so the command still isn't recognized as a controller command.

The consequence of this is you get the following error when trying to send this 
controller command:

            Log::Write("Not sending a queued message because controller is busy.  m_controllerCommand = %d",m_controllerCommand);

Original issue reported on code.google.com by glsatz on 23 Feb 2011 at 9:20

Changed visiblity of value->Set from protected to public in value.h (no commit)

Didn't understand perhaps on the proper procedure for the sequence of 
calls, but I had to change the visibility of the Set() method in the value 
class so I could see it from my application...I think I'm calling the 
proper method, but I'm looping through all the commands I think, so I'm 
sure where the problem is here. There are others that are also protected, 
so that is confusing me some.

Here is my call:
if( value = static_cast<ValueByte*>( store->GetValue( _id ) ) )
{
    value->Set(); //turn on device for that command class
}

I could not access it when it is protected.

Let me know how to fix, test, or if you need more info. I'm think it would 
be nice to get one device turning on and off with callback status update 
within the next 10 days.

Original issue reported on code.google.com by [email protected] on 13 Feb 2010 at 4:39

TASK: Start system test plan

I'll start a basic system test plan and code up a few test cases. Mainly 
smoke test level at first. I'll draft out an outline with 4 tests to start 
with. Also, I'll see which way is best to code the tests.

Original issue reported on code.google.com by [email protected] on 11 Mar 2010 at 11:46

Changeset 288 breaks source compatibility with non-Linux systems

What steps will reproduce the problem?
1. Checkout open-zwave revision 288
2. Try to build the library for example on Mac OS X


What is the expected output? What do you see instead?

I expecte the open-zwave library to compile without getting aborted by an 
error. Instead compiling SerialControllerImpl.cpp aborts with the error that 
libudev.h could not be found. From my point of view, Linux-specific 
functionality has ben introduced unconditionally into the Unix source branch.


What version of the product are you using? On what operating system?

I'm using open-zwave revision 288 on Mac OS X 10.6.8.

Original issue reported on code.google.com by [email protected] on 29 Jul 2011 at 6:04

HSM-100 sensor class might be missing a variable type of byte

I'm not sure, but before I forget, I'll turn in this issue in the 
multisensor class. When looking at the class, I only see it returning 3 
decimal values and did not see where the sensor value is stored. I could 
be wrong, but I think this might be explaining the weird values of 10 and 
20's that being returned.

Original issue reported on code.google.com by [email protected] on 25 Mar 2010 at 1:42

Command Class Basic (Unhandled)

What steps will reproduce the problem?
1. Aoen labs Door Sensor
2. Sends a basic set command class 0x20 when open/closed though the class 
is not in its supported list.
  COMMAND_CLASS_SENSOR_BINARY
  COMMAND_CLASS_ALARM
  COMMAND_CLASS_MANUFACTURER_SPECIFIC
  COMMAND_CLASS_BATTERY
  COMMAND_CLASS_WAKE_UP
  COMMAND_CLASS_ASSOCIATION
  COMMAND_CLASS_VERSION
Which will raise an error in application command handler that the command 
class is not found.
3. I added the class 0x20 manually to all nodes. And the error was 
resolved:
"Received Basic set from node 13: level=0"

The HSM100 motion sensor seems to also send its motion alert via class 
0x20.

Do i have to add the command_basic class by force to all nodes?

Original issue reported on code.google.com by [email protected] on 3 Mar 2010 at 10:09

Association Groups are still queried when config exists

E.g on my 0007 RCS Thermostat:

2011-10-17 15:42:17:353 Sending command (Callback ID=0x0a, Expected Reply=0x04) 
- Get Association Gr
oupings (Node=3): 0x01, 0x09, 0x00, 0x13, 0x03, 0x02, 0x85, 0x05, 0x05, 0x0a, 
0x6b
2011-10-17 15:42:17:355   ACK received CallbackId 0x0a Reply 0x04
2011-10-17 15:42:17:359   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2011-10-17 15:42:17:360   ZW_SEND_DATA delivered to Z-Wave stack
2011-10-17 15:42:17:371   Received: 0x01, 0x05, 0x00, 0x13, 0x0a, 0x00, 0xe3
2011-10-17 15:42:17:372   ZW_SEND_DATA Request with callback ID 0x0a received 
(expected 0x0a)
2011-10-17 15:42:22:571 Timeout
2011-10-17 15:42:22:572 Resending message (attempt 1)

Original issue reported on code.google.com by [email protected] on 17 Oct 2011 at 10:47

Sample code missing on how to turn devices on and off

With all the new recent changes in the code. I don't see any sample code 
in the sample application for doing any work with devices.

I think this would greatly help people till we get the wrapper done.

Putting this in as a bug for now.

Original issue reported on code.google.com by [email protected] on 9 Apr 2010 at 6:30

Create Ubuntu .deb package

Request for a Ubuntu .deb package distribution.

Original issue reported on code.google.com by glsatz on 19 Sep 2011 at 4:47

This line is broke - ValueList::Item const& item = value->GetPending();

I'll post my sample code in the HA04 topic, but I had to patch around this 
line in order to turn my HA04 device on. (only ON, no off, no callback)

The line above is from the file SwitchAll.cpp (line 124). When executed, 
it is causing a vector subscript out of range error. The vector is looking 
for something like the number 2, but its comparing it with garbage, so 
it's failing. m_pendingIdx seems to be the problem in ValueList.h .. it is 
not initilized / referenced.

Not sure how you want to handle all this as I could probably fix it, but 
it would take several weeks. I don't feel comfortable with any 
architecture stuff, only minor stuff.  

Original issue reported on code.google.com by [email protected] on 13 Feb 2010 at 4:13

Attachments:

• assertion.jpg

Patch for /trunk/dotnet/examples/OZWForm/src/MainForm.cs

Fixed config path. 

Original issue reported on code.google.com by [email protected] on 13 Jul 2011 at 5:02

Attachments:

• MainForm.cs.patch

Controlthink USB stick - how to use this wrapper for C#?

I see in the demo for the wrapper that you guys are using serial ports? I 
have a ControlThink usb stick. How can I use your wrapper for my usb stick?

Original issue reported on code.google.com by [email protected] on 3 May 2010 at 4:42

PM52 Meter reports negative values.

This is a:  <Product type="454d" id="3532" name="PM52-ZW Z-Wave Home Energy 
Meter" />

I'm not in an immediate position to provide a full log for this since it's a 
colleague's setup, but I'm hoping the log snapshot with raw data might be 
sufficient:

2011-10-17 14:15:29:500 Received Meter report from node 8: Energy=-260.52kWh
2011-10-17 14:15:29:503   Received: 0x01, 0x14, 0x00, 0x04, 0x00, 0x08, 0x0e, 
0x32, 0x02, 0x21, 0x44, 0xff, 0xff, 0x9a, 0x3c, 0x00, 0x00, 0xff, 0xff, 0x9a, 
0x3c, 0xbc

2011-10-17 14:15:34:500 Received Meter report from node 8: Power=-1244W
2011-10-17 14:15:34:503   Received: 0x01, 0x14, 0x00, 0x04, 0x00, 0x08, 0x0e, 
0x32, 0x02, 0x21, 0x14, 0xff, 0xff, 0xfb, 0x24, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x33


He has tried reversing the power clamps.  The values are correct apart from 
sign, so I don't know if there's a bit interpretation error somewhere.  It's 
worth noting that both the instant and cumulative values are negative.

I have the same meter elsewhere and don't see this.

Original issue reported on code.google.com by [email protected] on 17 Oct 2011 at 9:23

No useful information is comiing out of the Manufacturing class

Either or both of these classes don't seem to return anything? I did not 
look into this at all, but I would expect at least the brand name to print 
on the screen when the node is queried?

I don't have time to look at this for a while so if anyone wants to grab 
the issue or investigate the issue, just assign it to you and let the 
board know if you need help testing it.

COMMAND_CLASS_MANUFACTURER_SPECIFIC 0x72
COMMAND_CLASS_VERSION 0x86

What is the expected output? What do you see instead?
Some useful information.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by [email protected] on 27 Mar 2010 at 5:31

Avoid hidraw usage?

Is there any way to change the code of the library to avoid hidraw usage? My 
device is running on old version of linux (2.6.22), where hidraw is not 
supported.

Original issue reported on code.google.com by [email protected] on 8 Sep 2011 at 7:50

Disable assert in release build for linux

In Linux build asserts enabled in release version.

Changes to Makefile:
RELEASE_CFLAGS  := -Wall -Wno-unknown-pragmas -DNDEBUG -Wno-format -O3 

Original issue reported on code.google.com by [email protected] on 20 Jun 2011 at 7:43

TASK: Make wrapper so C++ can be read from C#

This is a task to follow the research, progress, or percentage of 
completion of generating a .NET wrapper for the project. I don't think the 
task will be that difficult, but the code could change as the idea of 
using a variant type might be used, but I think the subject needs more 
researching. I suggest starting with one basic call such as turning a 
device on and off. I would advice not putting any time frames as of now. 
More of an ownership status is what I'm thinking.

Original issue reported on code.google.com by [email protected] on 6 Mar 2010 at 10:54

Manually pressing a binary device button does not produce a callback

What steps will reproduce the problem?
1.Set a break point on the callback in the sample application after 
networks starts
2.Press button on binary switch
3.Breakpoint does not get hit

What is the expected output? What do you see instead?
Breakpoint to be hit and callback called

Additional information:
The last fix did correct the above behavior and the breakpoint was being 
hit, but because the dynamic data was already read in the node request 
block a few lines earlier, the nodes were being read twice.

Original issue reported on code.google.com by [email protected] on 5 Mar 2010 at 8:56

Patch for /trunk/dotnet/examples/OZWForm/src/MainForm.cs

Config path fix.

Original issue reported on code.google.com by [email protected] on 13 Jul 2011 at 2:34

Attachments:

• MainForm.cs.patch

Patch for /trunk/cpp/src/command_classes/CommandClasses.cpp

Fix Error   1   error C2065: 'uint' : undeclared 
identifier  D:\OpenZWave\cpp\src\command_classes\CommandClasses.cpp 238 1   OpenZWa
ve

Original issue reported on code.google.com by [email protected] on 13 Jul 2011 at 4:51

Attachments:

• CommandClasses.cpp.patch

Sleeping devices no longer marked as sleeping.

I am seeing this on my sleeping devices. In the past (last working revision I 
got is r244), devices would be marked as sleeping.. some example logging:

2011-05-19 20:06:40:878 Error: ZW_SEND_DATA failed.
2011-05-19 20:06:40:879   Node 4 has been marked as asleep
2011-05-19 20:06:40:880 Node not responding - moving message to Wake-Up queue: 
Get Associations (Node=4): 0x01, 0x0a, 0x00, 0x13, 0x04, 0x03, 0x85, 0x02, 
0x01, 0x05, 0x08, 0x6a

Then the device would behave as expected upon wakeup:

2011-05-19 20:10:01:771 Received Wakeup Notification from node 4
2011-05-19 20:10:01:772   Node 4 has been marked as awake
2011-05-19 20:10:01:773 Queuing command: Get Associations (Node=4): 0x01, 0x0a, 
0x00, 0x13, 0x04, 0x03, 0x85, 0x02, 0x01, 0x05, 0x08, 0x6a
2011-05-19 20:10:01:774 Queuing command: Set Thermostat Setpoint (Node=4): 
0x01, 0x0c, 0x00, 0x13, 0x04, 0x05, 0x43, 0x01, 0x01, 0x01, 0x0f, 0x05, 0x09, 
0xa0

2011-05-19 20:10:01:776 Sending command (Callback ID=0x08, Expected Reply=0x04) 
- Get Associations (Node=4): 0x01, 0x0a, 0x00, 0x13, 0x04, 0x03, 0x85, 0x02, 
0x01, 0x05, 0x08, 0x6a
2011-05-19 20:10:01:780   ACK received CallbackId 0x08 Reply 0x04
2011-05-19 20:10:01:783   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2011-05-19 20:10:01:785   ZW_SEND_DATA delivered to Z-Wave stack
2011-05-19 20:10:01:795   Received: 0x01, 0x05, 0x00, 0x13, 0x08, 0x00, 0xe1
2011-05-19 20:10:01:797   ZW_SEND_DATA Request with callback ID 0x08 received 
(expected 0x08)
2011-05-19 20:10:01:803   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x04, 0x07, 
0x85, 0x03, 0x01, 0x04, 0x00, 0x01, 0x03, 0x74

In newer revisions, devices never get marked as being asleep (see attached 
logfile). This causes serious issues, such as certain device info not being 
discovered.

Can anyone cross check this? I am not sure where to start fixing this issue..

Original issue reported on code.google.com by [email protected] on 30 Sep 2011 at 10:29

Attachments:

• OZW_Log.txt

Bug in CommandClass::AppendValue(msg,value,precision,scale). Doesn't append value

What steps will reproduce the problem?
1. Set ThermostatSetpoint to any value
2.
3.

What is the expected output? What do you see instead?
The thermostat target temperature should update. Because the value is not being 
appended the thermostat target temperature goes to its lowest setting.

What version of the product are you using? On what operating system?
Latest SVN as of 31st December. Linux (Ubuntu). 

Please provide any additional information below.
The bug is around line 309 of CommandClass.cpp file.
_msg->Append( (uint8)((iValue >> (size<<3)) & 0xff) );

To get it working I simply hardcoded the below value. This assumes the size is 
only 1 byte.
_msg->Append( (uint8)(iValue));

Original issue reported on code.google.com by david%[email protected] on 4 Jan 2011 at 7:19

Aeon Labs DSB04100-ZWUS Wireless Door/Window Sensor - No Event Received

What steps will reproduce the problem?
1. Install a Aeon Labs DSB04100-ZWUS Wireless Door/Window Sensor into the 
z-wave mesh.
2. The sensor will go into sleep mode and therefore not query.
3. When the sensor is activated, no notification is processed.

What is the expected output? What do you see instead?
I would expect to receive a NodeEvent or ValueChanged notification, however I 
am not receiving anything at all.

What version of the product are you using? On what operating system?
Latest Branch as of 6/6/11, Windows 7 x64

Please provide any additional information below.

I haven't tried to debug this too much yet, as it may be something I am doing 
wrong. Perhaps I need to try and create an association before the controller 
will receive a notification--I wonder if that would do it...

Original issue reported on code.google.com by [email protected] on 7 Jun 2011 at 1:13

Explore collision scenario where messages received cause previously transmitted message to timeout

It appears that every time an asynchronous message is received when a previous 
message was transmitted, the transmitted message never gets a response. It 
seems the asynchronous received message collides or blocks the previously 
transmitted message's response.

We should explore code that shortens this scenario when the asynchronous 
message is received if a previous outstanding message exists, terminating the 
wait for a response and just retransmit the previous message again.

Original issue reported on code.google.com by [email protected] on 21 Oct 2011 at 4:50

Really looking forward to this

Hello,

Didn't know how else to contact the author so I am submitting an issue.  I
am extremely interested in this project.  I have been using Controlthink's
SDK for a couple years now and have become increasingly annoyed by their
lack of support.  I have been looking for an alternative and came across
your project.  When do you plan on having an initial release?  I would be
willing to help if I can.  Thanks.  

You can contact me at bwoodworth (at) gmail (dot) com

Original issue reported on code.google.com by [email protected] on 18 Oct 2009 at 7:59

linux makefile doesn't support cross-compilation [incl. patch]

A common env variable for controlling which cross-compiler to use is

CROSS_COMPILE

I've attached a simple patch so that the linux Makefile respects this.

Cheers!

Original issue reported on code.google.com by [email protected] on 11 Oct 2010 at 3:52

Attachments:

• openzwave-linux-cross-compile.patch

min/max are not honored for Values

There is provision for zwave values to have min/max values, which we store in 
the config file. In some cases, we can get these from the device, in other 
cases, determined experimentally.

However, these are not enforced anywhere, so it is possible for example, to set 
a completely bogus value in openzwave (e.g, a thermostat set point), which it 
will hold onto until it gets an update from the device. 

Enforcing these in most cases is easy - consider min and max of 0 as unknown, 
and refuse otherwise.  

The problem here is for thermostats, which typically have the option of 
reporting in C and F, which will naturally have different ranges.

Original issue reported on code.google.com by [email protected] on 17 Oct 2011 at 10:33

Wrong command sent in SwitchToggleMultilevel::RequestValue

What steps will reproduce the problem?
1. Start the example OZWForm
2.
3.

What is the expected output? What do you see instead?
My lamps start to flash and newer stops

What version of the product are you using? On what operating system?
Latest retreived from svn (2011-08-31)

Please provide any additional information below.
I do not know anything about the protocol but changing the code to send 
SwitchToggleBinaryCmd_Get instead helped

Original issue reported on code.google.com by [email protected] on 1 Sep 2011 at 7:00

Task: Detail out the rest of device request command classes

This is for me so I don't forget.

Original issue reported on code.google.com by [email protected] on 26 Mar 2010 at 11:27

Use of non ansi c standard functions in the Windows implementation

I wanted to compile open-zwave using mingw32, but the build fails due to the 
use of fopen_s and fprint_s functions within the log implementation 
(LogImpl.cpp and HidControllerImpl.cpp). It would be nice if these functions 
are replaced by standard ansi c functions, so non Microsoft compilers work as 
well. After removing those functions it compiles just fine.

The Linux imlementation uses the right functions so I guess it could be easily 
ported.

Original issue reported on code.google.com by [email protected] on 27 Mar 2011 at 8:10