Stop the automation!

Can I get some ideas here? I'm thinking of creating a rule that disables all automatic rules, like 'turn on lamp on motion, time etc' or others that perform actions independently. Should I use MODE or a variable? I'm considering activating this rule when I'm away or when I don't want lights and functions to start and stop automatically.

Personally I keep my modes simple: Day, Night, Away and Cleaning. Away is a broad meaning and could just be away from the house for a few hours. I then have a Vacation virtual switch that I integrate with my Google Calendar which disables certain rules and automations from happening when we are away on vacation. Now this said I did create this Vacation switch many years ago well before hub variables existed so I could have done this with a hub variable today. But apps like Basic Rule, Simple Automation, and Room Lighting have restrictions to disable based on the state of a switch so having this as a switch helps in that regard.

1 Like

I'm similar with my modes: Overnight, Ambiance in the Morning/Evening, Circadian. They really just represent time periods based on the sun and how I want my lighting to adjust. For your request, I use a virtual switch (or switches) to determine how things should adjust based on presence or if I need specialty lighting due to holidays/seasons.

You could create a virtual switch called "disable rules", then edit your rules such that if the VSwitch "disable rules" is active then the actions are skipped.

Might be a lot of editing though.

Seems adding a AND operator in triggers would be a nice feature (other controllers have it) but instead they want that logic in the actions sections which seems more cumbersome to edit.

2 Likes

Maybe I have too many modes? Or do I? :roll_eyes:

Big vote for this approach, but instead using a boolean Hub Variable (with or without a virtual switch connector...handy!) that gets included in a Required Expression for any rule you want to govern with it.

I actually name my HV's for this purpose "Enable_XYZ" instead of "Disable" and leave them set to True (or On) until I want stuff to stop executing.

2 Likes

I use Modes for this. I try to keep it simple - I have Day, Evening, Night, and Away as my Modes. I use Hubitat's built-in "Mode Manager" app to perform all of the various mode transitions based on time of day/Sunrise/Sunset as well as detect when all of us have departed (using our phones as geo-presence sensors.)

This allows my lighting automations to adjust based on the mode, to have the correct lighting levels based on Sunrise and Sunset. Some automations also change their behavior based on the house being in "Away" mode. However, I have found that since I want the house to still look 'lived in' when we are away, I allow most time-based lighting automations to run normally. Most all other lighting automations are motion-based, and thus they only activate when someone is in the house.

Thus, it really does feel like this is much more of an overall strategic thinking exercise, that is somewhat unique to each individual's style for home automation.

2 Likes

Modes here are for time of day.

States of being, like "AWAY" and "VACATION", are virtual switches.

For RM, use your "enabled" (or "disabled") virtual switch as a Required Expression for your automation rules.

2 Likes


I'm testing this. Note that this is just a preliminary test and an idea. Will build a real rule when I've decided how to do it..
Thank you for all your responses and feedback

1 Like

I also use a ā€œAutomated Lights Disabledā€ switch for some rooms and one global one.

In your rule above, I notice you have a 12 hour delay. This will delay the pausing of the rule.

If you want the rule resumed (un-paused) after 12 hours, then the delay and action to resume it will need to be added separately.

Also, for this to work well, I would suggest making the flipping of the switch on as the trigger.

Here is what I would do:

Trigger:
Automatic On Off Global Variable becomes True

Actions:
Pause Rules
Wait for condition elapsed time: 12h or Automatic On Off Global Variable becomes False
Resume Rules

2 Likes


Thanks, I have done something like this. It's just a rough test routine so far.

An AND operator in a trigger creates an almost impossible situation to have occur. Triggers are instantaneous and it would require both things to happen at exactly the same time. If other platforms have it, then they are likely to not truly be triggers.

Hubitat does have AND operators in the required expressions as well as AND operators in the logic section for conditions.

Using a virtual switch creates a condition. It could be a trigger, but that trigger only occurs at the exact instant it goes from on to off or from off to on. In order for that to be used with an AND in the trigger, that would have to occur at the same instant whatever other trigger is for the rule (time, motion detected, etc). That is not likely to happen.

For the OP's post, either the required expressions OR the logic section could be used to limit rules when the condition of a virtual switch is on/off. The required expression would probably be the better location. But, it could also be made to work within the logic parts of the actions.

2 Likes

Youā€™ll find that the ā€œELSEā€ condition will never happen. The rule will be triggered only when the ā€œV_Stop automatic Rulesā€ turns on.

If you prefer to use a condition instead of a wait, then you would want to trigger on ā€œV_Stop automatic Rulesā€ changes.

I just think adding logical operations in triggers to combine an edge condition (trigger) with a state condition would make for a cleaner rule.

Here's an example. I have a light call Box Lights Main and another called DR Chandelier. If they both get turned on I would like to turn on a third light called Walkway. To do this in Hubitat I would do something like this:

RuleA

But if the triggers was relaxed to trigger/condition then it would simplify to this:

100%

Ditto. But I also have a mode called manual. Basically modes used everywhere and this mode is triggered when home is away mode and a guest arrives.

Manual mean all auto rules and apps don't do anything and it's switches only.

1 Like

I let Modes drive everything.

  • Day - sunrise to sunset when I'm home
  • Evening - sunset until bed time when I'm home
  • Night - manually triggered when I go to sleep and dock my phone
  • Away - essentially I'm not at home. Whether walking the doggo around the block or spending an afternoon at friends, I am not home
  • Vaca - I am away for an extended time, typically out of town
  • Guest - keeps lighting automations working, blinds, etc. but doesn't alter the HVAC. Typically only used during Vaca when someone is checking on the house for me
  • Work - reserved for on-call overnight stuff, it turns on limited lighting to get me to my home office and not blind me awake

I've not found a need to disable automations since most are the house essentially being self-aware and doing things (blinds, HVAC, lighting, etc). I have lighting configured to "ghost" the house when I'm not home so (from the outside observer) it appears exactly as it does when I'm home as lights are driven by presence in rooms. Anything outside of these are driven by my presence so they're not running when I'm not there anyway.

1 Like

Your example can be greatly simplified by just selecting both switches and having them be all turn on. See:

This works just the way you want and simplifies the rule so there is no need for conditional triggers.

3 Likes

Hi all,

A similar take on what has already been mentioned with using modes. I make it a standard practice add two mode statements at the top of nearly every rule routine (vacation & disarmed). No switches to flip, buttons press. Just change the mode. See photo.

If the system is disarmed I am testing (similar to ADT testing)
If the system in vacation I don't want those routines running while away.

  • Don
1 Like

Strong vote for keeping modes SIMPLE.

Personally, I use "override" variables, e.g. Override Garage, Override Circadian, Override Ralph, which disable/reenable the associated automations. Each automation refers to the override variable in the required expression of the respective rule.

Works for us.

1 Like