Help Needed (again :-() - Disable/Enable Rule with "Physical" Switch

I have my motion lighting rules set up in RM as I need them to use shade position. All lights are standard switches connected to Fibaro Dimmer 2 modules. I'm trying to modify my rule so that:

a - if the switch has been turned on "physically", it doesn't run the rule in the first instance
b - if motion has already been detected and the rule has started (lights are on), "physically" altering the dimmer level will cancel the remaining steps, leaving the light on
c - "physically" switching off the lights will re enable the motion rule

I've tried a few things but the options I need don't seem to be available in RM. For instance "physical switch" and "physical dimmer" are only available as a trigger so I can't use Physical Switch is Off as a Predicate/Defined Expression. In actions I can't use a conditional IF Physical Switch/Physical Dimmer is On - they're not available. I've even tried to create an additional rule to switch a boolean variable that could be used in the main rule - Trigger is Physical Switch On, Physical Switch Off, Physical Dimmer Changed. Action IF.......Nope - stopped again as I can't select Physical Switch there either even though I've included it as a trigger. I could do it but I'd need 3 rules to switch the boolean - one for physical on, one for physical off, one for physical dimmer changed.

I'd rather not create a load of virtual switches if I can help it. Is there another way that I'm missing? TIA

This may give you a few ideas to try.
I have an outlet that I do not want to turn off if turned on manually.
The outlet records in the events for the device if it was turned on/off physically/digitally.

Summary

When the device state changes I save the change into a variable called state.
In the screen shot below you can see what is saved to the variable.
I then use what is in the variable called state to do different actions depending on how it is turned on/off.

Summary

If the Fibaro switch records physical/digital in the events you may be able to use this in a similar way.

As I said, this may give you ideas on how to accomplish what you require.
Good luck.

1 Like

Thanks @bobbles - yes the Fibaro Dimmer does record that info. I initially just created an empty rule with a trigger of Dining Light Physical Switch On to see what happened and could confirm from the log that the rule would only run when I used the switch and not a dash tile etc so knew it should be possible somehow. I'll see if I can figure it out based on your example.

I had problems with reliability that way. I is a virtual switch as follows.



1 Like

Thanks @kahn-hubitat and @bobbles

I'll maybe try one method with one room and one with another and see if either work better/worse.

Currently I'm trying it with two variables. One captures the state text, writes it to a variable and then changes another boolean to true/false according to the contents that text. I'll then add that true/false condition into the predicate for the motion rule (as an AND to time or curtains closed) Then I'll have to add something into the actions to deal with when the change occurs after the rule has already triggered.

So the second variable is not being changed even though the condition in the rule is met. This is the rule and the resulting log - it skips the action as if the condition is False. Any ideas?


Hi @johnwill1
I'm not sure why I used 2 statements. One for 'physical' and one for 'off'.
It was some time ago that I wrote this rule.
Maybe I could not get 'physical off' to work. I cannot remember to be honest.
Try breaking it into 2 statements and see if that works ok.

I'll maybe have to leave it, I don't want to create multiple rules and variables to get it to work. If I do a Physical On it works - otherwise it doesn't. It doesn't give me much faith in Rule Machine.

All I can say is the way I have it works. :man_shrugging:

I've changed it again as only one of the four conditions needed to change the variable to True. So I just left the one condition with an ELSE set to false as shown but it's still hit and miss. I'll add separate triggers and see if that works

  1. Use a hub variable diningRoomMotionEnabled and set it to true
  2. Create one rule with a predicate expression for diningRoomMotionEnabled=true that does just the motion lighting (single trigger by motion active) and exits when motion is inactive or dining room lights are turned off
  3. Create a second rule for the physical switch and physical dimmer triggers that will set the diningRoomMotionEnabled variable to false and cancel rule timers for the motion app
  4. Also, in your physical trigger app, re-enable diningRoomMotionEnabled based on some condition (elapsed time, mode change, lights off, etc). For instance in some rooms I have physical on/off/dim disable motion for 1 hour, in other rooms I have physical on/dim disable motion for 30 minutes but physical off only disable it for 15 seconds (enough to exit the room and close the door)

When I first got my HE about a year ago, I wanted to have very few apps installed so I had these monolithic apps trying to manage too much state and conditionals, loaded with debug logs and
exit conditions. You end up with trigger spam, multiple running instances, odd behaviors, errors. By splitting the monolithic rules up into multiple simple rules with simple triggers and simple actions, my automations run more fast, consistent, and error free.

2 Likes

Just wanted to second @birbeck’s comments real quick.

I also spent a LOT of time, energy and frustration early in my Hubitat journey creating multiple large, complex, self-contained rules. Think I figured it would be “cleaner” that way.

Over time though I’ve come to appreciate the efficiency, speed, and reliability of splitting as many things into multiple rules instead — and leveraging hub variables much more to help trigger or manage my rules.

Not that this use specific rule/case is even a big deal compared to the monstrosities I used to create on my hub but if I could go back in time two or three years ago and give myself one piece of automation advice it would be to embrace variables and multiple smaller rules much much sooner.

1 Like

This seemed a bit strange to me as I use a standard switch, connected to a Z wave module which is in turn connected to the load. So without any rules and with the hub unplugged the switch will operate and dim the light. However thinking about it I could use that to force the light to a certain level at switch on rather than either 100% or the last known level (which is how the module would turn the light on)

I started another thread regarding this problem. What I've done so far is a little different.

  1. Create a hub variable diningRoomPhysical

  2. One rule with triggers Physical Switch On, Physical Dimmer Changed sets the variable True

  3. One rule with trigger Physical Switch Off sets variable False

  4. A rule that triggers on motion active between sunset/sunrise or if curtains are closed

In RM I can then use that variable being false as a required expression for the main motion activated rule and I will also be able to use it within the rule to keep the lights on if I adjust the dimmer once the motion detection has already put the lights on. Switching the lights off at the switch will put the variable back to false allowing the motion to trigger the lights again.

Annoyingly I could have used Motion Lighting rule rather than RM as I can use the variable in there to prevent lights on/off - I've tried this and it works great and is noticeably more responsive than RM. Unfortunately what I can do in RM but can't in ML is use the shade position closed to enable the rule to run outside its time window. I need this as there are no luminance devices (I'm using the motion sensors on my alarm system via MQTT as I don't want additional battery devices). If I get up after sunrise and the curtains are closed the lights need to come on. ML has a "buttons to enable turning on/off" but I can't use window shade position. As shades make the room dark I think this option would be helpful in Motion Lighting.

Yeah, use ML if that works for you. I personally don't use ML because I like my lights to fade off, and after a little practice (and a lot of pulling hair), you can setup advanced motion lighting in no time. RM can be just as fast as long as you keep your triggers and actions simple and short. If there is a ton of logic and conditions before the lights on action, all of those will take up hub processing time causing a delay. By having clearly defined rules, and using predicates, you can get straight to your actions.

Anyhow, to the point... You can combine your two physical rules to a single trigger 'Physical switch changed', and then set the variable to true if lights on and false otherwise.

I like using the Hue motion sensors because they have light and humidity capabilities as well, but since you need to do this without a illuminance sensor then you can use a virtual switch to turn on and off when the curtains open or close, then you can use that in ML to disable the automation if the switch is on.

Yeah I'd much rather use ML as it's noticeably quicker.

I'm trying to do it the other way around - motion lighting is active between sunset and sunrise OR if the curtain is closed. I can't see an option in ML to enable the rule based on a Switch, only a Button, so it won't work. The curtain module does present as a Switch that is On when Open and Off when Closed. If I could use that it would be fine, but the option isn't there and if it were, the "Switch" is the wrong way around.

You can use a hub variable with a virtual button connector, or ML can also disable the automation when a variable is false, so if you can have a basic rule or rm rule that either toggles the button or updates the variable when the curtain switch is open/closed.

I would just do this entirely in ML though. Note: I haven't tested this, I created virtual devices that mimic what you have, and created the rules in less than 5 minutes, but this is the idea...

One automation that simply handles the motion lighting when the conditions are met:

Then another that overrides the motion app with physical switch/dimmer:

Modify it as you see fit, but this should be a basic template for what you want to accomplish.