Calling all Schlage Zwave Lock users

1

I’ve been having quite a few issues with my Schlage BE469ZP lock being flaky with OpenZWave, and was wondering if anyone else is having similar issues. I previously used the native Zwave integration with few issues.

At the moment, I’m kind of stuck with the lock not having some of the reported sensors “available” in HA. Specifically

  • sensor.be469zp_connect_smart_deadbolt_user_code
  • sensor.be469zp_connect_smart_deadbolt_access_control

Sometimes these sensors do show up in HA, but even when they do they aren’t updating as they do with the Zwave integration. This will be an issue for anyone wanting to use the various lock manager packages that are available for HA.

2

I missed this. Thanks for starting this. I was doing some testing the other day, and have similiar issues. I removed and readded the lock a coupe times as well. I have two BE469 locks and one fe599. I did notice on the codes, that it looked like they showed, and then quickly reset back to 0. Maybe we can work with that, or maybe its a bug.

EDIT: For me the best thing about the new OZW is that it is outside of HA, so if I restart HA, I dont have to wait 2-4 minutes before zwave becomes responsive again. I really like that a lot. I definitely need to figure out how to get the user code, but I think everything else can be done right now. Lock/unlock, clear codes!, add codes, I think manual lock is now a sensor, but It also seemed to “not stick when used”. So if I was doing a lock package today (I think I’d wait a bit, haha), the only thing I dont think I could do it tell you who unlocked the door, which is a big one though. :slight_smile:

3

I found in the OZW control panel a setting that is defaulted to 5000 ms that clears the sensors. You can change it to 0, to keep them from clearing, but if you remove your USB stick the value resets to 5000 ms again.

I’ve also noticed that my fe599 lock shows as unknown on OZW 16., but is detected properly on the old 1.4. The funny/weird thing is that on the beta (1.6) there is even an xml file for the fe599. But since it does not properly see the product code, its not used.

4

Which sensors are you talking about that are cleared? What’s the setting that you change to 0?

@firstof9 are you aware of this?

5

After the defined (configurable) time in the lock, the events are auto cleared, so the Access Control and User Code sensors should clear back to 0. It’s a feature of the lock.

6

It is a feature for sure, but you can turn off that feature, bu changing the value from 5000ms to 0. But as of now it does not seem to stick between restarts of OZW. I’m still testing though

7

Also note these sensors should update more reliably now as well in 0.115+

1 Like
8

How? Can you provide a screenshot in the ozwadmin interface?

9

BTW, what I’m doing in my latest code is mirroring the user code sensor and access control sensor with input_text entities. Anytime those sensors change, I update the input text entities.

So those sensor changes indicate it’s time to build a new report. It also indicates that whatever “event” occurred is one that was generated by some action of the lock itself. A entered code, lock button pressed, the lever locked/unlocked, lock jammed, etc. I call all of these LOCK EVENTS. I also want to have the report indicate when Home Assistant does things to the lock. Like locking/unlocking. I call those HA LOCK EVENTS.

My latest ozw code attempts to report both of those. It’s about 80% effective in distinguishing between the two. Hopefully with the 500ms delay setting I can get them working 100% of the time.

1 Like
10

my owz is off at the moment, so I could not grab the screenshot, but I posed it here last week. I could not figure any way to set this via HA though.

11

It’s this, correct?

I don’t have that Automatically Clear Events row. My Bootloader is also 6. What model lock do you have? How old is it? Mine is just a few weeks old btw.

12

Be469. It’s several years old. Maybe 3-4
The default value is 5000. I have two be469s and and fe599. They all have that value set to 5000 by default.

13

Note: This option only comes up on older locks with a CC113 (Notifications Command Class) less than v4.

1 Like
14

Which means it probably doesn’t effect anything

15

For me it does effect my lock. It resets the sensor to after 5 seconds. for locks that dont have the option, does it still reset the sensors? Either way, there are workarounds, just curious if other can set the value to ‘0’ and have the sensors not reset (if they choose)

16

Newer locks auto clear the Access Control and User Code after xx time. I want to say it’s 5 seconds, but I’m not 100% sure. The configuration option you and I have on our locks is to mimic the newer method since we’re using a lower Notification Command class version.

17

From our chat on discord, did you get the impression that changing this setting actually changes any behavior whatsoever on the lock?

18

For my lock the status doesn’t clear, even with the setting enabled (anything > 0).

19

My work around for this problem was to create sensors via NodeRed:

[{"id":"3123282e.6f939","type":"server-state-changed","z":"8a2abea4.5b30a","name":"Door Code","server":"63517380.eb951c","version":1,"exposeToHomeAssistant":false,"haConfig":[{"property":"name","value":""},{"property":"icon","value":""}],"entityidfilter":"sensor.front_door_lock_user_code","entityidfiltertype":"exact","outputinitially":true,"state_type":"str","haltifstate":"0","halt_if_type":"str","halt_if_compare":"is_not","outputs":2,"output_only_on_state_change":true,"x":900,"y":2560,"wires":[["a95748a.8f4a6b8"],[]]},{"id":"a95748a.8f4a6b8","type":"ha-entity","z":"8a2abea4.5b30a","name":"Front Door Code Used","server":"63517380.eb951c","version":1,"debugenabled":false,"outputs":1,"entityType":"sensor","config":[{"property":"name","value":"Front Door Code Used"},{"property":"device_class","value":""},{"property":"icon","value":""},{"property":"unit_of_measurement","value":""}],"state":"payload","stateType":"msg","attributes":[],"resend":true,"outputLocation":"","outputLocationType":"none","inputOverride":"allow","x":1080,"y":2560,"wires":[[]]},{"id":"19b5f048.3542a","type":"server-state-changed","z":"8a2abea4.5b30a","name":"Lock Control","server":"63517380.eb951c","version":1,"exposeToHomeAssistant":false,"haConfig":[{"property":"name","value":""},{"property":"icon","value":""}],"entityidfilter":"sensor.front_door_lock_access_control","entityidfiltertype":"exact","outputinitially":false,"state_type":"str","haltifstate":"0","halt_if_type":"str","halt_if_compare":"is_not","outputs":2,"output_only_on_state_change":true,"x":910,"y":2620,"wires":[["5b7510a7.7a7ef8"],[]]},{"id":"5b7510a7.7a7ef8","type":"change","z":"8a2abea4.5b30a","name":"Set Text","rules":[{"t":"change","p":"payload","pt":"msg","from":"1","fromt":"str","to":"Manual Lock","tot":"str"},{"t":"change","p":"payload","pt":"msg","from":"2","fromt":"str","to":"Manual Unlock","tot":"str"},{"t":"change","p":"payload","pt":"msg","from":"5","fromt":"str","to":"Keypad Lock","tot":"str"},{"t":"change","p":"payload","pt":"msg","from":"6","fromt":"str","to":"Keypad Unlock","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":1060,"y":2620,"wires":[["d444b734.66833"]]},{"id":"d444b734.66833","type":"ha-entity","z":"8a2abea4.5b30a","name":"Lock Access","server":"63517380.eb951c","version":1,"debugenabled":false,"outputs":1,"entityType":"sensor","config":[{"property":"name","value":"Front Door Lock Access"},{"property":"device_class","value":""},{"property":"icon","value":""},{"property":"unit_of_measurement","value":""}],"state":"payload","stateType":"msg","attributes":[],"resend":true,"outputLocation":"","outputLocationType":"none","inputOverride":"allow","x":1210,"y":2620,"wires":[[]]},{"id":"63517380.eb951c","type":"server","z":"","name":"Home Assistant","legacy":false,"addon":false,"rejectUnauthorizedCerts":false,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":true,"cacheJson":true}]