Managing Lock Codes without Groovy

It’s just that it doesn’t seem to be documented in the next-generation eventing APIs at all.

I took a look through the Z-wave Lock Edge Driver and it still has some references to event.data, so I just put in an order for a Kwikset 910 and will try it out.

wow, that’s very nice of you. I am excited to see if you are able to extract that info. would definitely be nice to react to the specific user code or entry method. in the meantime, how can I check if I am using an edge driver for my zwave lock?

You can open the SmartThings mobile app and open the device you are interested in. Give the screen a moment to load, then tap the ... in the top right and if you see a ‘Driver’ option, it’s on an Edge driver.

From what I understand, as of today, you’ll only be on an Edge driver if you’ve explicitly reonboarded the device recently (removed it and re-paired it to SmartThings). The exception to that is if you are part of the Edge Driver Betas in which case they have automatically migrated some drivers already. I believe the plan is to start the automatic migration for regular SmartThings users sometime late August through end of September.

Hi! Groovy refugee working on transitioning my handful of live WebCore pistons. Similar to @RichB, I want to enable a lock code for my cleaners during scheduled visits. I originally had mine tied to a GCalSearch presence sensor which I’m working on mimicking in IFTTT. On the Rules side, I need to add the code when that presence is active.

My input arguments appear to show in the opposite order from your screenshot, with the numeric value coming last. I’ll try it out with the reverse sequence when I get home and can confirm the code enters properly but wanted to raise it here given the discrepancy withwhat you just posted.

1 Like

Are you moved over to the next-generation integration? Keep in mind, the next-gen connection is only enabled for new users by default, so if you had a legacy connection to SharpTools at some point in the past, you may still be using that.

If you’re just getting started with SharpTools and don’t have many rules/dashboards built-out yet, you can deauthorize your existing legacy connection which would then make the next-gen connection available to you (proceed through auth, select the location, and tap deny).

Alternatively, we can get you added to the beta so you connect connect the next-gen connection side-by-side your existing legacy connection. :slight_smile:

I would also add that the Groovy platform has an oddity where when it is asked for the list of parameters, they don’t always come across in the right order. You can fix it by tapping the ‘Advanced’ toggle in the top right of the Device Action in your rule and then change the parameter types as you see fit.

1 Like

Got it in one. I didn’t realize the different connection would lead to a different presentation of the options. I set up an account ages ago and am just now making an effort to use it, so re-linking the couple of rules I started setting up was no big deal.

1 Like

Feel free to send a note to support@sharptools.io if you’d like us to reset your trial so you can try out the premium features. :slight_smile:

1 Like

Just following up. Any luck getting access to event.data?

The data property is there on the Z-Wave Lock Edge Driver in the next gen platform and has the codeId property in it (along with codeName and method = keypad). I won’t be able to get to it right away, but since the data is there the good news is it’s possible. :slight_smile:

Is that based event data from a subscription?

:tada: Update: ‘Extra’ event data is now available in production! Extra event 'data' properties

We’ve exposed the data attribute from events in beta - I sent you a PM with access. There’s a new ‘Extra Data’ option in Context Variables for Event → Device which will prompt you for the extra data ‘property’ that you are trying to access.

Like other context variables, you can use this in conditions as well as actions like notifications. In the case of door locks, it looks like common properties include:

  • codeId - which code ‘slot’ was used to unlock the door
  • codeName - the name of the code (if you named it while creating it in SmartThings)
  • method - indicates if it was unlocked with a keypad or manual

Yes, it’s based on event data from subscriptions

Could I be add to the beta :smiley:

Would like to test this feature!

1 Like

I would like that feature as well!

1 Like

@josh is this the argument structure your using to sent the codes using the API?

"arguments": [Slot,"Pin","Name"]

The commands are dynamically built with the Rule Engine. This allows for introspection of custom capabilities so we can expose the commands from those devices.

It also allows for customization of the order and type of arguments in ‘advanced’ mode when a command is ‘overloaded’ with different parameter types.

A post was merged into an existing topic: [BETA] Event extra ‘data’ properties

I just want to let you all know how useful these posts have been. My LUM died today and I lost all my lock codes trying to fix it.

The Samsung Smart Lock Guest Access isnt available in New Zealand.

I came across this chain, installed sharptools and was able to recode my locks in about 3 hours.

Thanks so much for your work and documenting this.

Richard

3 Likes

I would definitely like this feature as well. Can you add me to the beta please.

Thanks.

Hi Martin-
The ‘extra’ event data is available directly in production:

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.