Out of the blue I can't open Lock Code Manager on a hub. I have other hubs with the same firmware version working fine. The error received is "Error: No such property: name for class: java.lang.String" and then in the logs it says "groovy.lang.MissingPropertyException: No such property: name for class: java.lang.String on line 1302 (method main)"
Anyone have a fix or workaround?
Platform Version: 2.3.0.124
HW Version: Rev C-7
can you check the codes on your locks (from the lock driver details), are there any with a blank name?
All have names.
try removing LCM, then re-installing it. You won't loose any of your lock codes, if you have scheduled lock codes enable/disable setup these will be lost however.
I do see a lock with a code that is just a string and not an object. How can I clear that?
When I try to delete the bad code from the device page I get the following error in the logs
org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object '' with class 'java.lang.String' to class 'java.util.Map' on line 745 (method parse)
You're going to have to remove and re add the lock.
Were you using a custom driver at some point?, I don't understand how the bad code got in there...
Briefly there was another built in driver used, likely the cause of the issue. Why does the lock need to be re-added to solve it?
i can't think of any other simple way of clearing out the bad code
Couldn't I use the menu on the physical lock and clear all programmed codes?
that will clear the codes in the lock, it may not clear them in the driver, can't hurt to try that first...
I changed the driver back to the basic built-in one. Should I have kept it on the specific built-in one?
I changed it back to the Yale Lock (from user repo apparently) and was able to delete the bogus code. I then changed it back to the generic built-in one and lock code manager loads again.
It is frustrating that the lock specific support is limited and the lock specific ones out there don't work with lock code manager.
All the Hubitat supplied lock drivers work with lock code manager.
Yes I understand that but the supplied lock drivers fail to implement some of the additional features that many of these locks provide. Therefore the built-in lock drivers are lacking beyond the basic.
I would contact the authors of drivers that are problematic with LCM and have them fixed...
I would be happy to add the features myself if there was a working base to start from but it appears the built-in drivers are not accessible for enhancements.
Totally confused by what you’ve just posted. Do you not have the code for the community drivers that you’ve used?
Look at the virtual lock driver on Hubitat’s GitHub repository, and see what’s done incorrectly in the community driver you’re using.
Why would I want to start from something that I have provide is broken with LCM?
Is the virtual lock driver the same thing as the zwave built-in driver? If not it would be again starting with something that is incomplete.
Download the Hubitat app
