openzwave / open-zwave Goto Github PK

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

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.

Config path fix.

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

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 )
        {

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.

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).

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.

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.

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

In Linux build asserts enabled in release version.

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

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.

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)

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.

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.

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.

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.

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));

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.  

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.

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.

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...

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.

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?

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

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.

Request for a Ubuntu .deb package distribution.

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.

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.

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

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..

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!

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?

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.

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);

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.

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.

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.

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

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?

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.

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

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.

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.

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.

This is for me so I don't forget.

Fixed config path. 

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.

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

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