Little Help with understanding ZWave secondary controllers with ST

So, I am trying to wrap my head around how Z-Wave secondary controllers work.

I am trying to achieve something pretty simple - ability to easily, quickly, and reliably control individual lights from multiple remotes - seems like it should be easy…

Some background - on my network these days I have (among other things) Z-Wave light bulbs in places I care about reliability (had bad experiences with Zigbees bulbs, so they are now relegated to less important locations), as well as some Minimotes, ZRC-90 (thats the 8 button Z-Wave+ remote) and GE on-wall Remote (45631). Experience has been mixed - with Minimotes being the easiest to setup, with all commands flowing through ST hub, ZRC is similar, but took some messing with the ST Hub to set up. GE has proven to be most frustrating from ST point of view (it bypasses it altogether) but… it is by FAR most reliable. Basically if I press the GE button, it is pretty much guaranteed to turn its target on or off (even if ST is having trouble talking to the devices). Down side is that ST does not see what is happening with the lights, but at this point I am willing to live with it…

Unfortunately GE has a number of other issues. First is the fact that oddly it can only control devices with IDs in the first 32 (why!!!) and since each time I re-pair a device it bumps the ID, this proven to be a headache at times. Then there is the wall form factor, which is not always ideal, but most importantly, they no longer make or sell them, so they are out. So, I am trying to see if I can get the Minimotes or ZRC-90’s I already have act as secondary controllers they are supposed to be, but this is where I am getting confused…So, this is what I am trying to understand:

  • What exactly is the intended function of “secondary controller” mode in Z-Wave network? Is it like the GE, able to control devices directly, or is it supposed to tell primary HUB what to do?

  • If Minimote(or ZRC) is a secondary controller, is there a way to have it control devices directly instead of going through the ST hub. Going through the hub seems to work in theory, but very problematic in practice, as it takes forever and is very unreliable. Unlike GE, it seems that those only support Scenes and not Groups, but Minimote scene creations instructions are lacking (and do not work) and ZRC does not even provide them, which is odd for a “scene controller”

  • What else I am missing about this that I should understand?

Thanks

Z-Wave allows multiple controllers on the same network. There’s only one primary and can be multiple secondary controllers. Any controller, be it primary or secondary, communicates with devices directly. There’s a confusion between “controllers” and “remote controls” also known as “button controllers” in SmartThings. Button controllers do not control devices directly, but send commands to the hub, which then triggers some preprogrammed action or routine. Some Z-Wave secondary controllers can act as button controllers (e.g. Minimote), but others are not (e.g. old GE handheld and wall-mounted controllers). If you feel even more confused now then before reading my answer, you’re not alone. Welcome to Z-Wave . :smiley:

P.S. This primer is a good start to learn Z-Wave technology:
https://www.domotiga.nl/attachments/download/1075/Z-Wave%20Technical%20Basics-small.pdf

1 Like

Thanks, looks useful, will read.

It does not help that I am now realizing that there are not only primary and secondary, but also scene controllers (which I erroneously thought were same thing as secondary, but apparently not so much) :-/

I am not sure why such a basic use-case - a switch - gets so little love in the smart-home world… Not everyone wants to whip out their phone every time they walk into a room :frowning:

For what its worth, I discovered that if you delete the “Button Controller” SmartApp, the Minimote works MUCH MUCH better - though it is a nightmare to program, given that each button’s each press type has to be programmed separately and due to bugs in SmartThings App, you have to kill the app after programming each one of those.

To be clear, I deleted the “Button Controller” and created rules using the “Smart Lighting” app - the result is similar to button controller, but executes locally, and seems to be a night and day difference in reliability

1 Like

You’re absolutely right. However, to be fair, it’s not Z-Wave per se that is the problem, but rather its poor implementation in SmartThings hub. Z-Wave is very flexible protocol with many cool features, some of which SmartThings does not support entirely, and others tollally messed up, particularly secondary controller support.

2 Likes

I don’t know. On one side, you are right, on the other side it seems more of a far larger industry-wide issue. There are just not too many products out there for ST to even try to support in this space. I mean, there are only a handful not-hardwired remotes in existence, many of which are out of production, and most of those were clearly not meant to be used as a simple switch stand-in - I mean I do not find it that easy explaining to someone that “three dots arranged in a triangle are used to turn on the table lamp, but the six dots in a circle with a dot in the middle means to turn that light off…” and I do not even know where to start with the blank slate of Aeon’s WallMote or Fibaro’s playstation themed buttons. How hard is it to make something that looks and feels and works like a plain old light-switch people are used to? If I replace a light bulb in a lamp or add a outlet adapter, I guarantee the first person near it that is not me will just turn it off, and all the “smart” capabilities go out the window. Owning a home automation hub today is an exercise in fighting entropy… (sorry, I am clearly a bit frustrated with this stuff)

Sadly, it is true. The industry does suffer from a fragmentation and lack of a single standard. Sort of like the cellphone industry in the late 90s. But unlike the cellphone industry, it’s not converging. Quite the opposite, every year new “standards” appear, promising to fix the old problems once and for all, but here we are, no better off than 10 or even 20 years ago. :confused:

1 Like

There are over a dozen “button” and remote devices that have been confirmed to work with SmartThings. Some look exactly like a regular wall switch. So just depends on your own needs.

Have you had a chance to look at the FAQ yet? This is a clickable link. Each device is identified by region and whether it is wall mount or handheld, mains powered or battery operated, so read the description carefully. If you have any follow-up questions about any specific device, please ask them in the discussion thread for that device, not in the FAQ thread itself which is intended to just be one post per device. :sunglasses:

The reason most people who have smartthings don’t use local zwave controllers Is because those have four very significant limitations when compared to what smartthings calls a “button controller”

  1. The controller device will only be able to control other Z wave devices. Most people who want to use only zwave don’t use SmartThings as their hub: one of its main advantages is that it supports multiple protocols. If you are going to use only zwave, you can get a cleaner more efficient network by choosing one of the other platforms that specialize in zwave.

  2. The controller device will probably be limited to other Z wave devices that are within one hop, Usually just a room or two. You couldn’t press a button on your nightstand controller and have all of your outside lights turn on, for example.

  3. Because a button controller sends a message to the hub, it can trigger pretty much anything that smartthings can do, including Change the mode, run a routine, change the smart home monitor armed status, etc. A local Z wave scene controller is limited to just turning another nearby Z wave device on and off.

  4. local scene controllers were used in the days before people used smart phones and tablet dashboards To control their systems. Pretty much by definition the design of the local controller means that the hub will get out of sync with the status of the wall switches.

So for all four of these reasons, there hasn’t been very much demand by smartthings customers for local Z wave scene controllers. A button controller just gives you a lot more functionality. :sunglasses:

If you’re having an issue with responsiveness, that usually means the mesh isn’t strong enough, and the combination of adding a couple more repeating devices and running the Z wave repair utility will typically fix that. Support can help you with that.

If you’re looking for something to operate when your smartthings hub Is not functioning properly, that’s a different issue: but if that’s something you’re running into a lot, you might even want to consider changing hubs all together.

So that’s the short answer as to why neither smartthings the company nor this community have put much effort into supporting local Z wave scene controllers. They are almost antithetical to the vision of the SmartThings platform, which is to let you control devices of many different protocols all from your smartphone. :sunglasses::iphone:. That doesn’t mean the only method of control will be the smart phone, but it does mean that most smartthings customers will expect that their smartphone app will remain up-to-date on the status of all their devices.

Thanks. I have read that thread many a time over the years and just went through it again, and I am still not seeing much there for the US market - although admittedly I missed the Sylvania Lightify button, which looks promising and may be good enough for my needs, and I will be investigating. The thing scares me there is use of Zigbee (which is ironic, as I am working on Zigbee Mesh devices for a living at the moment) - I find Zigbee home automation reliability horrible, with devices dropping off the network for no good reason on regular basis. Switching key devices to Z-Wave/Z-Wave+ made a huge difference in reliability (except when people reset them by turning them on and off too many times in a row).

The only other thing that seems even remotely like what I was thinking was Cooper Aspire button, but it is a button, not a switch. I actually have it and had a hard time getting it to work properly, although I was trying to do something more complex with it than I would do now - of course I now need to get the batteries on it replaced before I can try it again)

(well that and the fact that SmartThings does not support them well)

Reasonable limitation, but I disagree with the all or nothing approach - I can(and do) have Z-Wave devices for lighting/devices I want to control with a Z-Wave controllers and still have other devices using other protocols that are not related.

Again, reasonable limitation, but in most cases people want to be able to turn on a device in the room they are in - with trying to control other devices a useful feature, but far less commonly necessary.

Again, agree with awesomeness of having a button controller, but in MOST cases, it is not what is actually needed. Button controller gives you awesome extraordinary operation abilities, but what is usually needed first is something that is equivalent in simplicity and usability to a light switch, where you touch it and the light turns on/off near instantaneously and reliably. The button controllers promise that in theory, but fall far short of it in reality. If you give me a button controller that is as easy and reliable to operate as a light-switch and I do not have to have a full day offsite training seminar to get someone else to use it - I am all for it.

This, I think, is at the core of why smart-home concept is failing. The idea that when you walk in the room to get something , you should be required to:

  • Get you phone out
  • Unlock it
  • Find the right smart app in your launcher
  • Locate the right screen within the app relevant to the room you are in
  • Locate the right switch in the room
  • Then switch it on

That is a completely ridiculous expectation for most people. Not to mention that it requires that every person entering the house has the software installed and configured on their mobile devices and they always carry them. It may appeal to small number of people, but most people would rather just stumble in the dark and curse.

The only things that make this somewhat palatable are voice assistants like Alexa, but even those are only useful in some cases.

More functionality is not always better. A race car gives you far more power but it pain in the ass to go to the grocery store in… :slight_smile:

My lights (Z-Wave) seem to work reliably/quickly every time, so I assume the mesh is good enough for them, so why would Minimote, which is often less than a foot or two away from them, is so unreliable and slow? I wondered if it is possible that the lights are not repeaters, so at one point I added a Z-Wave electric plug between the lights and the hub (not that the hub is particularly far) and it did nothing to improve minimote reliability or responsiveness. What did work was getting rid of the Button Controller SmartApp - that made a huge difference, although I have not used it long enough in that configuration to confirm that is going to stay reliable.

I just want something that works reliably enough so that someone who is not a techie who is excited about all the possibilities of a “Smart Home” does not consider it to be a headache/problem - which, in my experience, is true in every single household where the person installing an automation hub(not just ST) lives with someone else (i.e. a spouse)

Yeah, and while I totally get that - especially the part where the hub becomes out of sync with the devices - but I think that smartphone-first approach is also exactly what seems to be killing the industry right now. I am not saying the “Scene Controllers” are the answer - they are just something I am exploring while looking for the answer. The GE controller turned out to be the closest thing to something just working reliably and quickly for anyone who walks into the room and wants to turn on the lights without appropriate certification training. I spent a lot of time and money on smarthome stuff, and every day I have to walk around the house and turn back on/plug back in all the devices that are just turned off because it is too complicated to turn them on/off any other way…

-M

1 Like

Understood, and well stated. People who like voice assistants now have several very good ones to choose from, and this more than anything else seems to be driving smart home adoption in the lowest cost tier, which I think speaks directly to your point. But not everyone likes it, so definitely other options are needed.

One reason the minimote is likely having difficulties Is that it is in a device class called a “portable” controller, which means it doesn’t know physically where it is in your house at any one time. This means it can take an extra second or so to figure out which repeater to use if it’s more than one hop from the hub. Local scene controllers like the GE Don’t have this issue as they assume they are in a fixed physical position (even when they aren’t).

Another popular option, but that may not fit your needs, is to add a hardwired Z wave device which isn’t wired to the load. That way it can’t cut the current to your smart device, but because it’s mains powered it never sleeps, unlike just about every battery operated device. So you can pick up another half second or so that way as well, and of course have something that looks exactly like a regular wall switch. The Linear WT00Z is very popular for this purpose, but of course you do have to wire it into the mains.

Zigbee is a whole other conversation, but I would argue that one of the most successful low cost home automation products Is the Phillips hue bridge. Reliable, responsive, and quite consumer friendly. And of course it’s using zigbee. :sunglasses: but as @geko Already mentioned with regard to Z wave, it’s not the protocol itself we’re dealing with: it’s the SmartThings’ implementation of it, and the whole underlying cloud architecture. :cloud_with_lightning_and_rain:

1 Like

Just wanted to follow up with some new experiences and provide some feedback:

First of all, MiniMotes are working MUCH MUCH better since I got rid of the “Button Controller” SmartApp. That said, it still seems to go south on regular basis where it just seems to lose contact with the hub or something - at those times when they are not working, it seems that the MiniMotes are trying to tell me something with an elaborate patterns of blinking of the blue and red LEDs - but I cannot find any information about these patterns, so, who knows… I think you are right on it getting confused on waking up (as usually this happens after not using the remote for a while and after this sort of a freakout, once it starts working, it keeps working - so I guess it establishes a route…) but it is a lot more than a second, it usually takes a minute or two of pressing various buttons before either it starts working or we give up. I am starting to wonder if my ZWave bulbs are actually acting as repeaters or not… I may need to add a dedicated repeater somewhere here - though it has not helped in the past…

Second, at your urging I have re-read the remotes thread and took a closer look at the Sylvania’s Switch. I even bought one. It is (relatively) cheap and while the form factor was not exactly what I was hoping for, it definitely fits my needs of having a simple enough switch with on and off sides. I think this is a winner. It was easy to pair with ST, and as easy to program as any other button device (which is not bad once you know what you are doing and know how to get around SmarthThings’ app bugs, and avoid “Button Controller” SmartApp ). Once I configured it, I was blown away at the speed and reliability of it. It worked every time and fast. So I moved it to the location I actually wanted it in… and things got murkier… It works, except when it doesn’t - and when it doesn’t often I am getting very odd behavior. Specifically It seems to queue up all the attempts… and then execute them all in a row a minute or two later. I am wondering if I am having a range issue as I primarily have Z-Wave devices now in this location, so I moved a Zigbee plug adapter close to this and going to see if the issue will go away…

Thanks for the answers. I will keep on plugging away at it. I still think there is value in the GE’s approach to things, but as GE stopped making these and there are apparently no others that work that way, I guess I need to look elsewhere… Thanks again.

1 Like

This is an old thread, sorry I did not see it sooner, but I want to add some information to what JDRoberts said - which was a lot of good information.

  • The word CONTROLLER is misused all the time - as he pointed out, you can have a handheld device that the manufacturer calls a controller but it may not be (technically) a controller. A controller is a library type in Z-Wave, and the library type defines some of the behavior of the device. There are four types, but over the years we have gotten down to using only two, controller and slave. There are sub-classifications such as static controller, portable controller, slave, routing slave, etc. but those are the main two. It is OK to call something a controller if it is sending signals to control something, but for purposes of “secondary controllers”, it has to use a controller library. You can go to the catalog of certified products (https://Products.Z-WaveAlliance.org) and look up a device to see what kind of a library it uses.

  • If the device uses the controller library, then it could have special capabilities; a secondary static controller (one that does not move) gets updated information about new nodes in the network or nodes that are removed through periodic updates sent by the Z-Wave Plus primary controller. If the primary controller is not Z-Wave Plus, then the secondary static controller is only updated when you make it get an update. The way to trigger an update is to re-add it to the network without removing it from the network; the node number will not change, but during inclusion, a copy of the most recent network will be sent to the device. There are some very old Cooper (now Eaton) wall controllers and Leviton wall controllers that would operate in this fashion; you could not program a scene into those controllers for a device you just added to your network unless you do an update first, because otherwise the controller does not know about the newly added node. This is also why we stress to people to go only with Z-Wave Plus devices because everything is easier!

  • Handheld or portable devices that operate other device may be the controller library if they are older, or the routing slave library if they are newer. If they are newer, then they also probably use the CENTRAL SCENE command class which I will mention shortly. If the handheld controller uses an actual controller library, then it needs to be updated periodically unless your main primary controller is Z-Wave Plus.

  • There are 3 ways that the word SCENE has been used over the years, but only 2 of them are actual scene technologies:
    – 1 – Not really a scene: There are handheld, wall mount, and battery operated controllers out there that say they do scenes, but all they really do is send commands to devices. There is a basic command class that a device can send to operate all devices, but it gets very complicated to send a basic command to a thermostat for example and to know if you want to change the mode, fan mode, setpoint, etc. So, these devices typically do not take full advantage of some of the commands available in the device such as being able to tell a dimmer how quickly to ramp up or dim down. Also, because these are just sending commands, you will get a “popcorn” effect with multiple lights turning on or off because it takes typically a few hundred milliseconds for a direct command to be sent.
    – 2 – The Z-Wave Scene Command Class(es). Back in the early 2000s, Leviton worked with the owners of the Z-Wave technology to put together a set of command classes that could operate several devices in a scene, but the effect is instantaneous. In other words, when you invoke the scene, all of the devices in the scene go on or off at once, and the overall scene can even have a ramp rate from seconds to hours (so I can dramatically dim the lights in the home theatre with a scene). These scene commands to activate are sent by the scene controller using a multicast, which transmits to all of the devices in the scene at the same time. A multicast does not route, so the scene controller has to follow up every scene activation command with an individual command to all of the devices to make sure they heard it. So if you set up a scene involving all of the lights in your home, you will still have some popcorn effect because you won’t be able to reach all of the devices at once (although Z-Wave Plus makes that more likely and the 700 series even more so). Not all of your hubs will support setting up scenes in this way, so if you are a professional installer, you really have to look for a hub that can do these commands.
    – 3 – Central Scene: With the earlier mentioned issue of devices having features that remotes wanted to take advantage of (but could not) Z-Wave realized that the best way to solve this was to move the scene to the primary controller/hub. So, modern handheld devices or “buttons” that can operate devices, do so using Central Scene. With Central Scene, the device that you press sends information to the primary hub on which button you pressed, and then it is up to automation in the hub to do what you want it to do. If your hub supports the Z-Wave scene commands, then you can still have all of the lights come on at once for all of the devices that support the Z-Wave scene commands. But with this setup, because the hub knows some of the advanced features of the devices you are controlling, you can often do more powerful things.

  • I won’t get into the details here, but a device that uses a controller library can be used with older Z-Wave networks to help with device management. If your primary hub is Z-Wave Plus, then even an older handheld remote can be added to the network, and it will become a secondary inclusion controller if it has a display and the functions for adding/removing devices. (In other words, a wall scene controller may use the controller library, but it cannot add/remove devices because it has no UI for it.) What happens is that on the handheld after you added it, you tell it that you want to add a device to the network, and it talks to the primary controller to get a node ID it can assign to the new device, and then it does the inclusion, and when it is done, it reports back to the primary controller all of the information about the new node and its neighbors. So if you have older devices that do not support Network Wide Inclusion and they cannot be added to your network because they are too far away from the main hub, even adding more devices won’t fix that but an old handheld controller may very well do the trick! This is going away at some point though because older controllers cannot do what is needed with the Security S2 requirements, which includes verifying a DSK when a device is added to the network, so at some point it may be more difficult to service very old networks (Z-Wave Plus started in late 2013).

  • Finally, a secondary controller is also a mechanism to have multiple controllers if one does not provide all of the functionality that you seek, but many controllers today are designed to be the primary only and do not operate very well as a permanent secondary controller, so your mileage may vary. The ability to be added as a secondary controller however also means that it should be possible to add another controller as a secondary controller, and if that works well, then you can repeat that procedure with an option called “shift primary” and that then allows the secondary controller to become the new primary controller. This is how you can change what your primary controller is without having to remove/reset all of your devices and re-add them. Keep in mind that your devices are all set to report their lifeline information to the old controller node number, so you have to update the associations to be for the node number of the new primary controller. This is rare that you will need to do this, but it is (currently) built into the protocol so that you can do it.

I hope this helps - it is a lot of info and it is a bit technical, but some people here appreciate knowing the full story!

2 Likes