I moved my BE469 from wink to Hassio via a Zooz Zwave stick. I see the secure node added correctly and can get to all sorts of stuff through the configuration-Zwave UI, but see no entity to allow locking or unlocking. Do I have to make something? I do see an error about Zwave in the log.
2018-11-24 12:58:52 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File “/usr/local/lib/python3.6/site-packages/homeassistant/components/zwave/init.py”, line 949, in discover_device
self._zwave_config)
File “/usr/local/lib/python3.6/site-packages/homeassistant/helpers/discovery.py”, line 151, in async_load_platform
assert hass_config, ‘You need to pass in the real hass config’
AssertionError: You need to pass in the real hass config
I moved that over from Wink and didn’t have any troubles. Try restarting and then wait like 15 minutes for the zwave network to finish starting up and see what happens
It has been hours with many reboots as I move Lutron devices over too. I see all the zwave and sensor entities, but no lock entity. From what I can tell, it doesn’t show unless you made a network key and add secure node which I did. I’m looking to confirm whether the lock was added securely successfully, it did give me the green checkmark immediately when I added it securely. The new instructions say not to include zwave: in configuration.yaml, which where the network key used to be specified. I see an entry in options.yaml that is commented out with a default network key. Cannot find any other reference to network key in config folder or subfolders. I do see:
I moved my stuff over before the new zwave configuration took place so I am not sure. I manually added my zwave key and added via add secure node and it worked. Unfortunately I am not sure what else to try.
The instructions seem to contradict themselves for the current version. It is explained that a network key entry is needed throughout the documentation, and then in one place it claims that it is no longer the case. So which is it?
I guess the network key is set implicitly, but won’t I need that value in the case that I have to recreate my hassio server. One of the solutions for this problem with locks is in fact to reinstall: Kwikset z wave
Some really weird stuff going on with my Z-Wave. I decided to move some plus and non plus items around physically and I use the IOS to pair. They appear fine in the IOS app but when I go back to Chrome on my MAC, they are not in the node pull down list. Cleared cache, still the same.
I’m having the same issue after upgrading from 0.80 to 0.82.1. First thing I had to do was blow up my zwave conifguration in configuration.yaml and use the zwave integration, it was the only way I could get secure devices to add. Now I don’t see the lock entity…very strange
I added a second lock, a yale, same issue. No lock entities are being created. I also tried reinstalling HASS to see if i could get rid of the zwave error, but the error is still there
Nov 26 19:48:52 hass hass[30854]: 2018-11-26 19:48:52 INFO (Dummy-3) [openzwave] Driver ready using library Static Controller version Z-Wave 3.95
Nov 26 19:48:52 hass hass[30854]: 2018-11-26 19:48:52 INFO (Dummy-3) [openzwave] home_id 0xedc3ffe2, controller node id is 2
Nov 26 19:48:52 hass hass[30854]: 2018-11-26 19:48:52 INFO (Dummy-3) [homeassistant.loader] Loaded lock.zwave from homeassistant.components.lock.zwave
Nov 26 19:48:52 hass hass[30854]: 2018-11-26 19:48:52 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Nov 26 19:48:52 hass hass[30854]: Traceback (most recent call last):
Nov 26 19:48:52 hass hass[30854]: File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/zwave/__init__.py", line 949, in discover_device
Nov 26 19:48:52 hass hass[30854]: self._zwave_config)
Nov 26 19:48:52 hass hass[30854]: File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/helpers/discovery.py", line 151, in async_load_platform
Nov 26 19:48:52 hass hass[30854]: assert hass_config, 'You need to pass in the real hass config'
Nov 26 19:48:52 hass hass[30854]: AssertionError: You need to pass in the real hass config
The AssertionError: You need to pass in the real hass config error should be fixed in the current beta. Please try on 0.83 beta and submit a GitHub issue if it’s still not working.
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?
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.
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)
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.
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 %}