Install-time vs. "scriptable" setting of Z-wave device param

I have an aeotec doorbell unit. i had been looking for a general way to play sounds from my system when certain events happen.

the aeotec unit comes pre-configured with a handful of different door-bell-simulation sounds (6 , i think), but it also can be loaded up (via USB) with other mp3 sounds, so could in theory be used to play a variety of different warning sounds for different events and/or to play pre-recorded spoken warnings like "Water detected in Laundry Room".

Indigo currently provides a way to set the sound that the unit will make and to set its volume level. both of these are great and useful, but they are done interactively via the device setup dialog. what i would find would make this device much more useful would be the ability to make it play different sounds and possibly different volume levels in response to different events - that is, to have scriptable control of the Z-wave params that control these or even more ideally, to have a scriptable action for this device something like "Play Sound" that takes which sound to play and the volume as optional parameters.

this could be done with a plugin i suppose or it maybe could be done by scripting and using the z-wave send raw command. but my question is a general one - i'm wondering what the general rationale is behind making certain settings/parameters of z-wave devices be handled only in the interactive setup dialog vs. being available as general actions for triggers or scriptable in python.

Are you aware you can create an action to set parameters, so you could actually achieve what you want using normal processes?


Sent from my iPhone using Tapatalk

What it does rely on though is the wake-up interval, as params aren't processed until the device wakes up which is hourly by default.

Someone does this with their motion sensor; they reset the wakeup param at 9pm, so within the hour it will have picked up new, quicker wakeup, then they send various configs overnight to achieve their need, then reset wakeup to hourly at 7am.


Sent from my iPhone using Tapatalk

yes, i see "modify z-wave configuration parameter" exists as an indigo verb, so i suppose i could go dig up the programming docs for this module, find the appropriate z-wave parameter that selects the sound and the one that sets the volume and then generate actions that set these things, what the allowable values are, what the datatype or number of bytes for parameter is, etc.

my observation is that somewhere in the Indigo code base or configuration file, this information is already there. i know this because i can see it in the setup dialog for this device.

so I guess my question really relates more to the Indigo model of what it means to be a "supported" device -- i.e., to what degree it is reasonable to expect that Indigo provide access to most of the functionality of a device? will it be the case that Indigo will generally limit the actions supported to simple on/off/dim type verbs, and let the user roll their own when it comes to anything more complicated than that?

i don't have a lot of z-wave devices, but for the few that i have so far, each seems to have "quirks" as to how well the device's functionality conforms to a standard Z-wave class. example: i have a somfy ZWTRSI Z-Wave to RTS interface which is a way to send commands to things like window coverings, awnings, etc. Indigo treats this as multiple "Motor Control Class A" devices. this "works" to some degree, however in order to send a command to "stop" the device, i have to use z-wave "send raw z-wave command".

my sense is that Z-wave in general holds a lot of promise in that it is a true industry standard, allowing potentially allowing for a much greater diversity of different device types from multiple companies. i'm still getting my head around what this means in terms of how much burden falls on the user to make these devices useful/usable in Indigo.

maybe it's my bad luck, maybe i've been an "early adopter", or maybe i'm leaning too much on being able to script what others would consider to be "obscure" settings/functionality, but in general i'd like to see more customization in Indigo to support a richer variety of devices. when googling about this device, i stumbled across info in other forums for other HA control systems (e.g. SmartThings) that seem to provide somewhat more customization. i also came across what appears to be some kind of a central "registry" for z-wave devices. this registry contains the ZW056 device and provides a link to an XML file that describes it, including all of its command classes, parameters, etc. so it would be great if Indigo could just map some sort of model-ID to these config files, then parse the config files a and auto-generate code to support all the commands and setting all the params for "supported" devices. easier said than done, i'm sure...

summary: given that Indigo is already "programmed" in some sense to know which device parameter ID selects the sound and which parameter ID selects the volume, it would be nice for it to expose scriptable commands for setting these parameters as well.

[jay (support)]

The current thinking and design is that device configuration is not done on the fly as part of a devices normal usage. Thus, setting random parameters in either Z-Wave or Insteon devices aren't presented as actions since they don't normally need to be changed on-the-fly. The selection of sounds is somewhere in the middle, thus it might be an interesting action though as you know demand frequently drives features like this and thus far demand is low (given that it's not a "standard" feature of Z-Wave but rather specific to one particular device).

We attempt to present the most useful configuration parameters to users in the UI and leave the more esoteric parameters to be configured manually (thus enabling full customization of the device). We think this is the best balance for our users. In Indigo 7 we've added lower level hooks for developers to use to implement more custom Z-Wave functionality, and we are continually looking for ways to make it easier for new devices to be added. Being a tiny company, we have to carefully choose not only our target customer base, but also the features that we think make Indigo attractive to that customer base.