Use the virtual lock driver to understand what is missing from the community driver that you’ve been using, because the latter seems to have everything else you want besides LCM compatibility.
And the bits that are missing are unlikely to have anything to do with zwave or zigbee.
Is there something that secretive in the built-in zwave that it can't be shared?
The only drivers shared are those on Hubitat’s GitHub repository. And honestly, in this instance, what is available on there is sufficient to help you fix the community driver that supports the Lock features you want.
Yes, it's hard coded. All code part of the platform is proprietary and not open for examination. Hubitat is not an open source platform.
Such inviting responses from "Ambassadors" of the platform. I wasn't asking for source code to the whole system. A base driver that works with physical hardware is a reasonable ask.
No offense, but as @rlithgow1 indicated, this is not an open source platform.
And as I indicated, since you already have the source for the community driver that has the features you need, and Hubitat Inc. have published their virtual lock driver, you can, if you wish, edit the driver you have to make it compatible with LCM.
That has been made very clear. I would imagine the interaction here is likely why there aren't more community drivers.
More like no one has run into your issue before and commented on it. I'm sorry if you take someone not having something available as an affront. Everyone has offered you options and it seems that's not good enough... I would follow @aaiyar's advice and see what you come up with.
I was actually being totally sincere in suggesting you take a stab at fixing the community driver you have.
Three years ago, I needed a momentary zigbee switch driver for a Securifi Peanut plug. I put one together using a SmartThings DTH, examples from Hubitat’s GitHub, and help from a community member (@ogiewon - wonder if he remembers!).
Just this morning, I modified a community zigbee valve driver to add a capability, remove two others, and add a user-configurable polling interval.
You actually have all the tools you need to make your existing community driver compatible with LCM. And if you get stuck, create a new thread here, and I’m sure someone will pitch in to help you.
Taking that first step is entirely up to you, and I would argue in your best interests.
I’ve never read that particular sentiment before. There are literally thousands of community apps and drivers. And more added all the time.
I am not taking issue with the troubleshooting provided, it was helpful and I worked through the issue on one of the two locks affects. The frustration is not having true base drivers to start from.
The tools are there but it still lacks a true base driver. I understand I can go create my own drivers and I will when I can do it against a lock that isn't installed, If it was just enhancing something existing it would be a different story, it is modifying a crippled driver to make it match functionality of a black box so that features can be added. Additionally the underlying black box can be changed in a way to break any enhancements. From the changelogs I have read there is not sufficient detail to know if LCM or other required components have changed to the point of breaking lock functionality.
I can certainly program a driver, I just would prefer to not do it blindfolded with one hand tied behind my back.
The lock stuff in the github repository uses standard lock commands that the yale, schlage, etc already follow. You should be able to hit Yale up for anyother z-wave parameters available to the lock. The community driver code should be following those command parameters. So you're not exactly working blind. Doing a structure comparison between the lock code in the hubitat github and the community driver should help you solve it fairly easy...No need to write an entirely new driver, simply fix the community one. Hubitat's native driver will follow the coding that's in the repository
Again. The virtual lock driver should give you all the information you need vis-a-vis requirements in a driver for LCM to work.
If lock, unlock, setCode, and deleteCode works with your other driver, you're well on your way to creating what you need.
If these commands don't work, then start a new thread linking to, or posting, the community driver you want modified. Indicate what works and what doesn't, and it is very likely that someone will chip in to help/assist.
Edit: whatever LCM needs hasn't changed since at least early 2019. Also, AFAICT, LCM only requires that the device support setCode(), getCodes(), deleteCode(), and setCodeLength(). These are basic functions in any lock driver.
Download the Hubitat app
