Certain Z wave devices fail with value validation

[bencpeters]

Some Z-Wave devices (including the Aeon Labs 4-in-1 Multisensor, but there may well be others) do not update properly when the open z wave option to verify value updates is set to true. From my research it is unclear whether this is a bug in open z wave or the actual devices, but for these devices to work properly with openzwave, SetChangeVerified must be set to false. Since for many devices verifying changes is a desirable behavior, I propose adding an option to verify changes globally as part of the node module config.

Here's an example from a log file showing the problem:

2014-10-21 08:59:40.811
2014-10-21 08:59:40.811 Node004, Response RTT 30 Average Response RTT 29
2014-10-21 08:59:40.811 Node004, Received SensorMultiLevel report from node 4, instance 1, Temperature: value=1627389.952F
2014-10-21 08:59:40.811 Node004, Refreshed Value: old value=72.2, new value=1627389.952, type=string
2014-10-21 08:59:40.811 Node004, Changes to this value are verified
2014-10-21 08:59:40.811 Node004, Changed value (changed again)--rechecking
2014-10-21 08:59:40.811 mgr,     Refreshing node 4: COMMAND_CLASS_SENSOR_MULTILEVEL index = 1 instance = 1 (to confirm a reported change)
2014-10-21 08:59:40.811 Node004, Queuing (Send) SensorMultilevelCmd_Get (Node=4): 0x01, 0x0a, 0x00, 0x13, 0x04, 0x03, 0x31, 0x04, 0x01, 0x25, 0xae, 0x5e
2014-10-21 08:59:40.811 Node004, Queuing (Send) SensorMultilevelCmd_Get (Node=4): 0x01, 0x0a, 0x00, 0x13, 0x04, 0x03, 0x31, 0x04, 0x03, 0x25, 0xaf, 0x5d
2014-10-21 08:59:40.811 Node004, Queuing (Send) SensorMultilevelCmd_Get (Node=4): 0x01, 0x0a, 0x00, 0x13, 0x04, 0x03, 0x31, 0x04, 0x05, 0x25, 0xb0, 0x44
2014-10-21 08:59:40.811 Node004,   Expected reply and command class was received
2014-10-21 08:59:40.811 Node004,   Message transaction complete
2014-10-21 08:59:40.811
2014-10-21 08:59:40.811 Node004, Removing current message
2014-10-21 08:59:40.901
2014-10-21 08:59:40.901 Node004, Response RTT 30 Average Response RTT 29
2014-10-21 08:59:40.901 Node004, Received SensorMultiLevel report from node 4, instance 1, Temperature: value=0.000F
2014-10-21 08:59:40.901 Node004, Refreshed Value: old value=72.2, new value=0.000, type=string
2014-10-21 08:59:40.901 Node004, Changes to this value are verified
2014-10-21 08:59:40.901 Node004, Changed value (changed again)--rechecking
2014-10-21 08:59:40.901 mgr,     Refreshing node 4: COMMAND_CLASS_SENSOR_MULTILEVEL index = 1 instance = 1 (to confirm a reported change)
2014-10-21 08:59:40.901 Node004, Queuing (Send) SensorMultilevelCmd_Get (Node=4): 0x01, 0x0a, 0x00, 0x13, 0x04, 0x03, 0x31, 0x04, 0x01, 0x25, 0xb1, 0x41
2014-10-21 08:59:40.901 Node004, Queuing (Send) SensorMultilevelCmd_Get (Node=4): 0x01, 0x0a, 0x00, 0x13, 0x04, 0x03, 0x31, 0x04, 0x03, 0x25, 0xb2, 0x40
2014-10-21 08:59:40.901 Node004, Queuing (Send) SensorMultilevelCmd_Get (Node=4): 0x01, 0x0a, 0x00, 0x13, 0x04, 0x03, 0x31, 0x04, 0x05, 0x25, 0xb3, 0x47
2014-10-21 08:59:40.901 Node004,   Expected reply and command class was received
2014-10-21 08:59:40.901 Node004,   Message transaction complete
2014-10-21 08:59:40.901

Basically, for this particular sensor the initial read of the temperature is correct, but all of these attempts initiated by the controller to verify that value fail, and this generates A never-ending stream of traffic to attempt to verify the value.

PR to come....