What does your input_boolean.allow_automation_execution
state show?
wait, can’t i just use the lock.clear_usercode service? HA exposes this in the dev tools…
edit: nevermind, i see now there are many threads on the issues with this. i’m not at all familiar with MQTT though, so i’m having issues following the guide on this. ugh.
Change the door sensor to the “fake” one for now. I think it’s at the bottom of the dropdown
Are you using docker? If so it’s pretty easy.
You need to add the following:
binary_sensor:
- platform: template
sensors:
allow_automation:
friendly_name: "Allow Automation"
value_template: "{{ is_state('input_boolean.allow_automation_execution', 'on') }}"
Then from the UI you can add the input_booleans:
allow_automation_execution:
name: 'Allow Automation'
initial: off
system_ready:
name: 'System Ready'
initial: off
as well as some automations:
automations:
- alias: zwave down
initial_state: true
trigger:
- platform: state
entity_id: binary_sensor.ozw_network_status
to: "off"
action:
- service: homeassistant.turn_off
entity_id: input_boolean.allow_automation_execution
- alias: zwave up
initial_state: true
trigger:
- platform: homeassistant
event: start
- platform: state
entity_id: binary_sensor.ozw_network_status
to: "on"
condition:
- condition: state
entity_id: binary_sensor.ozw_network_status
state: "on"
action:
- service: homeassistant.turn_on
entity_id: input_boolean.allow_automation_execution
and a mqtt sensor:
binary_sensor:
- 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"
lock.clear_usercode seems to work on my yale YRD446. i tested it a few times last night and it cleared the code every time.
i can see the spot in the code that does the clear, so i know where to go to change it (i think) if i were to branch or fork and make that change…but how do i get the new code installed then?
I added some automations and a script in the top post that should handle making sure `input_boolean.allow_automation_execution’ is disabled when HA starts, and is enabled after your Z-Wave network starts. This should work for both zwave as well as ozw.
Please tell me if you find any problems and refer others to this. I probably should get this added to the README.
Most of the zwave locks we’ve come across have either the older alarm_type
sensor or newer access_control
sensor.
I believe there is a standard that the sensors should return the same values regardless of the lock manufacturer. You can see these values by looking at line 203 here. The first block is for alarm_type
locks and the other is for access_control
. When you are specifying User Code
and Access Code
in the lock-manager integration options, you should be able to select the available sensor. Matter of fact, for Access Code
I believe it will only give you one option to choose from. In other words it might just work without any changes.
Open up your zwave integration and find your lock. What sensors does it have?
i apologize but i’m not following any of what you just asked…
is this what you’re looking for?
zwave.assa_abloy_yale_key_free_touchscreen_deadbolt_yrd446
Z-Wave
Assa Abloy Yale Key Free Touchscreen Deadbolt (YRD446) Access Control
sensor.assa_abloy_yale_key_free_touchscreen_deadbolt_yrd446_access_control
Z-Wave
Assa Abloy Yale Key Free Touchscreen Deadbolt (YRD446) Alarm Level
sensor.assa_abloy_yale_key_free_touchscreen_deadbolt_yrd446_alarm_level
Z-Wave
Assa Abloy Yale Key Free Touchscreen Deadbolt (YRD446) Alarm Type
sensor.assa_abloy_yale_key_free_touchscreen_deadbolt_yrd446_alarm_type
Z-Wave
Assa Abloy Yale Key Free Touchscreen Deadbolt (YRD446) Power Management
sensor.assa_abloy_yale_key_free_touchscreen_deadbolt_yrd446_power_management
Z-Wave
Assa Abloy Yale Key Free Touchscreen Deadbolt (YRD446) SourceNodeId
sensor.assa_abloy_yale_key_free_touchscreen_deadbolt_yrd446_sourcenodeid
Z-Wave
That’s the one! Specify that as your “Access control sensor” in the lock-manager options.
Use sensor.assa_abloy_yale_key_free_touchscreen_deadbolt_yrd446_alarm_type
type for “User code”
I don’t have this lock, but @firstof9 does, so he can help out.
i’ve already done that. i’m trying to avoid having it clear a code by generating a random code, i want it to actually clear the code…
Are you using ozw?
no, native zwave
i had seen those reports as well…but i can confirm (at least on my particular lock) that when i run lock.clear_usercode from dev tools, it does work to clear the code. unless it’s doing something similar and creating a random code to overwrite, it is working. if i enable the slot via lock manager, and go to the lock and test, it works (as expected). if i then leave it enabled but go into dev tools and run lock.clear_usercode on that slot, the code no longer works…so it’s definitely clearing the code somehow.
From what I recall, it used one method to clear codes that only worked on specific locks.
1.6 clears for all locks.
okay, that explains that then…but how can i modify the lock manager code to use that service rather than setting a random code?
seems like that would be an easier change to make than to try to set up ozw right now (i’m trying to wait until i absolutely have to, as i’m not at all familiar with mqtt and i don’t really have the time to figure it out right now)…
Is 1.6 distributed now?
1.6 Is what the docker container’ed ozwd is.