Extra event data properties usage

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.

    "type": "event",
    "subtype": "device",
    "data": {
      "platform": "samsung-smartthings",
      "source": "DEVICE",
      "description": "lock was unlocked",
      "descriptionText": "lock was unlocked",
      "eventID": "76e4435f-56df-11ed-82be-4577cc7d5fcd",
      "value": "unlocked",
      "isPhysical": false,
      "isDigital": false,
      "isStateChange": true,
      "datetime": "2022-10-28T16:42:09.153Z",
      "attribute": "lock",
      "data": {}

Hi Zach-
Thanks for posting. The data property in your example is referring to this one, which seems to be empty on your device:


What Device Type Handler or Driver are you using with your device?

Note that the isPhysical field is not consistently implemented by all platforms and thus is not exposed. In the case of the Samsung SmartThings connection, it will always be false.

Hi Josh,

Where do I find the device type handler or driver in smart things?

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.

I wondered if that transition would make it harder. I didn’t use a special driver, just added it to smart things.

Thanks for your help.

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.:

 "data": {*
  "codeId": "1",*
   "codeName": "Code 1",*
  "method": "keypad"                   

The properties vary based on the nature of the event. For example, if you manually unlock the door the codes would not be present and the method would be “manual.”

1 Like

Thanks! I guess I’ll just wait until I’m on the EDGE drivers.

Even the DTH supplies the codeID, code name and the method.

Hmmm, mine definitely didn’t and I tried numerous times after I transitioned from the RBoy driver back in September. The results for my Schlage Connect locks looked exactly like Zach’s.

Well that’s interesting, it used to send that data. I wonder if something changed after the migration to the new integration.

Seems unlikely, but with SmartThings you never know. Stranger things have happened.

I know there were multiple Z-wave lock drivers in the IDE. I’m certain I was using the plain “Z-Wave Lock” driver, but since I migrated my locks to EDGE drivers, I can’t confirm that now.

I’m hoping RBoy is eventually able to deliver a new EDGE lock driver to replace his old groovy one. That drive had some really useful features.

Previously when the sharptools Tasker integration still worked I was able to get the method of the lock and codeID because I used it to disarm the STHM. I used the DTH Lock with Codes.

I checked the events in in the smartthings api and it shows a method of manual. Am I missing something? Why wouldn’t this come across to sharptools?

EDIT: If I manually unlock the door, it does indeed send the manual method.

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…

Physical with the keypad

"data": {
    "codeId": "1",
    "method": "keypad"


"data": {
    "method": "manual"

Digital (app):

"data": {},

@IslandSoul I am going to correct myself. I did a test this morning. The DTH does still provide code information.

This is from a pushover notifications I made.

Lock State: {"thing":"Front Door Lock","attribute":"lock","state":"unlocked","method":"keypad","codename":"","codeid":"4"}

And it provides manual as well.

Lock State: {"thing":"Front Door Lock","attribute":"lock","state":"locked","method":"manual","codename":"","codeid":""}
1 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.

1 Like

So is there an advantage to switching from a DTH driver to an edge driver for a schlage z-wave deadbolt? If so, is there a good resource on manually installing that?


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.

Thanks! I assume when my drivers are migrated I won’t have to remove and re-add them, so if that’s the case, I’ll just wait. I don’t have any custom drivers atm.