[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
5

@mbishop Mike, this app is crazy helpful. Wondering if it would be relatively straightforward to add two others: Battery (read-only) and Lock (read-write)? TIA

1 Like
6

Not too bad. There's no Generic Component Battery in-box, so I needed another dummy driver for that, and the pass-through functions for lock/unlock. Gave me an excuse to revive some code that had been sitting in a side-branch to make it more generic.

This would be really easy to do by meta-programming in Groovy, but those approaches seem to be blocked on the Hubitat. Still, see if GitHub - MikeBishop/hubitat-device-mirror at lock_and_battery has what you need.

I notice that the in-box Generic Component Lock actually supports both Lock and Lock Code capabilities. It's easy enough to add the Lock Code calls and attributes for all locks, if you want them, but that might also be what you're trying to strip out. Right now it only exposes lock()/unlock(), but the plumbing is there for commands with arguments.

7

I started playing with the battery component. After installing FDM via HPM, I added your generic battery driver from here. Except, unsurprisingly that doesn't make battery devices magically available through the FDM U/I.

I'm not sure how to make that part happen. Can you point me the way? TIA...

8

You'll need to manually install the app and parent driver from that branch as well. Once this version is published to HPM, it will overwrite your manual updates.

1 Like
9

Ah duh sorry. I installed it all this time -- locks and batteries are working too now. Will watch them more closely than normal next few days, but so far looks great. TYVM!

1 Like
10

Under the heading, “no good deed goes unpunished”, could this app support temperature sensors without a lot of effort?

11

Sure, that's a 1-line change. Publishing to HPM is more trouble than adding it.

2 Likes
12

Hah that's great.

If you're going to all that trouble ;), maybe you want to make it a temp & humidity sensor then? I don't need it per se, just figured it adds more extensibility and flexibility for those that follow. But maybe not.

You da bomb.