Zwave breaks out the user codes on locks into their own value. I’ve been working on integrating those into my setup as component that extends from ZWaveDeviceEntity and Entity. I think I have something that works well (haven’t worked on the front end yet) so I’d like to work on adding it into the general ecosystem.
To really integrate though, I’d be interested in figuring out if a ‘usercode’ generic component makes sense or if it would be more useful to combine it with the ‘lock’ type in the same way that ‘climate’ combines several pieces (a mode, a set point and a sensor reading). The obvious issue is that all locks may not have user code available to set.
I see that you’re coming from a Vera background, too.
Z-wave lock handling is the one thing that has me still tied to my Vera. For user code management, as well as userID callback notifications on unlock.
This feels tightly tied to Z-wave locks. Do you have any other situations where you’d manage this kind of code in a way that’d make it make sense to go with some sort of platform just for the codes (where things would be general enough)?
Yeah, that’s kind of my feeling too, specific to a subset of Z-Wave locks. Doing a cursory search at what’s available now is showing more ‘smart’ locks moving to other forms of authentication like fobs, bluetooth, NFC, etc. And some of the other locks with keypads on other platforms like Insteon don’t appear to let you set codes remotely. I imagine that setting up NFC based authorization will probably require the user to have the device near the lock (or custom controller) to setup not something done through an average HA setup at this point.
Trying to think generally, I guess I don’t see a fit for a generic lock code setting/clearing. The only general case would be for logging information about people entering. The question would be, are they just 1) new sensors, 2) decoders in other devices (like locks) that put events onto the bus when they detect something or 3) something else? I’m not sure if sensors fit as they are noting discrete events that occur, not a state. i.e. when the same code is entered at the same lock several times in a row, that is 3 events, not a constant state.
For now, I guess I will finish off the code/events and the front end piece and offer up the code as a custom_components option for zwave folks with similar locks.
Right now I log/notify from my custom_components/locklogger.py component (see the github link). Its specific to my lock type (older Schlage units) though and I’m convinced that because its old, its not the standard, just what ever Schlage came up with at the time. I really don’t know what I always get caught in the first adopter trap.
Once I get the frontend panel working, I’ll post instructions, etc in the “Share your Projects” section. Adding decoding for other locks would be pretty easy with the openzwave log information. The only really missing piece in pyopenzwave is that they don’t expose the CommandClass objects which sometimes has some useful data.
@drytoastman I know I am late here but do I understand correctly in that you have a way to set user codes for older Schlage Smart Locks in HA? I have three of them suckers (FE599) and am also tied to Vera because of it. I’d like to get those locks over into HA but I like the convenience of being able to set user codes, which I do use not terribly frequently, but I do use it.
So you think the trend is more towards the presence type locks? Using Bluetooth or similar close range technologies? Any of those working well with HA that you know of or anyone know of?
I posted some more stuff with my work in a new post. You can see the details there. As for what’s coming down the line, it seems more NFC related but who knows. My old Z-Wave locks work just fine.
