Automation for daily schedule with "exceptions"?

Hi guys, I could use some pointers on how to solve this.
I need to create an automation with a regular daily schedule, so far not a big thing, but…

This is for an irrigation system (Rainbird, already integrated) to make it smart.
In this automation multiple switches have to be controlled, 1 at the time.
Another thing is that only for 2 of them, there has to be an option to delay that action because of when sitting in that area.
I guess this last issue is solved with a helper as condition not to process but how to run it delayed then?

Any help is highly appreciated!

Anyone, please?

Hey Nick! I honestly don’t understand what you’re trying to achieve, sorry. Could you please make a little automation, so that we can get a better grip on what you’re trying to do? No need for the automation to work, just for the visual aid, you get the idea. :slight_smile: :rofl:

It would be interesting, what are the conditions to run, delay or … and what switches/sensors (???) need to be triggered. Please be detailed, I have no garden, so personally I have no idea how these irrigation systems work. :rofl: In my case it’s fill the watering pot and spill it over the next reachable plant. :rofl:

1 Like

Hi Patrick, thanks for picking this up!

The irrigation system is seen as 6 switches by HA.
Those have to be turned on/off 1 by 1, so in the evening at 10pm start with 1 on/off for 15 minutes, then 2 and so on, because the system doesn’t allow more then 1 to run at the time.
So far, this would be easy by putting a delay between every ‘switch’ and start the next.
I don’t know if this approach with a time delay is “the best/logic” way…

For 2 of them, they are close by the terrace, so there should be a way not start them (I thought with a helper that is switched on) but when not started, run hours later as well.
Also, this part would not be that hard if executed that way.

But then: how to make it so that when those 2 did not run because of that helper still are processed later on?

I hope it’s more clear now… :grin:

Ok, now I get a better feeling what you want to do! :+1:

Hmmm, my first thoughts (and they might be totally wrong) would be to chain some automations, not only one, to work around the delay. I don’t like delays, because they get lost when you need to restart HA while the automation is running.

Automation #1 
  start switch #1 and let it run for xx minutes 
Automation #2
  triggered by the end of automation #1 
  turn on switch #2, same delay
Automation #3 
  triggered by the end of automation #2

If divided, the automations should be possible to run after a restart with a “homeassistant: start” trigger.

For the last two switches, I’d work with a helper, that you set yourself when going out on the patio. An input_boolean should work. This is the wait_for_trigger you’d set in the second last automation, so these switches are blocked, as long as you don’t turn off the input_boolean.

Does that make sense to you? :slight_smile: As I said, just a few first thoughts. :wink:

Another way I could imagine, would be to work with an input_select as the trigger for each switch. You’d have an option for each switch and trigger the next automation by changing the input_select.

Automation #1
  start first switch
  after finishing, set the `input_select` to the next option
Automation #2
  triggered by the `input_select` change

If you’re sitting on the patio, it should change the input_select to the next automation, that could check for the condition if you sit outside or not. This way, it would survive a restart of HA, and you can trigger it after a HA restart to work along.

These are just two ideas, let me know what you think. I’m quite sure some of the code gurus might come up with something better, but for now, let’s see what fits your needs best. :slight_smile:

1 Like

What are the entity IDs of your six switches? Could you not just run the sequence at e.g. 2am to avoid the issue of people sitting there?

Something like this should run each switch for 15 minutes starting at 10pm, with currently no inclusion of your “delay” function. Relies on the switch entities ending in a number but we can work around that if needed.

  - platform: time
    at: "22:00:00"
  - platform: state
      - switch.irrigation_switch_1
      - switch.irrigation_switch_2
      - switch.irrigation_switch_3
      - switch.irrigation_switch_4
      - switch.irrigation_switch_5
      - switch.irrigation_switch_6
    to: "on"
    for: "00:15:00"
  - choose:
      - conditions: "{{ trigger.platform == 'time' }}"
          - service: switch.turn_on
            entity_id: switch.irrigation_switch_1
      - service: switch.turn_off
        entity_id: "{{ trigger.entity_id }}"
      - service: switch.turn_{{ "off" if trigger.entity_id[-1] == "6" else "on" }}
        entity_id: "{{ '%s%d' % (trigger.entity_id[:-1], trigger.entity_id[-1]|int + (0 if trigger.entity_id[-1] == '6' else 1)) }}"

Uses the “best practice” of not including delay logic within automations: it triggers, does something and exits. The delay logic is all in the for: statement in the trigger.

1 Like

But that doesn’t avoid the restart problem… If you have a restart while any of the switches are on, or one of the switches goes dark (power or wifi out or …), this will stop the automation as the switch before isn’t on for 15 minutes… What could help would be to check for “from: off”, but not “to: on”.

Anyway, I wouldn’t want to work with a fixed start time…

BUT, what I haven’t thought about before, have you taken a look at the various irrigation integrations? One of them can even calculate the water needed to get an optimal result and safes water on the way… :smiley:

1 Like

Any news on this one? :slight_smile:

Hi Patrick, thanks for your interest.
I have put it in place, in 1 automation with delays and a helper as condition that can be switched on/off from the dashboard.
This way, it’s all or nothing.

You are right that the process might be halted by a power cut.
Your solution with ‘cascading automations’: will this not be affected when, let’s say 1 has already run.
Then, the power goes off, is restored: 1 will not execute since the time has past so the rest will also not fire…
OTH, power failures are very rare and this is not a critical automation.

Out of curiosity: I wonder how this can be prevented.
Now that I think of it, maybe it could be done with helpers that are switched on/off at the beginning/end of each step and used as a condition.

There might be other/better ways, ideas are welcome!

@Troon: I have to put your code into a test to fully comprehend. :grin: