Time range condition template

[tom_l]

Thanks @petro.

I had to add two triggers for the case that heat/cool required is already true when the on times roll around and also put my extra temperature conditions back in for this.

Also the condition you added in the action section is not required as this is taken care of in the following template sensors:

- platform: template
  sensors:
    lounge_ac_heat_required:
      friendly_name: "Lounge AC Heat Required"
      value_template: >-
        {{ states('sensor.aeotec_lounge_temperature') < states('input_number.lounge_ac_heat_temp_set') }}
    lounge_ac_cool_required:
      friendly_name: "Lounge AC Cool Required"
      value_template: >-
        {{ states('sensor.aeotec_lounge_temperature') > states('input_number.lounge_ac_cool_temp_set') }}

[tom_l]

Spoke too soon. This is still giving me trouble.

For the following template sensors:

- platform: template
  sensors:
    lounge_ac_am_automation_time_active:
      friendly_name: "Lounge AM Automation Time Active"
      entity_id:
       - sensor.time # required to update now()
       - input_datetime.lounge_ac_am_on_time
       - input_datetime.lounge_ac_am_off_time
       - input_boolean.lounge_ac_am_automation
      value_template: >-
        {% set d = now().strftime("%Y-%m-%d ") %}
        {% set t = now().timestamp() %}
        {% set am_start = strptime(d + states('input_datetime.lounge_ac_am_on_time'), '%Y-%m-%d %H:%M:%S').timestamp() %}
        {% set am_end = strptime(d + states('input_datetime.lounge_ac_am_off_time'), '%Y-%m-%d %H:%M:%S').timestamp() %}
        {{ (am_start <= t <= am_end) and is_state('input_boolean.lounge_ac_am_automation', 'on') }}
    lounge_ac_pm_automation_time_active:
      friendly_name: "Lounge PM Automation Time Active"
      entity_id:
       - sensor.time # required to update now()
       - input_datetime.lounge_ac_pm_on_time
       - input_datetime.lounge_ac_pm_off_time
       - input_boolean.lounge_ac_pm_automation
      value_template: >-
        {% set d = now().strftime("%Y-%m-%d ") %}
        {% set t = now().timestamp() %}
        {% set pm_start = strptime(d + states('input_datetime.lounge_ac_pm_on_time'), '%Y-%m-%d %H:%M:%S').timestamp() %}
        {% set pm_end = strptime(d + states('input_datetime.lounge_ac_pm_off_time'), '%Y-%m-%d %H:%M:%S').timestamp() %}
        {{ (pm_start <= t <= pm_end) and is_state('input_boolean.lounge_ac_pm_automation', 'on')  }}

In the front end the sensors change from :

to

Exactly when they should.

However this automation never fires:

- id: lounge_aircon_auto_off
  alias: 'Lounge Room Aircon Scheduled Off'
  trigger:
    - platform: state # AM or PM off time trigger
      entity_id:
       - binary_sensor.lounge_ac_am_automation_time_active
       - binary_sensor.lounge_ac_pm_automation_time_active
      to: 'off'
  condition:
   - condition: template # Only if AC is on
     value_template: "{{ not is_state('input_select.lounge_ac_mode.state', 'Off') }}"
   - condition: or # And only if workday not tested or if workday
     conditions:
      - condition: state
        entity_id: input_boolean.lounge_ac_workday
        state: 'off'
      - condition: state
        entity_id: binary_sensor.workday_sensor
        state: 'on'
  action:
    - service: input_select.select_option
      data_template:
        entity_id: input_select.lounge_ac_mode
        option: 'Off'

Looking at the template editor I see this before the event:

and this after:

I even tried my original sensors (with @pnbruckner 's suggestions):

- platform: template
  sensors:
    lounge_ac_am_automation_time_active:
      friendly_name: "Lounge AM Automation Time Active"
      entity_id:
       - sensor.time # required to update now()
       - input_datetime.lounge_ac_am_on_time
       - input_datetime.lounge_ac_am_off_time
       - input_boolean.lounge_ac_am_automation
      value_template: >-
        {{ (states.input_datetime.lounge_ac_am_on_time.attributes.timestamp <= (now().second + (now().minute * 60) + (now().hour * 3600)) <= states.input_datetime.lounge_ac_am_off_time.attributes.timestamp) and is_state('input_boolean.lounge_ac_am_automation', 'on') }}
    lounge_ac_pm_automation_time_active:
      friendly_name: "Lounge PM Automation Time Active"
      entity_id:
       - sensor.time # required to update now()
       - input_datetime.lounge_ac_pm_on_time
       - input_datetime.lounge_ac_pm_off_time
       - input_boolean.lounge_ac_pm_automation
      value_template: >-
        {{ (states.input_datetime.lounge_ac_pm_on_time.attributes.timestamp <= (now().second + (now().minute * 60) + (now().hour * 3600)) <= states.input_datetime.lounge_ac_pm_off_time.attributes.timestamp) and is_state('input_boolean.lounge_ac_pm_automation', 'on') }} 

I see the same thing. The state changes in the front end and the template editor exactly when it should but the automation never fires.

The reason I’m using template sensors is because I have to trigger on or test this condition in multiple automations and it does not seem efficient to keep having to write the long hand templates everywhere.

[petro]

What events are happening in your logs? The automation looks good.

[tom_l]

Excellent suggestion. Why didn’t I look there? I l only looked at the error log.

The automation is actually firing according to the log book. However my AC is not changing state when the input_select that controls it changes state… Hardware problem perhaps?

I logged into the web interface for the device that controls the AC unit - I can control it fine. So not that.

Oh bugger! I accidentally deleted the automation that manually controls the AC unit via an input_select when tidying up all the time/temperature automations.

Just as well I have a copy.

Thanks petro!

Needless to say, I feel like a bit of an idiot.

[petro]

We’ve all been there…

[tom_l]

So one last question, do you see any advantage or disadvantage for using either one of these templates? They both work and both do the same thing:

{% set timestamp_no_date = (now().second + (now().minute * 60) + (now().hour * 3600)) %}
{{ (states.input_datetime.lounge_ac_pm_on_time.attributes.timestamp <= timestamp_no_date <= states.input_datetime.lounge_ac_pm_off_time.attributes.timestamp) 
    and is_state('input_boolean.lounge_ac_pm_automation', 'on') }}

or

 {% set d = now().strftime("%Y-%m-%d ") %}
            {% set t = now().timestamp() %}
            {% set pm_start = strptime(d + states('input_datetime.lounge_ac_pm_on_time'), '%Y-%m-%d %H:%M:%S').timestamp() %}
            {% set pm_end = strptime(d + states('input_datetime.lounge_ac_pm_off_time'), '%Y-%m-%d %H:%M:%S').timestamp() %}
            {{ (pm_start <= t <= pm_end) and is_state('input_boolean.lounge_ac_pm_automation', 'on')  }}

[petro]

Nope, either are fine. Personally, I avoid using states.domain.entity.attributes.attr. Only because of startup issues and errors when those devices haven’t been created. If you use state_attr('domain.entity','attr') your templates will return results at all times if you convert them to the proper type. I.E. state_attr('domain.entity','attr') | int will convert the result to 0 if domain.entity doesn’t exist yet. Then your template will still resolve to a false/off state and no errors will be produced in the logs.

[tom_l]

Ok so

states.input_datetime.lounge_ac_pm_on_time.attributes.timestamp

Is easy enough to convert to state_attr() format:

state_attr('input_datetime.lounge_ac_am_off_time', 'timestamp') | float

However one template that is glitching for me on start up is:

{{ states('sensor.aeotec_lounge_temperature') > states('input_number.lounge_ac_cool_temp_set') }}

But I am not sure how to represent with state_attr() - or even if I should.

[petro]

Just convert the states into floats and it will default to zero when ‘undefined’ is returned during startup:

{{ states('sensor.aeotec_lounge_temperature') | float > states('input_number.lounge_ac_cool_temp_set') | float }}

[Mariusthvdb (Marius)]

would that apply too for the mold indicator, which uses an entity_id, and always errors out on startup:
# https://home-assistant.io/components/sensor.mold_indicator/

- platform: mold_indicator
  name: Schimmel sensor
  indoor_temp_sensor: sensor.temperatuur_living
  indoor_humidity_sensor: sensor.luchtvochtigheid_living
  outdoor_temp_sensor: sensor.rsd_temperature
  calibration_factor: 1.16

as do several other statistics sensors

[petro]

The sensors themselves error or templates that use them?

[Mariusthvdb (Marius)]

@petro

he sensors themselves error or templates that use them?

I think the sensors themselves, that together make up the Mold indicator. see the log:

2018-09-18 23:32:00 ERROR (SyncWorker_3) [homeassistant.components.sensor.mold_indicator] Unable to parse sensor temperature: unknown
2018-09-18 23:32:00 ERROR (SyncWorker_18) [homeassistant.components.sensor.mold_indicator] Unable to parse sensor humidity: unknown
2018-09-18 23:32:02 ERROR (MainThread) [homeassistant.components.sensor.statistics] mean requires at least one data point
2018-09-18 23:32:02 ERROR (MainThread) [homeassistant.components.sensor.statistics] variance requires at least two data points
2018-09-18 23:32:02 ERROR (MainThread) [homeassistant.components.sensor.statistics] variance requires at least two data points

tha last 3 lines are from a statistics sensor, that apparently isnt initialized yet either.

and, an ever returning error:

2018-09-18 23:35:54 ERROR (MainThread) [homeassistant.core] Error doing job: Future exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.6/site-packages/homeassistant/util/__init__.py", line 325, in wrapper
    result = method(*args, **kwargs)
TypeError: update() takes 1 positional argument but 2 were given
2018-09-18 23:35:54 ERROR (MainThread) [homeassistant.core] Error doing job: Future exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.6/site-packages/homeassistant/util/__init__.py", line 325, in wrapper
    result = method(*args, **kwargs)
TypeError: update() takes 1 positional argument but 2 were given
2018-09-18 23:35:54 ERROR (MainThread) [homeassistant.core] Error doing job: Future exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.6/site-packages/homeassistant/util/__init__.py", line 325, in wrapper
    result = method(*args, **kwargs)
TypeError: update() takes 1 positional argument but 2 were given
2018-09-18 23:35:54 ERROR (MainThread) [homeassistant.core] Error doing job: Future exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.6/site-packages/homeassistant/util/__init__.py", line 325, in wrapper
    result = method(*args, **kwargs)
TypeError: update() takes 1 positional argument but 2 were given

No idea where and how to start looking for that one…

[tom_l]

I see start up mold sensor these errors too. Unfortunately that’s not something we have control over (as it is the component itself that has start up dependency problems).

[Mariusthvdb (Marius)]

will see if I can raise an issue on this, thanx for adding to the report.
see: https://github.com/home-assistant/home-assistant/issues/16733

[petro]

Yeah, it doesn’t look like this is normal startup errors related to templates. What’s odd about these errors is that it doesn’t appear to come from the mold indicator. Have you turned on debug logging to view what the component is outputting?

[Mariusthvdb (Marius)]

@petro

Have you turned on debug logging to view what the component is outputting?

No not yet. did that before once, and it almost halted my system… Other than setting debug globally, could I set it to a separate component, based on this log output?

[tom_l]

Hmm. These are still occasionally glitching at start-up.

- platform: template
  sensors:
    lounge_ac_heat_required:
      friendly_name: "Lounge AC Heat Required"
      value_template: >-
        {{ states('sensor.aeotec_lounge_temperature') | float < states('input_number.lounge_ac_heat_temp_set') | float }}
    lounge_ac_cool_required:
      friendly_name: "Lounge AC Cool Required"
      value_template: >-
        {{ states('sensor.aeotec_lounge_temperature') | float > states('input_number.lounge_ac_cool_temp_set') | float}}

[petro]

what do you mean by glitching?

[tom_l]

As soon as HA is started The heat or cool required template sensors are in the wrong state. Probably because the zwave sensor they rely on has not initialised yet.

I attempted to mitigate this with a “glitch_delay” sensor set as the first action in a start up automation. Unfortunately it was not fast enough to prevent the incorrect sate triggering the AC unit.

If I could access a HA start timestamp. I could prevent the AC automation running until 5 seconds or so after start up. Is there one?

Something like:

condition: state
entity_id: homeasistant?
state: on
for:
 seconds: 5

Edit: maybe this,

sensor:
  - platform: uptime

Edit 2: or maybe add a time to the heat required condition:

 conditions:
   - condition: state
     entity_id: binary_sensor.lounge_ac_heat_required
     state: 'on'
     for:
       seconds: 5

[petro]

add this line to your templates:

{% if states.sensor.aeotec_lounge_temperature is defined %}
  {{ states('sensor.aeotec_lounge_temperature') | float < states('input_number.lounge_ac_heat_temp_set') | float }}
{% else %}
  False
{% endif %}