Invert/Inverse Option for Mirror

Please add an inverse option to the Mirror App.

i.e. when Device X turns on, turn Device Y off - in addition to the on-on function that Mirror currently offers.

Honestly you could easily do that in RM

1 Like

Are you also implicitly asking for the ability to increase Level on Device B when Level on Device A decreases, and vice versa? (i.e. dimming as well as switching)

P.S. I'm fairly certain this feature has been requested once or twice in the past, and denied, but it continues to warrant consideration IMHO.

No

1 Like

Pretty easy in Basic Rule, too:

I don't think this would get much consideration in the Mirror app, which was really intended for certain wall controllers like the RGBGenie devices that track an internal state based on physical manipulation of the device and where such an automation would have been difficult to create ain a rule or other app given the number of attributes and commands involved.

This is isn't that use case, and it's very easy to set up. Historically, that has made these kind of changes less likely. :slight_smile:

4 Likes

That is only one half of an inverse mirror...

I have an inverse mirror implemented using two Simple Automation Rules but it would be simpler (and more elegant) if the Mirror app had this option. Thus the feature request.

Then you wouldn't like Mirror for this, either. Like my rule, it also goes only one way.

1 Like

Sorry, the "one half" I was referring to was that your Basic Rule example will only turn off a mirrored switch. i.e. a whole other rule is needed to turn it on correct?

I have no expectation that an inverse mirror would function in both directions - but that would also be useful in some situations I imagine.

1 Like

Ah, yes, it only handles responding to off. But you don't need a second rule to make the rest happen--you can just add a "Wait for..." action, choose the one switch turning on, and then make the other turn off, all in the single rule. (But, of course, either way would work.)

1 Like

A wait action sounds like it would tax the hub more than a conditional action? I’m speculating.

Can someone more well informed verify?

Less.

With that said, this topic has run aground. You’ve made your request - it’s upto Hubitat staff to determine if it fits their priorities

So @bobbyD, could you close this thread?

I'm not sure what you mean with "conditional action" in this context, since Basic Rule does not have them. If you went with Rule Machine, conditional actions don't create event subscriptions and have no effect except at the exact moment in action execution when that action is reached. I can't see a way they would be helpful here; you need an event subscription somehow so the app actually wakes and responds to the event. A "Wait" in either Basic Rule or Rule Machine is one way to do that. Two different apps (of whatever kind) that each "trigger" directly on the event would be another.

Whether you have two (technically one or two, depending on where you are in the rule) different subscriptions in one app (e.g., with a wait) or one subscription in two different apps would be of negligible difference to the hub. Either is just an event subscription that will wake the app when needed. There seem to be some who think a rule will just spin endlessly at a wait as it constantly checks for some state, which is not the case.

2 Likes

Download the Hubitat app