Hi everyone, I’m fairly new at ST home automation scene (long time x10 user but recent convert to ST) but like what i’ve seen so far, especially the focused and dedicated member posts in these forums!
I have a STv2 hub with three Schlage BE469 deadbolts, three First Alert Smoke/CO2 sensors, a Chamberlain MyQ, a v2 MiniMote and Aeotec Repeater.
[Apologies in advance for the long post…]
Everything works great except for one of the deadbolts that happens to be the furthest away from the hub. I decided i needed an Aeon Labs Aeotec DSD37-ZWUS range extender. Before installing the deadbolt on the door and adding it to ST, I added the repeater was added to ST first.
At first, i thought the repeater (whose signal has to traverse at least four interior drywall-based walls) successfully added to ST. It shows up in ST as, “Z-Wave Device”, had on/off & Refresh buttons in the ST GUI app on my phone. For awhile its status showed as “On” but after installing it 12 hours ago its status now says, “Off” and under “Recently” it now says “Switch is off”. While its status was “On” I successfully added the deadbolt to ST by executing the whole operation while the deadbolt was only 1 foot away from the repeater. After reinstalling the deadbolt on my door (10ft line of sight from the repeater) i was not able to control the lock from ST. I suspect that the beaming traffic for the join-hub operation didn’t flow through the repeater but was now just within range of the hub that it was able to connect and handshake but who knows. I find it frustrating that there’s no way for me to confirm the way this traffic flowed!
I executed a “Repair Z-Wave Network” as well as rebooted the hub but this didn’t seem to help. When i view my hub settings from graph.api.smartthings.com, under “Devices” i now have two entries for this particular lock, ones status is “Removed” and the others is “Inactive”. Clicking on the “Removed” one takes me to a screen that says “Access Denied We’re sorry but you are not authorized to perform the requested operation” Incidentally, if i unplug/replug in the repeater, “Last Activity” column shows it talked to the hub.
Questions:
Should the repeaters status in ST show, “On” or “Off”? Does it matter either way?
How can i confirm the repeater is working?
Under My Hubs | Devices, how can i purge the deadbolt entry with the status “Removed” if i get an access denied error?
Again, sincere apologies for the long post, but as much as i’m excited about home automation and ST in particular, i have to say it’s been quite a frustrating troubleshooting and diagnosis experience so far. Hoping the community can help me!
Thank you!
They communicate a slightly different want… Hopefully @JDRoberts will show up here and correct some of my technical errors, but basically think of it as encrypted messages. The Hub speaks the encrypted language, but not all repeater do. For instance, most light switches don’t.
What I don’t know is if the Aeotec repeater speaks this language. If it doesn’t, it won’t repeat to the hub. It’s possible that the repeater is working perfectly but still not repeating he messages because it doesn’t understand the dialect of z-wavese that the lock is speaking.
Encryption is one issue, but the real issue is what’s called “beaming.”
Door locks represent a special challenge in home automation because you don’t want the person to have to stand there and wait too long while the unlock request is being processed, but at the same time you want the batteries to last as long as possible because you also don’t want them to stand there and wait for an unlock request that isn’t going to process because the battery died.
So to save battery, the Zwave locks do sleep most of the time, but they use a special message repeat protocol which causes the neighbor who gets the message for the lock to keep resending it multiple times so that it will be right there when the lock wakes up. So it’s a battery saving protocol intended to also reduce lag. It’s the nearby powered device, typically a light switch, which is drawing power to send the message over and over.
It’s only the very last neighbor in the message relay chain who has to have the multiple resend ability. So you only need one beaming device. But that one should be the neighbor closest to the lock.
( sorry, I’m out and I don’t have time to respond to the original message in this thread, but hopefully others will. But at least this should explain beaming.)
To check if a device supports beaming, read its “conformance statement” on the official Zwave alliance website for that exact model. The manufacturer’s product manual may also say so, some do and some don’t, especially if only some models have the feature.
Two entries for the lock might mean there’s a database issue. There was announced platform maintenance last night, so it might straighten itself out, but I would go ahead and contact support@smartthings.com so they can look at it.
Thanks chrisb, I had checked out the conformance statement for this product on the zwavealliance page and it said it supported beaming so i went forward with the purchase.
Database issue…yuk! I’m an IT professional by trade and never like hearing those two words together in a sentence as it usually meant i was in for a long night alongside my DBA colleagues… Luckilly i can just open a case with support and have them take a look.
Also, i ran across a post by ‘Walter Edwards’ in the link below which seems to have some good steps for hard resetting/excluding/re-pairing a problematic Schlage lock. Schlage camelot lock not responding
In brief, we restore factory settings to the lock, bring the ST hub to within 1 foot of the lock, issue an ST exclude command, enter the ‘enroll/unenroll’ programming code, lock is completely excluded. At this point it seems we would re-pair the lock while the ST hub is still 1 foot away which should work without issue.
But what about the repeater that is still 10 feet away? After a successful (re)pair and with the hub now back in its original location, do i need to do a network repair routine so the routing table has the lock using the repeater as it’s next hop neighbor to the hub?
Yes. Anytime you pair a device in one location, and then physically install it in another location, you should use the network repair utilities to make sure everyone knows who their true neighbors are.
I talked to ST support and it turns out that devices that are removed stay in the “Devices” list under My Hubs for 24-48 hours so there’s a history to review.
I followed the instructions for resetting the lock, excluding it and re-pairing it with the hub being only 1 foot away from the lock. I actually did this for all three of my locks just to be consistent. They all re-paired without issue, and much quicker than when the hub was further away. I even did this for my Aeotec repeater because i had the hub on a 50ft ethernet cable and it was convenient. Lastly, i waited about 10 minutes and then executed the Network Repair. Checking the Events i see the error below logged:
Date
2015-10-21 8:38:08.875 PM CDT
Source
HUB
Name
zwNwkRepair
VALUE
failure
Displayed Text
Network repair for Back Door Lock [0F]: Failed to update route
Changed
false
I confirmed once again i am still unable to control the lock even with the repeater being within line of sight. At this point I’m wondering if the repeater is “repeating” traffic between the lock and hub but i have no idea how to validate this. Anyone have any ideas?
Addendum (10/22/15 @ 12:05pmCST) - In the IDE, Live Logging, for two of my three locks i was able to see the debug entries appear when i went into the ST app on my phone and hit the Refresh status button. I end up seeing 5 entries with the 5th one being the status message sent back from the lock. However, for my “problem” lock all i see is the first four debug messages and no status sent back from the lock.
Interestingly enough, for the Repeater Thing, whether i hit refresh or the On/Off button for it in the gui app (which I have no idea why it would have an on/off) absolutely no status messages appear in Live Logging. It successfully paired with the hub and it shows up under Devices so i would expect to see some sort of status communication with it.
