WTH can't I temporarily enable/disable certain services (e.g. light.turn_on)?

Archive Month of "What the heck?!" (2020)
1

Say I want to make an “Away” house mode that ensures that neither my lights, nor my AC will turn on while I’m gone.

Currently, I have to manually add every automation that turns on lights into a group, then call homeassistant.turn_off("group.automations_that_turn_on_lights").

What if instead we could do something like:

  • homeassistant.turn_off_service('light.turn_on')
  • homeassistant.turn_off_service('climate.turn_on')
  • homeassistant.turn_off_service('switch.turn_on', 'switch.air_conditioner')

This would make it so:

  1. Future automations with light.turn_on are automatically compatible with “Away mode”.
  2. You can still run an automation that has other useful steps. Ex: you have an evening automation that turns on lights and security cameras. When away, the automation would still get called, but it would skip the lighting step, and still run the security camera step
2

Alternatively you could write proper automations that have conditions like not away or similar.
Can you imagine the issues we’d get if someone turned these off accidentally ?
It’s a nightmare

5 Likes
3

100% agree with @Mutt.
Some food for thought for your logic:
What if you want to randomize your lights, while you are on holiday? What if you want to turn on your climate x hours before your expected arrival to have a comfy temperature when you arrive?

1 Like
4

What if you want to randomize your lights, while you are on holiday? What if you want to turn on your climate x hours before your …

Then you wouldn’t add a “turn_off_service” service call step in your automation.

The idea here is that you have, say:

  1. A “house mode” dropdown
  2. An automation that disables some service if the dropdown is set to “Foo”
  3. An automation that re-enables that service if the dropdown is no longer set to “Foo”.

So if you want to run christmas lights, or set climate in house mode “Foo”, then you just wouldn’t add the disable step for those services.

5

IMHO there are “better” ways to achieve this end goal (as Mutt suggested, in automation conditions). Disabling service calls does not seem like the right way to achieve your goal, and is likely to do more harm than good.

1 Like
6

Your logic is flawed.
In your “Away” mode you disable the light service and the climate service, then for the vacation lights you have to enable it again, but then all your other automations will fire again because the light service is enabled.

I’ll quickly explain how I (and I think many others tackle this:
Have an input_select or similar that shows the mode of the house like “away”, “home”, “vacation” whatever.
Create automations that change this input_select, e.g. everyone left home -> mode = away.
Then in your lights automations that shouldn’t run while you are away,add a condition to only execute when the input_select is not equal to “Away”.

1 Like
7

then for the vacation lights you have to enable it again, but then all your other automations will fire again because the light service is enabled.

I don’t follow. Why would the light service being enabled trigger anything?

I’ll quickly explain how I (and I think many others tackle this:

I understand how to use input_selects and conditionals to implement house modes. I used exactly the pattern you described for years.

But now I have 10 house modes, and 60+ automations. With conditionals, any time I added/removed/change a mode, I would have to review each automation to see if I had to add/remove/modify the condition list. Potentially having to change a dozen or
so automations.

Similarly, any time I added a step to an automation, or a new automation entirely, I would have to review all of my house modes to see if this automation was now incompatible with a mode. It was tedious and error-prone, and made it hard to experiment or prototype an idea.

I’ve shifted away from conditionals, and now use the homeassistant.turn_off service to disable those automations entirely when the house mode changes. This makes it so that when I add/remove/modify a house mode, I don’t have to change a dozen automations, I just have to add automation ids to a group (if needed). This works much better for me, but I still need to keep my groups well-groomed.

It seemed like being able to say “Hey Home Assistant, please don’t run your light services while I’m gone” would be way, way easier. But maybe it has too many pitfalls.

8

I can certainly accept that it could do more harm than good (my ideal solution is to have automations/entities be taggable, which is in another WTH).

But, for my use-case, I don’t agree that automation conditions are better. I lay it out in my reply to Burningstone, but in short: in my years of using HA, I’ve found that conditionals make house modes hard to maintain or experiment with when you have lots of automations. They also tend to “drift” over time as you inevitably will miss an automation or edge-case every time you make changes to your modes.

But, I can still accept that my suggestion isn’t the best way to fix the problem.

9

Honestly, I think you need to look at your logic in setting ‘house modes’ and their consequences.
I don’t use any house modes.
I have heating that operates 24/365 but it changes set point according to if there is a window/door open - if anyone (from the household) is not within a given radius of home - if its night - if its day - if its evening - if you want a temporary (1 hr) boost mode
Lighting is similar - but there’s a occupancy simulation which in the evening controls the lights - when we come home it knows which lights ‘it switched’ to turn them off again, so we control them when we are home.
Announcements are again based on who is home and what the situation is calling them.
Music is controlled centrally switched either manually or by schedule, playlists can be set locally or all devices grouped to be synchronised and all switch off when we go beyond home radius AND then come back on in the mode they were turned off in when we return (unless that schedule/timer has expired).
I have 225 automations for this and have never thought that turning light services (etc) off would be a boon.
Some people have water sensors, monitoring flood conditions (maybe a temperamental drain or an old washing machine (other shit appliances are available) and having the ability to turn a switch off that piece of junk is a really good idea.
And motion sensors to deter burgers / help visitors etc. etc. etc.
I just don’t think you are approaching this right and the vast majority of members (and all the experienced ones) disagree with you.
You have not galvanised any of the cognoscenti (or even some of the lesser mortals (me)) to adopt your cause to wage a glorious battle.
What makes you think your argument carries weight ?

Edit: you have 3 votes, but 4 people are listed as having voted (I’m the fourth, but I don’t see how I would have voted for this)

1 Like
10

You said in your initial post that you want to disable services such as e.g. light.turn_on.

So with your method, there’s an automation that disables the service “light.turn_on” when the house mode is “away”. Now you are away, the “light.turn_on” service has been disabled and let’s say after 3 hours the vacation lighting automation (random lights to simulate occupancy) triggers, however no light will turn on as the “light.turn_on” service is still disabled. If you enable the “light.turn_on” service again, other automations you have that trigger for example “turn on light at sunset” will trigger at sunset and turn on the lights but you don’t want them to.

I think you need to rethink your modes/automations, what you describe does not sound scalable/maintainable. For example I don’t understand why you need to check your modes when you add a step to an automation.

11

“turn on light at sunset” will trigger at sunset and turn on the lights but you don’t want them to.

Ah, got it. I misread your sentence as “all your other automations will be triggered” rather than “can be triggered”. I get it now.

Yes, that’s a pitfall. But the pattern I use today already solves it. For example, here’s how I would do Away/Vacation today (by disabling automations from running):

  1. Create three groups. One with all light automations, one with all climate automations, and one with the “fake lighting” automations.
  2. When entering “Away”, turn off light and climate groups
  3. When leaving “Away”, turn on light and climate groups
  4. When entering “Vacation”, turn off light and climate groups, turn on “fake lighting” group
  5. When leaving “Vacation”, turn on light and climate groups

Each mode assumes the same default starting state, adds/removes features accordingly, then restores to default when done.

(Note: It might be possible for the “leaving old mode” trigger to happen after the “enter new mode” trigger, but I’ve never seen it happen, and can think of a few solutions if it does)

what you describe does not sound scalable/maintainable. For example I don’t understand why you need to check your modes when you add a step to an automation.

A new step might now offend one of your modes when it didn’t before. So, even if just in your head, you need to review the modes to see if you need to add a conditional.

Worse, when you add a new mode you need to review each automation and add duplicate conditionals to each “offender”.

To me, that’s what wasn’t scalable. Adds duplication, adds logic branching making the automation harder to reason about, and I found myself needing to remember special snow-flake things for certain steps types.

Now, adding a new house mode trivial. I don’t have to change any automations, I just make one automation that turns on a few existing groups.

The annoying part is maintaining those groups. Hence my WTH. Services are like self-descriptive “groups” that represent the same category of actions. If I could disable services, I wouldn’t need as many groups. All automations would run freely, but certain steps wouldn’t.