Pass command to another zwave device

zwave
z-wave

(Scott Ainsworth) #1

I’m looking for a way to send a command to device B from the device handler for device A. Specifically I’m creating a device handler for a scene controller. To set up a scene controller you must set the scene in the controller and in the device with separate commands.

Obviously I can (and have) set the scene from the DH of device B. However that makes deployment more difficult because each device in the scene must have a DH modified to set up scenes. If the commands can be sent to the correct devices in the scene controller DH it is a better solution.

Any help appreciated


(codersaur) #2

This is what smartapps are for. Create an app that subscribes to the appropriate attribute of the controller device and sends commands to your other devices. Alternatively, you may be able to use CoRe to do what you want.


(Scott Ainsworth) #3

Thanks for the response. However what you are suggesting does not resolve my issue. To properly configure a scene the scene configure command must be sent to the device. Very few if any DHs have been programmed to allow that. You can’t do it from an app if the DH is not prepared with the command.
This is the reason I would like to issue the command directly from the scene controller DH. All the information needed is already there (nodeid, level, duration).
I’m trying to avoid customizing all the DHs for each device.

Since this is a one time (or occasional) setup another approach would be to create a substitute DH like your Zwave Tweaker. The process is very similar to setting up associations. While associations only require setting up the controlling device scenes require setting up the controller and the controlled. For the scene controller I’m working with I’ve almost got that sorted. I’ve modified the DH for my linear lights to set up scenes in them. However I don’t think its reasonable to modify every DH for a device that someone else my want to use with the scene controller.


(Robin) #4

I’m almost certain a DH cannot talk directly with another DH.

You can setup direct association betweeen two compatible Zwave plus devices but that’s only for on/off, sometimes dim.

You need to do what @zcapr17 suggests, use a smart app as a bridge between the two DH’s.

I assume your scene controller sends scene ID’s to the hub? This can be used as a trigger (via CoRE) to set all your other devices to suit the desired scene.

Example:

IF
Scene ID is 24
THEN
Turn on XYZ
Turn off ABC
Set level to Y
Shoot the cat
Walk the dog
Etc.


(codersaur) #5

As per @RobinWinbourne, I am also 99% sure that DTHs can only issue commands to the physical device they represent. This is by design (presumably for security reasons). When DHTs issue commands, the target DNI is not specified in the code, it is added by the platform (e.g. inside sendHubCommand()) prior to the command frame being physically sent over the radio, so you can’t change it to send commands to another device.

If you have some DTHs that do not support all of the command classes supported by the physical device, it’s best to contact the author of the DTH and request for the missing command classes to be supported.

I am curious to know: what specific scene controller are you using, and what command classes it is issuing to controlled devices?

I am familiar with the Fibaro Dimmer 2, which will issue COMMAND_CLASS_SCENE_ACTIVATION (0x2B) : SCENE_ACTIVATION_SET (0x01) commands, but as far as I can see, it only sends these commands to the hub and doesn’t broadcast them over the network. Plus, I haven’t yet come across any devices that would respond to these commands if sent to them.


(Scott Ainsworth) #6

I am using a Cooper RFWC5. Its command classes are: zw:L type:0202 mfr:001A prod:574D model:0000 ver:1.13 zwv:2.78 lib:01 cc:87,77,86,22,2D,85,72,21,70. All though it is not listed it does indeed send scene activation 2B commands to properly associated devices. What I was looking to do was send 2C (scene actuator configuration) commands to the associated devices. For a zwave scene to work both the controller and the device must be set up.

Here is a link to a thread on the device: Aspire rfwc5 device type?

I’ve modified a DH for my linear dimmers to set up the scenes using 2C commands. I’ve posted it to github: https://github.com/saains/SmartThings_Z-Wave_Lib/tree/scene_active. I’ve documented the sections I’ve modified. I’m looking for a better way to do this portion. Adding 2C into Zwave tweaker would be a better solution.

The information on page 5 of: http://www.cooperindustries.com/content/dam/public/wiringdevices/products/documents/technical_specifications/advancedtechinfo_V2.pdf
has been very helpful and confusing for setting up the Cooper. The device must do some funky things based on the order and the timing that the commands are sent. But it works if done exactly as instructed, I have programmed the controller from ST. It does indeed control both devices by both scene and or association. I’ve got some work to do before I post the DH for others to try. What confused me was the configuration commands seem to overwrite each other. The device must store the information internally based on the previously received command. Only the value of the last sent configuration command is reported via configuration get. The Fibaro device may require some similar magic command order to set up properly.

The cooper device uses the association to send off commands to the scene controlled devices. It will also adjust level. I can use the indicator command to determine which buttons are on. However, I don’t think there is a way to determine which level is being adjusted. ST will only pass On/Off info to other devices.

I want all this because my house has some locations that should have had three ways switches. I want those to function independently of the hub. Its a bummer if the lights don’t work because the internet is down.

Linear/Nortek/GoControl devices respond to 2B as well as Cooper devices.


(Robin) #7

Now it’s making more sense, you’re looking for a device handler to setup direct association, not act in the middle of multiple handlers.

Like with Zwave tweaker, once association is set, the handler, hub and ST cloud will be out of picture.

You lost me on the whole 2C association though.


#8

The OP is not trying to set up direct association, he already knows how to do that.

He’s trying to use a zwave scene controller device to send scene commands to other devices that supports Zwave scene commands.

This is a very specific group of zwave commandsets. It is a group that is not fully supported by SmartThings, and they don’t have to, because it’s not part of the basic group which is required for certification.

My own guess, although I’ve never seen anyone say so officially, is that they chose not to fully support these ( that is, let you define scenes to the hub in a way similar to setting up routines) because if they did, Z wave devices would be treated differently than zigbee devices and they were really trying to keep the protocol invisible to their customers.

If you take a Z wave only controller like the older Veras or Homeseer, customers can set up scenes on the controller, typically using a web interface, and then distribute that scene information to the local scene controller, typically a wall mount multibutton light switch, and then when you press a button on the local scene controller, that device can send the scene activation command directly to the devices in that scene.

While it’s similar to Direct association in some ways, it’s a more sophisticated version because each device can be sent to a different dim level and it uses a different group of command sets. And in fact not all local scene controllers support association.

I think it’s reasonable to suggest that the tweaker should expose scene settings. I honestly don’t know if it can enable scene configuration since it’s not fully supported by the hub. (While association is.)

I agree also with @zcapr17 on the security issues involved in having one DTH talk directly to another except in a parent/child configuration. And I also agree that if the command sets are supported by the device, they should be in the DTH, and the DTH author should be contacted to update it.

JMO , of course. :sunglasses:


#9

I should add that one of the advanced features of local scenes versus direct association in zwave is that a direct association is always active. Press the button on device A, the light on device B comes on. There’s no way to temporarily disable the association.

Local scenes were different because The scene is “activated” each time, and otherwise is ignored. While there isn’t usually a practical difference for these Wall mount multibutton devices, there can be, and you do see some which allowed for schedules.

Anyway, the main point is just that it’s a different group of command sets than Association, and both the sender and the receiver have to support them.

Here’s the conformance statement for the specific device The OP is referencing.


(codersaur) #10

Okay, this all makes sense now. The Scene controller is capable of using Z-Wave Association, albeit with some custom jigger-pokery to send different levels to multiple sets of devices associated with the same grouping id (which makes me wonder how the controller responds to Association Report Requests).

Additionally, it supports Scene Controller Conf (0x2D) to configure it to send Scene Activation (0x2B) commands to other devices that support Scene Activation. These controlled devices will need to support Scene Actuator Conf (0x2C) to allow them to be configured.

As far as I can see, all the required command classes are supported. See the Z-Wave Command Reference here.

So if you want to configure the scene actuators, you will need to update the relevant DTHs to send physicalgraph.zwave.commands.sceneactuatorconfv1.SceneActuatorConfSet() commands. To repeat my answer the original question, you won’t be able to send these commands from the controller’s DTH.

I will look at whether I can add this functionality into my Z-Wave Tweaker. However, I don’t have any Scene Actuator devices to test with, so ideally I need some working code examples.


(Scott Ainsworth) #11

Robin
The scene command class is similar to association in that it allows one device to control another. The difference is that scene is designed to control more than one device and at different levels. For instance association can send on/off command or level commands but not both at the same time. With scene command the controller can activate a scene that might look: On for device A, 50% for device B, 75% for device C. The all the levels are set up in the devices themselves. The controller just sends a command that tells them to activate scene number X.
Scenes command class has a problem in that there is no off command. The cooper controller ( and I believe others) uses association to send basic off commands to turn of the scene.
It is also capable of using straight assocation in parallel with scene commands so you can include non-scene devices.


(Scott Ainsworth) #12

The commands do all work. I have tested them.

Yes, with respect to updating the relevant DTHs. I started this thread looking for a way around that.


#13

Yeah, the Cooper is a really weird device because they were trying to beat out Leviton as the most advanced zwave lighting solution at the time. So while most manufacturers were choosing either association or local scene control for an individual multibutton wall switch, Cooper decided to mix both in one device with, as you note, some proprietary magic. Their goal was to make it simple to have the same devices in different scenes controlled by the same multibutton controller.

That’s so long ago in development years that it doesn’t even seem like an issue now, but at the time it was a big deal.

They also wanted to be able to “turn a scene off” which is not a concept in the official standard. But they wanted you to be able to push the same button and toggle all the devices in the scene. Again, seems pretty simplistic now, but at the time it was super advanced.

The end result is a device that looks like it should support what is now considered pretty standard lighting controls, but it’s doing it in an archaic way. Hence the complexity in untangling everything.

Newer devices are more commonly using yet a different group of command sets, “central scene commands.” The “central” means that the hub is notified of all the events, which allows you to include devices which are more than one hop away, or in a multiprotocol platform, are of a different protocol.

But this Cooper device does not support central scene commands. Just local ones. Which is where the challenges arise.


(codersaur) #14

Yeah, I used to have RAKO lighting, which worked in a similar way. The scene controller just sends out scene IDs, and each actuator holds the configuration for how to respond to each scene. It’s a reasonably good way of doing things, and it certainly beats building pseudo-scenes in a smartapp.

Also, normally, OFF is just another scene (with its own button), where all devices respond by setting themselves off.


#15

It’s a good way of doing things when you do it from the hub, and it’s the way that central scene commands work.

If you do it from a local controller direct to the end devices you run into two problems.

First, if the hub doesn’t know what happened, statuses get out of sync and a lot of if/then rules don’t work correctly.

Second, in Z wave you will be limited to devices within one hop of the local controller. That’s OK for some use cases, but not all.

So the basic concept of scene IDs is certainly a good one. I’m not sure the concept of local scene controllers is, though. You just introduce a lot of limitations relative to central scene management. But choice is good. :sunglasses:


(codersaur) #16

Some good points, but isn’t this the same for Z-Wave Association?

The first problem shouldn’t really be a problem as devices should send a report the smartthings hub whenever they change state (regardless of whether this is initiated from a physical button press, or receiving a z-wave command from a controller).


(codersaur) #17

So in summary, there’s no way around it. The commands need to come from the DTH that is currently installed for the physical device.

I can look at adding scene controller and scene activator functionality into my Z-Wave Tweaker (in a similar way that Associations are configured - i.e. one at a time), but will need you to provide some working code examples and explain the workflow in a little more detail. Devices that support Scene Actuator Conf (0x2C) seem to be pretty rare at the moment.


#18

[quote=“zcapr17, post:16, topic:86673, full:true”]

Some good points, but isn’t this the same for Z-Wave Association? [/quote]

Yes, which is why we generally don’t use zwave association that much anymore unless the hub itself is also included in the association group, in which case we’ve bypassed the limitations.

The issue with the multibutton local scene controller is that it doesn’t tell the hub which scene has been activated. The central scene command sets do.

As for this:

The first problem shouldn’t really be a problem as devices should send a report the smartthings hub whenever they change state (regardless of whether this is initiated from a physical button press, or receiving a z-wave command from a controller).

That’s actually not part of the original zwave design philosophy, which wanted to absolutely limit the amount of traffic being sent. Not sending a message was considered always preferable (the “should”) to sending a message. This is the “fire and forget” standard.

Local controllers, in particular, were not supposed to bother the hub.

It was all about keeping costs down, in terms of both dollar cost for individual devices and energy draw.

That was what led to the concept of the original “basic” command which would be as small and generic as possible. Without a reply.

In more modern systems, particularly those with status dashboards or trigger if’s, we do tend to think of it as natural that every device should tell the hub at any time anything changes, but in the zwave “less is more” context that would be considered both expensive and redundant. :sunglasses:


(Scott Ainsworth) #19

By including the hub in each scene, the Cooper controller is sending all its commands to the hub as well. The hub does not know what button has activated the scene, as any scene can be programmed into any button. However, with the cooper device the indicator lights can be interrogated to determine which buttons are on or off. This runs into a problem when a level is changed (not a scene command) as the cooper controller sends the button held command to all devices associated with that button. However, since the indicator does not change there is no way for the Hub to know which button was pressed. I’ve not figured a way around that yet so for now ST will only get On and Off for each button.

I have also been unable to get the controller to activate a scene remotely.


(codersaur) #20

All very interesting. Thanks.

All I can say is that I’ve been using direct z-wave association a fair bit in my home, mainly with Fibaro devices and it all works flawlessly. I’ve checked that when a device state is updated via association, it still reports any change back to the hub immediately. Admittedly, each instance of association is for devices within the same room so I don’t run into the second issue. Using Association is certainly much more responsive than trying to do the same with a smartapp anyway.

Interestingly, I have gone and looked at the specs for the Fibaro Dimmer 2 again. It’s weird that is supports Scene Activation as a Controlled Command Class, but doesn’t support Scene Controller Conf or Scene Actuator Conf, if it did I would definitely use it.