Recently I’ve gotten a couple of private engineering questions about remotes and I thought maybe the following would help clear things up. The following applies directly to zwave but there are similar issues in zigbee installations.
DEAD ZONES AND LAG
back in the old days of home automation, say 2008 - 2011, the assumption was that wireless HA installations would have some similar issues to commercial installations, specifically frequent local drop offs due to interference or battery powered devices having batteries changed or just tricky local dead spots. You’d turn on a switch in the attic and it would be a minute and a half before the light actually came on.
So “local controllers” were used a lot through “association” (zwave term) to physically control nearby devices without having to communicate back to the hub first. That could really reduce lag. One of the most common uses was to have a wall switch turn on several lights at once in an “association group.” Most of the time the hub had no idea what was going on locally, but didn’t care. When it wanted lights on, it set the on request. When it wanted them off, it sent the off. Because unlike zigbee, zwave remains powered even when “off” everything worked fine.
Then we moved on to “local scenes.” This was the idea that the LOCAL switch would save some settings for the few (usually no more than 5) LOCAL devices that it could control. Typically this was a dimmer setting with a few lights all set to the same dim level. Someone, naming no names (but might possibly include a G and an E ) started promoting these as “scene controllers.” Note that in this scenario the hub still has no idea what’s going on locally. The switch could switch things on and off, even save different dim parameters, and the hub didn’t know.
INTRODUCING GLOBAL SCENES
But we had reached the era when the hub WANTED to know (without having to do constant polling) so it could update its fancy status screens. Or fancy smart phone apps.
In addition, even in a zwave-only installation, the hub was starting to use a lot of “global scenes” itself, where it might include devices in different rooms doing different things that had no direct association with each other.
So now we have the local controller, usually a wall switch or a hand-held tv-style remote, creating its local scenes for the few devices it controlled, and the hub knowing nothing about that. And the hub creating its global scenes for any devices anywhere in the installation, and the local controller knowing nothing about those.
PRIMARY CONTROLLER TO LOCAL CONTROLLER INTERCOMMUNICATION
There were two different approaches to this, often both implemented in the same installation.
- The hub would add itself secretly to any “association group” that the local controller created. This defeated one part of the whole concept of local controllers, since it meant everytime the local controller did something it DID send information back to the hub. On the other hand, this was just information for the hub to receive, so the local lag and dead spot issues were still addressed, so it wasn’t too bad. It did increase traffic load on the network, but not by a lot.
(According to the developer documentation, ST does do this, it adds itself to the first association group created by a local controller. Weirdly this seems to imply that ST doesn’t know that multikey local controllers commonly have multiple association groups, but perhaps this is just intended as an example.
- The hub would be able to link a button push on the local controller to a global scene. So a button press on the local controller looks just like an open/close sensor closing, which triggers the HUB to start its global scene. This definitely reintroduced all the issues the local controller had been intended originally to avoid, like lag and higher traffic. But it did have the advantage that the local controller could now request actions from more than the original 5 devices it was directly associated with. And if the hub was unavailable, the local controller could probably still turn on and off some local devices, so your light switches still worked.
Unfortunately, when you use these two methods together (hub secretly adding itself to the local controller’s association groups and local controller requesting the hub to make action requests rather than doing so directly itself) you had the weird circumstance of the local controller communicating multiple times to the hub for one request. First the local controller would request the hub to make the action requests associated with a specific global scene, usually through acting as a contact sensor. Then the hub would ask the local controller to issue the commands to its associated children. Since those children include the hub via the association group, the local controller would then send the individual action request back to the hub, who would use it to update its information about device status. (Are we having fun yet?)
This is what we call “evolving design.”
WHEN IS A “SCENE” NOT A “SCENE”?
OK, now for the really fun part. No one ever told the marketing people that there are two types of scenes, global and local. And the zwave specification, another evolving design, assumes everyone knows that a “scene” created by a secondary controller must, by its nature, be a local scene that the hub knows nothing about, while a “scene” created by the primary controller must, by its nature, be a global scene.
Unless, of course, the secondary controller was a primary controller in a past life, in which case it’s possible that it created global scenes and then passed them on to the new controller. Or not, it may just have passed topography information. Passing topography is part of the regular Zwave controller operations, although perhaps not fully supported by ST. Passing global scene information is unusual and is typically manufacturer proprietary command class. Usually when you change primary controllers you have to re-enter all your global scenes. However, your local scenes may still exist in your local controllers, that varies.
All of which means: you can buy a zwave certified device that is marketed as a “scene controller” and it absolutely does not guarantee that it can set up a scene that the hub or other “scene controllers” in the same installation will know anything about.
As originally manufactured, both the GE keypads and the GE tv-style handheld remotes have the ability to “create scenes.” But these are LOCAL scenes. Most typically used so that button 1 sets dimmable lights on a group of 4 devices to, say, 25%, button 2 sets them to 50%, button 3 sets them to 75%, and another button turns them all off. These might be labeled “movie night,” “evening” and “craft night” but really they’re just a standard preset used for all the devices in a specific group that were directly associated to this local controllers. They are not global scenes the way we tend to think of them now, with schedule controls, multiple devices of different types, and even devices in different rooms. From the GE user manual:
Scenes are normally
activity based lighting schemes.
A Scene lets you establish preset
brightness levels for multiple
Z-Wave controlled lights and
then control them with one
command. This is ideal for mood
or task lighting. Scene 1 could
be the family room lights set to
dim for watching TV. Scene 2
could have the same lights set
to a different brightness level for
other activities like reading
And the keypad knowing about these setttings doesn’t mean the primary controller knows about these settings unless you did some behind the scenes work with groups.
So buying a remote/keypad, particularly an older design, that has “create scene” instructions does not mean it can create “scenes” the way Vera uses the term, or Hello Home Actions the way ST uses that term, or the way most people writing about home automation today use the term. It just means that secondary controller can save some settings for a specific very small group of locally associated devices and reuse the settings with one button push.
A lot of the custom code I’ve glanced at for new device types works by just treating each button on the device as a contact sensor, then using that sensor being pressed to trigger hub/ST activity to run Hello Home Actions. Should work fine, with the caveats above about extra network traffic and things not necessarily working in the expected sequence. But while the remote may still be able to create its local scenes through direct association, I haven’t seen any custom ST code that lets those local scenes be transferred back to the hub for use in Hello Home Actions.
So “create scene” on a remote or keypad functioning as a secondary controller almost always will mean “create local scene for use by this device.” That’s why those local scenes can’t include things like schedules or ST modes.
WHEN A HANDHELD REMOTE IS A PRIMARY CONTROLLER
It is possible for some handheld remotes to function as primary controllers, and so create global scenes, but those were mostly intended for entertainment center + light setups where there is no hub. Integrating ST as a secondary controller into those installations is a whole other discussion.
I hope that helps clear up some of the confusion, especially regarding handheld remotes with fancy “create scene” buttons. The user documentation won’t always help unless you understand that by definition in zwave a secondary controller is creating local scenes for use by that device.
If you have the right device type, you can still use a secondary controller like a handheld remote or keypad to trigger global scenes with a specific button push, which is good. But those global scenes were created via the primary controller (in this case, ST), not through the scene create feature on the remote. The remote in this case would be a “global scene” “controller.” But not a “global scene” “creator.”
I hope that helps clear up some of the confusion.