The solution for general pairing problems with zwave for people migrating from Smartthings

So everyone tells you to exclude your device on Smartthings before migrating to hubitat.

That advice is correct, except that it doesn't actually work at all in my experience. This applies to all manner of zwave devices. Some devices I can add to Hubitat after a factory reset, but many devices simply refuse then as well.

I don't have a zwave protocol analyzer, but I did spend 10 years running a IOT lab where we debugged things for companies like AT&T, and I have been a smartthings user for nearly all of that time. I have 4 different smartthings hubs, as well as many other popular hubs. None of them hold a candle to Hubitat, and I'm throwing all of them away... but I digress.

What I think I have found is that Smartthings does not correctly exclude zwave devices. So don't even try, it doesn't work at all. It is the correct thing to do, but only if it works. I don't know what smartthings is trying to do, or why it doesn't work, but that doesn't matter, it simply doesn't.

You don't have to exclude from the device it is paired to, it can be excluded from any device that has a working exclude mode. One popular zwave exclusion device is the Aeon Labs Z-stick... But wait! Don't run out and buy a Z-stick unless you are a pro that does this for a living. The fact is your Hubitat's own z-wave exclusion mode is all you need. That's right, you have the power in Hubitat to fix these stubborn z-wave devices, but the first step is to understand that the exclusion process is universal, it is not tied to your old hub, so stop trying to get zwave exclude to work on smartthings, it won't.

I ordered my Z-stick from Amazon, and 20 minutes later discovered I didn't need it... except that I sometimes handle a lot of this stuff, and almost fit into the pro category. So it is up to you, but the Hubitat exclude mode does work...

So here is how exclude works, you enter your Hubitat or z-stick into exclude mode, then activate the button on your device that answers the exclude handshake. For light switches that is usually by toggling the switch on or off. On other devices like a minimote you might have to try different buttons, until you are successful. The minimote lights tell you something is up, some devices flashj an LED in a new way, and others might blink their light or make a noise with their relay. Once you have excluded successfully, you can following pairing instructions.

For some of the older GE z-wave light switches, you will need to exclude them and pair them several times. The exclude is the easy part on these, but the pairing is prone to failure with the Hubitat. You might see it almost pair two or three (or 5 or 6) times before pairing is successful. Pairing is a more complex handshake, and it fails if any noise interferes with the handshake. If Hubitat misses one of the handshake steps, it does not recover, and you must run exclude again.

I had some really stubborn switches that took forever to pair. They would blink like pairing was successful, and hubitat would show something had happened, but it wouldn't complete. And it seemed to fail at different steps in the process. I'm not going to walk you through what those looked like because that was last week I got it done, and I don't feel like re-living it right now.

So don't try excluding from Smartthings, you will be wasting your time. Use Hubitat, or a Z-stick to do your excludes, and them be prepared to repeat your joins several times. It took me hours to figure out that smartthings exclude does nothing, but the first clue is smartthings itself indicated it was failing, but offered the option to "force" the removal which is just deleting it from the app without a proper exclude. Don't be fooled, you MUST do a successful exclude.

For the minimote, I think I hit as button under the door, probably the join button or the - button... But it was easy and worked the first time. Then upon entering join mode, pressing the join button and I was instantly connected.

If your device acts like it is doing nothing when you try to join, then you may not have excluded it yet. It should signal in some way to tell you exclude worked. Only then can you try a join, just be ready to try over and over until you get a clean handshake. We all live in wifi/bluetooth noise zones, and all of that RF noise makes joins take several tries.



If, after migration, the SmartThings hub is to be powered down/discarded, then there's little point in the specific use of ST as the Exclude controller. As mentioned, all ZWave Controllers can Exclude. However, if a migration plan leaves some devices on ST then using ST's Exclude will remove the device from ST's DB... independent of how good a job it does at excluding a device.

It may well be that two Excludes are needed, once to remove the device from ST's DB and once to make the device ready for Inclusion... dunno. I just know that the Exclusion process completely separate from ST will leave ST thinking it still has the device. Exclude removes the Home Network ID from the device, and therefore it doesn't matter to the device that ST thinks it's still available, it isn't but if you plan on using ST, it's device list will have a lot of orphaned devices.


My preferred method and the one I recommend is powering off the previous controller, and perform the exclusion from Hubitat. If the exclusion doesn't work, chances are that the device is out of range. Adding a repeater between the hub and the device, if the device is far from the hub, may resolve the problem. Moving to the next device and coming back later to the stubborn device is not recommended. Resolve the problematic device, first, before moving to next. And never force remove a device, run exclusion until you get a confirmation that "unknown device" was excluded.


Part of the issue with Z-Wave exclusion (and inclusion) has to do with the patchy nature of compatibility within the Z-Wave ecosystem. Nominally 'all' levels of Z-Wave devices are compatible with each other at some functional level, but dig a little deeper and you will find a rat's nest of incompatibilities at the feature level.

Some facts that bear keeping mind when joining and excluding devices in a network:

  • Not all Z-Wave devices can be factory reset by the end user (only 500 series and later devices were actually required to implement a device level 'factory reset' capability; many older devices like non-plus GE/Jasco switches, early Aeon sensors and the like cannot be reset by the end user; they rely completely on exclusion to permit them to be joined to a new network. Newer generations can be reset with a series of taps of the rocker or activation of some other switch. But many older devices have no built-in reset capability

  • Not all Z-Wave devices can be 'paired in place', even those that natively support that capability-- it may not work in their installed environment. Some only support inclusion ('Classic' inclusion) within radio range (single hop max distance) of the hub-- and some, like locks, may need to be even closer to the hub on initial join.

The success of NWI in general depends on whether or not the device itself supports it (Z-Wave version dependent; compliance statement can be examined for this feature), whether or not repeating nodes in the path of this device to the controller also support NWI, and whether the controller itself is properly set to do an inclusion using NWI (vs. the classic 'in-radio range' method). If any one of those criteria isn't met, you need to physically move your controller and device within range, and following its re-location initiate a repair on the node so it can discover its new in-range neighbor nodes.

  • And finally, even among devices that support NWI, Network Wide Exclusion is also not a universal feature. It depends on the Z-Wave level of the devices in your network. As recently as March, 2018, this section appears in the 'Z-Wave Network Installation Maintenance Procedures User Guide' (Silicon Labs Document INS12712):

"Z-Wave does currently not support network wide exclusion of devices so when excluding a nodes fromthe network that are out of range of the gateway another exclusion strategy must be used.

Removal of devices in direct range

When excluding a device in direct range of the gateway it can be done in a similar way as inclusion.

  1. Put the gateway in exclusion mode by calling ZW_RemoveNodeFromNetwork()
  2. Put the device in learn mode by calling ZW_SetLearnMode() and send out a node informationframe by calling ZW_SendNodeInformation()
    Removal of the node should now be done by the protocol and the gateway will remove information aboutthe deleted device and the device will be reset to default.

If the device is out of direct range the removeprocess will not start on the controller. Devices out of direct range will need to be moved into direct range of the gateway or the gateway will need ot be moved in order to exclude nodes out of direct range with this method."

At some Z-Wave version level, Network Wide Exclusion is supported; I'm not sure exactly which...


If this thread stopped here, it would be one of the most useful Z-Wave threads I've read.

Thanks for the info, very interesting and helpful both tactically, and mental-healthily (as in those moments of "WHY WON'T THIS PIECE OF SH_T PAIR!!!") :wink:


As you correctly mentioned, some devices will not exclude/include, unless they are within controller's range. But as a general word of caution. If device doesn't pair in its current location, chances are that once the device or the hub is moved back to their permanent location, the device will stop working. To solve this problem one must add additional mains powered devices (repeaters) along the way, to strengthen the Z-Wave network.

1 Like

Yes, certainly true. When the newly included device is relocated, its list of in-range repeating nodes (the only nodes it will try to direct a unicast message to) is not complete. It's effectively stranded; from the hub's point of view, a message directed to it will fail if the device is out of range (as the message will not be routed--the device was previously within range when joined).

Hence the need for Z-Wave repair after relocating such a device (critical in environments where devices don't fully support explorer frames). This is the mechanism whereby all repeating nodes send a broadcast to (paraphrasing here) 'listen for and update your list of repeating neighbors... if you are a repeater send the controller your new neighbors so it knows which ones you can hear-- it will build and distribute new return routes to you; if you're a battery device, use these new neighbors-- try each one until you get through-- as the first hop when you talk to the hub'

The new C-7 model has a major advantage. You can run repair on individual node, so you don't have to wait for the entire network to repair, when you only moved one device.


This ^^^ I was really tired of running a general Z-Wave repair when I had just one device out of sorts. Love that this feature is available on the C7.


There are dozens of threads I could have posted to. Because this was such a general issue, and my findings seems to slightly deviate from the non-working-but-technically-correct answer I saw in every other thread, I decided a fresh thread was appropriate AND I agree the info I presented is useful... Thus the reason I did it. Thanks for your comment!


And I would like to point out that the Zwave devices I had the least trouble with were located FAR from the hub, and the zwave devices I had the most trouble with were 6 feet from the hub. I agree range is important, but RF engineering is part of running the kind of lab I used to run, and in my testing range is simply not an issue within my house. I did strategically place hard wired Zigbee and Zwave switches in the house to act as relay agents, in the event I ever need that. I am intentionally optimizing everything well beyond the known requirement... I did that because Smartthings had so much trouble, and range was incorrectly cited as a potential issue...

No hub has a perfect behavior with all devices, but Smartthings had problems with excluding that Wink did not have. I moved from Smartthings to Wink to see if it worked better, and Wink did work a little better, fewer "we lost all of the cree lightbulbs again" moments under wink... but wink is going through changes, so I switched back to Smartthings. I never really left smartthings, just moved the things my wife operates. The wife is loving Hubitat, and wink is dead to me (and much of their customer base). I don't hate Smartthings, but I don't have a plan to keep running them. One is new in the box as a spare... so much for that.

1 Like

My preferred method and the one I recommend is powering off the previous controller

Yeah, when I was having the fight, I tried that, and it made no difference. The fact is that except for interference issues that could happen with two overlapping overpopulated networks, I did not see any evidence that turning off a hub helps in any way. If a hub is doing something like preempting some or all of my onboarding handshake that would be an issue, but I saw no evidence that was happening. I explored every reason for my issues, and was able to prove to myself that Smartthings exclusion mode was simply not working at all. Even smartthings reported each exclusion to have failed. And no range issues were involved. I was neither too close nor too far.

And to be fair, Hubbitat was the only one of the group to have issues with the zwave join after a successful exclude, but it was limited to the oldest zwave version I was running (which was on brand new devices). The newest version of zwave I was running worked flawlessly, but I was able to factory reset those. But Hubitat had a perfect experience joining zigbee devices, devices that were a problem on both smartthings and wink.

No one is perfect, but beating yourself up trying to get smartthings to exclude is a waste of time, it never happens.

Now if I could stop my ISP from doing all of their maintenance right before I go to bed... Nothing as much fun as a smarthome with a severed spinal cord when I'm trying to turn the lights off.

1 Like

This is a best practice kind of advice more than anything else. I have seen other controllers that automatically (or accidentally- not sure which) start inclusion mode right after exclusion. Last thing a Hubitat Elevation customer needs, when trying to include the device on Hubitat, is to accidentally include it on the wrong controller :slight_smile:

1 Like

^^^ Had this happen several times after exclusion today and when included the ST hub picked it backup. I ended doing exlusion on all the devices I was moving at that point and then pulled power on the ST Hub and then included on the Hubitat hub and all was fine

1 Like

This is a crazy conspiracy theory... But I would not be surprised in Smartthings is intentionally failing to exclude devices to make migration away from them make your new hum seem flakey. Every other device I have is able to successfully send the exclude signal to the older zwave devices, and smartthings was unable to exclude any of my zwave devices.

I tend to believe strongly that man's ability to screw up almost anything, given enough time and money (or too little time and money) is much more powerful than any tendency to conspire.

I've seen the ST dev team in their forum for years, and none of them have ever seemed anything but conscientious and diligent. :slight_smile:

1 Like

I just got bit again by this yesterday, finished moving the last of my 50 devices over and it was a Zigbee light, it worked one time but never turned off again. I left it sit and while unpairing the last device from ST hub it said 2 devices just unpaired and then it hit me what happened. I pulled power on the ST hub and then the light started working fine after that. Ugh... Glad to be done with the migration..


Thank you all for the discussion here. Wish I had read this weeks ago. Excluding from ST has been the only painful part of switching from ST. Even using my Gen 1 Aeon stick has not always helped. Now, I know why, and more importantly know what to do next. I appreciate it!!!

well st fffd me over.. i have not migrated my other site yet as i am not there and when i migrated this site, which i just ported to hubitat.. It failed. and took days to get all devices working again.

Iin the meantime i get an alert from the other location (still on st) that a temp is too low.

I go into the classic app to look at notifications to see which device and it says to check notifications on the new app.. big help..

when i goto the new app the location doesnt even show up as it hasnt been migrated yet!

I have a 10 email exchange with support complaining about the issue and they make all kinds of excuses like app version, etc etc. and fail to even look into the issue. I'll be SO happy when my other location is migrated away from the jokers!

1 Like