How do you replace Zwave devices in the new SmartThings IOS app?

In the old SmartThings classic app, when a device like a lightswitch died, you could select the device, go into settings and remove/replace the dead switch with a replacement switch with the same name.
This way the device retained it’s place in existing smartapps, automations, etc.

I cannot figure out how to replace an existing device using the new SmartThings app.

I finally added the replacement device using add a new device. Now I have the old dead device plus the new replacement device and I can’t delete the old dead device. The old dead device says it’s offline. When I edit the old dead device and try to delete device, it brings up Z-wave exclusion instructions.

How do I exclude my old dead device, which didn’t work and has already been removed and replaced?

I replaced numerous dead GE light switches in the classic app and never had this problem.

Let the exclusion run, after it fails, it then gives you the option to force delete.

Because ZWave Replace is not implemented in Newapp. With Zigbee you can re-join the device and as long as you haven’t deleted it, it will inherit everything. With Zwave - well. unless there’s something going on we haven’t heard about - you 're stuck with a delete/re-add.

That is awful. So I have to go through my automations one by one and re-add the new device?

I waited for the option to force delete. But the force delete itself has timed out several times.

What type of things might prevent force delete from completing?

This has worked for me for ZWave devices

  1. Note down the Device Network Id (from the ST IDE) for the rogue device that is no longer responding
  2. Change that Device Network Id to something else not already in use (I typically just add a couple of digits to it)
  3. Create a New Device using the IDE with dummy values - I use the same DTH as 1) but that probably is not required
  4. Give this new Device the Device Network Id noted it 1) and remove this new Device from ST, using force delete if required
  5. Re-add the physical rogue device to ST again using its standard Add protocol - this will create a new Device with a new Device Network ID
  6. Note down this new Network Device Id and change it to something else in the IDE (add digits).
  7. Put the new Network Device Id from 6) into the IDE settings for the original rogue device that was not responding
  8. Remove the new device added in 5 (force if necessary)

I’ve been able to do the above, get a device re-added to the Z-Wave ST network, and not had to manually re-do all my automations.

1 Like

Thank you so much for your detailed instructions! I never thought about fixing the problem in the IDE.
Followed your instructions and everything works again and I didn’t have to redo my automations.

Thank you, thank you, thank you. Sad we’re back into IDE for what should be basic troubleshooting.

Quick note for clarity. In Step 7, you must enter the ORIGINAL, UNEDITED Network Device ID from Step 6.

Thank you, worked like a charm.
I used it to revive my front door lock which has a lot of automation around it.
I have a Schlage FE469NX that stopped communicating. I was able to get it back to work without even resetting the lock all user codes and automation are back.
The only issue I had was to remove it from ST, even a force didn’t work. Removing it from the IDE worked.
Thanks, this is really useful

Ron

One problem with ‘replacing’ a device with the old app or the above IDE trickery is that ST keeps the original ‘fingerprint’. This isn’t a problem with current drivers because a match is not enforced. I wonder if the migration to ‘Edge’ drivers will interrogate the device or just blindly use what’s in the configuration.

The Zwave replace utility, part of the independent third party standard, is only intended for replacing one zwave device with another of the same model, or using the same generic capabilities.

As far as using another device of the same model, they should have the same fingerprint, so no issue there. :sunglasses:

And since Edge Drivers can offer a generic option, that should also work, although I don’t know the limitations on that method. :thinking:

I was recently doing inventory on my devices determining what Edge drivers I needed. I found the fingerprints for some older non-plus relay switches which I had ‘replaced’ using the old app That suggests that ST never updated the fingerprint. Similarly, the manual procedure above does not update the original profile.

Replacing with an identical device often isn’t practical or desirable. Replacing with a similar device without updating the DTH (requires IDE) may mean loss of new functionality.

If the Edge migration doesn’t verify the fingerprint, then this situation will only persist. I wonder what ST will do for devices that have been associated with the hub, but are currently offline. There’s no way to check the fingerprint. How long will they wait?

One solution to the ‘not breaking things’ problem is to add another level of abstraction. ST could introduce virtual devices which optionally mirror a physical device.

Bottom line is that ST configuration has historically been minimal seat-of-your-pants with no backup. I was using the ST app the other day and all my automations suddenly disappeared. I had to close and reopen the app to see them again and was very relieved!

They could, but then in practice the number of devices allowed per account would be halved…:thinking:

This worked for me as well, thanks!

It sure would be nice if they valued their long time users and didn’t force a new app without having all the functionality from the old one…

Hoping to follow up on your tips. You mention a rogue device. I need to swap out an old device for a new one. How would I use your steps to do so?

The rogue device is the old device. I believe the 5th bullet point should say ‘replacement for rogue device’. Note that this process assumes an identical replacement. The ‘fingerprint’ is not updated. The same was true in the old app

1 Like

Another thing I don’t understand is why do you create a new device in step 3 only to remove it in step 4? I was wondering if I could copy and edit the existing ID of old device then add new device then change the new devices ID to that old ID?

Presumably, the reason you want to replace as opposed to delete old + add new is to preserve the device settings and any references in routines.

Only the hub can assign a valid network ID to a Z-Wave device and this only happens during pairing. If you change the network ID in the IDE, it does not change what’s stored in the device. It’s like editing the phone number for someone in your contacts. Their phone number is assigned by their carrier. You can’t change it. However, if their carrier assigns a new number, they can share it with you and you can update your existing contact. You can then call your buddy again.

The dummy device is created and later deleted as a way to unpair the old network ID without losing the old settings.

The new device is created to generate a new network ID. You want the new network ID with the old settings.

You’re not unpairing the new device. You already changed the network ID to something nonexistent. You’re deleting the SmartThings settings associated with the new device. There will be no response from the device. That’s why you need to use the ‘force’ option.

If you wanted to be really clever, you could eliminate steps 3-4 and just put the old network ID in the new device. Then, when you delete the new device, you get rid of both the new settings and the old pairing. Instead of swapping network IDs, you’re really swapping settings.

1 Like

Ok so instead of putting the old network ID into the new device you put the new network ID into the old device. I had it backwards.

Well apparently you can’t do this if you’re using edge drivers. It automatically added with an edge driver and the network ID shows up as blank. That stinks. Why this function was removed is beyond me. @SmartThings - one step forward two steps back.