Clear Lock Jammed Status?

I added several Yale YRD 256 locks to my Zwave HASSIO setup this week. Not all of them were seemless installs and I ended up having to tweak the door jams to get the bolt to slide in and out without getting hung up. Nevertheless, my question is there a way to clear the lock jammed entity after it gets flagged? I’d like to build a notification to alert me when the lock doesn’t seat correctly (ie “jammed”)…but I can’t seem to figure out how to tell the entity that the lock is no longer jammed?!

I don’t know about Yale but on my
Schlages a manual thumb turn back and forth would clear the status

Took a little digging, but I found I can change the jammed entity state in the developers tools tab. I made a script to notify me and reset them if they get tripped. Thanks all!

@mboarman

May I ask you to please share the details on which options were used in the Developer Tools to clear the ‘lock jammed’ state for the BE469?

After many attempts, I was unable to find a solution on my own.

I am hopeful a similar approach can be used to reset the ‘tamper alarm’, too.

Thanks for your assistance!

Sure…I built a simple script to clear it out, see below:

clear_lock_jam_status:
  sequence:
  - service: python_script.set_state
    data_template:
      entity_id: binary_sensor.lock_back_door_access_control_lock_jammed
      state: 'off'
  mode: single
  alias: Clear Lock Jam Status

You’ll just need to replace the entity name with your lock’s jammed entity. Hopefully that makes sense?

@mboarman

Thank you for your quick response and details!

Is the ‘set_state’ python script built-in to HA, or does this script need to be added to my configuration?

@cntx Whoops! I completely forgot I added that into HA to make this work since it’s not baked in natively to Home Assistant. See this post:

@mboarman

Thank you for your expeditious response and pointing me in the right direction.

I am reviewing the python script and integration instructions. This is a good fix until I upgrade my locks [BE469] or zwave_js supports the older notification CC items.

i dont think its a smart idea to manually set the lock status…you know in case it actually jammed…probably best to send another lock command to ensure its state is correct. Anytime I see its jammed I just send another lock command to fix it.

@dshokouhi While I don’t disagree with you, I haven’t found any other way to clear the status of my Yale jammed lock. I’ve sent commands to lock and unlock (both of which work fine) but the jam state remains unchanged once it’s registered as a jam. Any advice would be appreciated?!

coudl it be an integration bug? surely it must clear on its own somehow when the lock is indeed locked or unlocked.

I would have thought the same thing…To no avail, it won’t release the jam state on any of my Yale locks, and I have three YRD256 devices. That was the whole reason I built a script to manually change the state.

No, it’s not an integration bug. Some locks don’t send an Idle notification.

2 Likes

thanks for clearing that up :slight_smile:

When my Schlage BE469 locks were z-wave nodes on an ISY-994iz controller, the ‘jammed’ condition cleared after manually operating the lock or sending an RF lock / unlock. However, after moving the same locks to Home Assistant as z-wave nodes, the binary sensor for the jammed condition will not clear when the manual lock / unlock or RF lock / unlock is executed.

I am not sure if the ISY-994iz was clearing the jammed state after an observed state change OR a zwave_js issue.

1 Like

@mboarman

Thanks for sharing your information. The python_script.set_state implementation is working well to reset the binary sensor for the jammed lock. However, after the python script executes, it is renaming the frontend friendly name to be the entity_id and the icon is reset to the default device_class.

Are you experiencing this same behavior when observing the frontend state objects?

The code below includes the ‘commented’ icon section, but the script was tested with and without the comment-out.

# python_scripts/set_state.py
#--------------------------------------------------------------------------------------------------
# Set the state for the entity specified in the automation / script action
#--------------------------------------------------------------------------------------------------

inputEntity = data.get('entity_id')
inputStateObject = hass.states.get(inputEntity)
inputState = inputStateObject.state
inputAttributesObject = inputStateObject.attributes.copy()

newState = data.get('state')
if newState is not None:
    inputState = newState
    
#newIcon = data.get('icon')
#if newIcon is not None:
#    inputAttributesObject['icon'] = newIcon

hass.states.set(inputEntity, inputState, inputAttributesObject)

Sorry for the delayed response, I’ve been out of pocket for a bit. I haven’t noticed this behavior? Seems a little odd? Did you get it resolved?

Mark,

No apology necessary.

The error was on my side / user-error. Ultimately the working script is as follows:

# python_scripts/set_state.py
#--------------------------------------------------------------------------------------------------
# Set the state for the entity specified in the automation / script action
#--------------------------------------------------------------------------------------------------

inputEntity = data.get('entity_id')
inputStateObject = hass.states.get(inputEntity)
inputState = inputStateObject.state
inputAttributesObject = inputStateObject.attributes.copy()

newState = data.get('state')
if newState is not None:
    inputState = newState
    
#newIcon = data.get('icon')
#if newIcon is not None:
#    inputAttributesObject['icon'] = newIcon

hass.states.set(inputEntity, inputState, inputAttributesObject)

2 Likes

Thats because Yale/August has a faulty Z-Wave implementation …