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"
1 Like
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.
1 Like
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.
1 Like
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.
Ah, but he’s saying he cleared a code with zwave. I’ve never seen that work. But I suppose I can add a clear call after it does a random number. It wouldn’t hurt anything.
@crackers8199 I went ahead and added the clear_usercode call at the end, so it will randomize your lock then call the clear function. If you can call it manually and it works, then this should work for you.
https://github.com/FutureTense/lock-manager/releases/tag/v0.0.29. You should be able to update in HACS
1 Like
thanks!
the strange thing is that i got different messages in the zwave log from time to time, but each time it still did seem to clear the code.
I’ve commented on this many times in the past. Yes it does mean a code is in your door that you dont know that someone could guess, but it does not keep adding random codes for every erase, just per slot. So if you had 30 codes programed and then “cleared” them with random codes, you’d still have 30 codes in your lock. If you set and rest them 50 more times, you’d still only have 30 codes in your locks. Of course if you’re like most people you’d probably only have 10 or so codes in your lock. A person could randomly guess a valid code too.
Also I suspect most locks are like this, but I can only speak for schalage. After the 3rd failed attempt there is a time out period of a minute. Additionally if you set an alarm mode on your lock (be469 anyway) you can get a loud 100DB alarm when that happens as well.
So while it’s not ideal, it’s not a huge security risk, IMO. But as @firstof9 says, the newest version works correctly.
EDIT: and I see clear code seems to work with your lock. It definitely did not work with the schalge locks on the older zwave implemation, but I had head as already mentioned, that some locks did work. Easier to code for a solution that works for all than works for some. Once you get a greater understanding of the background automations, and sensors in the code you can change it to do exactly what you want. 