So when you enter the PIN into the slot and toggle Enable
what do you see?
Logbook shows
Status is connected
enabled_backdoor_1 turned on
Then I mosey on over to the door and try to enter the pin, and it just shows me a red x
Does manually executing the service from Services tab in Dev-tools work?
Huh. So yes, manually running the service does work. Just not in the UI… Interesting.
Update! Finally got this working. Not sure if it was automations.yaml
or binary_sensor.yaml
, but I did a bit of messing around and was able to figure out what the problem was. Can’t wait to add my front and side door locks too! Thanks for your help @firstof9
Also having a hard time getting codes sent to the lock. I did have it working using old yaml files posted back in May on this thread, but it has stopped working. Can you post your automation.yaml , binary_sensor.yaml, and config.yaml files to help compare?
Keep in mind I’m running the 0.0.11-ozw version.
Here’s automations.yaml
- id: ha_startup_autom
alias: HA Startup - Set Door Lock Booleans
trigger:
- event: start
platform: homeassistant
condition: []
action:
- condition: state
entity_id: binary_sensor.ozw_network_status
state: 'on'
- data:
entity_id: input_boolean.allow_automation_execution
service: input_boolean.turn_on
- data:
entity_id: input_boolean.system_ready
service: input_boolean.turn_on
- condition: state
entity_id: binary_sensor.ozw_network_status
state: 'off'
- data:
entity_id: input_boolean.allow_automation_execution
service: input_boolean.turn_off
- data:
entity_id: input_boolean.system_ready
service: input_boolean.turn_off
initial_state: true
mode: single
- id: ozw_status_changed_autom
alias: OpenZwave State Changed
description: ''
trigger:
- entity_id: binary_sensor.ozw_network_status
platform: state
condition: []
action:
- condition: state
entity_id: binary_sensor.ozw_network_status
state: 'on'
- entity_id: input_boolean.allow_automation_execution
service: input_boolean.turn_on
- entity_id: input_boolean.system_ready
service: input_boolean.turn_on
- condition: state
entity_id: binary_sensor.ozw_network_status
state: 'off'
- entity_id: input_boolean.allow_automation_execution
service: input_boolean.turn_off
- entity_id: input_boolean.system_ready
service: input_boolean.turn_off
mode: single
And here’s binary_sensor.yaml
- platform: mqtt
name: ozw_network_status
state_topic: OpenZWave/1/status/
value_template: >
{{ "ON" if value_json.Status in ["driverAwakeNodesQueried", "driverAllNodesQueriedSomeDead", "driverAllNodesQueried"] else "OFF" }}
json_attributes_topic: OpenZWave/1/status/
device_class: "connectivity"
- platform: template
sensors:
allow_automation:
friendly_name: "Allow Automation"
value_template: "{{ is_state('input_boolean.allow_automation_execution', 'on') }}"
system_ready:
friendly_name: "System ready"
value_template: "{{ is_state('input_boolean.system_ready', 'on') }}"
device_class: moving
I got em from this thread!
Thanks for the files. I have tried every combination but just cant get it to work again. I will try OpenZwave as people are having more luck with that. Thanks again.
I cant seem to give up… this project keeps drawing me back to make it work. I noticed my setup stopped working when HACS updated lock-manager to 0.0.10 or 0.0.11. I just went into some logs and found the new code contains ozw instead of zwave.
- frontdoor Clear Code: Error executing script. Service not found for call_service at pos 1: Unable to find service ozw/clear_usercode
- frontdoor Add Code: Error executing script. Service not found for call_service at pos 1: Unable to find service ozw/set_usercode
I defiantly didn’t download the beta, so I should not be seeing any ozw, correct?
Ah right, those files only work for ozwave. I switched to ozwave before I started messing with lock manager, so I can’t help you with the regular zwave integration. Sorry
Seems there was a ooof on the repo, I’ve submitted a PR to fix this.
Guys, sorry for the radio silence. I’ve been trying to fix some issues. Certain things aren’t working as expected, like numbered opening counts. We hope to have things settled down in the next week.
Pull request accepted. Give it a shot.
Thanks for reporting and updating firstof9 and Future Tense.
I uninstalled the ingratiation, HACS lock-manager, and deleted all files in packages. Reinstalled, added to Lovelace but still getting same error. Also getting this error:
Its stating scipt.py, and core.py files. That’s a little too deep for me to understand.
I’m sure if I do a fresh HA install it would probably clear, but trying to avoid that as much as possible. Do you think i should just go OpenZWave for future compatibility?
The only error that matters in that shot is the very last line. It says you have the ozw version service call in there, for some reason the ozw service call slid into the regular zwave branch and fuber the service call.
If you’d like to give the new openzwave setup a try feel free, the package works with both.
It does work with both, but make sure you select the matching release.
I’m trying to build the package using the new HACS integration. I had it working fine using the script previously but wanted to add a few more code slots.
I get the following in the logs:
2020-09-02 09:45:27 ERROR (MainThread) [homeassistant.components.template.sensor] Could not render template frontdoor Status Report: str: Invalid domain name 'UC'
It appears the scripts aren’t communicating with the lock. Here’s the Lovelace view:
My thought is that the appropriate script isn’t opening the new slots. I’ve checked the yamls and everything seems to be in order.
what does line 39-40 show in your frontdoor_lock_manager_common.yaml
show?
should be something like:
{% set UC = 'sensor.kwikset_touchpad_electronic_deadbolt_alarm_level_frontdoor' %}
{% set AC = 'sensor.kwikset_touchpad_electronic_deadbolt_alarm_type_frontdoor' %}
Here’s what I have in my yaml:
{% set UC = 'sensor.assa_abloy_yale_key_free_touchscreen_deadbolt_yrd446_alarm_level_frontdoor' %}
{% set AC = 'sensor.assa_abloy_yale_key_free_touchscreen_deadbolt_yrd446_alarm_type_frontdoor' %}
Of note, I also have a sensor called:
sensor.assa_abloy_yale_key_free_touchscreen_deadbolt_yrd446_access_control_frontdoor
that appears as a second option in the integration configuration for the access control sensor. I’ve tried both and get the same results.
Quick question…
So say I needed to remove/re-add the node to my z-wave lock randomly. Would I be able to leave all the settings alone and then just rename all the entity IDs to what they were originally, or would I have to remove all associated files/entities and re-call the service to generate the lock package again? Thanks!