I am just starting out with ST and Z-Wave and wanted to get some extra understanding of how things work on Z-Wave network. The questions below will probably demonstrate how little I know of this - so any pointers would be appreciated.
My understanding of it is that Z-Wave is a mesh network where each node can send and/or receive commands. ST hub acts as a controller and should be able at least to send signals to nodes (siwtches) and receive signals from nodes (motion, physical activity on switches).
I was wondering if ST hub can monitor all of the messages on the network? I realize it is possible the messages are point to point and the hub may not actually even see ALL the messages pass through it, but is there a way to have all messages delivered to the hub and/or at least show the messages that are seen by ST hub? If not, is there another way to monitor a z-wave network?
And second question, I am guessing each device has an ID on the network which is used as a MAC address to send messages to. Can ST hub create/emulate multiple virtual device IDs and receive signals from the mesh network. In other words, can I create a virtual switch in ST that can be controlled via Z-Wave from other controllers?
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
3
No.
You’ll get a detailed explanation of the alternatives from someone, but, in brief, the SmartHub is not configured as “scene controller” compatible, though it can pickup scene control events from some newer devices. Search for discussions on remote controls (esp. the GE 45600 or 45601) for details hashed over extensively).
Zwave and zigbee networks are designed to be cheap in terms of both dollars and energy draw.
If you set up two devices to communicate directly (association in zwave, binding in zigbee), the hub will have no clue what they’re saying to each other UNLESS you put them into a group that also includes the hub.
So really it’s up to you. If you want the hub to handle everything, just don’t directly associate the end devices.
And in all mesh networks, each device has a unique node ID.
As for virtual devices, I didn’t quite understand your question, but ST does provide the ability to create several types of virtual Devices which are then treated like physical devices by the ST hub. So you can’t directly associate a virtual switch with a physical lamp, say, but you can certainly have a virtual switch trigger hub activity that turns on the lamp. And the virtual devices look like any other device on your network to outside services like IFTTT or
Harmony. Indeed, one of the most popular uses for virtual switches by smart things customers is to create a method for communicating with such outside services.
However, that will only work if the request comes from the other system through the smartthings hub. You can’t directlly communicate with the virtual device via Z wave.
Ok, I looked at some of this but not seen much in terms of details as to why this is impossible. I am trying to understand it.
I understand about generic virtual devices in ST, I was wondering if there was way to make ST Hub emulate a z-wave device (switch) and listen for the events to pass to/through that virtual device. Apparently many secondary controllers do not work with many z-wave devices other than z-wave switches - and being that most of my few devices I am starting with are NOT switches (and some are not even z-wave) - so I was hoping that I could use hub as a place to proxy the controls sent from secondary controllers - but it seems even that may not be possible.
That makes perfect sense but does not explain the core of what I am trying to understand - i.e. can one Z-Wave device (ST Hub specifically, or another hub if not ST one) register with multiple Node IDs for single device?
Sorry, I’m still confused about what you’re asking.
There are certainly some secondary controllers that ask the hub to pass along a message to a zwave device. That’s how anything identified by SmartThings as a “button controller” works, including the Aeon Minimote, Aeon key fob, SmartenIT 3 toggle switch, and Securifi key fob.
Push a button on the secondary controller, a message is passed to the hub which then formats it for the end device and passes it on.
In fact with SmartThings, it’s fine if the button controller is zwave and the end device is zigbee or vice versa, ST will do the translating.
So the same applies to virtual devices.
If by “secondary controller,” you mean a device that is not known to ST, then it can’t talk to any of the end devices owned by the ST hub, regardless of whether they’re physical or virtual. That’s what the “home” identifier is for in the zwave addressing scheme.
If instead you’re asking if ST can be on a network with another zwave controller and both talk to the same end devices directly, the answer is maybe. As @tgauchat mentioned, this is typically done through scene configuration which ST does not support. But it can be done in other ways.
See the following discussion:
Some members have used this for alarm panel integration, although it is incomplete and gets tricky.
Can you be more specific about exactly what use case you’re trying to solve? That would make it easier to answer.
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
10
I seriously don’t think so.
Could you describe your use cases / end-goals, perhaps, so we can propose alternatives that we know work?
We don’t know a lot of details of the SmartThings Hub firmware, but I know it is very limited and focused in functionality. Instead, SmartThings lets you integrate / interrelate Devices through SmartApps (currently run in the cloud, local when Hub V2 hardware released).
It’s not that ST is particularly limited, rather that the hub is only certified for the Basic zwave command set. (That’s a specific technical term in zwave.) They’ve added a few commands from other levels as well.
But if you just think if it as a controller that supports the “Basic” set, you should be OK.
It has third party certification as a static controller. Look in the “system gateway” category:
This particular expedition into nowhere started as such: I have a handful of lightbulbs (GE, WeMo) and a few other devices controlled by ST hub. I want to have some wall mounted controllers for those devices (mostly bulbs). Bonus points for being able to trigger other events in ST hub - though for now I would settle for just controlling existing devices. I got a wall-mounted keypad (45631) to play with and while I realized it would not likely to work with SmartThings - I was thinking I could at least get it to control the devices (mostly lightbulbs) directly and have ST, if needed, react to the state change in the device itself. Of course that would be too easy.
What I found is that the way this works is that the keypad is a “secondary controller”, which, as I understand, means it talks to the Z-Wave devices directly. That is what I expected - but what I did not expect is the obtuse way the remote controller is programmed. At its heart, all that the remote controller does is when you press a button it emits a z-wave message to node id of the device and a command (on or off). The tricky part is how to tell the remote controller which device to send message to. To do this, you set the remote controller into “add” mode and press a button on the device which, I guess, emits some broadcast message with its ID. But this is where this all falls apart as the lightbulbs simply do not have a button. So there is no way to tell the controller which device to control. Ugh.
So, I’ve been thinking of various ways to get around this. One obvious way to get around it is to figure out what this broadcast is and send out a fake “broadcast” on behalf of the device so that the remote controller sees it and adds it to the group. Of course I have no idea what this message is or if there is a way of faking it (I know there is some encryption involved here, so I am not sure how hard is it to send a message with a different node Id.
Another way would be to have the remote control to talk to proxy virtual switch devices. Basically if a software backed node on Z-Wave network would behave as multiple node IDs (think of it as having one computer have multiple IP addresses) - each virtual “device” can be addressed directly. The remote control would then send signal to those virtual devices, which in turn will signal ST to do whatever we want. For that we would need to have ST hub or some other device be able to sit on Z-Wave network emulating multiple devices. I know this is possible in ethernet and TCP/IP networking, but I have no idea if this is possible on Z-Wave network at all, or on ST hub specifically.
Of course if there is a way to get into the remote controller’s firmware and directly tell it the configuration that would be ever easier - but I would not know how to even begin that…
So… Is what I figured out here correct? Am I missing anything? Any ideas or suggestions on how to do this “the ST way” without replacing my lightbulbs with switches? And without replacing the remote controllers with duct-taping Aeon MiniMotes to the wall (I have a few MiniMotes, and they do work, but not exactly what I am looking for).
That is actually not my understanding. My understanding (which is admittedly suspect, I could very well be wrong) is that the secondary controllers typically talk directly to the Z-Wave devices they control just like primary controllers. The difference is that the primary controller can add new devices to the network and assign node IDs, where the secondary controllers can only get the list of existing devices from the primary. In that respect, MiniMote and such are NOT actually secondary controllers - but act more like any other sensor device like motion detector or contact switch. The only difference is that instead of sending “motion detected” or “window opened” it sends “button X pressed” or “button Y held”. Honestly I think there is a great space for these “sensor” style remote devices - and if my 45631 would have done that, I would be pretty happy.
OK. Shortest answer: those wall controllers won’t work with SmartThings. No way around it. Many people have tried and failed. Search the forums for many long technical discussions, because a lot of people wish they did.
It is possible to initialize the wall controllers with a different primary, like Vera, and then end up with a really weird configuration where the wall controller can control the lights but ST has no awareness of what’s going on. Not what most peopke want.
There is a zone controller that some people have working, but not everyone.
And a nice 3 toggle battery operated switch which has a better form factor than the Minimote for wall mounts. But that’s about it.
Instead, what most people do is use the very nice dashboard called SmartTiles. It can run in any browser, so you can get a cheap android tablet and end up with a really nice looking wall panel controller.
All of the above is the right idea, In terms of how the zwave standard is written. But it’s more complicated than that when you’re looking at a SmartThings network.
The Minimote is a true zwave secondary controller. It can in fact exclude or include zwave devices to the network. It is certified as a handheld controller by the zwave alliance.
But in a smartthings network, the Minimote can also trigger zigbee devices, because, as you noted, it can be read more like a contact sensor.
So far, so good.
The problem is that “static controllers” like most of the wall mounts and a few of the handhelds like the old GE remotes are not read by the ST hub in the same way. (See my other note.) I wish they were, you wish they were, logically it seems like they should be: but the ST hub is only certified for the Basic zwave command set, and it doesn’t support the scene management commands necessary for communication with the wall mount scene controllers.
Interesting. So not all Z-Wave controllers are created equal. Do you have some examples of other controllers which support more than the basic command set and how it could affect the choice of a controller?
Just depends what you’re looking for. Do you know how to read zwave conformance statements? They’re not that complicated. One section is for which commands they can send, and one for which they can receive.
Just look at the conformance statements in the System Gateway device class.
Also look at the conformance statement for the wall controllers you have. You’ll see which command classes they use. You need the ones used by the device to be supported by the gateway in order to be able to use the device as intended. The missing ones in an ST network are typically controller replication and scene configuration. The missing one on an older zwave device is typically association.
Ok, so if MiniMote is a secondary controller after all, what makes it so much different from other secondary controllers that it can be read as a contact sensor where the other secondary controllers cannot? There is a piece here I am clearly not yet understanding - because the fact that it works for MiniMote makes me think it should be technically possible unless there is a substantial specific thing that makes MiniMote unique.
So what makes Vera more capable at this than ST? What can Vera controller do that ST Hub cannot?
And if you do end up having to run things via Vera - why would you need ST at all? Wouldn’t Vera replace the ST functionality? Or am I missing something here? (I swear I am not trying to troll, just trying to understand why would someone want to run both - seems redundant and more difficult.)
SmartThings can control both zwave and zigbee devices, plus some cloud services. Vera is zwave only. So different people have different use cases. I wanted the zigbee presence detector.
Also one of ST’s cloud services is the IFTTT channel, which I use a lot for voice control. Vera doesn’t have that.
If you want only zwave devices, forever and ever amen, Vera will probably be better for you.
In particular, Vera has full scene management. Their mobile app is pretty lousy, but their desktop client has a full rules engine.
Different solutions work for different people.
I don’t know anybody who wants to run both, although I know some people are. But if you used to have Vera and you initialized your scene controllers with it, you may be able to retain your button assignments after you move to ST. But ST won’t know what the status of the end devices are when you do use the scene controllers.
