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. 
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
The following Basic Rule works during testing when the wait is seconds to minutes but fails when the wait is hours:
I would provide logs to support this (from the Basic Rule app). New in 2.3.3, you can also check "Events" on the switch to see what commands were attempted, not just what events were actually generated (the idea being to see if Basic Rule tried). Along with this, the App Status page of the Basic Rule before and after the failure may be helpful. During the wait, there should just be an event subscription for the switch turning off, and the amount of time it takes that to happen should not matter.
Keep in mind that hitting "Done" in the Basic Rule will start things over (needing the switch to turn on again, in your case). The chances of someone accidentally doing that (or overlooking this detail) do increase with the amount of time that passes, and that's often the actual issue in cases like this. But if not, the logs will be the key to figure things out.
That being said, RM (as above) would certainly work too--but if it appears not to, logs would again be the most helpful to figure out why.
Appreciate the guidance everyone but I'm staying away from hours-long waits and sticking with two separate rules.
That's fine as well, but my point--more directly and in fewer words--is that separate rules won't help if the problem wasn't the rules in the first place (e.g., if the device wasn't responding). All the talk of logs and other tools was to pinpoint the actual cause; whether one rule or two, all you have is event subscriptions, which should work equally well whether it's one app or two or how much time passes between events (the root of my suspicion that it is probably not that).
Good luck! (But still maybe enable logging on the new rules just in case. 
)
