I consider proper lock management one of the biggest missing areas from Home Assistant. I found @ptdalen’s excellent Zwave Lock Manager and used it for a time but ultimately, I don’t like storing state in input fields and I really dislike trying to program in yaml. So I decided to write a quick and dirty lock manager in node-red. It turned out to be a lot bigger than I initially thought.
My goal was to create a simple user interface that would allow me to manage users and codes. I didn’t want to have to deal with or remember which user went with which slot. I also needed to have schedules and one-time codes. It needed to be simple enough that my wife could use it without me having to explain it to her. From there I decided to encrypt my data. If someone got my mongo instance I didn’t want them to see users or codes. I then decided to log everything because if I had a db, why not log? Then I decided to build notifications so I could see lock usage on my phone but when that got too noisy I created flags to only show certain notifications. Anyway, it stopped being simple somewhere along the way.
Here’s the github repository. The README should hopefully be good enough if you want to clone and use it. https://github.com/jayheavner/lock-manager
I’m using Docker, mongo, and a node-red instance specifically for this project. If you’re running Hassio and need to import this into that node-red then you might want to hold off. It may work but it may not. I’m planning on building a simpler version that strips out the encryption, logging, db dependency, etc.
The current implementation of z-wave in HA doesn’t handle lock.clear_usercode. You have to build your own version. I’ve tried to account for folks who can’t use that service call but I haven’t tested it thoroughly. Probably the biggest hurdle was consistently writing and removing codes from the lock. It’s still not what I would consider 100% reliable.
This only works with one lock because I only have one lock. It should scale to work with multiple assuming that all locks use the same codes.
This works with the Schlage Connect. It should, in theory, work with other locks but I haven’t tested that.
Finally, this is very much a work in progress. I’m using a concept of slot_offsets to protect immutable users and codes. This code will not touch any slot lower than the slot_offset value. This also means those codes aren’t written to any table or log, ever. I strongly recommend putting your important codes into these slots and protecting them.