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 %}can’t you set the retain flag on these events? I had that same issue in my first Z-wave integration in HA, but that solved nicely after having set the publisher to use retain on these events. No matter what, they always have a value.
They’re not mqtt sensors, can you do that with zwave?
Unfortunately this did not work @petro:
- platform: template
sensors:
rumpus_ac_heat_required:
friendly_name: "Rumpus AC Heat Required"
value_template: >-
{% if states.sensor.rumpus_room_temperature is defined %}
{{ states('sensor.rumpus_room_temperature') | float < states('input_number.runpus_ac_heat_temp_set') | float }}
{% else %}
False
{% endif %}
rumpus_ac_cool_required:
friendly_name: "Rumpus AC Cool Required"
value_template: >-
{% if states.sensor.rumpus_room_temperature is defined %}
{{ states('sensor.rumpus_room_temperature') | float > states('input_number.rumpus_ac_cool_temp_set') | float}}
{% else %}
False
{% endif %}
The AC unit still triggered on restart, when it should not have (I did check the final sensor states). I’m going to try the for: seconds: 5 in the conditions.
22:30 [Lounge AC Heat Required] turned off
22:30 [Lounge Entrance Multisensor]changed to initializing
22:30 [Aeotec ZW090 Z-Stick Gen5 AU]changed to initializing
22:30 [Upstairs AC Mode] changed to Normal Heat
22:30 [Lounge AC Heat Required] turned on
22:30 [Lounge PM Automation Time Active] turned on
22:30 Home Assistant started
for a delay at startup You can use this;
- alias: 'Startup HA'
id: 'Startup HA'
initial_state: 'on'
trigger:
platform: homeassistant
event: start
condition:
condition: template
value_template: >
{{whatever you want}}
action:
- delay: 00:00:20
- service: whatever
not sure if you can delay the creation of a sensor though…unless you’d create it via an automation or script (have these in python eg)
Tried it. It did not work. See “glitch_delay” in my image above (one event too late). This was the first service call in my start-up automation too.
I can because my zwave hub connects to HA via Mqtt 
Checking to see that the sensor has been on for at least 10 seconds seems to have solved the problem:
- condition: or # And only if room heating or cooling is required (for the case of a time trigger)
conditions:
- condition: state
entity_id: binary_sensor.lounge_ac_heat_required
state: 'on'
for:
seconds: 10
- condition: state
entity_id: binary_sensor.lounge_ac_cool_required
for:
seconds: 10history_stats is is… or?
2018-09-21 15:56:16 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/components/sensor/history_stats.py", line 114, in force_refresh
self.schedule_update_ha_state(True)
File "/usr/local/lib/python3.6/site-packages/homeassistant/helpers/entity.py", line 289, in schedule_update_ha_state
self.hass.add_job(self.async_update_ha_state(force_refresh))
AttributeError: 'NoneType' object has no attribute 'add_job'
2018-09-21 15:56:24 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-21 15:56:24 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-21 15:56:24 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-21 15:56:24 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
Still havent got a clue what to do here… deleted the history_stats sensors and the original error of the post above remains in the log…
Then it’s unrelated to your history stats sensor. Not sure what’s causing it because it’s coming from the core.
it don’t repeat!
do you know why?
- id: timeroven
alias: oven_timer
trigger:
- above: '1'
entity_id: sensor.ovenoo
platform: numeric_state
condition:
- condition: template
value_template: '{{ as_timestamp(now()) - as_timestamp(states.automation.oven_timer.attributes.last_triggered) | int > 4 }}'
action:
- data:
message: oven is on!
service: notify.ios_vahids_iphone
- service: homeassistant.turn_on
entity_id: script.timed_lamp_ovenlanguage Mr! 
you seriously removed my post yesterday over the - e x a c t - same thing.
I wasn’t a moderator 2 years ago 
1 Like
as i read for days and days while resisting posting a question you undoubtingly already answered, i do see you are a incredible asset to the homeassistant community and i apologize for the heckling. this has been nothing but frustrating, this rubics cube / addiction that homeassistant is.
I have a daily light schedule that is set via an input_datetime entity within the UI. it happens daily, everyday.
I have a script that changes many things, and in that script it has the lights turning on. however the daily light schedule has the lights off for about thirty minutes. all im trying to accomplish is, timediff to time now to time of next occurance of schedule. i can format the string, to give me the 'hours / minutes / seconds result. but im struggling to get the string.
im coming to the conclusion that i need to add todays date/year format to the input_datetime, then time difference to now and ensure both are using timestamps instead of strings, then divide the seconds or epoch it returns?
sorry, i would post code and my attempts but itll be a book. however, i will post when i get home from work. day 3 on this. please. forgive me almighty templater. 
This is super-great, thank you. I’m using it in my smart heating control automation. I’ve found an interesting bug, that the value of t is not coherent on all the systems, and it depends on the timezone set. To circumvent this, my fix is:
- condition: template
value_template: >
{% set t = strptime((now().timestamp() | timestamp_local), "%Y-%m-%d %H:%M:%S").timestamp()-strptime(now().strftime("%Y-%m-%d 00:00:00"),"%Y-%m-%d %H:%M:%S").timestamp() %}
{% set time_start = state_attr('input_datetime.heating_weekday_morning_start','timestamp') %}
{% set time_end = state_attr('input_datetime.heating_weekday_day_start','timestamp') %}
{{ time_start <= t < time_end }}
Thanks again.
it depends on how your datetime is configured. If your datetime doesn’t use a date, that’s not included with the timestamp. What you could have done is used strptime on your input_datetime states. Then t wouldn’t change. Plus it’s easier to read.
{% set t = now().timestamp() %}
{% set fmat = "%Y-%m-%d %H:%M:%S" %}
{% set start = strptime(states('input_datetime.heating_weekday_morning_start'), fmat).timestamp() %}
{% set end= strptime(states('input_datetime.heating_weekday_day_start'), fmat).timestamp() %}
{{ start <= t <= end }}
1 Like
I get UndefinedError: 'str object' has no attribute 'timestamp' in template editor with this.
That means the format is wrong, if your datetimes do not have dates, you need to remove the dates from the fromat.
{% set t = now().timestamp() %}
{% set fmat = "%H:%M:%S" %} #<---- Change this to match input_datetime's state
{% set start = strptime(states('input_datetime.heating_weekday_morning_start'), fmat).timestamp() %}
{% set end= strptime(states('input_datetime.heating_weekday_day_start'), fmat).timestamp() %}
{{ start <= t <= end }}
Naaah. It’s not the same.
It always returns false becaue the results:
{{ t }}
{{ fmat }}
{{ start }}
{{ end }}
are the following:
1604591220.001948
%H:%M:%S
-2208969600.0
-2208958200.0
My inputs are:
heating_weekday_morning_start:
name: Workdays morning
has_time: true
has_date: false
heating_weekday_day_start:
name: Workdays daytime
has_time: true
has_date: false
You don’t remember your own code, do you ? 
The thing is, you have to substract from the current time the midnight timestamp. The original problem was that now().timestamp() returns the UTC time while I need the local times. Everything else is perfect.
That’s only if you don’t have todays date in the datetime. The original code you’re cherry picking is assuming its full date and time. You should have cherry picked the other template in the original response which has an additional line. It appears that the striptime isn’t making that assumption so you have to add it yourself, like the link suggests.
{% set t = now().timestamp() %}
{% set date = now().strftime("%Y-%m-%d ") %}
{% set fmat = "%Y-%m-%d %H:%M:%S" %}
{% set start = strptime(date ~ states('input_datetime.heating_weekday_morning_start'), fmat).timestamp() %}
{% set end= strptime(date ~ states('input_datetime.heating_weekday_day_start'), fmat).timestamp() %}
{{ start <= t <= end }}
No, I wrote it 50 versions and 2 years ago. Things have changed drastically and I don’t use input_datetimes because they’re terrible in the UI on mobile.
1 Like
I fully agree with you.