Zwave Lock Manager

[ptdalen]

I hear you. I had never heard of YAML when I started messing with HA last year.

Bottom line, the YAML provided does not do what you asked, but it would not take much work to get what you want. If your goal is just to turn off a security system though, then this is probably overkill. The foundations for what you want are in there though.

Basically you need a trigger. A trigger is what starts the automation

So in this case

  trigger:
  - platform: state
    entity_id: lock.front_door
    from: 'locked'
    to: 'unlocked'

then you need a condition and that condition is your code slot
Not tested but something like this should work

  condition:
  - condition: template
    value_template: "{{ 'user 1' in states.lock.front_door.attributes.lock_status | lower }}"

then your action will be whatever you want to happen, in your case disarm your system. I’ll say if you search the forums you’ll find many examples of doing similiar things that you’ll be able to adjust to fit your needs. Good luck

[ptdalen]

Been there done that. Many, many times. haha

[Motive313]

Thanks again for the help.

[Motive313]

I did have to correct 3 lines in the common lock yaml to match my lock names. My primary issue was that I had configured my uptime sensor incorrectly, and I was completely missing a time_date sensor.

The one time use code uses the uptime sensor as a condition and the google calendar code uses the time_date sensor.

Figured it out and I’m working great now. Thanks again for your hard work and for your help.

Edit: The only odd thing I’ve noticed, is that if I schedule a code for say 4 PM, it doesn’t activate until about 4:04 - 4:08. Are you seeing this type of behavior also, or am I having a possible timing issue?

Thanks.

[ptdalen]

I have seen issues with google calendar. I believe it only updates once every 5 min. But I’ve personally not had issues when the calendar event was in a 5 min increment. Such as 5:05am vs 5:04am.

Glad you got it “mostly” working. I did use input date times on my initial implementation and they worked on a per minute basis. But was not nearly as flexible as the calendar.

[Doranagun]

Its giving no reaction, and it may be due to the way its being created via the automations interface in HA. this is the resultant yaml, minus the action section. I feel like its borking the code somehow.

- id: '#############'
  alias: Disarm Security System on Coded Door Unlock
  description: ''
  trigger:
  - entity_id: lock.front_door_lock_locked
    from: locked
    platform: state
    to: unlocked
  condition:
  - condition: template
    value_template: '{{ ''user 1'' in states.lock.front_door.attributes.lock_status
      | lower }}'

[ptdalen]

Sorry my example may have not been the best

What is the name of your lock?

The entity need to be the name for the trigger and the condition.

Lock.front_door_lock?

[Doranagun]

hah… I didn’t even notice the wrong name in the condition. My error there… I’ve done coding, logic, and other assundry, should have spotted that. oh well… I’ll fix and see what goes.

yea. front_door_lock. very basic… heh.

[Doranagun]

couple questions… the user 1 variable. is that the name i’ve assigned that slot in your lock manager? or is that coming from the lock itself? what is the “| lower” doing?

These codes were set manually on the lock itself. But with a lock manager on Smartthings I was able to see which user unlocked the door with the name I set in that ST smartapp. I have added the code and name to your lock manager. Does it force set those the moment I do that?

value_template: '{{ ''user 1'' in states.lock.front_door_lock.attributes.lock_status | lower }}'

changed to… (based on https://www.home-assistant.io/docs/configuration/templating/)

value_template: {{ 'user 1' in states('lock.front_door_lock.attributes.lock_status') | lower }}

[ptdalen]

Home assistant reports user 1 (or 2 or 3) in that attribute natively. It does not know who is who

Lower just ensures that regardless of the text that comes out fro HA that the value for the condition will be lower case. Saves you from having to worry about case

The info I provided has nothing to do with my yaml colde for lock manager.

[Doranagun]

looking at the .lock_status I have a long text line in the value. is the IN states search for the ‘user 1’ string in the data stored in that value?

[Bartem]

So I have been using the old setup for awhile now, other than the user code/google calendar stuff (and I don’t really use scheduled codes) that changed is there any other reasons I’d want to update?
Been working awesome by the way, thanks for your time!

[ptdalen]

No reason at all. Really just shortened the lock and sensor names, added google calendar, and made the lovelace a little more “responsive”, but the core functionalty has not changed. Thanks for the kind words

[omriasta]

Hey @ptdalen it looks like pyozw was updated to 0.1.7. I was going to fork this myself but I’m not sure what you mean by “HA open-zwave” can you send a link to the GitHub that needs to be cloned or is this now fixed in 0.1.7 and no patch necessary?

[ptdalen]

If I understand this correctly, pyozw is just a wrapper for Open Zwave. About a year or so ago, HA forked Open Zwave to include a few fixes that had not been merged into the Open Zwave. For the most part HA is very close to the 1.4 version of Open Zwave. Version 1.5 is the dev branch, and 1.6 is what will be the next release version of open zwave.

The user_code.cpp is from Open Zwave, not the wrapper.

[omriasta]

so I should keep the openzwave and just change the pip install homeassistant-pyozw==0.1.7 ?

[ptdalen]

If your goal is to get the working user_code.cpp then pyozw will not make a difference. I think so anyway.

You’d want to fork

GitHub - home-assistant/open-zwave: a C++ library to control Z-Wave Networks...

Then add the usecode.cpp referenced above, and update your fork with that, then use that in HA.

Edit: It’s been so long since I’ve done it, apparently it’s both.

Zwave Lock Manager

Back before the Garage Door opener (cover) I am using was fully supported updating zwave was a common thing for a small group of HA users. Basically, I have a fork of the HA open-zwave, I manually updated the usercode.cpp file, I then install that version in my HA instance. It’s actually kind of a pain, because I have to do this almost every time I update HA. These are the basic steps to what you need to do I forked the HA open-zwave I then changed to the HASS branch and updated the usercode…

update for new pyozw version.

[garrettshannon]

There’s a section in common_lock I was curious about:

# this is where usercodes get deleted, for the Schlage locks there seems to be an issue with 
# clear usercode, so this sets a random code, of course that means there is an unknown code in the cleared
# slots.  If you dont like that set a specific code that only you know
    action:
#front Door Lock
      - service: lock.set_usercode
        data_template:
          usercode: >-
            {{ range(1000, 9999) | random }}
          node_id: >-
            {{ states.lock.front_door.attributes.node_id }}
          code_slot: >-
            {% set object_id = trigger.to_state.object_id %}
            {% set code_slot = object_id[7:-19] %}
            {{ code_slot }}

Specifically these lines"

node_id: >-
  {{ states.lock.front_door.attributes.node_id }}

1. Would it be better to use the following?

{{ state_attr('lock.front_door', 'node_id') }}

2. the node_id doesn’t seem to get referenced anywhere else so what is the function of this line?

[ptdalen]

Yeah, I assume that either would work. Also you are correct that this is the only place it’s used. You could even put in the actual node id since it’s only referenced once. That’s actually how i used to do it when I first started. I think the thought was that if I ever wanted to use this elsewhere it would be easier.

edit: I used to have this all in one package, but some people did not care to have to remove all the extra yaml if they only had one or two locks, so I tried to separate it out as much as possible. The node_id is used in each individual lock package as well. It actually used 4 or 5 times in the individual lock packages

like this

    action:
      - service: lock.set_usercode
        data_template:
          node_id: >-
            {{ states.lock.front_door.attributes.node_id }}
            
          code_slot: >-
            {% set object_id = trigger.to_state.object_id %}
            {% set code_slot = "_".join(object_id.split("_")[2:-2]) %}
            {{ code_slot }}
          usercode: >-
            {% set object_id = trigger.to_state.object_id %}
            {% set code_slot = "_".join(object_id.split("_")[2:-2]) %}
            {% set user_code_id = 'door_keypad_' ~ code_slot ~ '_code' %}
            {{ states['input_text'][user_code_id].state }}

[garrettshannon]

Ah got it; (again very new at this) looks like the service “lock.set_usercode” needs a node_id, code_slot, and usercode. code_slot and usercode are set dynamically with a template. Previously you had hardcoded the node_id but the new version uses the state attribute to pull the node_id instead. This way if you ever re-configure your zwave network and your locks end up in different nodes nothing needs to change with your door locks code.