[REQUEST] Virtual Device as Mirror of Physical Device (or Replace Existing Device)

Is it a valid approach (and possible) to have a virtual device that mirrors a physical device, using the virtual device in rules and apps? My gut feel is no....

I have some Zigbee contact sensors and buttons I want to move from my C-4 hub to my C-7 hub. There's about a dozen or so devices, so not a mammoth task, but some are involved in 5 or so apps or rules, so a bit tedious to migrate. I am aware of a technique to temporarily setup a virtual device to refer to in these apps or rules whilst doing a move like this. I am wondering whether it is possible and advisable to have this as the permanent arrangement, a virtual device mirroring the physical device used across the system. Aside from the overhead this would introduce on the hub, the other reason I am expecting the answer is no is that commands would also need to be relayed from the virtual device to the physical one.

I guess ultimately I am after a more seamless experience when moving a device, requiring it to be temporarily removed from the system. So any advice in this space would be welcome. I'll start moving the devices anyway, but would be interested to still discuss this if anyone has any suggestions.

Thanks.

Actually, thinking about it some more, since the devices I am interested in are only contact sensors, these only need to provide status updates, so reflecting that status in a virtual device shouldn't be too hard, even just some basic RM rules would do it....

You could use a small app, like the one below. Just change it to create a virtual contact sensor instead of a motion sensor, and send open/close instead of active/inactive:

1 Like

Thanks @bravenel.

The issue I have, or I am assuming I will have, is that because I need to remove the device from the C-4 hub in order to pair it on the C-7 hub, I need to account for that in the rules and apps first, and the removal of the physical device will be reflected across all hubs. Certainly hub mesh will allow me to still use the device on any hub once I move it, it is more the references to it I am trying to manage, if that makes sense...

After I re-read the above I realized what the real question was…

1 Like

Interesting idea -- essentially introducing a layer of indirection for devices. With this in place, there would be only a single app that needs to be updated when a device is changed. Overhead exists, but is small.

Maybe a variation of Mirror Me that works with any device type, creates a corresponding virtual device, and forwards all events of the real to the virtual.

5 Likes

That's essentially what I am after, a layer of abstraction. It would significantly reduce the prospect of, for example, migrating to a new hub. I know (think?) there are "whole of system" options, but sometimes there is a need / want to do the migration in stages.

1 Like

Or even contact sensors implementing the switch capability would be a start for me to be able to use this...? But thinking about that now, there would probably be a few drivers for you guys to update I expect... Whereas mirroring devices more generally provides the bigger benefit...

Might need a small change to the HubMesh devices to make this completely functional; from my playing it appears that the mesh component devices wil accept event from the real device, but any events sent to a component device aren’t forwarded to the real device.

1 Like

Alternatively, instead of maintaining an ongoing virtual -> physical device relationship, having a part of the platform to assist in making the kind of migration I am looking at could be another route. So that could include temporarily being able to suspend and then link up the representation of a device in HE, like what I am essentially wanting to do in moving my contact sensors to another hub. Or having an option to replace a device with a different physical device.

Technically the kind of situations I am describing are a point in time requirement, there isn't a day-to-day need for this. The only reason for me suggesting the virtual -> physical setup ongoing was so that the transition became easier within the current capabilities of the platform. If HE could handle that for us at the time of changing devices, then there would be no need for having the virtual device in place all the time.

Yeah, this would be nice. On our wish list... SMOP

2 Likes

…is rarely simple :sunglasses:

1 Like

That's completely understandable, it's all a balancing act. Anything you can do in this space would be appreciated, but there are still some options like the sample app, RM rules and potentially Mirror Me with a few tweaks, so I am certainly glad I raised the topic, thanks @bravenel.

Given that underneath is a database, and that can be manipulated, this might not be all that hard. Essentially, need to expose a means of mapping an old device id to a new one. One simply zaps the db to replace instances of the old device id with the new device id, a mass replacement. That plus some UI on top of it.

6 Likes

Using that layer of abstraction - how would that affect dashboards? since there are certain characteristics of the dashboard that would get 'lost' or am I misunderstanding how one would implement this?

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... :slight_smile:

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

2 Likes