Z-Wave locks and state tracking

[Daniel Ellison]

(I posted this question via email but it never showed up, so I'm now using the web interface. Apologies if this ends up appearing twice.)

Since Dave Badia is getting close to having the Z-Wave security command class working in openHAB, I thought I'd ask a few questions about Z-Wave locks.

I have a Weiser Z-Wave lock which is compatible with the Wink hub. It locks and unlocks fine after a considerable delay, due to Wink's cloud-based architecture. One thing the Wink software does very badly, however, is keep track of the lock's state.

It has no concept of the manual deadbolt lever, nor does it acknowledge the auto-lock setting on the Weiser where it locks automatically after 30 seconds. It only seems to keep track of what the Wink software itself has done.

Is this a limitation of Z-Wave locks in general, or of this particular lock, or is it just the Wink software being oblivious? I can't see a so-called "smart" lock being much use if I never know for sure whether the door is locked or unlocked. If we get lock support in openHAB thanks to Dave Badia, will I be faced with the same problems I've had with Wink? 

[Daniel Ellison]

Nobody knows! :) Is there a more appropriate place I could ask this question?

[Skynet Home]

Not much discussion seems to be going on in the openhab community regarding locks as there is no compatibility with the security class and until they are supported its hard to postulate answers to these questions. Smart locks seems to range from terrible to promising at best, with as I have seen so far, no real clear go to device. I have been looking seriously at the Yale Orb locks and the Gogi lock looks interesting as well. Bluetooth seems to be the worst possible method of controlling a smart lock so I am looking forward to being able to incorporate Z wave locks into my openhab setup. One way that you could retrofit a less than smart existing smart lock to update state would be to incorporate a reed switch contact into the dead bolt channel. If you drill into the dead bolt channel and insert a reed switch contact with magnet attached to the deadbolt itself and incorporate that switch into openhab then you would be able to update the state of you existing lock!

[Daniel Ellison]

I looked at various WiFi and Bluetooth locks as well. None of them seemed to be the right solution for me, not to mention that they're certainly not yet supported in openHAB. That's why I chose the Weiser/Kwikset Z-Wave lock. That and it's supported by the Wink hub - my first experiment with home automation. It does seem that thanks to Dave Badia at least locking and unlocking will soon be possible via the openHAB Z-Wave binding. All that remains is reliable state tracking.

I'll have to look into the reed switch approach. I'll be building some small Arduino-based sensors for my HA system. Maybe this will be the first piece I add! Looks like SparkFun has reed switches: https://www.sparkfun.com/products/8642. But it's the "incorporate that switch into openhab" part that I'll have to figure out. Any pointers would be much appreciated.

As I said, just being able to lock/unlock a door doesn't do much good if you don't know its state to start with. I still don't know if these capabilities are built into the Z-Wave locks or not. I'm starting to think nobody knows! :)

[Nathan Stratton]

I use the Yale locks via mios binding and state works even when my locks auto lock. 

><>
nathan stratton | vp technology | broadsoft, inc | +1-240-404-6580 | www.broadsoft.com

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/8e997720-20c0-4db0-8f3f-093f9b4f9c17%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Daniel Ellison]

See, that's part of what my original question was: are the limitations I'm coming across specific to the lock I'm using, or perhaps the Wink software? I just did a test to confirm and unlocking the door with the Wink app continues to show the door unlocked, despite the fact that it automatically locked again after 30 seconds.

It's good to know that at least one lock (or possibly the MiOS hub) properly tracks state. Are you able to lock and unlock as well, or is it just reads?

I'm not interested in adding another hub to my system, though. I'm just trying to figure out where the deficiencies lie.

[Nathan Stratton]

On Tue, Jun 30, 2015 at 9:50 AM, Daniel Ellison <zigg...@gmail.com> wrote:

See, that's part of what my original question was: are the limitations I'm coming across specific to the lock I'm using, or perhaps the Wink software? I just did a test to confirm and unlocking the door with the Wink app continues to show the door unlocked, despite the fact that it automatically locked again after 30 seconds.

It's good to know that at least one lock (or possibly the MiOS hub) properly tracks state. Are you able to lock and unlock as well, or is it just reads?

I'm not interested in adding another hub to my system, though. I'm just trying to figure out where the deficiencies lie.

Yes, I can lock and unlock also. Only downside is that is is via MiOS hub and not direct.

-Nathan 

[Daniel Ellison]

I'm going to remove my Weiser lock from the Wink hub and try accessing it with a Raspberry Pi 2 containing a RaZberry daughterboard and the Z-Way software. I'm unfamilar with the software so far (the lock is the only Z-Wave device I have at the moment) but at least I'll see it working outside the Wink network.

[Daniel Ellison]

I finally got a chance to transfer control of my Weiser (aka Kwikset) lock from the Wink hub to a Raspberry Pi with a RaZberry board and Z-Way software. It answered all of my questions as it works perfectly in all respects, even updating state properly when someone opens the lock manually. So not only do I now have a fully functioning lock, it no longer requires a connection to Wink's servers to function. I'd call that a successful experiment!

[Ben Jones]

That is excellent news Daniel!! When do you think it will be ready to merge into the Z-Wave binding?

[Chris Jackson]

>
>
> That is excellent news Daniel!! When do you think it will be ready to merge into the Z-Wave binding?

Maybe I don’t understand this well, but I can’t see that this can be merged into the ZWave binding. I understand that this is using the RPi z-way server, and then presumably using the REST interface to control the lock? If so, then this isn’t something that can be, or should be integrated into the OH Zwave binding.

[Ben Jones]

Yep my mistake! Misread the post and thought it was talking about a successful security command class implementation.

[Rob Dom]

I'm confused... you got openHAB to work with your lock?  I'm using Razberry Pi as well and have a Scalage lock that I'd like to get working.  It is already paired, but I didn't get past that as I realized the security command class didn't exist.

-Rob

[Daniel Ellison]

On Sep 10, 2015, at 6:05 PM, Rob Dom <fuoc...@gmail.com> wrote:
> I'm confused... you got openHAB to work with your lock? I'm using Razberry Pi as well and have a Scalage lock that I'd like to get working. It is already paired, but I didn't get past that as I realized the security command class didn't exist.

Nope, I never got OpenHAB working with my lock. I wasn't trying to, actually. What I DID do is confirm that my lock exposes more functionality than the Wink hub provided. Particularly, it does report manual activation of the deadbolt - a vital function if you want to accurately track a lock's state.

To answer my question I removed the lock from the Wink hub (and retired the hub itself). I put together a Raspberry Pi 2 and a RaZberry Z-Wave board. I installed the Z-Way software, which provides a REST API to control and read the lock state. Using that API I was able to control the lock completely and read its state no matter how it had been manipulated.

That was the successful experiment I was referring to.