Pass command to another zwave device

Developer Programs Writing Device Types
,
#5

As per @anon36505037, 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.

#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.

#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.

#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.

1 Like
#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.

1 Like
#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.

#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:

#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).

#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:

1 Like
#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.

#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.

#21

David
Here is a link to the Linear DTH I modified to allow setting up with 2C commands.

You can use that as a basis for any changes to Z-Wave Tweaker you would like to do. My execution of the user interface is poor and I don’t have the tiles updating correctly.

I don’t include a way of scanning to see what scenes are programmed that would be an improvement. I think you have to iterate through with a bunch of get commands to see what comes back. Similar to what you are doing with other things in tweaker.

#22

A couple of different responses here, but I’m going put them all in one post.

1) Local Scene Control was defined as always being actuated by a physical action (typically a button press) on the local controller. To the best of my knowledge, there is no way to send a command to a local scene controller to tell it to initiate the scene.

2) there are seven local scene command sets.

The first one is what is used on a daily basis to launch the scene. Press a button on the local scene controller, it tells the end devices to launch that scene.

A) Scene Activation Set. Launches the scene each time. May be multicast. Sent by the local controller to the devices in the scene. ( again, the official spec does not include any way to turn a scene off.).

The next three are used by the local controller to set up the end devices so that they know what they are supposed to do when a specific scene activation set is received. So for Lamp A, Scene 12 means “turn on at 50%.” For lamp B, Scene 12 means “turn on at 75%.”

B) Scene Actuator Configuration Set. Cannot be multicast (it will be ignored if it is). Sent by a controller to a device in the scene with the values that device should use for that scene.

C) Scene Actuator Configuration Get. Cannot be multicast (it will be ignored if it is). Sent by a controller to a device in the scene to request what values are set in that end device for that scene. If The scene ID is “0” then the values for the current scene will be returned.

D) Scene Actuator Configuration Report. This is the response from the end device to the scene actuator configuration get.

The last three are used by the primary controller to map the buttons on the local controller to the specific scenes. So pressing button one on the local controller should launch scene 12. Pressing button two on the local controller should launch scene 15. And so on. Note that this is different than association, where the groups are just numbered one, two, three.

Again, the idea of local scenes was that they would be created through the primary controller and then assigned to various local controllers, so they might’ve been created in a way that didn’t map sequentially to the local controller’s buttons, which was fine. This is how vera and homeseer work.

E) Scene Controller Configuration Set. This is how the hub maps the physical buttons on a local scene controller after the scene is created by the primary controller. Last time I looked this was not supported by SmartThings, but maybe it’s changed. Cannot be multicast.

F) Scene Controller Configuration Get. The primary controller queries a local scene controller for its current button settings. Cannot be multicast. Scene ID cannot be “0” because this isn’t about the commands mapped to the scenes, it’s about the scenes mapped to the buttons. So there’s no “current scene.”

G) Scene Controller Configuration Report. The local scene controller response to the scene controller configuration get.

#23

I bought a RFUSB PRO on ebay for $15. It is a cooper usb controller that uses a customized version of Homeseer. Unfortunately I found out the software cannot be registered and is only good for trial use (per homeseer). That said it has proved useful in figuring this thing out. It does NOT as far as I can tell activate a scene via the scene controller. It makes you think it does by letting click an icon for the controller button in the software and then watch your lights come on. However, after I was able to program my controller via ST it became apparent that Homeseer was only activating what it thought the scene was. It appears that Homeseer is sending the scene activation command directly itself. This agrees with what JD said in his point 1.

1 Like
#24

I Did want to clarify my earlier point about local scenes not being (fully) supported.

In most Z wave – only platforms, you define a scene on the interface to the primary controller. It keeps track of which devices are assigned to which local scenes and at what levels.

Then you use scene controller configuration to map the buttons on any individual local scene controller device to the pre-defined scenes.

This is the process piece that SmartThings is missing. You may be able to write code to individually send each required zwave scene command set, but there’s no platform management of zwave scenes. Each individual coder has to keep track of them in each individual Smartapp/DTH.

Again my guess, for which I have no data at all :wink:, is that they chose not to offer built-in standardized UI management of zwave scenes because it would be a feature that was not available for zigbee devices.

1 Like
#25

Good point. It would be great to see a standardised UI for many of the Z-Wave command classes, mainly all the ones my Z-Wave Tweaker tries to deal with: CONFIGURATION, PROTECTION, SWITCH_ALL, ASSOCIATION, etc…

1 Like
© 2020 SmartThings, Inc. All Rights Reserved.