[BETA] Filtered Device Mirror

⚙️ Custom Apps and Drivers Custom Apps
1

Some devices have lots of capabilities. Lots and LOTS of capabilities. Maybe it's one device with lots of capabilities. Maybe it's a parent-child device with different capabilities exposed as children. Normally, that's awesome.

However, if you have multiple hubs, you're probably using Hub Mesh to share a few devices across them. We all try to have logical boundaries so most things stay on their own hub, but there's always that one automation that would be easier if it could refer to a device on the other hub. And then that thing. Oh, and just one more.

But wait -- now every state change of those complex devices is causing events and load on both hubs, when the other hub really only cares about one particular property. Isn't there a better way?

What This App Does

This app lets you select a device on your hub and create a read-only virtual device that reflects a single capability of that device. You can then share this filtered device using Hub Mesh, and the other hub only sees state changes for the capability that you chose to expose.

For example, say you're using the Unifi Network Controller. You have lots of properties related to your network, polling status, child devices for managed network hardware, etc. all of which would get mirrored to the other hubs if you added it to Hub Mesh. But all the other hub really cares about is the child device exposing presence for your kid's tablet. Create a mirrored device that is only a presence sensor, then share that.

It currently supports Switches, Presence, Power Meters, and Power Sources because those are the attributes I've wanted to extract from my complicated devices so far. If you want something else, it's usually a one-line change to add support for a new device type. (If there's not already a Generic Component X for that device type, it also requires copying a boilerplate file.)

Currently on GitHub and HPM.

Updates:

  • 1.1.0: Adds support for switches, including mirroring on/off commands back to the original device
8 Likes
2

Brilliant concept. I run all my automations on a single hub and share my devices using hub mesh from 3 device hubs to the automation hub. This seems like it might be vrazy useful.

S

1 Like
3

Hm, that's a different partition than I have. I have one hub that handles all the network-based devices (anything that gets polled or subscribed to over the LAN, basically), while the other handles all the traditional mesh (Z-Wave, ZigBee) devices.

I try to keep automations local to each set of devices, but there are some key values from the LAN side that drive or influence the mesh automations.

It's great if you want to extract a single sensor value and pass it forward. The virtual device is (so far, at least) read-only -- you'll note I don't support any capabilities that expose commands that you might expect get commanded back to the original instance.

1 Like
4

Just merged a PR that adds support for switches, including reflecting on/off commands back from the mirror to the original device. (Internally, the on()/off() calls to the mirror only trigger the corresponding call on the original, so when you see the state change, you know the original device has acted on it.)

It departs from the original model that everything was templated, since there's type-specific code to handle this case, but switches are common enough that's likely warranted. Similar type-specific code would be needed for any other non-read-only types added in the future.

1 Like