I tried to send a simple command using this feature and received an error.
Do I need to do something else?
Thanks
John
You need to use the "formatted" command, basically the actual numeric value that the format() method in your screenshot would spit out if it were used in driver code--or if securely paired, that plus zwaveSecureEncap(). These aren't easy to figure out unless you are familiar with Z-Wave, or at least I think using a driver to send the command is easier because I'm not. 
2 Likes
@JohnRob Not even close... It isn't that simple/user friendly. Everything would be in hex.
So in your example it would be something like this (disclaimer, I didn't test it):
2502
25=Switch Binary Command Class
02=Get command
5 Likes
I was going to just abandon looking at the advanced , however looking a the xlsx file it looks reasonalby straightforward.
2502 did work I think, the results was:
not sure why the log says 2503 as I definitely entered 2502 my guess the response is 2503
John
1 Like
You are correct Binary Switch Report is the 03 command of the Binary Switch Command Class (23).
It really isn't too difficult if you take time to understand it. You will also need to get copies of the command class specifications. This will tell you what additional fields are needed for commands that are longer than two bytes. I use this method for setting up device associations. Its simple and straight forward, and I don't habe to do the driver dance.
Let me know if you have any questions. Ill be glad to give some sage advice.
Thank you.
Perhaps you could post one association command entry example with maybe some info on what the octets are?
That would be most helpful.
Thanks
John
2 Likes
You really just need to find the relevant z-wave specifications and construct the full command, using hex digits. Each command class has a list of commands and each command has a format defined that includes the size of the command message and what each bit/byte is used for.
Here is a message i posted last month on another thread about using this feature, that might help:
2 Likes
Thank you.
Attempting things I'm not comfortable with is how I learn 
And its so much more fun.
Here is a scenario where I plan to associate two switches, SW1 and SW2. My objective is to have SW2 command SW1.
Pertinent details about the switches.
SW1:
Device Network ID = 2C
Association groups
1 Lifeline, 5 associations
SW2:
Device Network ID = 30
Association groups
1 Lifeline, 1 association
2 Switch (on/off), 5 associations
The Association Command Class code is 85.
The Association Set command code is 01.
The organization of the Association Set command for this situation is:
Command Class: 85
Set command: 01
Association Group: 02 (of the source device)
Device Network ID: 2C (of the device to be controlled)
So the code string becomes: 8501022C
This is sent to SW2 from the Advanced feature the its driver edit page.
Notice the association group is chosen from the list of groups available on the device you are send the association command to, NOT the device it will be controlling. The Association groups for SW1 are irrelevant for setting the association in SW2. The group is all about what command SW2 is authorized to send directly to SW1.
Let me know if you have any questions.
p.s., If you’re patient, you can learn how to construct other commands too.
6 Likes
Thanks for that.
Are there good resources for finding out more on commands? Maybe specs on z-wavealliance.org?
Link to the SiLabs excel spreadsheet with all command classes and commands is above.
(EDIT here it is)
https://www.silabs.com/documents/login/miscellaneous/SDS13548-List-of-defined-Z-Wave-Command-Classes.xlsx
Some more info can be found at these links. A little old, but they are still pertinent (the samsung one requires a free Samsung account to log in):
wiki.micasaverde.com/index.php/ZWave_Command_Classes
https://graph.api.smartthings.com/ide/doc/zwave-utils.html
For info on individual devices and what command classes and configuration parameters they support:
https://products.z-wavealliance.org/regions/2/categories
3 Likes
Thanks. This will be very helpful (or harmful if things don't go right) for me.
Not to just focus on associations, but the key is that all the info is going to the 'associator', not the 'associatees'. So, as I think I've read, if the 'associator' device was to be removed from the network, its associations should first be removed or else risk mesh slowdown with extraneous communications to the removed device?
No, I think it is the other way around - if I am reading your paragraph right. The source can be removed from the network any time, the destinations can't.
Before you remove a destination device you should remove its association from the source. Although, as the source is still on the network, it can be changed at any time - including after the destination is removed.
If you don't, though, the source device will try to send packets to that address (because you told it to in its associations setup) that does not exist causing some mesh loading/retries.
All of this is why most people don't bother with associations and just live with the 250-500ms delay doing the logic from the hub.
2 Likes
I get it now, thanks.
Very true @JasonJoel. Thank you for jumping in. I have been handling a burst pipe here at home.
I have chosen to use associations, so the 3 & 4-way switching will continue to work even if I have to take HE offline for some reason.
Here is another way of describing how associations work.
I want switch A to control switch B, so I send an association command to switch A. This command tells switch A it is authorized to send commands (defined by the association group) to switch B.
2 Likes
Hi,
Just wanted to add that I found this other way of setting device parameters: https://github.com/hubitat/HubitatPublic/blob/master/examples/drivers/basicZWaveTool.groovy
It might be easier than the "Advanced" send z-wave command.
1 Like
@wayne.pirtle if I ever meet you in person, I will take you out for a steak dinner. This is so, so much easier and foolproof than trying to swap in the Inovelli drivers, use their association tool, and then re-swap drivers as suggested elsewhere. Yes, it requires a basic understanding of the command classes and command construction but with this little example, you give more than enough to go on.
After busting my pick for several hours of driver swap experimentation trying to re-establish associations in some old devices after moving from HomeSeer to Hubitat, I was able to get it done in 15 minutes using the info you shared in this thread.
Thank you from the bottom of my heart.
2 Likes
Thank you for the kudos @neum69. I am glad it helped you. It seemed the easier way for me too.
I almost exclusively use Eaton Z-wave Plus switches, dimmers, and outlets, and I like to use direct associations to ensure accessory switch functionality in the event the hub is offline for some reason. I don't have problems with HE. I just like to be prepared. This was the easiest way for me to accomplish that. Now @bcopeland has written Eaton specific drivers, it is much easier to use that.
If you ever find yourself headed to Dallas, PM me. We can meet and swap home automation stories. 
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
