[ST Edge] Questions about ST Z-Wave interface and preferences

Developer Programs Support
1

The current ST documentation lists the interfaces, but doesn’t say exactly what they do. I have some questions:

  1. Drivers have ‘preferences’ which can be modified by the user from the ‘Settings’ menu in the ST app. It looks to me like these values are completely under the control of ST with no error checking?

  2. It also looks like the settings are blind to external changes? For example, you change a device’s configuration through local button manipulations.

  3. Are the ST Z-Wave association commands incremental or exclusive? For example, if you call Association.Set twice with different values do you get the latter result or a combination of the 2?

1 Like
2

  1. The driver’s profile can set some limits on what can be entered - a range of integer values for example - that will control what the app will accept. If the app accepts the value, then it’s up to the driver to perform any error checking. Or, if the setting is being sent to the device as a configuration parameter, then a well-designed device should ignore an invalid value.

  2. If I’m remembering correctly, there was a time when a preference in a Groovy DTH could be changed by both the user and in code, but the ability to push a preference change from code was shut off at some point. I recall seeing somewhere that Edge drivers cannot update a preference from code (though I haven’t been able to find that reference when I looked for it recently), and I’ve run into errors in the little bit of testing I’ve done to try to do so. If you’re wanting to query the device for its current configuration setting and then display that value in the app, you’ll need to add it to the detail view (most likely using a custom capability).

  3. The z-wave spec for Association.Set uses the word “add”, so it should add nodes to the association group incrementally. It would be best to confirm behavior on the particular device if it’s critical to you though, as you might run into a device that does a full replace instead. If you’re using a driver written by someone else, then it might be written to call Association.Remove first to do a full replacement (my GE drivers are set up this way).

1 Like
3

I was actually looking at the code for your GE driver.

Based on your response above, wouldn’t it be safer and more efficient to add the hub to the list rather than make a separate association call?

if addhub then device:send(Association:Set({grouping_identifier = group, node_ids = {hubnode}})) end --add hub to group 3 for double click reporting
if #nodes > 0 then
device:send(Association:Set({grouping_identifier = group, node_ids = nodes}))
end

Also, the splitAssocString function uses a hardcoded 1 for the hub while the init.lua file references device.driver.environment_info.hub_zwave_id.

I’m not trying to knit pick, but I suspect many people (like me) will use your code as a starting point. I’m going to make these changes, so I might as well mention them.

1 Like
4

It would be more efficient, since it would consolidate two z-wave commands into one. I went this way because I was worried about the device rejecting the Association.Set because of some form of invalid user input that I hadn’t trapped for. This way should guarantee that the hub node gets through without error, and then if the follow-up Set command is rejected because of user input then that’s on the user. I’ve also tested on enough Jasco models to feel confident that they handle successive Set commands incrementally, which I believe is the intent of the spec.

Good catch. I thought I had caught all of those 1s, but there’s one still hiding in there.

1 Like
5

Fair enough.

1 Like