Stop an automation loop

Configuration
,
1

It’s silly, but I have an automation to reset my ice maker every night at 22:00 - this automation has to turn the socket off, wait, and then turn it back on. The ice maker is not ‘smart’ and if it loses power, it can leave water in the freezing part, which isn’t good for the unit - but as soon as it regains power, it ‘empties’ that bin but keeps the unit ‘powered off’ (meaning it won’t start making more ice)

I ran into a situation though that if - for example - someone turns it on after 22:00 to make a batch of ice and doesn’t turn it back off, the automation I created that runs at 22:00 has no way of knowing it needs to do it again.

SO… I wrote this:

alias: Ice Maker - back off
description: ""
trigger:
  - platform: device
    type: turned_on
    device_id: b5f9ef5619b40116296a60a7f0ff1564
    entity_id: b6303fdf24907c7705b2b7f7af8b3520
    domain: switch
condition:
  - condition: time
    after: "22:01:00"
    before: "06:00:00"
action:
  - delay:
      hours: 0
      minutes: 30
      seconds: 0
      milliseconds: 0
  - type: turn_off
    device_id: b5f9ef5619b40116296a60a7f0ff1564
    entity_id: b6303fdf24907c7705b2b7f7af8b3520
    domain: switch
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - type: turn_on
    device_id: b5f9ef5619b40116296a60a7f0ff1564
    entity_id: b6303fdf24907c7705b2b7f7af8b3520
    domain: switch
mode: single

I was super proud of myself, until I realized that since I’m turning the outlet back on, it will - in theory - re-trigger and loop the entire automation.

After digging around, this is what I came up with - will it work?

alias: Ice Maker - back off
description: ""
trigger:
  - platform: device
    type: turned_on
    device_id: b5f9ef5619b40116296a60a7f0ff1564
    entity_id: b6303fdf24907c7705b2b7f7af8b3520
    domain: switch
condition:
  - condition: time
    after: "22:01:00"
    before: "06:00:00"
  - condition: template
    value_template: >-
      {{ (as_timestamp(now()) - as_timestamp(states.automation.ice_maker_back_off.attributes.last_triggered | default(0)) | int > 2100) or states.automation.ice_maker_back_off.attributes.last_triggered == None }}
action:
  - delay:
      hours: 0
      minutes: 30
      seconds: 0
      milliseconds: 0
  - type: turn_off
    device_id: b5f9ef5619b40116296a60a7f0ff1564
    entity_id: b6303fdf24907c7705b2b7f7af8b3520
    domain: switch
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - type: turn_on
    device_id: b5f9ef5619b40116296a60a7f0ff1564
    entity_id: b6303fdf24907c7705b2b7f7af8b3520
    domain: switch
mode: single

Basically the important part here is:

- condition: template
    value_template: >-
      {{ (as_timestamp(now()) - as_timestamp(states.automation.ice_maker_back_off.attributes.last_triggered | default(0)) | int > 2100) or states.automation.ice_maker_back_off.attributes.last_triggered == None }}

I THINK that will properly say that if it’s been < 35 minutes (the automation waits 30 minutes before performing another power off / power on, so I built in 5 minutes of slush time) it will not run, and so should not re-trigger.

I’m no code monkey, so this is pretty complex to my small brain.

2

a thought (maybe solution) to your stated question, but a question back because i don’t understand your overall problem… and finally a recommendation…

  1. solution

actually, with “mode: single” this may not happen. remember that “single” mode means that this automation is only allowed to have one instance running at a time. so if the trigger happens while the automation is already running, the second trigger will get rejected.

however i’m not sure that you’re guaranteed all the triggers will happen before the final “turn on” returns. so… i think if you tried putting a delay: 5 seconds at the end after the turn_on, you’ll effectively nuke the recursion concern that you have.

  1. huh?

however the thing i don’t understand is this… you said at 22:00, you turn the socket off, wait and turn it back on. i presume this is a way to turn off the system but put power back which causes it to drain. so there’s power on and ice maker on… two “on” levels" right? and i’m guessing in your 22:00 automation you turn it off for just a few seconds. like in this automation you waited for 2 seconds.
so:
22:00:00 off
22:00:02 on

if that’s the case, then this automation should almost never trigger… because the switch is only off for 2 seconds. you’re not leaving it off at your 22:00 right?

2a) potential answer: “oh, no i’m actually leaving it off for from 22:00:00 until 6:00:00”
if that’s the case then you have an issue in your code above for this scenario:
22:00:00 off
22:10:00 on - someone’s using it - the socket is off, so they turn the socket on as well as turn the ice maker on. this starts your automatoin
22:40:00 off - automation above
22:40:02 on - automation above
23:00:00 someone uses it… it’s already “on”, you don’t see anything… it’s left on for the rest of the night.

so to solve this, maybe you need to turn it off again after some time?

  1. you should avoid using device_id’s
    Why and how to avoid device_ids in automations and scripts
3

Thanks a ton for your comment and response.

You’re spot on, I didn’t think it all the way through because no, the outlet has no way of knowing whether or not the ice maker is actually running… So it won’t shut it off again if someone turns on the ice maker after 22:00!

I might have to upgrade this to a power monitoring outlet, which I could then use a power draw determination.

Also, thank you for the information on device ID. I’ll dig into that and see if I understand it.

The more you know :beers:

4

Ok… then what you could do is to turn it off, wait a couple seconds, turn it on for however long you think it takes to drain then turn it off again. Do that at 22:00 and go it 30 mins after it is manually turned on. So then the default state is power off between 22:00 and 6:00.

That should mostly take care of things except if someone interrupts it during the drain cycle… Which hopefully is just a minute and unlikely…

1 Like