Proper way to prevent two automations from overlapping?

Configuration
1

I have an automation that does a “short” defrost cycle by switching off the compressor for 7 minutes. Relay on cuts off the compressor, Delay 7 minutes, Relay off allows the compressor to turn on again. This is triggered by a sensor that can happen pretty much any time of day when the coils are icing up. So far working so good.

Now, I want to add a “long” 30 minute defrost cycle once daily before sunrise. I’ve got the trigger by sunrise -30 minutes, and the relay on, delay 30 minutes, relay off, but… I’m concerned that if the short defrost cycle is in progress when this longer one gets triggered, it will switch the relay back off at the end of the short cycle and the long cycle won’t happen as intended.

What I think will mitigate this issue is: making the “Relay off” step of the short cycle conditionally executed with: “If Running automations of Defrost 30 min before sunrise is off”

What I’m unclear on is: what does Attribute: “Running Automations” State: “off” really correspond to? Does it mean that the “Defrost 30 min before sunrise” automation is not “current” or active at the moment, or does it mean that the automation is ready and waiting for a trigger to run?

If I could see a timeline of other automations’ “Running Automations” state, that would answer the question directly, but I can’t find how to do that.

2

You could add a set of conditions to your short cycle so that it won’t ever run in a time range that would interfere with the long cycle. Something like

  - condition: or
    conditions:
      - condition: sun
        before: sunrise
        before_offset: "-00:40:00"
      - condition: sun
        after: sunrise
        after_offset: "00:10:00"

I added 10 minutes on either side of when you described your long cycle as running; you should adjust to whatever suits you.

Note: you can add a before and after in the same Sun condition, but I think that only works if one of them is sunrise and the other is sunset. That’s why I’ve used an Or condition here.

1 Like
3

Thanks, that’s a workable thought: conditionally block the whole shorter defrost cycle around sunrise.

This is what I have at the moment with the conditional on the long defrost automation’s state being off, for switching off of the relay. I just don’t know if condition:state state: “off” attribute: current is what I think it is.

Edit: actually, I just confirmed by test, nope. The long defrost isn’t “running” but the conditional below blocked the relay off action of the shorter defrost cycle.

alias: Defrost
description: ""
triggers:
  - device_id: 1234567890abcdef1234567890abcdef
    domain: zha
    type: remote_button_double_press
    subtype: button_1
    trigger: device
conditions: []
actions:
  - type: turn_on
    device_id: 234567890abcdef1234567890abcdef1
    entity_id: 34567890abcdef1234567890abcdef12
    domain: light
  - delay:
      hours: 0
      minutes: 7
      seconds: 0
      milliseconds: 0
  - if:
      - condition: state
        entity_id: automation.defrost_30_min_before_sunrise
        state: "off"
        attribute: current
    then:
      - action: light.turn_off
        metadata: {}
        data: {}
        target:
          entity_id: light.relay
mode: single
4

The current attribute of an automation is a count. If is is 0, the automation isn’t running. if it is above 0 it is active. For automations that can run in parallel mode the count can be above 1. By testing the attribute for 0 you can be sure it isn’t active.

Your test for off will never succeed.

5

An option is to put it all in one automation and set the automation mode to queued. This way only one operation will occur at a time and triggers that occur which the automation is running will be queued and execute when the current operation completes.

1 Like
6

So, like this?

  - if:
      - condition: numeric_state
        entity_id: automation.defrost_30_min_before_sunrise
        above: -1
        attribute: current
        below: 1
    then:
      - type: turn_off
        device_id: 234567890abcdef1234567890abcdef1
        entity_id: 34567890abcdef1234567890abcdef12
        domain: light
7

A state condition testing for 0 will do just fine, and I would not worry about -2. But yes, I guess this would work too.

8

Bear in mind that long delays in an automation may not be a good idea - 30 minutes is on the long side. If HA restarts while it is running, for example, the compressor will not switch on again.

9

If you post both automations (in formatted YAML), we can show you how to consolidate them to work the way PeteRage recommended.

It’s more efficient than attempting to control an automation’s behavior based on the state of another automation.

10

So, what is the preferred way to turn on a relay for 30 minutes?

11

For your daily one, maybe a schedule helper, with an automation triggered by it going on and off. For the other a timer helper, maybe, (which can be set to resume when HA restarts) triggering an automation on start and stop.

1 Like
12

So, the “short” defrost automation is nominally triggered by a button, but more often it gets triggered when an “ice sensor” passes a threshold - this is the code with the kludgy check to see if the longer defrost is running:

alias: Defrost
description: ""
triggers:
  - device_id: 76066d58
    domain: zha
    type: remote_button_double_press
    subtype: button_1
    trigger: device
conditions: []
actions:
  - type: turn_on
    device_id: 4105ca8d
    entity_id: 12f08d33c
    domain: light
  - delay:
      hours: 0
      minutes: 7
      seconds: 0
      milliseconds: 0
  - if:
      - condition: numeric_state
        entity_id: automation.defrost_30_min_before_sunrise
        above: -1
        attribute: current
        below: 1
    then:
      - type: turn_off
        device_id: 4105ca8d
        entity_id: 12f08d33c
        domain: light
mode: single

If I didn’t want this defrost cycle to run longer (to guarantee a thorough defrost, not leaving any stubborn ice that might survive a 7 minute cycle), I’d just use the sunrise to trigger the regular defrost automation above, but since it’s longer…

alias: Defrost 30 min before sunrise
description: ""
triggers:
  - trigger: sun
    event: sunrise
    offset: "-00:30:00"
conditions: []
actions:
  - action: light.turn_on
    metadata: {}
    data: {}
    target:
      entity_id: light.relay
  - delay:
      hours: 0
      minutes: 30
      seconds: 0
      milliseconds: 0
  - action: light.turn_off
    metadata: {}
    data: {}
    target:
      entity_id: light.relay
mode: single

In the first script I’m controlling the device, in the last I’m using the associated light entity - works the same either way as far as I can tell…

13

Why is that trigger missing in the automation you posted?

14

Here’s the ice sensor trigger, it just triggers the same automation with the button, I suppose I could merge them into one more complex automation with two triggers - I also have dashboard interface buttons that do the same (trigger the standard Defrost):

alias: Defrost Because Ice Level is High
description: ""
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.coils_ice_level
    above: 10
conditions: []
actions:
  - action: automation.trigger
    metadata: {}
    data:
      skip_condition: true
    target:
      entity_id: automation.defrost
mode: single
15

So the standard defrost can be started two three ways (remote-control button or dashboard button or by frost sensor) and the longer defrost just one way (time-based; half-hour before sunrise). Is that correct? Any other ways to start defrosting?

If I understood your requirements correctly, if a long defrost is underway then an attempt to start a short defrost should simply be ignored (to prevent it from prematurely ending the long defrost).

If that’s correct then it means a short defrost started during the 30 minutes before sunrise should be ignored.