HubConnect Lock --> extracting unlock code used from an Event

Hey all, hopefully someone can guide me in the right direction...I have a Schalge FE599 on a gate and I want to perform different actions depending on which user code is entered. Through many hours of effort I have not been able to get the lock paired to my C7 hub. It will however pair to my Smartthings V1 hub. I've setup HubConnect and now have it in HE as a virtual lock...but from what I'm seeing and what I've read HE does not parse unlock codes, only the state (that it has been locked or unlocked). When looking in the Event Details when the lock has been unlocked, in the "data" field it does show which code was used to unlock it (see pic below):

But nothing in the current state (if HE were parsing it):
currentstatus

Is it possible to parse that field or perform actions on that field in the event details using Rule Machine or similar? Or maybe to modify the HubConnect virtual lock device to accept that info? As best I can tell I have no direct way of using "usedCode" or "codeId" in that data field

I created a virtual (simulated) Lock on my ST hub and added it to HubConnect and it was created on my Server hub, as expected. Log results show:

app:8 2020-11-18 08:59:22.269 pm info Received event from SmartThings/virtualLock: [lock, unlocked ]
app:8 2020-11-18 08:59:22.074 pm info Received event from SmartThings/virtualLock: [lastCodeName, null ]

also, as expected. "lastCodeName" is a Hubitat invention and isn't used on ST. Are you able to do the same?? Monitor the logs on your Server Hub and see if the ST Attributes are transferred over. If yes, then it can be handled by a HubConnect Custom Driver.

These are my logs when entering a code on the lock in HE:

[app:170]2020-11-20 04:12:58.358 pm [info]Received event from SmartThings Hub/Front Gate Lock: [lastCodeName, null ]

[app:170]Received event from SmartThings Hub/Front Gate Lock: [lock, unlocked ]

[app:170]2020-11-20 04:12:47.468 pm [trace]Received ping from SmartThings Hub.

On the SmartThings end this is what the event looks like--

Capture

@csteele can you describe what you mean in more detail? I'm a little lost because my lastCodeName is coming in null (just like your virtual lock did). Since mine are the same as yours you are saying that it cannot be handled by a HubConnect Custom Driver?

Are you alluding to what you did here? - [RELEASE] HubConnect - Share Devices across Multiple Hubs (even SmartThings!) and if so can you walk me more through it, I can't follow 100% what's going on in that post -- I think I would need that HubConnect driver that you speak of

ST has no websocket (Event Stream) to listen to and it's all out in the Cloud anyway... So, HubConnect has to Subscribe to a device on ST. The question is really what Attributes are coming across the http interface for your particular device.

This is different than Hubitat to Hubitat in which an Event Stream is available and ALL attributes are sent. No Subscription needed. Selecting a device causes the Other Hub to filter out anything not needed. It's rather nice because anything odd / non-standard can be used via a Custom Driver.

But in the ST case, of course we're not seeing any odd messages. I'll have to see if I can create a better virtual lock for ST to experiment with...

That would be great. I'm pretty confused why lastCodeName wasn't thought to be included by the developers of HubConnect for ST? In any case I appreciate anything you're willing to look into!

In the meantime I believe I have a workaround. I have webCoRE running on that ST hub. webCoRE has the ability to parse that last used lock code easily, so I made a piston that for each lock code I have, it will ping a local endpoint trigger in a rule in HE RuleMachine and do what I want from there. With groovy being phased out and ST future being uncertain I don't know how long that'll work for...but I guess maybe by then I'll have bought a new lever lock that I can just pair direct to HE :man_shrugging:

As I said, lastCodeName is a Hubitat invention, it doesn't exist in ST. It's reminiscent of Hubitat's pushableButton that has no equivalence in ST. However, in that case, the button functionality is baked into both Platforms and thus a transform could be created. As far as I can tell there's no hard (platform) definition for the last code. All the references I've found so far are via ST Community Apps.

1 Like

Download the Hubitat app