New to SmartThings should I avoid Wifi devices over alternative Z Wave or Zigbee devices?

I haven’t purchased a home automation system yet but my research has me choosing SmartThings. I understand the goal of ST is to integrate all connected devices but are there any benefits to choosing Z Wave vs. Zigbee vs Wifi devices?

It seems to me that there aren’t many complaints about z wave and zigbee devices but there are many complaints about waiting around/hoping for support for Wifi devices.

Should I strategically avoid certain Wifi Device if there’s a Z wave or Zigbee alternative?

To be more specific, my dilemma is regarding a connected thermostat and a connected garage door opener. Lift master sells a wifi module for my garage door (I’ve read claims that there are delays in communicating with the SmartThings hub) . Alternatively I could choose a z wave device to signal the garage door to open/close and use additional sensors to report garage door status. What method is more reliable, Z wave or Wifi? Why?

Ecobee3 looks like a great thermostat, I like the appearance and the extra features it offers and its exciting to see its also supported by SmartThings. My main goal is to trigger thermostat status to change from Home to Away mode when my alarm gets set to Away. The Ecobee3’s extra features and price tag would not be worth it if it didn’t operate flawlessly with smart things. With exception to appearance and a few extra features, does thie Ecobee3 really offer much more than a simple Z wave thermostat while integrated into SmartThings?

My main focus is efficency and reliability. How do all these different types of devices compare? I don’t have any home automation equipment and i would like to build a reliable and maintenance free system. I’d also appreciate it if you could chime in with recommendations for a connected thermostat or garage door opener

1 Like

I have ecobee Smart Si thermostats, which are WiFi like the 3.
Despite the great and extensive driver and app code by @yvesracine, they are simply a PIA to integrate.
Meaning ST and the thermostats schedule will fight each other.
I do have this working the way you want, but in essence you end up not using any scheduling that’s setup on the tstat, and let ST control all aspects of the scheduling.
If I had to do it over again, I would get a zwave tstat, and the dumbest one possible, since ST will be controlling it directly anyway.
RE garage door, I plan on going the arduino/st shield route. I have an arduino that controls a dropdown TV lift I built, and it works flawlessly.

Don’t go for WeMo’s that’s for sure. Mine are a mess with ST. I would stick to Zigbee / Z-Wave personally.
Get 3rd party ones if your worried about changing platforms, like Aeon Labs.

First, let’s be clear: nothing works “flawlessly” with SmartThings yet. Not even devices sold on the SmartThings site or in a SmartThings branded box. That’s because ST itself is still in a growing pains phase.

That doesn’t mean I don’t like it. I do. I am quadriparetic, use a wheelchair with limited hand function. ST solves several important convenience use cases for me, and for the money I spent it’s been a very good value. But on a good week, it works about 85% of the time, and on a bad week, like the last one, it’s about 50%.

Because I only use it for convenience cases, a failure isn’t terrible. If 9 lights out of 10 go on, or my door doesn’t unlock, or 2 buttons on a 4 button remote stop working, or a “sunset” trigger fires an hour early (all things from the last week), it’s annoying, but not tragic.

ST announced a 2nd generation hub in January, but it hasn’t been released for sale yet. My guess is that it will solve a significant number of problems, but still not all. And I’m sure it will introduce some new ones.

My personal guess (and it’s purely a guess) is that by summer 2017 we’ll see several very strong contenders in the reliable inexpensive home automation market. I expect Apple’s HomeKit/insteon to be one. And I do expect SmartThings/Samsung to be another.

But for March 2015, “flawlessly” isn’t on the market for any system costing less than $10,000. (And even those are really in the “almost perfect” category.)

And SmartThings, as one of the most innovative open platform designs with very rapid growth is certainly not the most reliable of the inexpensive group. Fun, interesting, amazing support team,terrific community, ambitious: it’s a leader in all of those. But the growing pains are real.

“All home automation is local.” What I want the system to do, the level of reliability I require,and what works at my house will be different from you.

If you really hope for “flawlessly,” or at least close to it, in a system that costs under $5,000 now, I would look at Staples Connect. You will have many fewer device choices and typical big box store support, but their target market was small business owners and they made reliability a first stage priority over openness or innovation. They don’t get written up much because they aren’t trying to support all the hottest new gadgets. And they aren’t doing much publicity. But it’s a solid, if stodgy, solution for a number of simple use cases. The only thermostat they support is Honeywell. Not as snazzy as the Ecobee. But I would expect it to work out of the box with Staples with high reliability.



Now to the protocol question. :blush: My college major was Computer Information Systems and I went on to work for IBM until the wheelchair-thing. My first commercial install was in a nuclear power plant. So I’m very interested in network protocols, and had worked with all of the ones you mentioned before ever starting with home automation.

As with many things, the choice for any individual device comes down to how you specifically want to use it.


Zigbee and Zwave were both designed for “mesh” networks where there would be a lot of mostly dumb, mostly cheap, often battery powered devices where any given device might be occasionally unavailable, if only to have its batteries changed.

In a mesh network, the hub doesn’t panic if a device is unavailable. Every device is allowed to choose from several alternate pathways. Messages can passed around the network, neighbor to neighbor, until they reach their destination. If a neighbor is unavailable, you try again with another. Many messages get resent a couple of times.

This design keeps the network “resilient” (one node going down is no big deal). It keeps energy use low, which means batteries last longer. It keeps device costs way down.


But there are two things it doesn’t do well. First, there’s no way to guarantee the exact sequencing of action requests because they tend to bounce around the network for awhile. You can turn on several lights at about the same time, but you can’t guarantee which will arrive first. In a roomful of lights this can lead to a “popcorn” effect when changing state. For the same reason it’s pretty bad at video or audio streaming because it’s possible for packets to arrive out of order.

Second, it’s really intended for deployment where it’s ok if you only force check device status no more than once every 15 minutes or so for plugged in devices, and once a day for battery powered ones. The devices will still tell the hub when they know something happens, like an open/close sensor detecting a window opened. That’s no problem. But the hub shouldn’t be sending, “hey, buddy, you awake?” Messages (polling) to devices on a mesh network very often, or you increase power draw and network traffic considerably. Nothing kills a mesh network faster than excessive polling.

This is all true whether you’re using SmartThings or any other brand of zigbee/zwave controller. For example Philips Hue does not let their Hue Bridge force poll all the bulbs (which are zigbee) at once. It does a few at a time in the background. Their assumption is that whether you’re turning lights on or off, it’s ok if it takes the bridge a few minutes to update the bulb status because the human can see if they’re on or off. It’s more important for the rest of the bulbs to still work even if you happen to be changing one. So mesh.

But you don’t choose mesh if you absolutely must have things happen in an exact sequence, or if you must know the exact status of the device at all times.

Mesh networks are intended to carry small packets for short distances at a low cost in energy and dollars, and to be able to deliver messages even when some individual devices are temporarily unavailable. That fits a lot of residential home automation use cases.


Zwave and Zigbee are pretty similar for most purposes. There are a few specific reasons you might choose one over the other for a given device.

A) zigbee is the same all over the world, although different regions may set different restrictions on the amount of broadcast power an individual device can produce. Zwave works at different frequencies in different countries. As of October 2015, the ST hub is sold in two models,one for the US/Canada/Mexico frequency and one for the EU frequency.

B) zigbee works somewhat better through rain than Zwave due to its use of DSSS. Almost all outdoor sensors will be zigbee. That includes utility company-provided smart meters. So you do also see zigbee on some indoor devices that are intended to communicate directly with outdoor devices, like energy monitors and some thermostats.

C) cordless phones and WiFi can interfere with zigbee. Baby monitors and intercoms can interfere with Zwave. The WiFi thing is why most devices other than sensors and lightbulbs sold for indoor home automation use are zwave. (You can reduce the likelihood of zigbee and Wifi causing interference for each other, but it requires smarter, and consequently more expensive, equipment.)

D) zwave devices are less likely to use manufacturer-proprietary encoding than zigbee, which means zwave devices from different brands are more likely to work together well.

E) the exception to D) above is lightbulbs. The Zigbee Light Link standard (ZLL) was intentionally designed for interoperability among different brands. (It helps that even the smartest smart bulb is pretty stupid and only does a few things: dim, change color, change color temperature.) For some highly technical reasons, and because zigbee antennas are smaller than zwave antennas, zigbee is usually the best choice for light bulbs.

F) zigbee usually gives a little better battery life, so is often chosen for physically small devices like little sensors.

G) zwave is limited to about 230 devices per networks while zigbee can handle tens of thousands. And zwave allows a maximum of 4 hops for one message, while zigbee home automation allows up to 30 (15 in to the hub and 15 out again.). For large sensor nets such as may be used in hospitals or hotels or commercial buildings, zigbee is typically used.

H) zigbee antennas are smaller than zwave antennas. So very small devices are usually zigbee. However, the newest generation of zwave, zwave plus, is somewhat smaller than previous zwave generations.

So in a residential installation usually tiny sensors, light bulbs, and outdoor devices are often Zigbee, and everything else indoors that’s mesh is Zwave. But if there are features on a particular device that appeal to you, you’re usually fine going either way.


WiFi is typically deployed in a “star” network, meaning every device talks directly to the central hub.

That’s great for keeping track of the status of every device.

It’s excellent for forcing packet sequence.

But it also means every device uses a lot more power than in a mesh network. The original Lockitron, for example, had to be withdrawn from the market because it turned out the reason no one else was doing a WiFi doorlock was that battery life was terrible. No surprise. (Their second generation took the WiFi transmitter out of the doorlock and used Bluetooth instead.)

WiFi in residential installations also tends to go on and off fairly often.

And a star network requires that each individual device have an IP address, limiting the total number of devices in the home.

And all the WiFi devices are competing with each other for the same bandwidth, so your Xbox and your garage door opener might be interrupting each other.

The reason Belkin’s WeMo didn’t just own the home automation market is because of all of the above. Read the Amazon reviews of WeMo and you’ll see complaints about switches going offline every few weeks and then having to be reinstalled each time. That’s a lack of resiliency.

You can make a star or tree network very robust, but it requires spending more money and rigidly controlling scheduling, something that doesn’t fit most home automation scenarios.

On the other hand, wifi is perfect for audio or video streaming. It’s also good for forced sequencing.


Some more expensive devices may use zigbee or zwave as their main communication protocol, but are also “wifi enabled” so they can send some notifications via the Internet or maybe work with IFTTT. Sometimes that gives you some of the benefits of both protocols, sometimes it’s the worst of both. You just have to look at the details.


not to go into too much detail, but point to point, as in regular bluetooth or RFID tags, is low energy, and allows forced sequencing. The negative is very short range, reliably around 30 feet. Apple’s HomeKit will use Bluetooth, but not a lot of device details yet.

Thread is the protocol used by Nest. Like zwave, it can only handle about 250 devices per network. The Zigbee alliance and the Thread group have a cooperative agreement which recognizes the strengths of both.

Bluetooth mesh was just approved a few months ago as a standard. It will have the usual advantages and disadvantages of mesh.

The ST version2 hub has a Bluetooth antenna, but It’s not turned on yet.


For indoor use where you’re OK with things happening at about the same time but not necessarily in a specific order, right now certified zwave is probably the simplest choice. It won’t run into wifi interference, it has a high degree of interoperability among different brands, good battery life. Just don’t add extra polling.

For outdoor use, tiny sensors where battery life is critical, things that have to talk to an outdoor smart meter, and light bulbs, consider zigbee.

For devices that stream audio or video, or where you have to force sequencing, or where you want more frequent status updates, consider wifi.

For devices that need near perfect constant status monitoring, use cellular. Or hardwire for local monitors. But neither of those work with ST. (These would typically be medical monitoring or expensive commercial alarm systems.)


At my house my SmartThings installation uses zigbee smart bulbs and a couple of sensors, and everything else zwave including the light switches. I have a separate wifi installation for the usual entertainment stuff. A cellular panic button for medical emergencies. And a separate nonST commercially monitored alarm system. But I’d certainly consider zigbee or Bluetooth or whatever for any individual device that had specific features I wanted.

I know a lot of people want to mix security and home automation under one controller. Because cost is a big issue for me, I use cheaper mesh networks for home automation and pay more for a separate security system. As a quad, I need to know the emergency monitoring stuff is very high reliability and I’m willing to pay more for that.

So again, it all comes down to your particular needs. Just because one protocol is typically better than another for a common use case doesn’t mean it will be the best choice for you. :blush:


Hi @kenny_Powerrs,

Here is my take on your question about WiFi thermostats such as ecobee3.

On my side, I have a z-wave thermostat (CT30) for a gaz fireplace and an ecobee Smart for my HVAC.

My z-wave thermostat is totally controlled by ST, I only use it to start my fireplace in the evenings when the outdoor temperature is quite cold.

Otherwise, my experience with a z-wave thermostat is the following: very slow UI response and very often no response at all. Why z-wave thermostats are not responsive? It could be an ST issue or simply a z-wave thermostat issue. The fact of the matter is that z-wave thermostats are just plain dumb and they only work for specific use cases. As soon as they are connected to a home automation like ST, you cannot program them.

On the other end, smart WiFi thermostats are more versatile and responsive. You can use them on a day to day basis by changing their setpoints via the UI w/o problems. You can also use their own scheduling capabilities to set your home/away/sleep schedule in general and then use ST to change their program on the fly when your schedule changes (ex. you’re away at a given time when you’re normally home according to the ecobee schedule)…

On more thing about the ecobee3, soon you’ll be able to integrate its remote sensors to ST as motion/temperature sensors thru the custom ecobee device that I created. This way you don’t need to buy additional sensors for your bedrooms for example.

For more details, please refer to the following thread. There are many smartapps that I have developed for the ecobee thermostats.

To conclude, there should not be any conflicts between ecobee and ST if you let each platform do what it does the best: ecobee owns the general thermostat schedule and ST manages the exceptions when you’re away or home (according to its hello home modes) and ecobee does not expect it

In brief, if your main factors are reliability and efficiency, then don’t hesitate to choose an ecobee thermostat over a z-wave thermostat. Most WiFi networks are very reliable now, and this issue should not be part of your decision making process.

If you have any other questions, let me know.

P. S. I created the custom ecobee device so that it works flawlessly with ST for my own home, and exploits all the richness of the Ecobee APIs.

Thanks for all the feedback and valuable information.

Do you have any idea when the new Samsung SmartThings hub will be released? I’m fascinated by some of the new Bluetooth devices being developed (TiltMyBlinds). It’s interesting to think they could be incorporated into SmartThings in the future. I might end up waiting for the new release if it’s only a year or so away…

In the meantime I’m going to get an Ecobee3 thermostat. I’m getting an offseason deal on an air conditioning install and they’re selling these thermostats well below retail. I just needed to get a feel for how well these work with Home Automaton before deciding.


Awesome explanation on the protocol choice for various use cases! Really helps in zeroing in on what I want.

Thanks so much for your concisely written explanation. You’ve answered virtually every question I had, and a few I hadn’t thought about. I’m taking a big step from 20 years of X10 switches (failing weekly) to ZigBee/zwave and am hoping I can do it seamlessly with the Smartthings hub. I also started down the NEST path with their thermostat/smoke detector, in conjunction with the Rachio sprinkler controller (and a Big Ass Fan is on the way).

I’m jealous - 20 characters

1 Like

I know this is an older post, but as a newbie I would like to say thank you for such a comprehensive explanation of the different protocols. I think it should become a faq or sticky because it answers so many questions I am sure many people have.

Smart things documentation is too dumb for me - I got the ST kit and the leaflets about each sensor don’t have any technical info just the regulatory guff about various EU directives, recycling, don’t eat it, etc. Eg the multi sensor has about 20 pages in the user guide. All it essentially tells you is to pull the plastic strip out to start using it, and press the connect button to reset. Nothing about what it actually does even.

Very useful to know for example that if I am on holiday in US there is no point buying a z-wave device in Walmart as it won’t work back at home in the uk, but a zig bee will.

I wouldnt buy ANY of this stuff right now, its just a huge mess, pre-standardization. I’ve used X-10 (i prefer this), zigbee and am stuck supporting my friend/family/neighbors crappy alexa/google integrations, and with that space, it is such a mess i cant believe it.

Its all just a waste of time. Unless you have a very specific need or handicap i would wait it out until a true open standard is ratified and gains traction. 5 years ago nobody would have anticipated that Amazon Echo or Google Home would be a key factor in home automation but now, since it made it so easy for people to create crappy installations i guarentee a standard is going to be built around wifi , with standard messaging and command protocols that center around these devices. This is an application standarization issue. The future 802.11 standards are just ridiculously awesome and makes sense to use that as a transport.

sh!t. I had no idea how old this thread was lol. please ignore.

1 Like

2019 Update:

Everything in my post above is still accurate except that we are now up to V3 of the smartthings hub (still with reliability issues, though), and staples discontinued the connective line.

Oh, and the Amazon echo has become a much bigger player for those just looking for something simple.

The following 2018 FAQ explains why someone might choose smartthings over some of the competition: