I tried the latest 0.83 beta and the lock appeared but would not respond to lock and unlock commands. There were piles of other errors from other components so I’ve gone back to 82.1. Where on github would I report?
I got this working with the custom component. Now 84.3 is out so I’ll try removing the custom component and updating.
Happy to report the BE469 works well with 84.3
Can some explain what was fixed with this update? What can i look for to see the changes in my install? Was there a recent bug that was resolved or a long time bug? I read the details in the update, but cannot see anything different.
The lock/unlock state from BE469 was not being reported properly to HA. A custom component was required untill 84.3
I am pretty familiar with these locks (and the FE599 as well). I know that as long as I’ve had them they’ve reported lock state (locked or unlock), as well as two of three ways that a lock could be locked or unlocked. They have always reported Manual lock/unlock, or keypad lock/unlock/ What they were not reporting was Locked/unlocked using Home assistant.
I’m on 84.6 and as far as I can tell it is still not reporting Locked or Unlocked via Home Assistant. I believe that is what was supposed to be fixed, so I’m wondering if it is being reported somewhere else, or in a different way.
For other zwave locks the alarm level sensor is what reported the lock type
for me it’s
sensor.lock_back_door_deadbolt_alarm_type
For zwave locks a value of 24 is locked by zwave and 25 is unlocked by zwave. Those are the values that dont get reported on the BE469. Many people used a template to work around this (I am), but making assumptions that if the lock changed state and the value of the alarm_type sensor did not change, that it must have been locked or unlocked using HA.
My question is, where should I see the changes in 84.3+ to be able to see that HA locked or unlocked the lock using zwave? I’m not seeing it where I thought I would (alarm_type)
1 Like
The lock entity reports the status. At some point it quit working and I used a custom component which I thought was integrated into 84.3. Schlage BE469 deadbolt problem
I’m reporting back to answer my own question or at least provide some more useful details.
The fix that happened in 84.x fixed an issue (I believe it has never worked) where the lock.lock_name_here did not report locking/unlocking correctly when locked via HA. Where I was confused, is that I always used alarm_type sensor to get the way the door was locked. That has been the way most people have been doing it for a while. I thought (I was wrong) that the update was supposed to fix that sensor to report back the value for HA lock/unlock, but it did not for me, so I assumed I was missing something. I dont use the lock.lock_name_here entity for much, so I did not really pay much attention to it.
Today I happened to be looked the lock entity and realized that it was reporting there.
node_id: 104
value_index: 0
value_instance: 1
value_id: 72057595788558336
notification: Manual Lock
lock_status: Manually Locked by Key Cylinder or Inside thumb turn
friendly_name: Front Door Lock
and
node_id: 105
value_index: 0
value_instance: 1
value_id: 72057595805335552
notification: RF Lock
lock_status: Locked by RF
friendly_name: Back Door Lock
The lock status and notification are what has been fixed in 83.x.
I know that is basically what you said, but it was not spelled out enough for me to realize where to look. I wanted to provide more details to help others. I will probably update my lock package at some point in the near future to make to more streamlined using this status for automations vs the template I was using.
1 Like
Hey I saw you posted an update to your lock package recently:
Was curious how you ended up handling the the problems with alarm_type not updating properly. Did you end up referencing the lock_status or notification? Or something else completely?
I actually found that alarm_type was updating fine. I did change my template sensor at one point a while back to just pull lock_status attribute from the lock itself. While it seemed like a good idea, I found it not as “flexible” for me. For example I wanted mine to say “Keypad unlock with code slot X by user Y” or locked with schlage button, etc. Overall I’m still using the same exact template that I’ve been using for quite a while. it’s got a lot of yaml, and I suspect that many of these codes are not reported. Like All codes cleared, etc. but it has been pretty solid for me
sensor:
- platform: template
sensors:
back_door_report:
friendly_name: 'Back Door'
value_template: >
{% set number = states('sensor.back_door_deadbolt_alarm_level') %}
{% set alarm_type_value = states('sensor.back_door_deadbolt_alarm_type') %}
{% set entity_id = 'input_text.door_keypad_' + number + '_name' %}
{% set user = 'Master' if number == '0' else states(entity_id) %}
{% set alarm_type_value = '24' if (as_timestamp(now())-as_timestamp(states.lock.back_door.last_changed)) < 15 and (as_timestamp(now())-as_timestamp(states.sensor.back_door_deadbolt_alarm_type.last_changed)) > 15 and (states.lock.back_door.state) == 'locked' else alarm_type_value %}
{% set alarm_type_value = '25' if (as_timestamp(now())-as_timestamp(states.lock.back_door.last_changed)) < 15 and (as_timestamp(now())-as_timestamp(states.sensor.back_door_deadbolt_alarm_type.last_changed)) > 15 and (states.lock.back_door.state) == 'unlocked' else alarm_type_value %}
{% set alarm_type_general_actions = {
'0':'No Status Reported',
'9':'Lock Jammed',
'17':'Keypad Lock Jammed',
'21':'Manual Lock',
'22':'Manual Unlock',
'23':'HA Lock Jammed',
'24':'HA Lock',
'25':'HA Unlock',
'26':'Auto Lock Jammed',
'27':'Auto Lock',
'32':'All Codes Deleted',
'161':'Bad Code Entered',
'167':'Battery Low',
'168':'Battery Critical',
'169':'Battery Too Low To Operate Lock' } %}
{% set alarm_type_lock_actions = {
'18':'Keypad Lock',
'19':'Keypad Unlock',
'162':'Lock Code Attempt Outside of Schedule' } %}
{% set alarm_type_code_actions = {
'33':'Code Deleted',
'112':'Code Changed',
'113':'Duplicate Code' } %}
{% if alarm_type_value in alarm_type_code_actions %}
{{ alarm_type_code_actions[alarm_type_value] }} (Code {{ number}})
{% elif alarm_type_value in alarm_type_lock_actions and number == '0' %}
{{ alarm_type_lock_actions[alarm_type_value] }} with Schlage Button
{% elif alarm_type_value in alarm_type_lock_actions %}
{{ alarm_type_lock_actions[alarm_type_value] }} with Code {{ number }} ({{ user }})
{% elif alarm_type_value in alarm_type_general_actions %}
{{ alarm_type_general_actions[alarm_type_value] }}
{% else %}
Unknown Alarm Type Value {{ states('sensor.back_door_deadbolt_alarm_type') }}
{% endif %}
Ah got it. Your back door is a BE469 right?
Sure is. Works well
Bringing this back from the dead. Not sure if I should lay any packages on top of this as I can’t get it to lock or unlock after pairing. Everything seems to be added correctly, but calling a lock or unlock service looks like it’s resulting in a timeout error. I’m pretty new to most of this. Can anyone help? Should I try installing @ptdalen’s package?
Here’s the log when I try to unlock the door:
2020-06-14 17:53:19.109 Info, Node020, Value::Set - COMMAND_CLASS_DOOR_LOCK - Locked - 0 - 1 - False
2020-06-14 17:53:19.110 Info, Node020, Value_Lock::Set - Requesting lock to be Unlocked
2020-06-14 17:53:19.110 Detail, Node020, Queuing (Send) DoorLockCmd_Set (Node=20): 0x01, 0x0a, 0x00, 0x13, 0x14, 0x03, 0x62, 0x01, 0x00, 0x25, 0x7c, 0xcb
2020-06-14 17:53:19.110 Detail, Node020, Queuing (Send) DoorLockCmd_Get (Node=20): 0x01, 0x09, 0x00, 0x13, 0x14, 0x02, 0x62, 0x02, 0x25, 0x7d, 0xcb
2020-06-14 17:53:19.110 Detail,
2020-06-14 17:53:19.110 Info, Node020, Sending (Send) message (Callback ID=0x7c, Expected Reply=0x04) - DoorLockCmd_Set (Node=20): 0x01, 0x0a, 0x00, 0x13, 0x14, 0x03, 0x62, 0x01, 0x00, 0x25, 0x7c, 0xcb
2020-06-14 17:53:19.115 Detail, Node020, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-06-14 17:53:19.116 Detail, Node020, ZW_SEND_DATA delivered to Z-Wave stack
2020-06-14 17:53:20.358 Detail, Node020, Received: 0x01, 0x05, 0x00, 0x13, 0x7c, 0x00, 0x95
2020-06-14 17:53:20.358 Detail, Node020, ZW_SEND_DATA Request with callback ID 0x7c received (expected 0x7c)
2020-06-14 17:53:20.358 Info, Node020, Request RTT 1248 Average Request RTT 1211
2020-06-14 17:53:20.358 Detail, Expected callbackId was received
2020-06-14 17:53:29.111 Error, Node020, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-06-14 17:53:29.111 Detail, Node020, Removing current message
2020-06-14 17:53:29.111 Detail, Node020, Notification: Notification - TimeOut
2020-06-14 17:53:29.111 Detail,
2020-06-14 17:53:29.111 Info, Node020, Sending (Send) message (Callback ID=0x7d, Expected Reply=0x04) - DoorLockCmd_Get (Node=20): 0x01, 0x09, 0x00, 0x13, 0x14, 0x02, 0x62, 0x02, 0x25, 0x7d, 0xcb
2020-06-14 17:53:29.117 Detail, Node020, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-06-14 17:53:29.117 Detail, Node020, ZW_SEND_DATA delivered to Z-Wave stack
2020-06-14 17:53:30.328 Detail, Node020, Received: 0x01, 0x05, 0x00, 0x13, 0x7d, 0x00, 0x94
2020-06-14 17:53:30.329 Detail, Node020, ZW_SEND_DATA Request with callback ID 0x7d received (expected 0x7d)
2020-06-14 17:53:30.329 Info, Node020, Request RTT 1217 Average Request RTT 1214
2020-06-14 17:53:30.329 Detail, Expected callbackId was received
2020-06-14 17:53:39.112 Error, Node020, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-06-14 17:53:39.112 Detail, Node020, Removing current message
2020-06-14 17:53:39.113 Detail, Node020, Notification: Notification - TimeOut
I’ll try to provide more input later, but if your lock does not lock or unlock natively, then packages/automations, will not help, and will likely complicate things for you. It looks like the lock is having communication issues.
Did you pair the lock using Add Node Secure? You will need to have a zwave network key for that too. Without pairing it securely these functions won’t work.
I did pair using that button but how can I tell if actually added securely?
I’ve read somewhere that it adds regardless.
Well I dont see a NONCES report in your OZW logs so that suggests it wasn’t added properly. Start from here to ensure you have done everything properly:
Thanks for sending me there. Somehow ~20 devices and ~38 entities in, z-wave devices in, I never noticed that I missed creating a security key. I unpaired the lock, configged in a security key, restarted and added secure. Now all of the core functions are working
Side question - I have a bunch of other devices - mostly motion sensors and lights and switches that are sitting on my z-wave stack that I now know have all been added unsecure. Should I go back and re-add them secure? I already have a lot of binary sensors built on top of them - would these entity IDs lose their mapping if I remove and re-add?
Its really only for security devices like a lock, you can tell if you did not pair it correctly because some functionality is missing. If you suspect a device has missing functionality then yes you’ll want to pair it securely. Entity ID’s may lose mapping but you can always rename.
1 Like