Please can the following change be made, and if not please can Hubitat Opensource the BE468/BE469 built in driver to enable the community to make the change instead.
At present the lock / unlock methods in the built in BE468/BE469 driver does not accept an optional pin code. Therefore when calling from voice assistants (e.g. Google Home) the lock method fails as the driver lock method is not expecting a pin code parameter.
@skippy76 I don't think that particular think is available in the z-wave api... You could probably write a secondary app that calls that and then write an amazon skill to parse it.
Can't speak to Google Home, but on Alexa, the PIN for a lock is a setting in the voice assistant itself. It does not use the PINs you may have configured on the lock itself. This isn't really relevant to Hubitat at the moment because I'm pretty sure it doesn't support locks (Google Home or the community integration might?), but that's the way it would work if it did. 
Further, in the Hubitat lock capability, the lock() and unlock() commands indeed do not take PINs because they will just lock or unlock when the command is called. Again, the configured PINs are for on-device use. It feel like something else might be going on in your case. If you're getting an error, consider showing the log entry here.
I completely forgot about that (mainly because I don't use it) I'll have to note that for the future...
In the case of Google, the PIN gets passed through the unlock / lock event. Specifically the device Trait configuration states if the device requires a pincode to unlock (and lock), Google just passes through the captured code.
This leaves the responsability for validation to either Hubitat App or the device itself. I am using the Google Home Community App which provides the ability to either:
In the case of (2), the pin codes are configured through the app and is less ideal as they are duplication in configuraiton.
In the case of (1), the GHCA passes the pin code through in the lock / unlock command to the driver with the intent that either the driver validates the pin code or the actual device itself.
Hm. So this wouldn't be a problem specific to Schlage locks; the standard Hubitat lock() command just doesn't take any parameters. See: Driver Capability List - Hubitat Documentation
It looks like the app is actually passing the code position rather than PIN? (Line 2155 which gets called from the method at 2360? Just a cursory glance at the Groovy, as I'm not otherwise familiar with this app.) Validating the PIN seems like something the app should do on its own--and it seems like it basically does except it still passes the code position. Maybe it's trying to simulate a physical unlock (possibly triggering the same automations)? But again, this won't work with standard commands. It might be a neat feature request for extension (simulating a "virtual" unlock with code from the hub rather than a physical keypad unlock), but it's just not how the capability works now and I'm not sure why the app would be written like that if what I'm seeing is correct. May be a good question for the author.
But I guess to go back to the other part of the question, most Hubitat drivers are closed source, and this is not one they've released as an example. So, modifying it is out of the question. Creating your own isn't, but I think I'd still prefer to have an app work within the capability definitions instead of going this route anyway.
Interesting. I'm unaware of a z-wave/zigbee lock that supports a digital lock/unlock with a code. I am under the expression that codes were always used for physical unlock (and more rarely lock).
Great points and feedback, thanks to everyone for thoughts and info.
So for now this sounds like an issue with the Google Home Community App impelmentation for lock / unlock. I will follow up seperatly.
Download the Hubitat app
