And there it is as simple as something like
Update appTable Set dni = newDni Where dni = oldDni
1 Like
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...
5 Likes
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!
2 Likes
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.
2 Likes
Moved this to the Feature request category and tweaked the title, seems more appropriate with where the conversation has gone....
Device substitute. Please.
1 Like
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.
1 Like
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.
