Status reporting anomaly, Schlage BE469, in automatic relock mode

[Guest]

A recently-installed Schlage BE469 Z-Wave door lock (late 2018-model) physically locks and unlocks and accurately reports the respective state when actuated by Z-Wave. But, with the 30-second automatic relocking option set, whenever the lock re-locks itself, the status (at least the status value displayed in the HS3 device management console) does not toggle back to "locked." The incorrect value can be corrected temporarily by sending a "lock" command via Z-Wave, but the the state will again hang on "unlocked" the next time the lock re-locks itself after the lock is unlocked, whether by exterior keypad or by the interior handle.

With an apologetic "please, pardon my dust as we work to serve you better (etc)" I have temporarily patched the status text to display "Unlocked & auto-relock" instead of "Unlocked", since the unit reliably locks itself!

But, this is poor security practice and we could do better. sparkman, , others, have you encountered this?

Thanks for any help.

[sparkman]

I haven't used the auto-relock function of my Kwikset deadbolts to see if they behave the same. I'll give it a try this weekend to see if how they behave. They do have a status code for Auto Locked and Auto Locked Failed, so I expect they would/should send that code if it did auto-lock. Does the BE469 show codes for Autolock in the Notification Device's Status Graphics tab?

[Guest]

Does the BE469 show codes for Autolock in the Notification Device's Status Graphics tab?

I guess the pair of 17 and 33 (Boolean AND) describe the situation of the physically-unlocked lock, pending Timeout of the 30-second auto-lock timer.

I have only seen 'Unlocked' and 'Locked' statuses in actual use, with no distinct indication of the 'pending relock' state. Accordingly, I modified the status description of value "0" from the original "Unlocked" to a temporary label of "Unlock & Relock" as a temporary reminder to users, and put a note with [fictitious] value "101" as a reminder about what 0 should be.

Originally, before my edit of the "Unlocked" status, only values 0 and 255 were associated with status levels on the Device Management page.

Here is the [modified] Status Graphics tab:





The temporary status description looks like this to users:



The door is secure for now, and family members don't have to remember to lock it! That's as far as I have been able to take it so far...

I would like to learn how to troubleshoot Z-Wave devices and state issues at a deeper level: beyond establishing that the device is on the network and receives frames.

Thanks for your help.

Dean

[sparkman]

Hi Dean,

I just tried it here and my lock does report the Auto Lock properly to HS (ignore the time stamp as that is way off):


Since your lock is able to send other codes to HS, I suspect it is a bug/feature with the Schlage. Might be worth calling them to see what they can tell you.

Cheers
Al

[jvm]

I would like to learn how to troubleshoot Z-Wave devices and state issues at a deeper level: beyond establishing that the device is on the network and receives frames.

As an FYI - Many of the status values used in HomeSeer come directly from the Z-Wave specifications. For example, the status values for the doors come from Table 33 in the document "SDS13781-5 Z-Wave Application Command Class Specification" which is available here: https://www.silabs.com/documents/log...cification.pdf

And a more complete listing of these specifications is here: https://www.silabs.com/products/wire...18q-zwv-041818

[Guest]

Al, Thanks for digging into this and providing 'criterion validation'. The granularity of your lock's status reporting and the presence of detailed codes in my lock's firmware (presumably the codes shown in Device Management came from the lock's firmware via zwave messages to homeseer during device setup) suggests that full detail is not being transmitted. It would be nice to be able to see the contents of messages the lock transmits over the network. Is there an obvious way to do this in the homeseer/zwave ecosystem?

And jvm thanks for the reference to the zwave spec and the suggestion (in another thread) to implement the automatic re-locking delay function in HS rather than using the built-in option.

All the best,

Dean

[sparkman]

Hi Dean, unfortunately there are really no good user tools available that can help troubleshoot z-wave issues like this. You can try turning on debug in the z-wave plugin just before an autolock is triggered and then checking the resulting log file to see if there are any indications that HomeSeer received a packet from the lock. On the development side there are some tools available. See here for a good write-up about a “zniffer”: https://drzwave.blog/2017/10/26/how-...super-sniffer/

Cheers
Al

[randy]

I don’t use the lock’s auto lock, so I really cannot help. I handle auto locking by HS Events so that I can enable or disable it based upon a number of factors and only when the door is closed. Does the auto lock only operate with the door closed? I’ll try to test it this weekend and see how it behaves.

[Guest]

Hello Randy, thanks for offering comparison data from your lock.

I don’t use the lock’s auto lock, so I really cannot help. I handle auto locking by HS Events so that I can enable or disable it based upon a number of factors and only when the door is closed. Does the auto lock only operate with the door closed? I’ll try to test it this weekend and see how it behaves.

The BE469 auto-lock occurs whether the door is open or closed (and I do not have a closure sensor on that door).

Thanks also for the Virtual Device tutorial you posted. I appreciate the work you put into this very helpful project.

ASIDE (on HA system design):

The selection of canonical control paradigms is *non-trivial* to say the least. And, if the system implementer happens to lean more to the analytical side than to the decisive side, it may be difficult to reach closure!

I am acutely aware at this point in my HA project that marshalling a dynamic herd of events and devices and a steady stream of new protocols into a sustainable ontology depends as much on planning (and making good, timely decisions!) as programming; and user-acceptance of the system implemented upon that ontology requires consistent, intuitive control paradigms such as the "ON, OFF, ON" pattern or the default/one-click/double-click lighting-intensity control pattern you describe in your tutorial. [Yes, I know the experienced system integrators are all saying at this point: "So, what else is new?" -- The point is that while HomeSeer can 'interface with' lots of third-party protocols, the interfacing is not sufficient per se: System integration requires more attention to design, and is more difficult than one may expect. That is not a failure of HomeSeer, it is simply a challenge that one accepts in return for being set free from the proprietary constraints of any number of device manufacturers.]

Now, transitioning from my startup homeseer implementation -- essentially an evolving v.0.n beta test -- to a model-driven approach, I want to roll out patterns (soon) that my users can use for a long time, and will find easy to learn. I also want to simplify change-management per se. My experience as a novice working with UPB, then Z-wave, and then Alexa over the past two years has reminded me of the importance of having a prospective bottom-up model with clear abstraction layers -- and a top-down simple, consistent user interface design.

I have been thinking about all of this for too long! Now, it's time either to fish or cut bait. Looks like the top three use-cases for v.1 are: Pulsing the hot-water circulating pump, motion-control of a few lighting scenes, and auto-relocking of some doors. I am in the process of reorganizing that subset of devices, switches and voice-control patterns to hide/isolate/encapsulate the low-level devices and intermediate virtual controls from the exposed user interface.

Thanks for your generous help on this forum. Your input makes the process much more enjoyable.

Dean

[Guest]

Hi Dean, unfortunately there are really no good user tools available that can help troubleshoot z-wave issues like this. You can try turning on debug in the z-wave plugin just before an autolock is triggered and then checking the resulting log file to see if there are any indications that HomeSeer received a packet from the lock. On the development side there are some tools available. See here for a good write-up about a “zniffer”: https://drzwave.blog/2017/10/26/how-...super-sniffer/

Cheers
Al

Al, thanks for the zniffer link! That is exactly the direction I wanted to explore out of curiosty about the RF and message-format aspects of Z-Wave. I browsed the sites and see what you mean about user vs development side: Wow $2k for the development kit. But the UZB hack looks like an interesting project for sometime down the line!

Thanks for reminding me to use debug. Reading your posts is like taking a programming course. Thanks for your input to the homeseer community.

...

FYI, from the Silicon Labs website cited by DrZWave : In consideration of Z-Wave lock security: it's a bit ominous to see in the search results on silabs.com the following:

Decrypt S2 frames in Zniffer trace

https://www.silabs.com/community/wir....entry.html/20...

Question How can I decrypt S2 frames using the Z-Wave Zniffer? Answer The Zniffer can decrypt S2 frames, by following a few steps. First configure ...

S2 'security' is one of the new features of the Schlage BE469ZP as distinct from the BE469 model ( jvm, you mentioned S2 security in passing, as part of considering whether to upgrade to the new model).

Hmm... I guess locks are mainly to keep out honest people (and perhaps also some small children).

Dean