RBoy
(www.rboyapps.com - Making SmartThings Easy!)
2401
Whenever you change drivers the platform automatically clears all user entered data (names). You can always rename them directly from the SLGA app (the codes remain in the lock and the driver discovers them automatically when installed), names however aren’t stored in the lock so the driver has no way to discover them, the user will need to correct them in SLGA.
The driver supports scenes, routines and automations and also adds many more features which aren’t available in the stock driver to use in scenes and routines (like auto lock, keypad controls, tamper alarms, built in alarms, one touch locking, invalid code notifications etc). Eg you can create a routine to get a push notification when someone enters an invalid code and also have the routine disable the keypad on the lock at the same time or increase the built in alarm sensitivity. A routine can also be used to change the build in alarm levels for Schlage locks at pre defined times, eg at night activate alarm and in the morning change from alarm mode to alert mode. Hundreds of combinations possible.
It also has fixes for many bugs in the stock driver related to missed notifications, incorrect code reporting, out of order packet ordering, improved battery life for Yale locks and more
Essentially everything the stock driver does (100% backward compatible) + new features and bug fixes.
My locks are still on the Rboy DTH. Rather than exclude one, could I just delete it using Taustin’s SmartThings API Browser+? Would that work? Or would deleting it from my Hub just cause me issues trying to add it back? Thanks.
Yeah but since SGLA doesn’t let you see the code, only the name, you don’t know which name to change “Code 1”, “Code 2”, etc back to. And the other functions were grayed out, so I decided to just follow along here and try again later.
Yeah, if you are going to change drivers, best to screenshot SLGA, write down the code to name association, or capture it from the ST CLI. The driver is responsible for maintaining the lockCodes capability where the name to code relationship is maintained.
bep@debian10:~$ st devices:capability-status 65
───────────────────
# Id
───────────────────
1 main (default)
2 settings
───────────────────
? Select a component. 1
────────────────────────────────────────
# Id
────────────────────────────────────────
1 battery
2 lock
3 lockCodes
4 platinummassive43262.unlockCodeName
5 refresh
────────────────────────────────────────
6 tamperAlert
────────────────────────────────────────
? Select a capability. 3
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Attribute Value
codeLength 6
maxCodes 30
maxCodeLength
codeChanged "5 set"
lock
minCodeLength 8
codeReport
scanCodes "Complete"
lockCodes "{\"1\":\"Bruce and Teri\",\"2\":\"Gladys\",\"3\":\"Sean\",\"4\":\"Studio Guest Laundry\",\"5\":\"Jeremy\"}"
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
I’ve had luck using the graph.api site to change the device type to the stock “Z-Wave Lock” driver. From there I was able to enable rboy’s beta driver and switch in the app without ever deleting any of my locks.
You were able to change the DTH driver to an Edge driver using the browser API? I didn’t think that was possible unless Samsung already changed it. I’m still using Groovy DTHs.
Using the old graph.api.smartthings.com site, I changed the “Device Type” field to the new “Z-Wave Lock” type. That, I believe, is one of the many new edge drivers.
Once I did that, everything continued to operate normally, but then I could enroll and switch to rBoys beta drivers. No lost codes or zwave setup hassle.
Pre Edge transition I had changed it to rBoy’s groovy universal smart lock driver. After the transition, all the custom groovy device drivers were no longer an option, so the word “Placeholder” was selected. I imagine that was a result of ST’s automatic migration to the Edge driver.
I saw no change when I flipped it to “Z-Wave Lock”. Though I can preface that statement that before they shut down Groovy, I tried several of the “Z-Wave Lock” variants, and the only one that would program correctly with LUM (when it still worked) was the “Z-Wave Lock” type. The with codes or without codes variants both didn’t work.
This driver is intended as 1) an Edge driver replacement for their former DTH; and 2) an Edge driver that provides more capabilities and settings than the stock lock Edge driver. It has no relationship to LUM or RLA at the moment since there are no replacements for them in the new architecture.
@gjanes, @jkp is correct. I think there’s a confusion in the names used for each platform. So, here’s more info for some clarification:
All the options that you can select for “Device Type” in the IDE are a DTH, not a driver
Even if you change the option selected there to “placeholder”, it won’t be moved to a driver, you must reinstall it for that purpose through the app
a. In this option, you need to make sure one of the ST drivers support your device or that you already installed the custom driver that does
You can check which drivers you have installed easily from the app. To do so, follow these steps:
a. In the ST app, go to the Hub and enter its details
b. Click on the menu (three-dot symbol in the upper-right corner)
c. Select “driver”.
You’ll see the list of installed drivers and the channels in which your Hub is enrolled
To quickly check what’s controlling the device, if you enter its detail view, go to menu and you don’t see the option “Driver”, it’s likely using a DTH, otherwise you’ll be able to see which driver is controlling it.
Another option is to query the API and the tool mentioned by @jkp can help you check that (API Browser). In case you can use the console of your operative system, you can install the SmartThings CLI.
