Comparison of an input_datetime and now() - can this be achieved simply?

Configuration
1

Hi there,
One of my automations requires me to compare a day from my input_datetime with a current date.
After some studying of HA docs I came across to the below config:

- condition: template
  value_template: '{{ (states.input_datetime.grass_next.attributes.timestamp| int | timestamp_custom("%Y%m%d", False)|int)|string == (now().year ~ "%02d"|format(now().month) ~ "%02d"|format(now().day) ) }}'

One of the problems is that the timestamp_custom filter outputs the month and day number with a leading zero and I didn’t find a way to make now() to be output with the leading zero for month and day and I had to split it into strings and format separately.

It turns out to be a complete template nightmare that one cannot simply embrace and understand :frowning:
Is there a way to do this simpler?

I feel this should be super simple like comparing A with B. but it\s not. I think the date_time entity and the now() variable should be unified and have a uniform set of attributes that we could compare in our templates.
Something like date comparison seems like an obvious and natural thing in automations. It should be super simple because of this. The current solution is truly cumbersome. In a ‘native’ Python script that would be a lot simpler I guess.

1 Like
2

ok I found a bit simpler solution regarding the now() part and shortened it a bit:

- condition: template
  value_template: '{{ (states.input_datetime.grass_next.attributes.timestamp| int | timestamp_custom("%Y%m%d", False)|int)|string == now().strftime("%Y%m%d") }}'

But this is still cumbersome to me. The first part is still long.

I wish the devs coould unify the attributes of both objects (now and input_datetime) and for example added strftime to the input_datetime as well.
It could look like: states.input_datetime.grass_next.attributes.strftime("%Y%m%d")

Perhaps it would be better to unify it even more. It’s a work for the HA-core team.

1 Like
3

you’re casting items when you don’t need to be.

  1. Not all state attributes are strings. This one for example is already an int, don’t need to cast it as an int.
  2. You incorrectly cast a timestamp_custom as an int and then cast it as a string right after and compare it to a string. I don’t know why you do this.
  3. You can shorten any attribute access into the method that grabs attributes. state_attr(‘entity_id’,‘attr’). But…
  4. You’re doing all these jumps and hoops to get the date when the main state is the date…

So with that being said:

{{ states('input_datetime.grass_next') == now().strftime('%Y-%m-%d') }}

This assumes that grass_next is just a date. If it’s not…

{{ state_attr('input_datetime.grass_next','timestamp') | timestamp_custom('%Y-%m-%d') == now().strftime('%Y-%m-%d') }}
1 Like
4

I guess I either did did because I found some samples like this one in the forum, or I confused it with the as_timestamp filter that applies to now() - and this one is a float for sure.
But that’s what I mean in general - we compare similar objects with each other - a date_time and now() which also holds a date and time information. These two should have the same set of attributes/methods/functions giving the same results. But they don’t. This is inconsistent and adds confusion to people as we all need to remember about these nuances. I guess you’re a HA dev, so these things may be obvious to you, but I bet they’re not to ‘normal’ users like me. I admit, I’m still learning HA automations each month, but it’s a pain when I want to do quite a simple automation I need to dig and test so much to achieve a trivial comparison.

Good point, but this shortens the expression with 3 only characters less, but in this case I guess there’s no a better solution having in mind how HA is built inside.

yes, it is, but you cannot simply compare it to now(), can you? And I really believe it should be a lot simpler than playing with jinja filters etc.
Compare the below expressions with something potential like: {{ states.input_datetime.grass_next.attributes.date == now().date }} where ‘date’ could be some standarized date format e.g. 20190606. A lot simpler don’t you think? There could be another attribute for time as well.

In general I really believe that comparison of functionally the same object types (even when technically they are different) should be simple in terms of notation.

I know HA is open source and often it means less user friendly, but I hope some day such small details will be polished as they influence user experience and ‘firndlyness’ positively not to mention that it would be a lot easier to build automations.

Anyway - thanks for all you remakrs - very helpful - I got rid of unnenessary casting and for a discussion, which is why I love community forums :slight_smile:

5

In all endeavors, there are non-obvious things … to novices.

Learn it and then others who don’t know it will think you’re not ‘normal’.

1 Like
6

If you implement the date sensor, you wouldn’t need to use now() which is the root of your problems.

now() is a datetime object from python. It will be confusing if you don’t program.

The same goes for timestamps. They are timestamps based on unix time. It will also be confusing if you don’t know programming languages.

For example, the comparison for a date only input time to a sensor.date is:

{{ states('input_datetime.date_only') == states('sensor.date') }}

So this functionality exists.

1 Like
7

That’s very true, but these non-obvious things may be either hard or easy to learn and understand. A typical learning curve problem.

8

I suggest you look through the components and get a gauge for what exists. Too many times I see people come on here asking for templating help instead of looking through components that do the job for them.

1 Like
9

Well, there must be a reason for this. Some are probably laizy / ignorant, but some simply have troubles to ‘connect the dots’ because some things are not intuitive in HA. I heard from different people that HA is something between Domoticz and OpenHAB in terms of complexity and flexibility. I mean it was supposed to be relatively easy to learn and allow relatively easy automations. But the more automations I do, the more I think that it’s not really like this. Soon I’ll have nightmares with templates and jinja filters playing the main characters :slight_smile:

For typical tech guys, especially developers it is sometimes hard to see that some things could be done easier and more intuitive. Especially when they got used to something and treat something as an obvious thing. It’s a matter of a different perspective.

10

I think you’re missing the point. Chances are there is a component that will work for these complex templating nightmares that you are talking about. All you have to do is look through the components that are well documented.

I help a ton of people with these templates, yet I use very few because components cover most of my needs.

1 Like
11

Anything particular you can recommend apart from input_datetime and a time_date sensor?

I think I’m not missing the point. I mean I understand your point is that there are components for everything. Perhaps that’s true. I haven’t gone through all of them, so not sure here.
And my point is that one needs to know all these things first to make life a little bit easier. I saw many times people with a similar point of view as mine regarding different aspects of automation ‘programming’ in HA. And that’s exactly my point - it’s like moving from A to B within a large city. You can take a tram, 2 busses and a subway to get from A to B. That’s HA approach - all these indirect ways of accomplishing things. Quite often to realize a simple solution/automation. But people would prefer to take a helicopter and simply fly from A to B :slight_smile:
In commercial smart home systems this is a lot easier. But this is a different discussion. Hopefully HA 2.0 will get closer to this kind of solution.

12

Not really, thes time_date sensor is the best for this because it will give you all forms of date output for home assistant for easy comparisions

You just might need to incorporate more than one of the sensors to get what you want in every situation.

Also, for templating make sure you check out all the methods because they do alot

13

I don’t know what system you were using but time was still a pain in the ass when I was using smartthings. It wasn’t built in and I had to cruise the internet to find the correct component to handle time.

Granted that was 3 years ago

14

I didn’t. My friend does. I’m sure you haven’t heard of it as it is made in Poland and is very young. Slowly reaching other markets than the polish one. It’s called ‘Grenton’ and is a wired system with z-wave wireless capabilities. It has LUA built-in (and a GUI for building a script with graphical blocks for non-geek people :wink: ) and since I don’t use it I cannot be sure how exactly will my case look like, but from the docs it seems it would be something like
if(grass_next == Date)....
where grass_next would be my date variable. Hard to do it simpler, right? :slight_smile:

15

At one point I agree with @grzeg8102.
I don’t find it very logical to have a software that has two components ( input_datetime and ‘time_date’) that aren’t directly comparable to each other without applying transformations.
It would be much more logical to have them in the same format, or at least to have the option to configure them in such way…

16

this is the worst ever. i use homeassistant to make my life less complex. not force myself to read for litterly DAYS for information that should be able to sort it self out by automagically detecting when an time template is open for more than 72 hours. Like the snippy fella. This shit is so so so so dumb. I wanna ask for help but not looking for another 5 day wasted.

17

Slow your roll. Just ask the question. Swearing up and down in the forums isn’t going to help anyone. What issues are you having? Post code with your question please and refrain from angry responses.

18

Hey everyone,
I do have a question of this kind.

So I have a templated sensor that takes the value of a temp sensor from, say, 8am to 8pm, and then the value of another the rest of the time. Actually, the 8am and 8pm values are taken from 2 time inputs.

Until today, I was doing something like this (with added “debugging” code):

{% set n = now().time() %}
{% set b = now().fromtimestamp(state_attr('input_datetime.heater_target_rooms', 'timestamp')).time() %}
{% set e = now().fromtimestamp(state_attr('input_datetime.heater_target_living', 'timestamp')).time() %}
{% if (b >= e and (n >= b or n < e)) or (b < e and (n >= b and n < e)) %}
  {{ states.sensor.temperature_1.state }}
{% else %}
  {{ states.sensor.temperature_2.state }}
{% endif %}

{{ n }}
{{ states('input_datetime.heater_target_rooms') }} -> {{ b }}
{{ states('input_datetime.heater_target_living') }} -> {{ e }}

Which outputs the following:

20.9

23:32:00.002545
21:00:00 -> 22:00:00
06:45:00 -> 07:45:00

We can see I had a problem with an offset hour being added to my target times. Now, I do understand this is due to not passing the timezone argument when calling “fromtimestamp” (I’m ashamed to say I did not get how to do that from a template). Reading this thread, I convinced myself this was unnecessarily complex and tried to replace now() with the time sensor I’m already using for automations.

This leads to this code, which is indeed simpler and actually gives the correct result:

{% set n = states('sensor.time') %}
{% set b = states('input_datetime.heater_target_rooms') %}
{% set e = states('input_datetime.heater_target_living') %}
{% if (b >= e and (n >= b or n < e)) or (b < e and (n >= b and n < e)) %}
  {{ states.sensor.temperature_1.state }}
{% else %}
  {{ states.sensor.temperature_2.state }}
{% endif %}

All should be well, but I’m a bit uneasy, because I’ve got the feeling I’m now comparing strings instead of comparing times. I know said strings include leading zeros so string comparison should work fine, but it still feels a bit off to me. Should I indeed worry or should I just stop obsessing with this and happily go back to trying to understand how the whole media_player thing is supposed to let me play something to a local bluetooth sink ?

Anyways, thanks a lot for HA, which is indeed an amazing piece of software, particularly combined with the myriad other open source software that it plays nice with. The HA crowd is amazing :heart_eyes:

19

hi,
is this correct please?

{{ states('input_datetime.irepair_opened_at') < today_at("09:00").strftime('%Y-%m-%d') }}
20

Without an explanation of what you are trying to do, it is hard to say if your template is correct. However, the way you have constructed it ( with the strftime() ), your template will not use the time information at all, it will only use the date.

If your goal is to test if the Input Datetime is before 9AM today use:

{{ states('input_datetime.irepair_opened_at') | as_datetime | as_local < today_at("09:00") }}
1 Like