I’m writing a device handler for a new z-wave sensor. I’d like to associate all devices of this type with each other automatically somehow.
I see a way to set the association in the device handler, but haven’t seen a way to build the list of z-wave node IDs of similar devices to target the associations with.
What’s the best way to do this?
Is there an API call in device handlers or smart apps that returns a list of z-wave devices? If so, I assume I can walk the results and do a get info on each to determine the device type, doing the set for each match.
Or is there a way to share state across device handlers? If so, I could maintain a list from my device handler and use that.
Any other suggestions or examples implementing this or something similar?
I’m not sure you understand what association is in the Z wave specification. This term has a very precise meaning. You wouldn’t usually associate one sensor to another because zwave association is based on a trigger device and a target device. The trigger device sends a “basic” (that’s a specific zwave term in this context) directly to the target device. When it receives the “basic“ command, then the target device does whatever a basic command is supposed to activate for that device class.
Most commonly, this is used for a sensor to trigger a light or siren to come on.
But a sensor cannot usually trigger another sensor.
Another common use case for Z wave direct association is a virtual three-way where two switches control the same light fixture. In that case, one light switch can certainly be associated to the other. In fact you can set up associations in both directions so that the switches stay in sync. But you wouldn’t associate a switch to a sensor because nothing will happen if you try to actuate a sensor. So a sensor might definitely be the trigger device for association, but it’s unlikely to be the target as you’ve described.
It sounds more like you are trying to group multiple devices together. That can certainly be done in smartthings, or at least in the custom code associated with the classic app. But you will need a smartapp as well as the device type handler.
For an example of how to do that, see the now deprecated zone manager.
Thanks for your response. I was trying to keep the post short, and left out some details that would clarify what I want to do. The device is a new gas sensor that should act similarly to wired smoke detectors. Each device has both a sensor and a siren. When the sensors cause an alarm, we send z-wave notifications on association group 2 to cause all the associated devices’ sirens to go off. We have this working, but by manually adding associations between all the devices with a non-SmartThings z-wave controller.
I’m looking for a way to programmatically do the associations in either a device handler or smart app (or some other method) without involvement from the user. A new gas detector device gets added, an association to group 2 is made between it and all other gas detector nodes. A gas detector node is removed, and the association is automatically trimmed.
I looked at the reference post you provided, hoping I would see some similar logic to discover like nodes and act on them, but unfortunately the Github repo is gone so I can’t see the code. I will go through the thread and see if there are any remnants or forks of the handler.
Thanks again for your help. Please let me know if I can clarify more or if you have any more tips.
I see. In that case the code I linked you to isn’t likely to help.
Prior to “ smart start” the Z wave specification paradigm assumed that there would always be physical manipulation of an end device when reconfiguration was required. This was important for two separate use cases.
First, imagine the situation where two people live in the same apartment building and each has their own hub and their own devices. You definitely don’t want a situation where doing something on the hub for neighbor A picks up some devices from neighbor B’s apartment.
Second, was just a security protection. You don’t want people to be able to in anyway modify the existing network from outside the home. Even if it was just a case of nuisance alerts.
So the solution to both of those was to require physical manipulation of the individual end device at the time of reconfiguration. The assumption was that having access to that physical device would be a safeguard against both of the problematic use cases described above.
That said, some of this philosophy has changed with the new S2 and SmartStart specifications. Both are designed to make it easier for professional installers to pre-configure devices before they are shipped to the customer.
But I honestly don’t know if or how that would affect the kind of design you are suggesting. It’s just that it might and I don’t know the details of it.
What generation of Z wave are you using for your device?
It is pretty recent tech: Z-wave Plus with S2 support, but no Smart Start.
Does association require pressing the button on the source and/or target device?
I’ve been using z-wave in my house for years, but haven’t had to dig into these details before. I was assuming that since inclusion required the physical act of pressing the button on the device that operations like physicalgraph.zwave.commands.associationv1.AssociationSet could be done without it, as the trust was established already. But, my knowledge is very limited and I haven’t tested the theory or researched it.
If it can be done programmatically without pressing the buttons, then the I’m back to “how can I get a list of the nodes to associate with”? I was hoping, worst-case, there would be a call in the device handler API or smart apps API like “getZwaveNodeIds”. Then I could iterate the list and figure out which ones are gas detectors and do an association set on them. I guess I could also go fishing and ‘physicalgraph.zwave.commands.manufacturerspecificv2.ManufacturerSpecificGet’ on each of the 232 possible node IDs, but that’s an ugly sledgehammer.
The other obvious method would be to use a state shared by the device handlers to manage a list. A quick look at the documentation on state led me to believe that it is all scoped to a device handler instance and can not be accessed by multiple handler instances. Although I didn’t look long before coming to the forum to ask for help.
Thanks again for your help. I really appreciate it.
I personally think it’s a really bad idea to make the assumption that the user wants all their gas detector devices tied together.
Users often have different actions they want performed based on which sensor gets tripped. If a user wants all their gas sensors to trigger a siren then they’ll use a SmartApp to setup that rule.
Even if it was a good idea, device handlers can’t communicate with more than one device or get information about other devices and I’m pretty sure SmartApps can’t send z-wave commands directly to devices so I’m pretty sure there’s no way to do it automatically.
You would have to create a device handler for the gas sensor with a custom command that accepts a list of nodes and adds them to that devices group 2 association and a SmartApp that allows you to select the devices and pass the list of nodes to the custom command of each handler.
Thank you very much for the feedback. I hadn’t thought of it being bad policy. The intent was for it to act like wired smoke detectors for safety reasons, but I suppose that could be an old paradigm that doesn’t fit with the current home automation expectations.
Users often have different actions they want performed based on which sensor gets tripped. If a user wants all their gas sensors to trigger a siren then they’ll use a SmartApp to setup that rule.
Do you know of an example SmartApp that implements something similar I could use as a reference?
That was just my opinion so it might not be “bad policy”. I personally hate when vendors make assumptions on how I want to use a product, especially if it’s a feature I can’t disable.
It’s probably different in commercial setups, but I doubt SmartThings is used in those situations very often.
In my setup, I get different audio, SMS, and Push messages based on which sensor was tripped.
Smart Home Monitor allows you to perform a variety of actions if any of your Smoke or CO2 detectors go off, but the code isn’t public.
I can’t think of anything that does what you’re looking for, but the examples in the developer docs should be enough to get you started. It needs an input field for a specific capability and then in the updated method it builds the node list by going through the devices in the input field. It then executes each device’s custom command and passes in the nodelist.
ST doesn’t have a built-in generic Gas Sensor capability so you’ll most likely have to use something like the Carbon Monoxide Detector capability to get your device to work with the built-in SmartApps.
Another solution which I’ve seen implemented in some device handlers is a text input field that allows the user to enter the list of node ids that should be added to the association group. The user would need to manually look up the node ids and add them to each device, but it would eliminate the need for a separate SmartApp.
Is this a new product that your company developed or are you just trying to integrate a device you purchased?
Assuming you have experience in publishing device handlers and SmartApps, if I went this route, how likely and/or difficult would you expect getting this through whatever process needed at SmartThings to have this functionality included in production (i.e. it will happen without requiring the user to go through a secondary step of installing the device handler and SmartApp)?
At the moment, getting a handler you write for a z-wave device published by SmartThings isn’t possible.
They no longer accept publication requests for this platform and the development section of the new platform doesn’t support hub connected devices yet.
That being said, if the manufacturer contacts SmartThings and sends them the device then SmartThings might add the fingerprint to an existing handler so that it gets identified properly when joined, but it won’t support any of the configuration parameters.
If it doesn’t work with any of the generic handlers they might create a custom handler for it, but it still wouldn’t support the configuration parameters and would most likely take a really long time.
If the device doesn’t fit any of the capabilities then they most likely won’t support the device.
Everything mentioned above is based on what I’ve heard from a few different vendors so it’s possible things have changed since they went through the process or it could work differently for each vendor.
I’m trying to implement this now. I have a SmartApp that lets me choose all the gas sensors and I can iterate the list of selected sensors. But I’m having a hard time figuring how to get the Z-Wave node IDs of the sensors from this list.
I’m hoping there’s an attribute on Z-Wave devices that I can get from the SmartApp with the currentValue call. I don’t see such an attribute documented anywhere, so I’ve guessed with currentValue("zwaveNodeId") and some others, but haven’t found it yet.
How can I get the IDs from the SmartApp?
BTW: I did implement your other suggestion of a text input field in the device handler that lets the user list the IDs to associate with group 2. But as far as I can tell, this requires the user to log into the SmartThings IDE to get the IDs. That is not something my client wants the user to need to do. Are there any other ways to get the list?
I believe it’s a device property, not at attribute, so you would need to use .deviceNetworkId
The user will still need to log into the SmartThings IDE to create/publish the device handler and SmartApp, but having to install the additional SmartApp will still be a lot easier than having them manually look up the nodeIds and enter them into a text field.