I'm using the Basic Z-Wave Tool to send an option to a Leviton DS6HD dimmer. The option sets the state of the Indicator LED, it is Command 7, 1 byte, with either 0 (always OFF), 254(Status Mode), or 255( default, Locator mode).
I'm sending 255 as the data and it acts like I'm sending a zero. Sure enough the logs show I AM sending a zero.
I FOUND THE PROBLEM. Bug/anomoly in Basic Z-Wave tool.
The Basic Z-Wave tool will not accept any data value over 127. If you send 128, 150, etc. it will send a zero to the device. In order to get around this you need to set the value field to a negative number. In my case, I need to send 255 so I would enter -1 In the data field of the Set Parameter box.
Yes, that it uses two's complement isn't exactly obvious.
I think this could be a manufacturer documentation oddity, or perhaps a misunderstanding on their part. It's my understanding the Z-Wave spec requires signed values, so a 1-byte signed value would get you -127 to 128. This is technically 256 values, but half of them are negative and, as documented, they don't all make sense for this device.
At least one manufacturer I know works around this by making the value 2 bytes and documenting an acceptable range of something like 0-255 (or whatever works for their device and the parameter in question), though this is obviously not as economical on space. I'm not sure how others handle this. But in any case, I'm not sure I'd consider it a bug with the Basic Z-Wave Tool. 
Yea, probably more of an anomaly than a bug. But the newbies (like myself) would not know that signed values are used in the Z-Wave spec and are carried forward to this number entry box. A short line of text specifying this in the GUI would be helpful.
Either that or just make the user enter all values in hex instead of decimal.
It's really up to Leviton to fix their documentation.
Z-Wave Application Command Class Specification, 4.30.2 Configuration Set Command:
Configuration Value... The field MUST carry a signed value.
I still think this is on the manufacturer to document it more clearly, or use a 2-parameter value so the numbers they provide actually work. 
(This is what Inovelli does, for example.)
Seems to me that it would be pretty easy for the Basic Z-Wave Tool code to convert a 255 data value into a two's complement byte before sending. Hell we're already entering values in decimal that need to be converted to Hex.
Nothing gets converted to hex, it gets changed to binary.
um okay, 8-bit binary values represented as hexidecimal digits. Hex IS binary.
It's a computer.. everything turns into binary sooner or later.
In this case, I think even binary is only an intermediary.. the device output is radiation RF
Yeah, but even that is binary encoded over RF. 
In the end devices it is all 1s and 0s - at least until we shift to quantum computing.
Well, no. Hex is a human readable character representation of a number (i.e. a numeral), AFAIK, there's not a computer in the world which uses hex. The closest might be MLC flash, which often uses quaternary circuits. Binary is also a numeral, but is physically realized in computers. Hex is just used to make binary numerals more human readable. Computers work, almost universally, on binary. Hex and binary are as different as English and Spanish. They're both languages, can covey the same information, but are very different and definitely not the same.
Download the Hubitat app
