The solution above is specific to Rule Machine. Other apps will still have problems with removed devices.
Removing devices without first fixing the apps is just a bad practice, and should be totally discouraged. This isn't a platform or app problem, this is a user education problem. The platform can't protect a user from doing wrong things. Well, it could just refuse to remove the device as long as it was still in use.
That is actually what happens when you try to delete custom drivers that are currently "in use by" a running app... A notification pops up stating the driver cannot be deleted because it's in use by X app.
But you said that In-Use-By may not be updated when you remove a device from a rule.
So, is preventing the user from removing a device that is "in use" really feasible?
Just reading the thread and wanted to weigh in on this. Right now, I think that would be a bad option. I like Bruce's solution to show missing device in the rule.
I do my absolute best to make sure a device has been removed from a rule before deleting the device, as described. But sometimes it says it is still involved in a rule, but it isn't. Likely it's because I've cloned a rule, switched out a device in the clone, but the rule hasn't really released the original device. When this happens, I do a page search for the device in the rule, and if I can't find it, I OK the deletion.
That was a sarcastic comment, not a serious suggestion. We aren't changing the way device deletion works, but we might make the warning a bit stronger worded.
When you remove a device, any app that references that device should be assumed to be trashed by the removal. Hence, if you don't want to trash the app or rule, remove the device from the app first!
Bruce, just to clarify, are we getting the "Missing Device" enhancement in the next release? It would be awesome to rid the random OR operator. Thank you!
This will be in the next release. It is not at all a good idea to use this approach of just ripping a device out without first removing it from the rules and apps.
This feature is not ready to be released. There can be undesirable side effects discovered in testing.
I heard you mention that in last night's live show. Good info to know for sure! Would it be possible to add a "Replace" feature? Some of my devices are contained in a metric ton of rules and it can be pretty painful to go through everything to remove the device and then add the new one back in. Maybe something that would take the references to the outogoing device, replace it with a placeholder virtual dummy device, and then allow the incoming device to replace the dummy? Maybe that is messier than it is worth though..
This is on our roadmap.
Excellent! 
+1
I assume that there's at least an internal method of DeviceWrapper that can be called to find where a device is referenced? I couldn't see anything obvious in the developer docs. I'd certainly find it useful in my LIFX master app which can wipe out all LIFX devices when doing a full scan - if only to warn users which rules/apps would break.
Old thread but it popped up on suggested topics and I want to throw this out there. A nice option would be a replace app. Where you could do the following:
Configure a new device
Launch the Replace App
Select Old Device
Select New Device (must be of same type as the old device)
Execute the replacement
Then all rules in all apps would be updated to use the new device instead of the old one. Then you could remove the old device.
Your wish has been granted:
Just click Replace and a Join/Include is started with the Node Number reused.
A ZWave feature that Zigbee can't do.
But more seriously, I don't believe an App can't do that. It's that one-liner "execute the replacement" that looks easy in words but I don't believe there is a mechanism for that.
So if you click REPLACE it will ask for a new device? Nice!
REPLACE is rather a lot like clicking the Include button. The difference is that instead of using the NEXT node number, it re-uses the current node number. Everything else about the join/include is the same.
But recognize that the OLD device is presumed to be dead/defective.. if it's NOT, it's still thinking it's Joined to the network.. it will have to be Excluded first if you intend to reuse..
For example, let's say you have a ZWave Dimmer and you buy a lovely ZWave+ Zooz or Inovelli to replace it. You can physically swap the devices and do nothing else.. don't try to join the new device.. Eventually your old dimmer will show as FAILED, and REPLACE shows. Begin the replace and click the new device to get it to include... it will drop right in. But that old device that is powered off WILL try and reconnect when you power it on.
I assume you do need to pair the new device first and then don't do anything with it until the old one fails and then do a replace? At any rate nice for Zwave replacements.
Really a shame my idea wouldn't work as then you could change device types even. It would just be a matter of the database swapping out all the old references for a new one for a given device. Old school programmer here so that seems like it could be done but maybe there are hurdles I don't know about here.
Absolutely incorrect 
Do NOT do anything to the new device.. it gets Included during the REPLACE process. Don't do it before.
I've REPLACED a device with itself more than a few times... It's gone 'stupid' on me and I just decide to replace it would be easier... my steps for doing this are:
For those with an actual, real new device, vs my reuse, the process is pretty much the same.. I'd start with an Exclude of the New device, just to be sure. The difference is that you end up with the old one in your hand, that has the same Node number and thus is a potential problem. Not for me.. I have multiple hubs and I can just use a different one to do an Exclude of that old device. Be careful of using an Aeon ZStick that is currently joined to your existing.. because that's a Secondary Controller and it WILL inform the Primary that it excluded the Node.. and the hub is probably just going to delete your newly added device. The solution is to reset or exclude the Z-Stick first.... Same with anything used via PC Controller. If it's acting as a Secondary, it WILL inform the Primary.
I have learned to be very wary of single-line-solutions that sound better when "Just.." is prepended. In your example "Just Execute the replacement" seems like everyone knows what that entails. It's written as if it's just as simple as " Launch the Replace App " Except all of us have launched an app.. we all know what that entails. I'm pretty sure none of us have "executed the replacement" process that in itself is not a page of detail
I'm not critiquing.. I'm enjoying the humor inherent in that set of 4 words.
there's a post that explains the migration from C-5 to C-7
An App would have to do all of that.
Maybe I'll try this on these ZEN30's that are giving me grief with the fan part of the switch. And ya I get it about the hidden things that a "execute the replacement" might entail. I'm just envisioning a table where Device X is a member of 5 rules, as you can see on the devices page, and that a magical swap could happen behind the scenes with those rules. Just like bringing each up and selecting a new device in lieu of the old. But I get it that it's not that easy. 
Download the Hubitat app
