I am having very serious issues with my hub at the moment, please help!
current firmware: 18.20
Major issues:
Unable to pair secure devices (FRONT DOOR LOCK)
Because of the other issue below (lost devices) I have to repair my front door lock (Yale Keyless Connected (UK)). However it is IMPOSSIBLE. I have now included and excluded this device maybe 50+ times in addition to countless other failed attempts - but every time I get the error: "this lock failed to complete the network security key exchangeâŠ.â
- I have tried moving the hub right next to the lock
- I have excluding and re-including etc over and over and over again
- I have tried the stock DH during inclusion
- I have tried rboys DH during inclusion
- I have tried rebooting the hub
- I have tried a new Yale Z-Wave module (in case the device itself was at fault)
- I have tried every trick I know to get this thing to pair correctly but it wonât anymore
Lost Devices both Zigbee & Z-Wave
The hub loses devices all the time. This has caused significant issues for me. There is a very clear pattern when it happens with Zigbee - but Z-wave is a general mess when it happens. Sometimes the damage is irreversible. - ZIGBEE: When Zigbee devices are lost it usually happens that every single zigbee device in the house suddenly is no longer connected to the hub. I can still see the devices in the app but the hub can no longer control or receive commands from them. The only way to get them back is to re-include them when the hub is in inclusion mode - then they start communicating again and the hub doesnât actually need to go through the full inclusion process again and the devices pick up where they left off. UNFORTUNATELY I have 2 zigbee devices that are in completely inaccessible places - are these lost forever now? - as I cant get to them to press the reset button. It is also particularly painful because some of my lights are philips hue connected directly⊠so to reset them one by one with the lutron connected bulb remote makes the process even longer - Z-Wave: This is the biggest mess because there is no pattern. Sometimes the hub will lose devices randomly, and the hub actually removes them completely so they donât show up at all - when this happens its hard to tell it can be a long time before I realise something is missing. Other times the hub will continue to show the device but will not register any commands sent from them. Again I have Z-Wave devices in very hard to get to places (thankfully not completely impossible like the zigbee ones - but still hard enough that I may need to hire a builder to get to them)
I wish I could help, but I havenât heard anything specific to those issues. A couple of random things about locks but that doesnât sound like what youâre running into. @rboy has been tracking the lock issues, so he might be able to say more.
My first question would be have you checked the IDE to see what it says is the status of the Z wave and zigbee hub modules?
And second, have you reported it to support? Just in case theyâve heard of anything.
I only ever did any pairing / excluding whilst continuously refreshing the hub events page to see if it actually was in the correct mode and what was happening.
My thoughts are that the whole process takes too long and the Yale lock seems to time out before smartthings has a chance to finish the key exchange
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
7
There is an issue with some devices and secure pairing with 18.x firmware. Itâs to do with how ST processes secure inclusion and associations. Whatâs the raw description your lock is showing after pairing?
Also try this, exclude the device and remove the batteries for a bit and reinsert them, also remove the Z-Wave module and reinsert it in to the lock (sometimes loose modules are known to create an issue also). The reboot the hub, bring the lock within 5ft of the hub and then start the pairing process. If the secure inclusion fails, copy paste what you see in the raw description.
To add to what @rboy suggested⊠both zwave and zigbee use omnidirectional antennas, which means the signal will spread as you move away from the source.
The most effective place to do a secure pairing will be between one and 2 m away from the hub, but not right on top of the hub. This gives the signal a chance to spread a little bit and actually helps remove a little bit of interference.
Also, if you have an energy reporting Zwave device in secure Mode which is a repeater ( such as an Aeon pocket socket) within one hop of the hub, unplug it and leave it unplugged while you pair the lock. The energy reporting on these things is so frequent that it interferes with their ability to be a repeater and that just causes a bunch of potential problems.
Not saying either of these is contributing to the issues that youâre seeing, just that every advantage you can get on your side is a plus.
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
10
I see the 0x98 being reported by the lock so it should have ST automatically start the secure inclusion process. If you can use the Universal Z-Wave Lock DH and PM me the Live Logs (catch it from the getgo while pairing, the first few logs will be critical - donât forget to filter the locks by the device one). I can take a look at the see why ST may be failing the secure pairing.
Weâre working on a new device and saw a similar issue last week and it required a custom patch to the secure inclusion process to get the device to complete inclusion but that device wasnât reporting the capabilities properly.
It could be possible that your Z-Wave module may have failed, Iâve only seen that happen once so far, unlikely but possible.
I seem to be having the same issues⊠as Iâve been having a real hard time including devices and I now seem to have a slew of zwave devices reported with their ID in the events log sending messages on the network whilst not appearing in my list of devices⊠Not sure how that is possible but Iâve searched most of the IDs and none are current devices. I might be seeing devices from another me in a parallel universe??
Itâs depend on how the Phillips bulb dropped off the network. If itâs actually drop off the hub then all you have to do is force remove in the ST app. Power cycle the bulb and run discovery again. I did this quite often before because of my weak zigbee mesh. Now I have very strong mesh but firmware update is still scary sometime.
And this one is definitely need the remote for reset. Instead of dropping off the network. The bulb changed from to ZHA to ZLL. This happened to me during one of the firmware update and it was painful even with the Lutron remote.
@jdroberts - I think Iâve tried pairing at every increment of distance by now
@Brad_ST - I think this morning I have now proven it is 100% a smartthings issue. I had another Yale lock (brand new) that Yale sent to me by mistake (the keyless, not keyfree) - that I was supposed to send back to them, but due to this mess I opened it this morning to see if it would pair. Exact same results, other than that Rboyâs handler correctly identified it⊠but still failed the secure inclusion
@Navat604 - Iâll give your idea a go if they drop off again - but bear in mind if it doesnt work it would be even more painful to correct - because you are counting on them coming back to the hub with all the same associations as the original device? or you have to re add them to all your automations? at least with the lutron reset the original device in the hub stays the same.
Unfortunately you will have to add them to all your automation again. I usually put a dummy device in the automation before removing the bulb.
One thing I find about the Android ST app is that sometime it finds the device during discovery but wonât show up at all until you force close the App and open it again and it will be there. Itâs the reason I usually open the log in IDE during device discovery.
07:37:36: debug âErr 106: ZW secure inclusion failedâ parsed to [âdescriptionTextâ:âThis lock failed to complete the network security key exchange. If you are unable to control it via SmartThings, you must remove it from your network and add it again.â, âeventTypeâ:âALERTâ, ânameâ:âsecureInclusionâ, âvalueâ:âfailedâ, âdisplayedâ:true, âisStateChangeâ:true, âlinkTextâ:âYale Keyfree Connected/Conexis L1â]
07:37:36: trace Battery null%