Correct way to implement home modes?

[Zapnologica (Dylan)]

Good day, I am fairly new to ha and I would like to ask you more experienced users what is the correct way to go about setting up modes for my house.

In my mind I want the following modes.

Away,
Home,
Sleep,
Visitors,
Vacation

Each one of these modes would have different behaviors. For example set the alarm differently, it change schedulers for geysers if we have visitors, etc.

Should one use scenes for this? Or should one create binary sensors as variables which you can turn on and off? Is there maybe this sort of. Blueprint somewhere?

Really looking forward to hearing your advice and pointing me in the right direction…

[Stiltjack]

I use input_booleans to set away mode and night mode. Automations and scripts check whether these are on or off before proceeding.

[tom_l]

I use an input select. It can have as many modes (options) as you want.

Then use it in conditions or triggers in your automations.

[PecosKidd]

And I use both! A Boolean helper for “Security”, and a Select helper for [Morning, Day, Evening, Night].

There is no wrong or right on this: find the way that works best for you and the way you think. And don’t be afraid to evolve the methods as you gain experience… and complexity with your environment.

[calisro (Rob)]

Yep. There is no right way. I use none of them.

home/away is an automatic operation that is handled by the home being vacant ( motion/wasp/sensors) and people being away (companion app)
sleep is an extension of being home handled by time period and parts of my house being vacant, phones being plugged in, etc.
vacation is an extension of away and is handled by zone proximity/direction of travel greater than 20 miles for longer than x hours.

This all evolved. Just make a ‘sane’ approach and you’ll find you’ll refactor some of it as you learn and as you integrate more.

Well. I do have one boolean for ‘company/visitors’ that does disable some things when company is over. So i guess it isn’t really ‘none’.

[Zapnologica (Dylan)]

Thanks all for this,

I get your points there many ways to skin a cat. I didn’t think it was as simple as just a boolean value etc. I thought there might be some advanced feature or plugin in HA that would handle this.

So if I understand it correctly I will just have some variable names. and use and reference them in my automation.

Then I can also trigger certain things to change them? Like if Alarm is on Stay Mode it can go and change House mode to SLEEP. etc.

[lennon101]

I’m bubbling this topic back up to the surface because I have tried it a couple of different ways now and I’m still trying to settle on one.

Method 1

Day/Night modes are a single input_boolean
Away/Home modes are a single input_boolean ’

Toggling each one not only runs a script to get the house into the create state (eg for night mode → dim lights/close curtains/army security system) but also contains state for other automations (the input boolean becomes a blocking entity if it’s enabled)

Method 2

Using a manual Alarm Control Panel entity where each state (arm_home, arm_away etc) runs a script as in method 1 but also contains state

Method 3

Using an input_select to do the same thing as method 2 but with more flexibility to add other states that the alarm control panel doesn’t support

---

My issue with all of this is how get the house into the correct state for that mode, while at the same time toggling the blocking entities from multiple different routes (i.e from google home, from HA, or getting the script to do it)

It’s a complex issue. And one I havn’t solved yet.

[lonebaggie]

Method 3

Don’t know if this helps , but I break out my Input_select into template switches. The advantages of this is all the switches always match the input select and vice versa , so only one switch can be on . More importantly template switches don’t trigger when set with value template.

Example I have group of lights which three modes Dark, Relaxed and Bright. so the input select (input_select.mood) has 4 states

Off
Dark
Relaxed
Bright

So if I trigger Dark by turning the dark switch On ( and will trigger any automation) , Relaxed and Bright will be off , and will not trigger Off to any automatons. If I then Trigger Bright on the Input Select . Bright switch will turn on ( will not Trigger) and then other switches will be off ( no Trigger) . This should simplify any automatons, as you can keep all your switches in sync ?

Here is the code for the template switch.

      relaxed:
        unique_id: relaxed
        value_template: >
          {% if is_state('input_select.mood','Relaxed') %}
            true
          {% else %}
            false
          {% endif %}
        turn_on:
          service: input_select.select_option
          data:
            option: "Relaxed"
          target:
            entity_id: input_select.mood
        turn_off:
          service: input_select.select_option
          data:
            option: "Off"
          target:
            entity_id: input_select.mood

I use this with Alexa. It use the switches to change the input select . I trigger using the input_select

[PecosKidd]

There should be relatively few ways that the master state values change. For example, my home state changes to “Evening” based on local sunset only. The change from “Morning” to “Day” is based on either the time (becoming x:00 on weekdays or y:00 on weekends), or the user manually changing if they’re up at a non-standard time.

Lots of other flows / automations look at the home state value (e.g. don’t do x if it’s currently “Night”), but very few actually change the primary values.

Separately, I started with a Day/Night boolean, but evolved that to an Input_Select of [Morning, Day, Evening, Night] for additional flexibility. For example, 45 minutes before I’m scheduled to “get up” I set home state to Morning, and based on that turn a few lights on dim and adjust the thermostat to start making it comfortable. Then at “get up” time I set the home state to “Day” and that triggers the lights and other adjustments to bring things into full daytime mode.

[lennon101]

@lonebaggie

Don’t know if this helps , but I break out my Input_select into template switches.

This is a really cool method. Thanks @lonebaggie! I’m going to dig into this more and I’ll let you know how I go. Thanks for the insight!

[lennon101]

@PecosKidd

Separately, I started with a Day/Night boolean, but evolved that to an Input_Select of [Morning, Day, Evening, Night] for additional flexibility. For example, 45 minutes before I’m scheduled to “get up” I set home state to Morning, and based on that turn a few lights on dim and adjust the thermostat to start making it comfortable. Then at “get up” time I set the home state to “Day” and that triggers the lights and other adjustments to bring things into full daytime mode.

This is pretty much how I’m doing things at the moment too. But I’ve found time and time again that I’m getting tied up in knots with the edge cases or exceptions to the rule. An example is:

I currently have several input booleans:

1. away_mode (automatically set when house becomes empty)
2. sleep_mode (manually set via script or switch)
3. nap_mode similar to sleep_mode but only blocks automations in the bedroom instead of all over the house (useful when wife wants to take a day nap)

These booleans are used in lots of different automations as conditions that control if an automation is triggered or not.

But I also have Bedtime and Good Morning scripts that do certain things like dim the lights, turn the kettle on, and by their nature, also set the modes if relevant → i.e the Good Morning script turns off the sleep_mode and the Bedtime script turns on the sleep_mode.

Now, this all sounds great, but there are cases where I need to leave the house in sleep_mode even if the house becomes empty (like we are all leaving the house early in the morning but the dogs are still inside).

So I don’t know, I can see the usefulness of the input_select method, but I also see cases where each mode/state is not mutually exclusive and I need different modes to be activated at the same time.

Perhaps the answer is making use of the input_select method for the home modes as you have (day, evening, night etc) and then another input_select for the state of the house (home, away, visitors).

I don’t know, I’m just spitballing now

[PecosKidd]

It is complex, which is why this is a system for tinkerers, and any sort of advanced home automation is extremely difficult to make “set and forget”!

In addition to my main home state, I also have completely separate Input_Selects for “Security Mode”, “Season”, and “Outside Temp Range” (ie Hot, Warm, Cool, Cold, Icy), and Input_Booleans for “It’s Dark Outside”, “Holiday Time”, “Upstairs Occupied” (ie, we have guests staying with us), and others.

Some of these are manually set, but most are system set by various sensors/conditions.

Hopefully, you find the logic puzzles of accounting for all the permutations of these a perverse sort of fun! It’s extremely rewarding when things work as they should and you realize you can implement some new condition, or utilize some new sensor, by incorporating the right set of those already existing fundamentals.

I will also suggest that, at least for me, doing automations in Node Red is easier than using the native automation engine. This is definitely a personal preference, maybe a right-brain vs left-brain thing, as some folks pretty adamantly are not NR fans. But for me, the visual flows of NR are much easier to grasp and to troubleshoot.

[lennon101]

@PecosKidd

I will also suggest that, at least for me, doing automations in Node Red is easier than using the native automation engine.

Yeah I’ve considered it and I am already hosting a NR server in docker beside my HA instance (also in docker). Whats your process/method of routing all triggers from HA to NR and back to HA? or am I thinking about it wrong? I’m guessing MQTT is involved?

[lonebaggie]

It can get very complex . The real issue is home assistant will trigger on any action so you need to account for all these options in your automation’s . Again template switch can help . If a switch is “on” you cannot turn it on again . The value template however can turn a switch off and on without Home assistant noticing . So if you turn away mode on , you can force a number of other switches to be permanently on / or off. If you trigger these switches on , the template value will turn them off or on . The switch will trigger when you turn it , but not when the value template does.

Basically your moving some of the logic of the automation to the switch. I use this to make momentary switches , same as a button , but without an automation .

  audio_clear:
    friendly_name: Audio Clear 
    value_template: "{{is_state('switch.audio_clear','on')|iif('false','')}}"
    turn_on:
      - service: shell_command.audio 
    turn_off:

As soon as you turn the switch on it does some thing ( in this case changes audio on my TV) , then almost immediately the value template turns it off.

[andarotajo]

I’m currently thinking about implementing house modes but quite indecisive on the approach. At most my intended house modes would be

• Home
• Away
• Sleep
• Guest
• Vacation

Guest and vacation being manually triggered and home/away based on my presence. But thinking about all the aspects to consider when setting the mode automatically is hard. Examples:

• Setting the correct mode when HA is started
• Not setting to home when it’s on guest/sleep
• Setting the previously set mode when waking up
• Not setting to away when it’s on guest/vacation

Stuff like that… but triggering on globally set house modes is probably cleaner than rewriting all the conditions I’d need to consider myself asleep etc.

[PecosKidd]

Don’t feel like you need to make it all fit into a single mode. You may find it easier to split some out, like Home / Away / Vacation in one entity and Guest True/False in another. Or whatever combinations work best for the way you think about it.

[andarotajo]

Having it split between input_select and input_boolean feels to messy but that’s just me. I think I figured out the conditions I need to consider for each mode yesterday. There will probably be edge cases I didn’t consider but that’s just how it is

I also decided to split the automation for setting the house mode automatically to each one having a seperate automation.

And my point about setting the correct mode on startup is also kinda unnecessary. I’ve started keeping HA on over night and now I can’t think of a situation where I have HA turned off for so long that the restored value doesn’t fit any more (except maybe a power outage)

I’ll just try it out and see how it works

[PecosKidd]

Excellent! The single most important factor is that it “feel right” to the way you think about your home and its automation.

And expect and embrace your approach evolving over time as your experience and the complexity of your automations grows.