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

I believe you need leading zeros for values under 9.

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

well spotted that man well done that must the reason.

You guys really are the best

Did it work? I haven’t tried it

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

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

2 Likes

another great spot!!!

Testing once again.

- 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.

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

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

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.

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

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?

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.

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

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

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

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

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

so not a bug a design but a quark of how it works.

This worked first time without any issues what a star you are! Much appreciated!!!

1 Like