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.
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.
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
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.
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!
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
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.
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.