KeyMaster Z-Wave lock manager and scheduler

FutureTense · July 2, 2020, 2:51am

What repo did you use for the OZW beta?

firstof9 · July 2, 2020, 2:53am

I use the docker image that Fishwaldo puts out: docker pull openzwave/ozwdaemon:allinone-latest

FutureTense · July 2, 2020, 10:23am

I’m not surprised. I knew (but failed to document) that loading times can be painful. This is part of the reason that my recommended method of adding the GUI is to use an entire view. You should only load this GUI when you actually need to use it.

Have you narrowed down what elements are actually slowing down load times? If you’ve managed to find a solution I’d be happy to update the package.

FutureTense · July 2, 2020, 10:29am

~~I assume you’re also using a container for home assistant. Can you share how you’re firing that up? Especially any docker-compose files.~~

Ah, the beta exists in integrations already. Did you have to disable the non-beta integration first?

After adding the beta integration, do you see multiple “lock” services? For example, lock.clear_usercode is not working in the standard integration, but you said it’s working in the beta for your kwikset lock? Are they named the same way?

firstof9 · July 2, 2020, 2:59pm

Yes, I also moved my Home Assistant to a docker container on one of my servers, my Zwave is now decoupled from my HA and running on the rPi3 that used to host HA as well.

No currently you only get lock.lock, and lock.unlock. I can manually add/remove user codes via MQTT.

I’m going to try to see if I can whip up a PR for user codes.

champ26 · July 2, 2020, 4:06pm

With my UI updates that I posted yesterday, the front end loading is nice and quick on low-end hardware. On high end hardware it’s negligible. A ~1 second delay on the lock config page load and 1-2 seconds on the specific code edit popup.

Regarding the actual HA z-wave load, after some monitoring, it’s only an extra minute or two to finish z-wave starting, and that’s fine considering I normally don’t restart HA, except when tinkering.

But as I mentioned yesterday, decoupling the Lovelace page with button cards from the actual popup of code config data made a big difference.

Thanks for the awesome package!

firstof9 · July 3, 2020, 12:13am

So when I delete a use code this happens:


2020-07-02 16:59:17 DEBUG (MainThread) [custom_components.ozw] [VALUE CHANGED] node_id: 14 - label: Alarm Type - value: 33 - value_id: 144115188316782609 - CC: CommandClass.ALARM,
2020-07-02 16:59:17 DEBUG (MainThread) [custom_components.ozw] [VALUE CHANGED] node_id: 14 - label: Alarm Level - value: 3 - value_id: 144396663293493265 - CC: CommandClass.ALARM

Alarm Type: 33 (User Deleted)
Alarm Level: 3 (Code Slot)

This happened when I deleted code slot 3. Guess that could be used to verify the code’s been wiped.

Edit: PR’s in.

FutureTense · July 4, 2020, 2:10am

I’m going to be afk for a few days. My NUC got hit by ransomware. Little f’ers

sean76 · July 4, 2020, 7:35pm

bummer.

sean76 · July 4, 2020, 9:16pm

First time posting here and there’s a LOT to read through in this thread so apologies if I missed something relevant. Moved to HA from Wink only about a month ago so I’m an HA noob. Be gentle.

I have a single Kwikset 916 lock. First and only lock I’ve ever played with. I’ve got HA running in Qemu on my NAS. It’s the default HASSOS 4.10 (4.11 was JUST released but I haven’t updated yet). It’s a VM that is a very stripped down OS that just runs docker. It’s what you end up when you follow the guides and download their images for running it as a VM. You can’t install gawk or any packages that I can see in that OS so I fired up Debian on WSL and did an apt-get install gawk and after considerabke mucking around was able to get a clean run of setup.sh then moved that folder into my HA’s packages folder and it all looks good.

Incidentally, to sum up the problems people are having with setup.sh I think they seem to be one or more of these:

No gawk and no way to install it.
They are using the shell you get from TMUX using the Terminal/SSH add-on which seems problematic. It loads Busybox which does not get hung up the below array creation but again no gawk.
Using the terminal directly from HASS OS produced different results. It errors out on the “(” in files=(*.ini) whatever version of BASH that is does not apparently like using () to create arrays. files=*.ini works but does not create an array so the for loop hates it. Probably would have gotten hung up on no gawk anyway if it had gotten that far.
As someone else pointed out sensorname= default contains spaces and caps so it makes you think it’s just a friendly name thing that can have spaces in it but this does not bode well with setup.sh. I would change that default or add a comment to the FrontDoor.ini
The error message in your else statement lock_manager.ini is incomplete or does not exist is kind of misleading. I spent some time looking around for this missing ini file before I realized it was just the generic error that’s thrown when parsing the ini files fails and has nothing to do with a specific ini file. I think this error should be changed to “Problem parsing your ini file(s). Please check the syntax and make sure you have gawk installed.” or something similar.

There are too many different ways to run HA me thinks. So perhaps a different, more universal, setup script might be in order but it’s way out of my league to come up with one. Not sure if HASS OS is also what gets used on the Rasberry Pi loads but if it is that would explain a lot. I think that’s probably the most popular deployment.

One other small thing I noticed was for notifications you use notify.my_devices which doesn’t work on my system. I’m guessing it’s a custom array you setup? I don’t know but changing that to my specific phone worked. I don’t know if there’s a universal value here that would work for any user that might be better or if it should be made into a part of the GUI to choose notification devices. Just thought i’d point out that you’re probably publishing something that only works for you.

Anyway, my real reason for posting is that I’m very very close to having this running perfect but I need some help debugging. The GUI is all setup fine. I did the bits with the input_booleans and all that is fine. But the automations never seem to trigger when I set the codes in the GUI. When triggering the Add codes automation manually it still does not set the codes. However, I can go to the node under Z-Wave and Node user codes section and program it fine there. Also, can go to Developer Tools -> Services -> lock.set_usercode and program it using that tool. My lock (I have no idea about others) requires the codes be converted from ascii and sent as hex in this format: \x31\x32\x33\x34 (which is “1234”). Even in the lock.set_usercode service I have to do usercode: \x31\x32\x33\x34.
Is this just my lock or does everyones locks send the codes as hex?

I assume the add usercode automation is supposed to be triggered after you set a pin and toggle enabled right? The execution time does not update on it though. Manually executing it does not set the codes either although i’m not sure if it’s supposed to work like that or only be triggered by the GUI?

So I guess I’m wondering where I should start debugging here. Is there a log I should be looking at? Do I need to figure out how to modify the code to convert the ascii to hex? I’m a sysadmin by trade and not a developer but I could probably hack that out but I think i’m getting hung up somewhere before that process.

I’m using PowerShell to convert the ascii to hex in the format it wants and then paste that into HA:

Function MakeHexforDoorLock { Param([string]$Code); (format-hex -InputObject $Code -Encoding ascii).HexBytes -split(" ") | %{ write-host $('\x' + $_) -NoNewline }}
# then run it like so:
MakeHexforDoorLock -code "1234"
# Output:
\x31\x32\x33\x34

And that’s how I’m setting my codes right now which works but I’d just love to get this GUI up and running 100% with the scheduling and guest codes, etc.

Thanks for reading my small novel. Any help is appreciated.
-Sean

sean76 · July 4, 2020, 9:28pm

One follow up thing I noticed was that while lock.set_usercode service seems to work fine when I pass the correct hex code values, running lock.get_usercode does not seem to do anything. I don’t see anything happen in the OZW log like I do when I trigger lock.set_usercode. Are these services part of this project or built into the system? Do I need to fix the lock.get_usercode first? Is that my real problem? and where would I look at that code?

firstof9 · July 5, 2020, 3:28am

Pass the value as a string or int, not a hex value.

They are a service provided by the zwave integration. Short answer: yes the system.

No

You can’t really in that version of zwave.

In the ozw beta that’s being tested, all the usercode commands work as advertised. (stay tuned on that).

sean76 · July 6, 2020, 4:06am

Thanks for your reply. I see you are right about lock.set_usercode. The hex values are needed only when I program directly from the zwave integration.

But what about the automation? They should work to program whatever codes I have entered into the GUI and upon enabling a code the automation should be triggered right? So it seems I have two problems. The GUI isn’t triggering the automation and the automation doesn’t work when triggered manually. I guess i’ll start there. Thanks.

firstof9 · July 6, 2020, 5:26pm

Depends, they should set, but if there’s an error for some reason, it won’t trigger and set the codes. Check your home-assitant.log for errors regarding the automations.

firstof9 · July 7, 2020, 11:54pm

There will be a breaking change for this package in ozw.

Example:

      - service: lock.set_usercode
        data_template:
          node_id: >-
            {{states.lock.kwikset_touchpad_electronic_deadbolt_locked_frontdoor.attributes.node_id}}
          code_slot: >-
            {% set index = 17 %}
            {% set object_id = trigger.to_state.object_id %}
            {% set code_slot = object_id[index:] %}
            {{ code_slot  }}
          usercode: >-
            {{ range(1000, 9999) | random | int }}

This will need to be changed to:

      - service: lock.set_usercode
        data_template:
          entity_id: lock.kwikset_touchpad_electronic_deadbolt_locked_frontdoor
          code_slot: >-
            {% set index = 17 %}
            {% set object_id = trigger.to_state.object_id %}
            {% set code_slot = object_id[index:] %}
            {{ code_slot  }}
          usercode: >-
            {{ range(1000, 9999) | random | int }}

FutureTense · July 9, 2020, 3:18pm

From node_id to entity_id?

firstof9 · July 9, 2020, 3:21pm

Correct, you can also send it a list of locks to update, so you can bulk add/remove codes if you like.

FutureTense · July 9, 2020, 3:25pm

Maybe you can help me get the new OZW installed? I’m using a docker setup btw.

firstof9 · July 9, 2020, 3:30pm

I use docker-compose to manage mine here’s an example you can use to fire your’s up:

version: '3'
services:
  ozwd:
    image: openzwave/ozwdaemon:allinone-latest
    container_name: "ozwd"
    security_opt:
      - seccomp:unconfined
    devices:
      - "/dev/ttyUSB0"
    volumes:
      - ./ozw:/opt/ozw/config
    ports:
      - "1983:1983"
      - "5901:5901"
      - "7800:7800"
    environment:
      MQTT_SERVER: "192.168.0.1"
      MQTT_USERNAME: "my-username"
      MQTT_PASSWORD: "my-password"
      USB_PATH: "/dev/ttyUSB0"
      OZW_NETWORK_KEY: "0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00"
    restart: unless-stopped

I put my ozw in /opt/ozw on my ‘DockerPi’ and I renamed my device to /dev/zwave

    devices:
      - "/dev/serial/by-id/usb-0658_0200-if00:/dev/zwave"
    volumes:
      - /opt/ozw:/opt/ozw/config
...
      USB_PATH: "/dev/zwave"

FutureTense · July 9, 2020, 4:07pm

That MQTT Server is the one that you were using before?
What’s the /dev/ttyUSB0 used for? How does that compare to the /dev/zwave you have below? I take it you renamed it so you didn’t have to modify your existing docker-compose?
Is the network key the same one you used for the older OZW?