Tiny Problem with Yale Assure SL Lock (Zigbee)


Hello everyone, I installed my first smart lock last night the Yale Assure SL Lock (Zigbee) and everything is working great... except that sometimes the very first message to it doesn't work. So for instance if it has been locked all night and in the morning I tell it to unlock, nothing will happen but hubitat will then say it is unlocked. If I refresh it will say it's still locked. If I "re-lock" it and then immediately unlock it again it will works perfectly. I know this is something small but it's kinda frustrating.

Could anyone help me?


hmmm, this is interesting, these drivers all work the same way, we send the command to the lock, then we do nothing, we just listen for the lock to tell us what it did, we don't assume that it locked, or unlocked...
So this lock is telling us that it unlocked, when it actually didn't, as evidenced by you running refresh, which is when we go ask the device what state it's in, and now it says, oh yeah, I'm unlocked...
I've not seen this before.


Do you by chance have any ideas of things I could try to either get more information or possible fix it? I thought about modifying the driver to one that refreshes after a lock / unlock and if it isn't in the expected state try X number of more times but this is more of a hack then anything.


Zigbee locks so far seem to be more reliable command than their zwave counterparts so far,
I guess we can have a look at your network construction.
Do you have any repeaters...
How far from the hub is the lock...
Do you have any zigbee bulbs paired to HE, and if so what brand,,,
What zigbee channel is your hub on, and have you tried a different one...
How many other zigbee devices do you have, and are they working correctly?


That's what I read, it's why I went with Zigbee. The lock is maybe 35 - 40 feet from the hub down a few stairs. I have a motion sensor on the stairs and one in the foyer right next to the door. I also have a multiple purpose sensor on the door where the lock is as well. Everything has been working perfectly, my townhouse is kinda small. I am on channel 20. I have 3 Phillip Hue A19 bulbs and one led strip but I haven't had any issues with those or any other Zigbee device.


I would add a repeater, also just for the heck of it, unplug your zigbee bulbs tonight, see if the situation improves.


There actually is a smartthings outlet not far from it which I believe should be acting as a repeater. I'll unplug the lights tonight and let you know if I see any different behavior.

Thank you.


A good way to test is to move your hub closer to the lock temporarily. Get it as close as you can, wait about 15 minutes, open up the log and throw some commands at the lock and see how it behaves. If it works as it is supposed to, then you have a range issue that will be solved with another repeater. I would also unplug the outlet for about 15 minutes and then plug it back in to trigger a mesh repair.

Are they connected directly to your HE or to a Hue bridge? If they are connected directly to your HE, I would recommend getting a Hue bridge and pairing them to that instead. Also, if you do have a Hue bridge, what channel is it running on? You might be having some channel overlap as Hue only allows for channels 11,15,20, and 25 and I believe channel 20 is what is selected by default.


Ok I will try these things today.

I do not have a hue bridge, they are connected directly.
May I ask what is special about bulbs specifically that they could be interfering?

Thank you.


Bulbs in and of themselves are horrible repeaters in a ZHA profile mesh network. Sometimes they will repeat properly, other times they won't. Often it boils down to the encryption/decryption differences between the two profiles and also how device ids are assigned. In a ZLL profile mesh, devices are strictly assigned ids based upon type and they (the devices) understand where and what they are doing within the mesh network. The ZHA profile doesn't have the same restrictions.

The basic rule is if you are using ZLL profile bulbs, they should be in a 100% ZLL profile mesh network for best performance. If you are using ZHA profile devices, they should be in a 100% ZHA mesh network. Mixing of the two is never a good idea.

I can pretty much guarantee you that if you remove the bulbs from your HE, your issues will go away.


Ok so I removed the three light bulbs and the led strip from the hub. I also unplugged and plugged back in a outlet. The problem still remains unchanged.

I then unplugged the hub from the network and moved it down to the foyer where the lock was so it would be much closer and used a button I had configured to test the lock and the same problem remains. I couldn't see hubitats status anymore as it wasn't on the network, but there were still the same times when I press the button and the lock didn't do anything mechanically or with the keypad (it will play one of two sounds). Which is the same behavior when I would see the issue in hubitat.

All I can think of to do left, is try a factory reset and see if that clears up anything and if not do an rma with amazon and order another one?

Also, how do I get an owner badge?



Move your hub back to where it belongs (a centrally located position in your house I hope). After removing the bulbs, factory reset your lock and re-pair it with the hub. If it was routing through the bulbs, which I, @corerootedxb and @mike.maxwell suspect, then what you have done is you've broken the route the lock had established through the bulbs (which was essentially a dead end anyway).

If you can now pair the lock and it's operational, then the bulbs were the problem. If you cannot pair the lock and you have a repeater midway between the lock and the hub, then you might have a problem with the lock or its Zigbee module. However, it is worth trying moving the hub closer to see if it pairs and functions correctly, but only after you have tried pairing in place. Moving the hub closer and having it work only tells you that your repeater isn't doing the job you thought is was. It doesn't solve your issue unless you intend to move the hub close to your lock and leave it there. And if that location isn't central to your home, I wouldn't use it anyway.

Keep in mind that removing the bulbs may not give you a correct route from hub > zigbee outlet > door lock for a few days. You can speed up the process by unplugging the hub for 20 minutes, then boot (without the bulbs screwed in) and wait for the mesh to heal. Even then it can take up to 24 hours, but with a single repeater it probably won't take that long.

Contact @bobbyD for your owner badge.


I never had an issue pairing the lock.

The issue is that sometimes I send a lock / unlock and hubitat says it happened, which I now know means the lock responding back saying it did it, but the lock doesn't do anything mechanically. 98% of the time it works fine, but one in every 15 or so doesn't do anything, as well as after the lock has been sitting for awhile.

The bulbs have been gone, i turned the hub off for an hour yesterday and let it come back up, and waited until today to test and the same exact thing is happening. There is no change in behavior at all. I do not think the bulbs have anything to do with it as they don't exist anymore. Range also has nothing to do with it because it still does the same exact thing if the hub is right next to it.


Weird. I think would test using your SmartThings hub and if it acts the same, get on the horn with Yale for an RMA or exchange at the retailer if you purchased very recently.

[Edit] Just wondering if you add refresh to your unlock rule, does it then respond every time?
Something like this:


@SmartHomePrimer, @mike.maxwell

I don't have an unlock rule, I'm just using the dashboard tile to lock/unlock. I'm not sure if I can use a rule like you suggested with the tile.

I did take your suggestion though and add the lock to SmartThings this weekend to view the behavior and saw some interesting things.

The lock still does the same thing, and I was able to see the same behavior in smartthings... but only once. It seems like SmartThings might be checking for it and proceeding accordingly.

I was watching the icon's change when i toggled the lock and it went something like this:

(lock is unlocked)

  • toggled it to lock
  • icon went to locked
  • icon went back to unlocked
  • icon went to locked

I think it is refreshing and checking the state to make sure the lock properly responds and if not resends the command (but only once). So I think it goes something like this:

  • toggled it to lock
  • icon went to locked
  • app refreshes lock, it's not locked yet
  • icon went back to unlocked
  • app waits a few
  • app resends lock command
  • icon went to locked
  • app refreshes lock, it's locked now

You can see the double lock command in the logs:


What is the lock actually doing mechanically during all this?


I'm not quite sure how to answer that honestly. When it doesn't respond to the command, it does absolutely nothing. When it does, it mechanically locks / unlocks like it should.

I also just realized that also occasionally with SmartThings, the lock makes sound twice like it's responding to two commands where with Hubitat it was always only once.


What do you guys think I should do? Exchange it and try another one? It's been working pretty good with SmartThings. Is there anyway to get the same functionality with Hubitat?


My suggestion is exchange it, since this isn't a reported problem from the other owners with the same lock and Zigbee module. I've done that dance, where I can't decide what to do because it's working ok in one situation but not another. Those products have always prematurely failed in my experience.

You can use virtual devices to trigger rules, so you'll get appropriate tiles and still interact with RM. Dashboard is just an interface layer. You can do anything with RM and Dashboard together.


If you're on one of the higher channels, I might give it one last shot, 15 is usually works well for everything.
You can go to zigbee settings and change it, most devices should just pick up the change immediately.