Slider input delay off switch? Help what have I done wrong?

Configuration
1 
- alias: 'scooter_charge_timer'
  trigger:
    platform: state
    entity_id: switch.kitmain
    to: 'on'
  action:
    - delay: '00:{{ states.input_slider.scooter_hours.state | int }}:00'
    - service: switch.turn_off
      entity_id: switch.kitmain

input_number:
  scooter_hours:
    name: Hours
    initial: 6
    min: 1
    max: 6
    step: 1

Nothing happens? Config is ok but after root I turn on kitmain after 2 minutes nothing happens? Any ideas?

2

I Do this with input select check it out


   - alias: Sleep TV Bedroom Input Select
      trigger:
        platform: state
        entity_id: input_select.sleepbedroom
      action:
        - delay: "00:{{ states('input_select.sleepbedroom') | int }}:00"
        - service: remote.turn_off
          entity_id: remote.bedroom





 sleepbedroom:
    name: Tv Sleep Time
    options:
      - '-'
      - '15'
      - '30'
      - '45'
      - '60'
    initial: '-'
    icon: 'mdi:sleep'
1 Like
3

I believe you need leading zeros for values under 9.

- delay: "00:{{ '%02i'%states.input_slider.scooter_hours.state | int }}:00"
1 Like
4

well spotted that man well done that must the reason.

You guys really are the best

5

Did it work? I haven’t tried it

6

testing now back in 5, my docker take a while for a reboot.

7

I think this should be states.input_number.scooter_hours.state

2 Likes
8

another great spot!!!

Testing once again.

9

- delay: "00:{{ '%02i'%states.input_slider.scooter_hours.state | int }}:00"

= first turn on of switch is ok then second turn on = on/off with a milliesecond.

10

are you waiting the full duration between turning it on again?

You may have to separate it into it’s own script so that it can override itself when subsequent presses are made.

1 Like
11

No I am not waiting. I will go do a proper test.

12

if I set 1 minute on slider

then I turn on the switch and it works for 1 minute.

And repeat and it works every time.

However should I set slider to 1 minute

then turn off and back within 10 seconds it goes off but any further switches just flip it.

13

There is a bug that if an automation is triggered and is then in a delay, and the automation is triggered again during the delay, the action jumps forward.

The workaround is to use a script and trigger the script, but then that doesn’t restart the delay if that was the desired result. In that case use a timer.

1 Like
14

Good to know. This might be the cause of some odd behavior I’ve seen with my automations. Any idea if this is going to get fixed?

Regarding the idea of moving the actions to a script, would it work if the automation first canceled the script (in case it was running), and then called it?

15

No idea, it’s been like that for ages. There was a bug report, but I don’t know what happened to it.

Yeah, that would work I think, but not tried it. Makes sense though.

16

if someone gets a working script then please can I have a copy.

17

So, going back to your original automation, I think the main issue was the delay action used the wrong entity_id (i.e., should have been input_number.scooter_hours.) I don’t think the lack of a leading zero is an issue - I know I’ve done that and it works just fine. Of course, it doesn’t hurt to use the suggestion to make it two digits.

The next question is, the name of the input_number has “hours” in it, but the delay is using that for minutes. Which did you want? The format for the delay is either ‘HH:MM:SS’ or ‘HH:MM’.

Regarding the automation bug, as long as switch.kitmain isn’t being turned off and back on by something while the automation is still running (probably in the delay), then that shouldn’t be an issue. However, if you do want to account for that, then maybe something like this:

input_number:
  scooter_hours:
    name: Hours
    initial: 6
    min: 1
    max: 6
    step: 1

automation:
  - alias: 'scooter_charge_timer'
    trigger:
      platform: state
      entity_id: switch.kitmain
      to: 'on'
    action:
      - service: script.turn_off
        entity_id: script.turn_kitmain_off
      - service: script.turn_kitmain_off

script:
  turn_kitmain_off:
    alias: Wait for specified period, then turn kitmain off
    sequence:
      - delay: '{{ (states("input_number.scooter_hours")|int*60*60)|timestamp_custom("%H:%M:%S",False) }}'
      - service: switch.turn_off
        entity_id: switch.kitmain

If you do want minutes instead of hours, then just remove one *60.

2 Likes
18

FWIW, I just used this technique to fix the automations I was referring to. In my particular case the problem was a wait_template followed by a delay. The wait_template was waiting for a timer to finish, but was sometimes not actually waiting when the timer was clearly still active. I moved all the actions (including the wait_template & delay) into scripts and used the “turn_off then run” sequence in the automation. Seems to work. I’m happy to share more specifics if anyone is interested.

2 Likes
19

You guys in the forum really are the best. thanks for the help much appreciated. I only wish I had this much skills.

input_number as “hours” is correct but when testing who wants to wait hours so I changed it to minutes hence the mash up or hours and minutes.

1 Like
20

You are are genius! I will try and implement this tomorrow.