[input_number] To have leading zero on input number

Feature Requests
1

I started integrating ‘config’ settings into my automations.

One I’m struggling with is the input_number.
1-9 is only single digit
10> is double digit

I’m trying to set a config to turn off the lights after X minutes (X is a input_number)
Issue here is the time formatting is 00:00:00 so my input number must start at be 1 to 0 else it’ll show 00:0xx:00

My second issue is notifying after X minutes (X is a input_number)
So this input number must be 1 to 9

00:{{ states('input_number.lights_on_notify_lights_on_for_x_minutes')|int }}:00

00:0{{ states('input_number.lights_automation_lights_off_after') |int}}:00

image
image398×596 11.7 KB

2 
00:{{ '%0.2d' % states('input_number.lights_....')|int }}:00

See printf formatting.

2 Likes
3

You want “leading zeros” not decimal places (those go to the right of the decimal point). I don’t think it is likely to be added (I could be wrong) so here’s a template that does what you want:

value_template:
  {% if states('input_number.your_minutes')|int > 9 %}
    00:{{ states('input_number.your_minutes')|int }}:00
  {% else %}
    00:0{{ states('input_number.your_minutes')|int }}:00
  {% endif %}

Note, you can use the input number directly if you are using the trigger for:, like this:

trigger:
  platform: state
  entity_id: light.some_light
  to: 'on'
  for:
    minutes: "{{ states('input_number.your_minutes')|int }}"

Edit: Beaten to the punch with a better answer.

2 Likes
4

No, using dedicated minutes: attribute is cleaner, much easier to read.

1 Like
5

I guess it depends where the template is being used.

6

I use this exact format and don’t bother with any formatting
for example : -

  sc_light_kitchenf_timer:
    alias: Light Kitchen Front Timer Script
    mode: single
    max_exceeded: silent
    sequence:
      - delay: "00:{{ states('input_number.in_light_kitchenf_timer') | int }}:00"
      - service: light.turn_off
        entity_id: light.fibdim2_kitf_level

I have these numbers set for 1 to 300 minutes
Just tested it with 1 minute and it works fine
Dumping the formatting should mean the template evaluates slightly faster too

Looking at this now, I’m not even sure you even need to cast it to integer :man_shrugging:

Edit: just tested with : -

      - delay: "00:{{ states('input_number.in_light_kitchenf_timer') }}:00"

And it still works fine (even with 1 minute)

1 Like
7

I’m not sure you can set it to 300 minutes delay like that.
That would mean the formatting would be 00:300:00 and that is syntax error.
I believe that needs to be converted to 05:00:00

Perhaps use timestamp_custom?
{{ input_number.in_light_kitchenf_timer | timestamp_custom('%H:%M:%S', false) }}

8

No.
I would ordinarily agree, but it does interpret “00:300:00” as 5 hours
I have been using this for about 3 years
I can only assume that it interprets this as : -
hours: 0
plus
minutes: 300
plus
seconds: 0

Which are valid on their own. … I am just guessing here though

:man_shrugging:

Edit:
I also have a motion sensor with a minimum ‘on’ time of 30 seconds, so I have an input number (0.5 to 10 minutes) to set the light on time.

  - platform: template
    sensors:
      ## kitchen motion (with delay)
      bs_light_kitchen_motion:
        value_template: "{{ is_state('binary_sensor.fib_mosen_kit_motion_sensor', 'on') }}"
        friendly_name: Kitchen Motion With Delay
        delay_on: "00:00:00"
        delay_off: "00:00:{{ (states('input_number.in_light_kitchenled_mosen_timer') | float) * 60 - 30 }}"
        device_class: motion

This means when set to 10 minutes (and it currently is) it generates : “00:00:600” sorry “00:00:570” (due to the minus 30, as that’s inherent in the sensor used, but 10mins overall)

9

There’s no guarantee you will be able to continue doing that. Look what happened to time pattern triggers over 59 seconds or minutes. Though that never worked in the first place.

10

Yes, there is always a possibility for a breaking change but can you say “hand on heart” that “this HA coding part” (pick your random/favourite HA coding technique and insert here) will never change ?

Every release is like a box of chocolates … you never know what you’re gonna get.
:man_shrugging:

11

I’m surprised it works but But I would not use it since it is a syntax error (although working).
Adding the timestamp custom isn’t in any way hard and will make sure it works even when they fix this “bug”.
But I realized I was wrong.
The minutes have to be multiplied with 60 first.

12

A ‘syntax error’ is a piece of code that either; will not compile or (in this case with yaml) code that can not be processed.

This is clearly neither, thus it is not a syntax error.

It merely is working code that does not follow the ‘purest’ interpretation of the documentation.
I suspect that my earlier suposition : -

is closer to the truth

Why would they ‘correct’ this bug ? (if it is a bug) It seems to be a robust method of handling, that correctly interprets peoples needs and avoids VERY COMPLEX coding (if less than 60 secs ‘do this’ if greater ‘do this’ and separate minutes from seconds except where its greater than an hour, then ‘do this’ separating hours from minutes from seconds evaluating their constituents, then assemble in the desired format) required to handle durations from 1 second to 1000 hours (maybe even more - but I’ve not tested that) and does it all in the same handling technique using the same format. ALL my time dependencies use this format (easy to remember that way and can be adapted for ALL circumstances, very good for cutting and pasting too - just change the names and positioning of the usual suspects).
I run all my templating methods through the template editor, timing their durations and choosing the fastest. I’ve often decided against (say) an elegant (and short) solution by petro and selected a (still elegant but) not so concise solution by Tom because it saves me 2 or 3 ms. They all add up.
I haven’t done the comparative timings on this yet (I may get to it later today) but the simple question is “why include formating and casting operations when you don’t need to ?”.
You, of couse, can select whichever method suits your needs. It is ‘your’ installation.

I think whoever coded this did an excellent job. Half the job of the developer is guessing how it will be used and possible ways it can be abused and ways to mitigate that.

13

Um, because some pedantic bastard like me opened an issue about it.

2 Likes
14

:rofl:
Now THAT is funny
:rofl:

Edit: how long is that likely to remain in place ?
ie will it evaporate ??? I hope not !

AND you say : -

Like it’s a bad thing !

15

You didn’t read my post did you…

{{ input_number.in_light_kitchenf_timer * 60 | timestamp_custom('%H:%M:%S', false) }}

Will do all that "if greater than 60… and all the formatting and what not you wrote…
Don’t invent stuff that is already invented…

1 Like
16

That’s a good shortcut to get to ‘your’ required format of (say) “05:00:00” but what happens when you get to 24 hours or more ??? CRASH ! It’s also much longer and more complicated than mine (and most important {{ input_number.in_light_kitchenf_timer * 60 | timestamp_custom('%H:%M:%S', false) }} doesn’t work in the template editor, I wonder why ?)
But you omitted the 30 sec offset … Hmmm !
So you didn’t read mine …

I do it for consistency
The ONLY time delay instance I use that performs a calculation (template conditions using UTC timestamps excepted) is this kitchen motion sensor one. the reason for that is that I’m happy with the resolution of my timers to be ‘whole minutes’, the location (in my UI) has multiple such entities (all in minutes) but due to this sensor having a minimum ‘on’ time of 30 secs I had to perform a calculation to get it into seconds. Again it’s a standard format I use all over, so changing it for one instance seems a) non-intuitive b) not able to match a search and replace pattern should (as Tom suggests) a breaking change come through
Besides, a small calculation is going to be quicker than a small calculation AND a timestamp function.

I’m not arguing that you can’t do it different ways (or that you MUST do as I do (that would be daft)) and following the docs is always a good place to start, but if I can find a quicker way to do something in a consistent manner (thus I instantly recognise and can search for it) Then I will do so.
Programming is always a battle to find quicker ways or more transparent ways or more intuitive ways. Look at sorting (There are) : -

  • Selection Sort .
  • Bubble Sort .
  • Insertion Sort .
  • Merge Sort .
  • Quick Sort .
  • Heap Sort .
  • Counting Sort .
  • Radix Sort .

Why ? Because it seemed like this was a good idea at the time. You may have a favourite, or you may just only understand one of them. The most intuitive is a ‘comb sort’ but the sort algorithm for that increases in time duration exponentially hence the variety.
Always test, always play devils advocate to your selection and see if someone else can assemble a cogent agument why you shouldn’t use a piece of code. And (like you are doing now) challenge ‘other’ peoples assumptions.

Edit: THEY all rise exponentially but some with a much lower exponent :smiley:

17

leading zeros is simply

00:{{ '%02i'%(states('input_number.lights_on_notify_lights_on_for_x_minutes')|int) }}:00

or

{{ '00:%02i:00'%(states('input_number.lights_on_notify_lights_on_for_x_minutes')|int) }}

number of ways you can do this

18

Thanks all.

Got what was needed, although my title wasn’t right

thanks all.

19

You (as the OP) can change the title. (hit the pencil by the title)
It’s also not a feature request but only a moderator like Tom or Petro can change that
If you have what you need mark the post you found most helpful as the solution (probably @m0wlheld 's in post No. 2)

1 Like