Yeah, that's part of what I was getting at with:
I had a similar thought about commands needing to be issued to the virtual device needing to be relayed to the physical one, whether that be commands issued inside rules or on a dashboard, etc. In my case the comm's are mostly one-way, so it is fine. This is also another reason replacing a device would be more appropriate than trying to maintain this ongoing relationship between devices.
and then theres that whole 'group' - thing too - I could see it getting messy if not well thought out before implementation!
Yeah, I think the options right now can help with very specific situations, and most of them I wasn't aware of, so this has still been quite helpful to talk through. But platform changes / features are very different proposition, it's not just my own personal setup you need to account for. It does sound promising though... 
to automate a device replacement seems like a really useful app that everyone would benefit from for sure!
My steps atm are to screen cap the device page so I can see all the places the device is used, then add the new device to the system and hand visit each dashboard, group and rule and add the new device. Finally, I go back a 2nd time and remove the first device that is defunct or being replaced.
In this way I don't have to re-write rules or recreate groups. It's not too bad but if I had to do 10-15 devices it would be a pain. But I'm zigbee so my life seems easier than others (gentle ribbing...)
And there it is as simple as something like
Update appTable Set dni = newDni Where dni = oldDni
Can't add much to the technical nature of this discussion, but this is one of the reasons (the largest being familiarity tbh) that I stick with webcore.
Alter one line/device and the entire Piston becomes transferable.
That is one feature I'd like in RM: device variables. (No, I've never asked.)
But I agree with what I think was eventually the conclusion above: some sort of hub-level "device replace" feature would be great! I'd rather see that than a virtual/mirror thing, which it seems like just works around the true issue while adding more overhead. Hub Mesh can sort of do this already, but you have to be working with meshed devices...
I had also thought about offering up the suggestion of using hub mesh to feed back into the host hub for a device, but, yes, it would still add unnecessary complexity for a point-in-time requirement.
That is a slightly different situation though, and not one I was specifically asking for. That could be used to update a rule to use another existing device, where you are not replacing the device entirely, just in that specific rule (app). The best I could think of in that case would be to try and use the import / export / clone option, which from memory prompts you to replace device references.
Yeah, I didn't mean to imply it would be a substitute for this, and I think an import would be a workaround for many of these cases (at least if you don't already have a device with that name, which I think it uses as at least a default match...can't remember the exact behavior). There could be other uses too, especially if you could make lists of devices and perform operations or queries on that, but now I'm dreaming...
...just like I have been for a hub-wide "replace" since probably the beginning. 
I know I've seen this request before and I think some concerns were raised, like what if the new device has different capabilities, but that's nothing you couldn't already break by, say, switching drivers. You just need to know what you're doing, so I could see this being a less-discoverable feature like export/import/clone. But I might still be dreaming--just a little more hopeful this time given the discussion above!
Kind of a coincidence but I was actually thinking about this last night, how it would be a nice feature if somehow you could set all rules with some type of virtual link to an actual device.
I was considering going through and creating virtual devices and then linking them back to the actual device so in the future a bad device or replacement becomes an easy swap. I have had several devices in the last month or so to go bad, or swapped for a another device or just had to re-pair because it lost connection and would not re-connect. I have an old GE /jasco that just went bad this week and I need to swap it out.
So this is a great idea.
Moved this to the Feature request category and tweaked the title, seems more appropriate with where the conversation has gone....
Device substitute. Please.
As in the Virtual Device option I was referring to originally, or are you talking about @bertabcd1234 comments for rules and alike?
Understanding the concerns that have been discussed more than once, I am for a platform wide replace of a physical device for another one.
Simply replacing a faulty bulb or a sensor becomes a real time consuming pain.
There are two sub-topics here: One is device abstraction that could have a number of uses, and another is device replacement.
@bertabcd1234 could you describe a use case for Device Variable? I assume it is the first topic.
I'm happy to split the topics if you prefer. My preference is for the replacement, to solve the situation I am facing at the moment, so would be happy to continue that discussion here and update the topic title.
Here are some threads I remember participating in where something like this would have made writing the Rule in question easy or possible. In many cases, the new Rule 5.1 "last event device" feature would address the need:
For cases like that last one, I normally end up writing a custom app. Here's something I replaced with a custom app that I wouldn't have needed to if something like that existed, though that request is more than simply a device variable (but rather a collection of devices, and the ability to do things like store matching ones to that collection--apparently a webCoRE feature people ask about sometimes):
OK, but none of those actually present a case for a device variable per se, and even with device variables would still be difficult. The cases shown:
He could select multiple thermostats and use Last Event Device, but in order to set some specific device related to which thermostat triggered, there would need to be some sort of table look up.
Again, the need for a table look up to select which variable to set, and again, a device variable wouldn't help solve that.
Solved using Last Event Device.
What can I say other than use webCore?
Your final case is another table lookup problem.
Having looked at the implementation of this, I believe that it would introduce more pitfalls and confusions than it would solve real use case problems. It would absolutely trash the UI to add the option of selecting a variable in every device selector context, as a device variable isn't a device. Or, attempting to solve that would require deep modification to the platform so that a device variable IS a device of some sort (isn't that what a virtual device is?). All in, I'd say this is a can of worms.
Download the Hubitat app
