Hello. I’m trying to harness an extra event data property. I saved a rule and then triggered it to check the log. I’m trying to use “isPhysical” to see if it’s false, but I’m not doing it right, I just don’t know what to properly label the context variable has. Any help is appreciate, here is the log output.
SmartThings is kind of in a funky spot as they are partially between their transition out of Groovy. So normally I would have recommended checking the SmartThings IDE, but it’s really not going to be a sustainable approach moving forward since they’re going to shut it down.
If you don’t recall explicitly installing a Device Type Handler (DTH) or Driver and the lock wasn’t added really recently, it’s most likely using a stock Groovy DTH for now.
Back to your original question, I would check what the event looks like when you unlock with various methods: from the keypad, physically from inside, from the mobile app, etc. If it reports different things in the special ‘data’ property based on those different cases, you might be able to check for the presence or absence of whatever is included.
If you’re on a EDGE driver, you can use the SmartThings app. Click on the device, then on the three dots in the upper right hand corner. If—and I repeat, if—there is a line there that says “Driver,” the device is using an EDGE driver and tapping “Driver” will tell you which one (and allow you to change to another EDGE driver, if one is available.
If there is no “Driver” option, the IDE can still be used to identify the current groovy DTH, but as Josh mentions the IDE and groovy will be gone around the end of the year. Another option is to use the SmartThings CLI (command line interface), which is very useful and not nearly as intimidating as it may look at first.
My guess, based on the data response you posted above, is that your lock is using the old groovy “Z-Wave Lock” driver, but it’s possible the new EDGE one provides an equally limited response. I’ll have to take another look when I have time.
*Edit: The Generic EDGE Z-Wave Lock Driver provides event data properties, i.e.:
Nice! That’s what I was trying to say earlier with testing various methods of unlocking the door to see what data is reported in each case and using the presence or absence of certain attributes for determining the unlock method.
In the case of one of my locks, I see something like…
Yeah, as clumsy as SmartThings can be at times, it seemed unlikely they would be the culprit in this case. I ran through a lot of different events and testing to confirm what I seeing, which only leads me to believe I wasn’t using the exact DTH I thought I was using. I moved fairly quickly from the RBoy driver to a stock DTH to the Edge driver.
The issue we are discussing on at the ST community with the locks needs to be FIXED. Speaking of RBoy I’m currently laying out a series of tasker profile to replace his driver and smartapp. Something will be easy to do but others will need a bit more work.
Not really, you can wait for your devices to be migrated. However I personally have moved all but just a few things over and fixed anything that got broke. Mostly rebuilding routines.
You simply subscribe to the beta channel, install the driver, then excluded and then included the device back into SmartThings. If you have a custom driver remove it, if you are using a stock DTH it will automatically use the driver.