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ā¦
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.
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ā.
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.
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.
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 ?
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.
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:
away_mode (automatically set when house becomes empty)
sleep_mode (manually set via script or switch)
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).
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.
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?
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 .
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.
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.
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)