Which lock to get? Z-Wave vs Zigbee vs Thread

Wiki Projects & Stories
1

Hello,

I’m looking at getting a smart lock that will integrate into home automation devices such as SmartThings and maybe Amazon Echo.

I’m most interested in the new Danalock V2 which adds a few options that aren’t available on other smart locks - namely either Z-Wave or true Thread/Nest Zigbee compatibility. However, I do have to choose between the two technologies and I’m not sure which one is going to be the best option at this point. I’ve yet to fully commit to a home automation hub or specific technology and at this point only have Philips Hue V1. I hope to add several things over time including video monitoring, WiFi plugs, multi temperature/motion sensors, water sensors, smart thermostat (prob Nest, though unsure), smart window A/C controls, and other stuff. My question is, with the Thread/Nest/Zigbee protocol being finalized now and with new item coming from that, would you recommend going with Z-Wave or Zigbee (it’s the full Thread/Nest protocol)? I honestly don’t know what the advantages or disadvantages would be between the two and I really trust this community when it comes to knowledge and understanding things like this. Could you please give your thoughts of which of these would be the best to go with and why? I want to learn and understand the reasons each protocol is different/better/worse than the other.

Thanks so much! Looking forward to hearing your thoughts. :smile:

2

You’re actually talking about four different protocols here.

Z wave

Zigbee

Thread for nest

Thread from the thread group (A cousin to the older thread for nest, but not identical)

Zigbee and the two threads run in the same frequency brand band but are not the same protocol.

Thread for Nest

If you want a lock that can function in the nest ecosystem, in particular that can be triggered by nest presence, you kind of have to go with a “works with nest” lock, which means thread for nest.

Thread from the Thread Group

Thread from the thread group is still in development, the developer docs were just very recently released, there are no devices that work with it yet, so frankly I would just set that one aside for now. It will be important starting in summer 2016, but not for anything you can buy before then. Samsung is a founding member of the thread group, and the SmartThings hub is “thread capable” but that capability is not turned on yet and it will require probably both a software or firmware update. I wouldn’t expect to see it anytime soon.

Zwave and Zigbee

If you want a lock that currently works well with SmartThings, you’re going to go with either zwave or Zigbee.

Here’s the FAQ on Z wave versus Zigbee, but it’s mostly a matter of personal choice.

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

The currently available Danalock V2 doesn’t have thread for Nest support, but rather offers a fifth protocol, Bluetooth. A new model has been announced for the end of this month, but you can’t buy it yet. (It just says “thread” but that would have to be thread for nest as the other thread is not yet deployable and they announced that it would work with nest in the same press release.)

https://danalock.com/?page_id=35

Nest does not yet list it as a partner:

The WiFi Problem at Your Front Door

The biggest issue for many locks is that boosted Wi-Fi can interfere with Zigbee, and obviously when it’s a doorlock you can’t just move the device 4 feet to the left to try and avoid interference. So Zwave locks have been more popular just because they’re less likely to run into the problem. ( wi-Fi does not interfere with Z wave.)

If you want to add a Wi-Fi camera, including a Wi-Fi doorbell, then I would generally think a zwave lock would make more sense unless you’re going to buy both devices from one brand which are designed to work together. Because otherwise you run into the problem that boosting the signal for the Wi-Fi video, which almost everybody ends up doing, interferes with the zigbee lock communications.

Specific Lock Brands

As far as Danalock, read the reviews. It tends to be the lowest rated of any of the locks.

Yale and Schlage are more popular in the community except for those looking for budget locks, and then Kwikset is popular.

All three work well with SmartThings for basic open and close operation. I don’t believe the official device types for any of the three support things like setting custom codes. But there is community-created code that can do that.

Your Project

So I guess the first question is do you want something you can buy in the next month or so? Or are you willing to wait until next summer? Or do you want to buy something you can use now with the thought that you may eventually replace it?

Long-term, I do think thread from the thread group is going to be very important in home automation. It’s just we’re nowhere near seeing actual devices for it yet.

1 Like
3

Thanks so much for your info. I had forgotten about the Thread fragmentation. It’s specifically Thread for Nest and Zigbee compatible… Or will be when released in the next few weeks.

Unfortunately, I’m somewhat more limited as to what smart locks I can use due to the fact that I still have to be able to use my existing deadbolt and key. So August Lock, Okidokeys, Danalock, or Lockitron are the type of lock I’m stuck with at this point. August makes lots of promises which they rarely deliver on and have a strong partnership with Apple to the severe detriment of Android development. Long promised basic functionality of basic smart lock features such as auto unlock are still nowhere to be seen more than a year later. Okidokeys had issues bringing out their internet bridge and no real integration with hubs, etc though some have apparently shown interest in developing using their API. I wouldn’t consider the Danalock except that it sounds like many of the issues going on with the first generation locks have been improved upon with lots of new features and options. Obviously I will only purchase through a retailer with a decent return policy as I’m not willing to deal with crummy systems. I know the V2 Z-Wave Danalock is already available with the Nest/Zigbee version coming out in a few weeks. I just wondered which one is generally better supported and easiest to integrate.

Of course all the locks do have Bluetooth as well, you’re quite right. I just didn’t mention it as I was highlighting things that I thought were different from most other smart locks and Bluetooth generally seems to be the protocol of choice for those types of locks. I’ll definitely read through the link you posted to try to understand more about the two protocols.

Any other thoughts on the benefits and differences between Z-Wave and Zigbee/Nest? Please share. Thanks so much.

4

I’ve been doing some research on this and would like to add the following:

“Thread for Nest” is called Nest Weave.

“Thread for Nest” is not an accurate description because Nest Weave is an application that sits on top of Thread.

The Thread group (developer of Thread) and Nest are both affiliated with Google. Also Nest is part of the Thread group.

Thread is and will be a big deal. In fact ZigBee 3.0, is essentially “ZigBee over Thread” a move inspired by projections of lost market share to Thread.

5

I don’t know the specifics of the Thread/Nest/ZigBee compatibility other than bits and pieces of what I could glean from press releases, web info and of course, the incredibly knowledgeable folks in this community. I know details were somewhat unclear when I was reading about it last year and I figured more would become clear asvit gets closer to actual market release which should be now based on the projections I read in November. When I said Thread for Nest I wasn’t meaning to denote anything other than the Thread specification for the Nest system vs the Thread specification for Google which Google released information on earlier last year that they would be forked/split/fragmented/different.It was extremely unclear how much they would be compatible and the inference that most people drew was that the wouldn’t be. Thus makes little sense however so maybe this will change. This seems to be a ZigBee type protocol though not exactly and I’ve never been clear on what will be compatible and what won’t. My understanding was that ZigBee would somehow be compatible with one or both protocols butbi basically decided to quit trying to figure it out until more information is available and people with more knowledge and expertise in the area could elaborate. I totally agree that Thread will be a big deal. I’ve always thought that. Just because it’s backed by Google means it’s going to have marketshare and even more so with the other members including Samsung (which obviously has implications for ST). I was specifically referring with my comment to a thread I had followed here on ST that talked about the Thread fragmentation as it was understood from what Google had released middle of 2015. In my original question, I forgot about the unknowns of the differing compatibility and the variables that had been discussed last year.

Please feel free to share anything else you find. I do believe it will have an effect on the HA segment and I’ve known that for awhile. It’s something I’ve kept in mind when looking at what else I need to purchase for my system and why I’ve bided my time on some purchases to see what pans out early this year. Again, please share what you find as we’re interested in seeing where Thread goes. I was just trying to clarify what was in my head with that particular reply. I wss not trying to set up names for protocols but differentiate it from the other variants that were discussed by smarter people than me. :slight_smile:

6

Old thread here but checking if anyone knows whether or not the Z-Wave and Zigbee protocols treats locks the same. I didn’t know if “lock” “unlock” “alarm” etc states were part of the Z-Wave/Zigbee protocols or if those states were some IoT standard for locks.

7

Also this is a really great writeup http://www.electronicdesign.com/communications/what-s-difference-between-zigbee-and-z-wave

8

It was a good article when it was written five years ago, but at this point it’s pretty out of date. For example, it talks about the range as they were five years ago, obviously, and now both protocols have significantly extended range.

In addition, three years ago zigbee made the decision that Zigbee 3.0 would combine many of the profiles for greater interoperability. So the whole design philosophy has changed in that time. There are only a few 3.0 devices released as yet, but the future is going to be very different than it looked like in 2012. :sunglasses:

http://www.zigbee.org/zigbee-for-developers/zigbee-3-0/

If you’re interested in more current references, IEEE has a lot of good stuff. If you just want to look at how some of the issues apply to smartthings, see the community – created wiki:

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

9

There isn’t any universal IOT standard at the present time. Zigbee and zwave are just two different network protocols. They do some things the same, they do some things differently.

If you were asking specifically within the context of the smartthings platform, smartthings puts an abstraction layer above the underlying protocols, so the smartthings smartapp commands work essentially the same. They certainly are not differentiated between zigbee and Z wave except in the device type handlers where they have to be. But smartthings introduces the concept of “capabilities” and those try to present the same way regardless of the underlying protocol.

Have you had a chance to look at the developer documentation yet? You can reach it from the link at the top right of the first page of this forum. It explains a lot of these concepts.

http://docs.smartthings.com/en/latest/

@tgauchat or one of the other coding experts could probably explain a lot more, but I suggest you start a new topic in the developer section of the form if you do want to discuss the smartthings abstraction layer. :sunglasses:

https://community.smartthings.com/c/developers

2 Likes
12

Sweet that’s exactly what I was looking for. I couldn’t English properly and forgot the word abstraction hahaha.

I was wondering where the layer of abstraction was and those docs will probably help. I probably should go through one of the DTH’s to see for myself but… I’m curious, when someone is creating a DTH for a Schlage lock, are they creating a layer of abstraction between SmartThings and Schlage’s own api? This would help answer if Schlage themselves have their own set of functions.

I’ll take a look through the docs in the meantime, but super thanks for the response.

Okay I’ll read through both. I might dig through some IEEE… it’s been years since I’ve had to even think about them.

1 Like
13

The programmer doesn’t have to write their own abstraction.

All certified Z wave devices use the standard Z wave commandsets.

All certified ZHA (zigbee home automation profile) Devices use the standard zigbee clusters.

Smartthings offers its own abstraction layer.

So the programmer writes smartthings code to send the appropriate information using the standardized protocol For that specific device.

It means you do have to know whether it’s a zigbee device or a Z wave device when you write the device type handler, but you don’t have to know much more than that in most cases.

Again, the developer docs will explain most of this and you can ask additional questions in the developer section of the forum. :sunglasses:

Here’s a discussion from that section of the forum from someone who is not a programmer and was writing theIr first device type handler.

1 Like
14

Yes and no.

If Schlage is just implementing a “Z-Wave Lock” (i.e., an existing standard in the Z-Wave universe), then a SmartThings DTH for any compliant Z-Wave Lock should work. However, most manufacturers add on extra functionality and/or do not implement the Z-Wave (or ZigBee) standard with 100% compliance.

So SmartThings’s “Capability Model” is often called a “redundant” abstraction; but that’s not giving it enough credit - nor enough blame sometimes.

Capabilities enable Locks to be presented to automations (or GUIs like ActionTiles) in a consistent fashion, not only regardless of manufacturer and model, but also regardless of protocol: ZigBee, Z-Wave, IP, Bluetooth, 433Mhz, IR, RFID, or carrier pigeon: As long as those protocols and APIs are sufficient to compliantly and comprehensively implement the Capability.

It also gives a “buffer layer” to workaround devices that do not 100% compliantly implement whatever protocol they claim. In this way, SmartThings is much better than Vera or other platforms which require full compliance to Z-Wave (etc.).

Please see the example for Capability Lock: https://smartthings.developer.samsung.com/develop/api-ref/capabilities.html#Lock

The weak parts:

(a) Capability definitions are not rigorous… e.g., data types and attribute domains are largely undefined; and

(b) Any DTH can be arbitrarily extended with additional Attributes and Commands with absolutely no standards, developer community reviews, SmartThings certification; just any arbitrary property name and datatype!, and

(.c) There is no mechanism in place to extend or deprecate a Capability. Are all Attributes and Commands mandatory or should some be labeled optional? If optional, what behavior should a device perform if an optional Command is called from an automation?; and

(d) UIs for a device are entirely distinct from the Capability. Two perfectly compliant Locks may have extremely different UIs within and external to the SmartThings App, and

(e) Capabilities are being horribly PERVERTED to express use cases that were never in the original paradigm. There is a Capability “Lock Only” which is complete cow-pucky. If there is a requirement to securely restrict the Commands and Attributes of a Lock with certain granularity, this should not be a fundamental and global platform paradigm. If we have “Lock Only”, then why don’t we have “Open Only” for Doors? or “On Only” for light-switches? or “Off Only” for fireplaces? Using Capabilities like this is an abomination!

2 Likes
15

I have to say, thanks @JDRoberts and @tgauchat. Exactly what I was looking for. It makes tons more sense now in my head.

@tgauchat oh goodness, sounds worse than the situation with browsers and w3c.

Will do more reading!

2 Likes