Do you use multiple technologies together or try not to?

Devices & Integrations
1

Hello,

I’m just starting out with ST and deciding on what sensors, add-ons, etc that I need. In my research, looking online, and learning from places like these forums, it appears that Zigbee and Zwave are the best and most reliable options (at least at this point…obviously when BT is activated it may be another option). In attempting to form a plan of add-ons, I’m realizing that I have a choice of whether to attempt to keep as many of the add-ons as possible within the same “technology language” ie Zigbee or Zwave or if it doesn’t matter as both are supported. I began to wonder if the system performs better that way, if it’s advantageous for the future for some reason as other protocols become more available (I’m particularly thinking of Thread/Zigbee but maybe others), or if it really makes absolutely no difference one way or another. I thought the best way would be to ask in this community what you think, what you use, what your experiences are, if both protocols work equally well, etc. I don’t know if it matters but I’ll give the basics of what I have already:

Several Philips Hue lights in different areas of the apartment (all Gen 1 as I have no interest in Apple products or compatibility…if Gen 1 vs 2 affects ST, please let me know)

Nest thermostat, recently purchased, which I plan to soon install. If there is are any issues with it working with my heating system, I’ll have to switch to something like the Zen Thermostat, although the Nest company says it will.

Items in the ST Starter Kit (socket, sensors, etc)

I’ll be adding more sockets, multi sensors, humidity capable sensors, water sensors, compatible smart lock for doors, video cameras for live monitoring and possibly security, and I’m not entirely sure beyond that. But at least that’s some idea in case it has a bearing on your thoughts as to what might work best together.

Any information about your experiences, knowledge of the systems/technologies, differences, what you use in your setups, any “best practices”, ideas, thoughts etc would be super helpful in my learning and planning what to use. Thanks so much for your help and kind spirits. The people in this community are really quite extraordinary and I’m so grateful.

2

Pick one protocol IMO. You want to build out one mesh so you can make that as strong as possible

1 Like
3

For what it’s worth, I’ve been running both Z-wave and Zigbee devices… most all my Zigbee are ST-branded devices. I think the only time you’ll really have a problem (assuming a “normal” house) will be Zigbee presence sensors. You’ll want to try to get a Zigbee repeater close to where those will be to make sure they have a nice solid connect to the hub.

Tim does have a valid point that sticking with one protocol will make the mesh over all more robust, it does mean you limit yourself slightly as well when it comes to looking for new devices to add.

Once you move beyond locally controlled devices to things that are cloud-to-cloud you do open yourself up to lots of additional possible issues. This is frustrating of course, but also somewhat understandable. The more complex any system is there more room there is for problems to occur.

I personally try to limit the number of cloud-to-cloud setups that I run because I don’t want to worry about the added complexity AND for me (again personal preference) most of those devices are not ones that I see a significant benefit to over more local devices.

Note that this doesn’t excuse ST from stability problems or say that it’s okay or we should just accept that there are and always will be problems. No… ST needs to be more stable and get a solid backbone. But the reality is that it isn’t there yet and I can reduce my headaches by keeping things as non-complex as possible until ST gets there.

1 Like
4

As long as The mesh for each is strong, it shouldn’t make any difference.

(Unless Slagle as a SmartThings employee is trying to give us A subtle hint that there are flaws in the SmartThings architecture to recommend using only one at a time, which would be weird since the whole market proposition for SmartThings is that it supports multiple. But who knows?)

The SmartThings hub is one plastic box that includes multiple radios. Everybody’s using at least two networks: ethernet to reach the SmartThings cloud and some device manager.

The Zigbee Coordinator and the Z wave controller inside the plastic box are independent of each other. So you’re really running two separate networks there. Each of which is communicating with your single SmartThings account for information.

The typical range inside a US Home for a single device is about 40 feet for one “hop.” It’s somewhat further for zwave plus devices. But because zwave and Zigbee are both mesh networks, the devices will automatically relay the messages along so that they can reach devices further away. Z wave allows up to 4 hops between the hub and the recipient of the final message. Zigbee can allow for more hops.

So if you place a SmartThings hub in the center of the home, it typically can cover an entire floor easily, and, because the signal is 360°, can usually cover two floors and the basement with 4 hops. But it all depends on the local architecture. If you have a lot of cement, tinted glass, brick, certain kinds of insulation, metallic wallpaper, water pipe based heating in the walls, etc. the signal may not go as far.

When people say “the mesh is strong” they mean you have a lot of devices of the same protocol fairly close together, so it’s easy to relay messages around.

But you can certainly have a strong zigbee mesh and a strong Z wave mesh in the same home. These two protocols do not overlap, and so they rarely interfere with each other.

If you have 17 Z wave devices on the first floor, one zigbee sensor on the second floor, and the SmartThings hub in the basement, the zigbee sensor might have problems getting its messages. But it probably just needs a friend also using zigbee on the first floor to get the messages through.

I used to be a network engineer. I chose SmartThings, as many other people did, precisely because it did offer multiple protocols so I could select each device based on the best device for that location and need. But I did check to make sure that each device has a good relay path back to the hub. :sunglasses:

More here:

http://thingsthataresmart.wiki/index.php?title=Z-wave_versus_Zigbee

2 Likes
5

I respectfully disagree with @slagle. You can run both without issues… in theory. Commiting to one protocol may limit your device options greatly. Most of the devices out there are Z-wave. Not so many are Zigbee. In my opinion, and I am not a network engineer or anything of the sorts, Zigbee works more reliably and faster. Again, this is what I have noticed in my setting and it may not apply for everyone else. BUT, there aren’t many Zigbee light switches out there, for instance. So I run Z-wave and Lutron in my house as well.

BUT, if you are getting a suggestion from a SmartThings employee, then maybe you should consider that and maybe you won’t have many issues with your setup. Just a guess, of course.

2 Likes
6

Everyone will forever debate this. It is the Apple Vs. Google of IoT… Who’s right? probably no one lol

7

Super helpful info and great explanations all around! This definitely helped me understand the two a bit more and hearing that Rodolfo has experienced slightly better communication with Zigbee is also interesting. I understand that it’s likely YMMV, but helpful to know nonetheless.

I’m assuming by strong mesh you’re meaning somewhat less than the 40 feet you mentioned? We don’t have a very large apartment anyway, though, so I doubt I’ll run into it.

The examples given for how to manage the networks so that each could receive messages was great. Same for the information about the limit on how far a Z-Wave will relay a message. My brain must be warped as I’m immediately wondering what happens when it’s more? Does the message not go though? Can Z-Wave reroute the message to only go through 4?it would be easy to have several devices close together that it could try to route through and fail because it reached the limit before I delivered the message. Or so goes the imaginings in my head…

I’ll have to read more about the cloud-to-cloud devices. I don’t know if I know of any or if I do, then I didn’t realize that’s the way they work. I’m assuming what was described is different from other (generally non ST compatible) devices that would use IFTTT as a sort of cloud-to-cloud communication pathway. Non local devices does indeed sound challenging!

OK, I’ll be very circumspect as I plan my add-on devices now that I understand things better. I’ll look for the product performance quality first and the protocol a close second. If I can keep as much as possible on one protocol, I will or I’ll be sure that they both have good coverage now that I get the importance of that more clearly. At the same time, I got a renewed perspective that I chose ST over other solutions precisely so I wouldn’t be too confined by a single protocol. I just want to make good choices on things for as decent a setup as I’m able.

1 Like
8

Both Zigbee and Zwave are smart enough to not use up hops unnecessarily.

The following text is the equivalent of sketching a picture example. Don’t take it too literally, but it will illustrate the point. :sunglasses:

Say the network is trying to get a message from the kitchen to the bedroom and the living room is in between, and there are 5 devices in the living room, the message will generally go as far as it can on one hop each time.

So if it can reach, it would go all the way from the kitchen to the bedroom in one hop, bypassing the living room devices all together.

If it can’t reach the bedroom, it will generally pick the device closest to the edge of its range for that first hop.

So you don’t use up hops just because you’ve added more devices in the living room. In fact, you’ve made the mesh stronger because there are more candidates.

(The above description is not 100% technically accurate, so don’t quote it as gospel, but hopefully it gives you the idea. The main point is what’s important: you don’t use up hops just because there are more devices in the room.)

So you don’t have to worry too much about the exact path messages might take. In fact that’s one of the advantages of mesh. You just have to know that there’s some path that can bounce the signal to where it needs to go.

This is also why you see so many recommendations to put the hub in the center of the home.

9

“Cloud to cloud” means “I talk to the Internet, you talk to the Internet, let’s use the Internet to talk to each other.”

The SmartThings hub uses the Internet to talk to the SmartThings server that hosts your account. It doesn’t matter whether that server is in Minneapolis or Miami, the hub just has to get the message to your internet router and it’s on it’s way.

Once the message gets to the ST server, it in turn could use the Internet to pass messages to some other server somewhere else. It doesn’t have to be exactly the same message the hub sent in. In fact that’s the “cloud” part–the hub in your apartment doesn’t have to know all the details of talking to the other server; it can leave that up to the more powerful computer that hosts your SmartThings account.

Close the Blind: Step 1. ST Hub to ST Cloud

This is how you could use SmartThings to control a Lutron Serena motorized blind, for example.

You’d have two control devices in your apartment: the SmartThings hub and the Lutron SmartBridge. Both connected to your Internet router. But neither talking directly to the other.

Instead, The SmartThings hub would use the Internet to send a message to your SmartThings account on the SmartThings server, “Close the living room blinds.”

Step 2. ST Cloud to Lutron Cloud

The ST Server would reformat that message as needed and send a request over the Internet to the Lutron server, which could be in Seattle or Chicago or wherever, that your account wants to close the living room blind.

Step 3. Lutron Cloud to Lutron SmartBridge

The Lutron server with then again reformat as needed and send a message over the Internet to the Lutron smartbridge in your apartment to close that particular blind.

Step 4. Lutron SmartBridge to blind

The smartbridge in your apartment would then issue the actual close command to the blind device .

That’s cloud to cloud. The whole thing might only take a few seconds, or if there is lag anywhere it could take a minute or two.

It’s cloud to cloud instead of just a regular Internet message because there is processing that gets done on each of the servers. The SmartThings hub doesn’t just format a “close blind” message that the Lutron blind device would understand and pass that along. It doesn’t actually have to know the format of the final message at all. It just has to ask its server to ask the Lutron server to send the correct “close blind” message.

As to why the SmartThings hub and the Lutron SmartBridge can’t just talk to each other directly given that they live in the same apartment, sometimes they’re not smart enough to (they’re both small inexpensive devices), sometimes it’s a matter of security, sometimes it’s just the way the architecture is designed. By going to their clouds, each potentially has to ability to talk to many different systems.

But obviously going cloud to cloud does introduce some inefficiencies. So it’s a trade-off.

IFTTT

IFTTT is a service that allows a company that has an IFTTT channel to pass messages to any other company that has an IFTTT channel as a way of standardizing the kind of cloud to cloud communication that is step two above. So that makes it technically cloud to cloud to cloud, but no one calls it that. IFTTT just becomes the way that one of these clouds formats the messages for another one.

It means that each company doesn’t have to keep track of 100 different message formats. It just creates an IFTTT message that gets passed over to the other cloud which then presumably knows what to do with it. The more companies participating, the more money each saves in not having to develop individual integrations. And the more options there are for the end users.

Again, you’ve introduced a little more inefficiency, so again it’s a trade-off. This is why companies do continue to create custom integrations for their most popular cloud to cloud partners, like the one between SmartThings and harmony, rather than only using IFTTT each time.

1 Like
10

Thank you so much for the wealth of information! I’m learning so much and I love that. Your examples really helped me understand what you were explaining and took a very abstract concept and made it tangible.

One question based on a couple of things you mentioned…where does the Philips Hue line fall in terms of being local or cloud-to-cloud? I realize that it has a bridge as your mentioned the Lutron does so from that example could be cloud based. But it’s also fairly popular, has an API I believe and many direct integrations so I could also see its being local. Adding to the fact that the ST hub speaks Zigbee, it increases my curiosity as to which type of communication it uses.

11

I don’t own Hue lights, but I know @smart does or used to. Maybe he can give you some advice.

This is a long thread, but go to the latest posts and maybe you’ll find some help with this.

1 Like
12

A Hue bulb uses Zigbee.

The hue bridge uses zigbee to talk to the bulbs, and uses an ethernet connection so it can also talk to your local area network as well as to the hue cloud over the Internet.

When bulbs are connected to the Hue bridge, they form their own mini network which uses the zigbee light link profile.

It is also possible to connect an individual hue bulb directly to the SmartThings hub using the zigbee home automation profile. However, this method is not recommended by SmartThings support and most people don’t do it.

Instead, for all the reasons you gave, SmartThings has provided a custom local integration between the SmartThings hub and the Phillips hue bridge. So the SmartThings hub talks to the Phillips hue bridge over the local network, and then the hue bridge controls the individual bulbs.

The hue bridge can also still use all of its regular capabilities including cloud to cloud to other services.

Note that even though this is a local integration, smartapps using Phillips bulbs will not necessarily run locally. Technically they should be able to, but there’s something in the implemented integration that appears to require checking in with the SmartThings cloud first.

1 Like
13

I would love ro help as a user basis but the doctor and missus has tied me to the bed and I do sneak in some posts here and more on Twitter site. I do apologize! Should be ok in a few days. :frowning:

1 Like
14

There is only 1 reason why I am using my Hue bulbs with the bridge instead of without (which would free up a network port on my switch) and that is my Hue Tap.

The Hue Tap is Zigbee Green Power and won’t work with ST (or anything other than the Hue hub that I am aware of).
I love the ability to just slap the Hue Tap’s big button to power off almost all my lights (have it set to power off 6 of 7, including the bathroom 3 which is when it’s generally used) as I walk down the hallway.

Sure, I can voice control with Echo, but this is quicker and it’s on the wall as I walk by.

1 Like