Input datetime automation wrong time?

foxsam · October 25, 2019, 4:46am

I basically copied the example from the docs and it only works if my time is set 4 hours back. Using templates I can see that the date_time is wrong maybe it a timezone thing?

here is the date_time screen showing that it is set to 00:30

and here is the template showing 04:30

here is my config:

sensor:
  - platform: time_date
    display_options:
      - 'time'
      - 'date'
      - 'date_time'
      - 'date_time_iso'
      - 'time_date'
      - 'time_utc'
      - 'beat'

input_datetime:
  test:
    name: "NEW Test Timer"
    has_date: true
    has_time: true

automation:
  - alias: new_dt_trigger
    trigger:
      platform: template
      value_template: "{{ states('sensor.time') == (state_attr('input_datetime.test', 'timestamp') | int | timestamp_custom('%H:%M', False)) }}"
    action:
      - service: mqtt.publish
        data:
          topic: "test/dt/test"
          payload: "ok"

Did I do something wrong or miss something?
Thanks

tom_l · October 25, 2019, 4:53am

Change your template to timestamp_custom('%H:%M', True). The True bit tells it to format in local time. If you leave it out it defaults to true too. See the bottom of the Time section here: https://www.home-assistant.io/docs/configuration/templating/#time

foxsam · October 25, 2019, 4:56am

Thanks. That looks like it did it. Not sure why the docs had it as False…

tom_l · October 25, 2019, 4:58am

I’ve submitted a PR to fix it.

pnbruckner · October 25, 2019, 2:41pm

Well, you fixed it for one case, but broke it for the original case for which it was apparently written.

Whether you should use True or False for local time in that example depends on whether or not the input_datetime has both date & time, or just time. The way the example was originally written was apparently for the case where it just had time, which does not work if it has date & time. The way you changed the example it now works if it has both date & time, but now it doesn’t work if it just has time. E.g.:

The reason is because the way the timestamp attribute is calculated is different in these two different cases.

Mutt · October 25, 2019, 3:05pm

I just use this : -

        value_template: "{{ states('sensor.time') == states('input_datetime.id_switch_a2_tmeslt2_on') [0:5] }}"

for a time value to trigger every day at the required time as listed by the input_datetime (has time, no date)

pnbruckner · October 25, 2019, 3:13pm

Actually, if you did [-8:-3] (instead of [0:5]) it would work whether it had a date or not.

And, yes, I agree this is a simpler/better solution. My point was the example was, and still is, wrong because it doesn’t handle both cases (and doesn’t say so.)

tom_l · October 25, 2019, 3:22pm

Ah. I see. Thanks Phil.

I’ve asked for the PR to be reverted. I’ll think about expanding the documentation to include both cases and maybe even the simpler solution tomorrow. Unless anyone gets their first.

Mutt · October 25, 2019, 3:51pm

Okay, now I thought I understood that … but then I looked again …
[0:5] (to me) means starting at char 0 (the first character) take the next 5
This allows it to match the string produced by sensor.time xx:xx

[-8:-3] … I would have assumed was take 8 off the front and 3 off the back and you’d be left with : -
“25 05:00”
So that wouldn’t work … or the model in my head is wrong ?

Edit: I assume you are talking about the documentation not ‘saying so’ as my input_datetimes are created especially for this purpose and highlight this in the template with the [0:5] ???

pnbruckner · October 25, 2019, 4:19pm

[x:y] is a Python range operator. The first parameter is the starting index, and the second parameter is one past the ending index. So [0:5] means start at index zero and take everything up to, but not including, index 5 (so 0 through 4.)

Negative indices mean start at the end, where -1 is the last, -2 is the next to last, etc. So [-8:-3] means start with the eight from the end and take everything up to, but not including, the third from the last.

This is just how Python ranges work.

I was referring to the example that was pointed out in the OP. That gave an example that assumed the input_datetime did not have date, but didn’t say so.

Mutt · October 25, 2019, 4:38pm

Ahhh ! so that’s why it’s the panacea for catching xx:xx regardless of whether it ‘has date’ or not
Thanks for the explanation.

finity · October 25, 2019, 4:55pm

Well, isn’t that a funny coincidence…

I was just messing around trying to work out a trigger using an input datetime and figured out that I needed “true” for it to work in the template. When I checked the docs a bit ago I saw that it in fact did have “true” in it. But I was trying to figure out where I would have gotten the “false” from and I could have sworn that I saw “false” in there yesterday.

So you just changed it in the interim. I knew my memory wasn’t that bad!

well, maybe it is…but not in this case…