Trying to figure out a problem with this template sensor

Configuration
1

I’m changing the way I schedule my pool heater start time, mainly because the date & time chooser in the UI is so bad.

My planned approach will be to select either “today” or “tomorrow” via an input_select entity, then a time of day via time-picker-card. I have a few lines of Jinja to get the day and time, then combine them… but it’s giving me issues, and I’ve traced it down to one line.

Why would the value of the swim_time variable be 0 here if input_datetime.pool_target_temp_time2 = 20:00:00?

{% set swim_time = states.input_datetime.pool_target_temp_time2.state | float %}
{{ (swim_time) }}

Value
Value926×169 12.6 KB

What
What941×358 22.5 KB

I’ve also tried:

          {% set swim_time = states('input_datetime.pool_target_temp_time2') | float %}
          {{ (swim_time) }}

…and the value of that is also 0, regardless of the time entered into the input_datetime.

2

Because you’re trying to force a datetime object to look like a number. The float filter does not recognise the state of the input_datetime as a number, because it isn’t, so it returns zero.

Have a look at the two helpful links on the template editor page, particularly the TIME section of the HA link.

What do you think the variable should be?

3

Hmmm… I see. Well, I’d like it to pass the timestamp 72000 so it can be added to the selected date. Here’s the whole value_template I’ve put together:

          {% if is_state('input_select.pool_target_temp_day', 'today') %}
            {% set swim_target = as_timestamp(now().strftime ('%Y-%m-%d')) | float %}
          {% else %}
            {% set swim_target = as_timestamp(now().strftime ('%Y-%m-%d')) | float + 86400 %}
          {% endif %}
          {% set swim_time = states.input_datetime.pool_target_temp_time2.state | float %}
          {% set offset = states.sensor.pool_heating_interval.state | float * 3600 %}
          {% set start_time = (swim_target + swim_time - offset) | float %}
          {{ (start_time) | timestamp_custom }}

…so I should be using some form of as_timestamp for that, I suppose…

4 
{{ state_attr('input_datetime.pool_target_temp_time2', 'timestamp') }}

See the warning box in this section of the docs.

5

Thanks! This did the trick.

1 Like
6

If you wish, you can shrink that to this:

now().date()

to produce this:

{% set swim_target = as_timestamp(now().date()) %}

The float filter isn’t needed because the output of as_timestamp() is a float value.

In fact, you can consolidate the if-else statement into a single line:

{% set swim_target = as_timestamp(now().date()) + (0 if is_state('input_select.pool_target_temp_day', 'today') else 86400) %}

EDIT

Correction. Added parentheses to group the terms together to avoid an incorrect calculation. See Troon’s post below.

1 Like
7

The replacement of date() in place of the strftime function worked, as did the elimination of the float filter… but the if-else statement changed the resulting timestamp from tomorrow afternoon to sometime in the 1970s :slight_smile:

8

Missing a pair of brackets:

{% set swim_target = as_timestamp(now().date()) + (0 if is_state('input_select.pool_target_temp_day', 'today') else 86400) %}
1 Like
9

Thanks–that does in fact work!

10

Yes. I’d encourage you to try to work out why — copy-paste is quick and easy, but it’s better to understand what’s going on.

11

Oops! Yes, without the parentheses it doesn’t produce the desired calculation. I’ll correct the example. Thanks for spotting the error.

1 Like
12

Well, yes. I turn here as a last resort. I’d much rather know enough to get it right the first time than struggle with it and have to ask why it’s not working. I want at least to try a few things and say, “I tried this and this and I’m not getting the result I expect,” instead of just, “how do I do this?”

1 Like
13

In this case, the template was intended to do this:

today plus (0 if we want today, otherwise 86400)

…which would give midnight at the beginning of today, or midnight at the beginning of tomorrow — 86400s is the length of most days, leap seconds/years ignored.

With the originally-missing parentheses, it was being calculated as this:

(today plus 0 if we want today), otherwise 86400

UNIX timestamps are seconds since the start of 1-Jan-1970, so a timestamp of 86400 is midnight at the start of 2-Jan-1970.

14

Yes. I had no idea if-then statements could be structured like that. Very cool.