Nice! it’s working fine now. But what when binary_sensor.open_windows will be on? 
Can we just set it to last state?
That would be ideal but at the final moment prior to restart, how do you get that binary_sensor’s “last state”?
It’s tempting to just replace:
{{'off'}}
with this:
{{ states('binary_sensor.open_windows') }}
However, the reason we are in the {% else %} section is because the state of both sensors is non-numeric (i.e. unknown). So all we will have accomplished is to set the binary_sensor’s state to unknown.
I suggest you test the example I provided when the binary_sensor reports on in the final moments prior to restarting. After startup see if the binary_sensor continues to report on (or it’s now off).
If it reports off, give the other technique a shot (shown below) because, after all, I may be wrong. 
sensors:
open_windows:
entity_id:
- sensor.temperature_out
- sensor.temperature_in
value_template: >-
{% set outside = states('sensor.temperature_out') %}
{% set inside = states('sensor.temperature_in') %}
{% if outside is number and inside is number %}
{{ (outside | float + 1) <= inside | float }}
{% else %}
{{ states('binary_sensor.open_windows') }}
{% endif %}
1 Like
Well it’s not that simple… It should be handled by integrations to be fine.
I will check when it will be on.
I’ve modified your code to make it work:
- platform: template
sensors:
open_windows:
entity_id:
- sensor.temperature_out
- sensor.temperature_in
value_template: >-
{% set outside = states('sensor.temperature_out') | float %}
{% set inside = states('sensor.temperature_in') | float %}
{% if outside is number and inside is number %}
{{ (outside + 1) <= inside }}
{% else %}
{{ states('binary_sensor.open_windows') }}
{% endif %}
If it doesn’t to work I may need an automation to store the last value in an input_number or something else and use that
Thank you for your help
Actually, your modification does the opposite.
You added float filters to the first two statements which means even if the sensor’s value is unknown, the filter will convert it to 0 (a number). So the next statement, that checks if the values are numbers, will always evaluate to true. Therefore this template will never execute {% else %}.
For testing purposes, you can temporarily alter this template {{ (outside + 1) <= inside }} to make it easier to have the binary_sensor’s state set to on. Perhaps just change the < to a > instead.
Ok just to let you know that I’ve done the opposite with a binary_sensor.close_windows 
Aaaaaannnnd it does not work 
I don’t know what you mean by that. However, if it used float filters the way I pointed out above then it’s not likely to work.
Effectively, the original problem posed in the first topic has had its root-cause identified and a mitigation technique has been offered and proven to solve the issue. Restoring the binary_sensor’s state is something that remains to be tested.
For the benefit of other users who may be experiencing a similar problem, and are searching for answers, please mark my post (the one containing the explanation or the one containing the example code) with the Solution tag. This will automatically place a check-mark next to the topic’s title which signals to other users that this topic has a solution. Thank you.
I tested your code and the binary sensor was always false. So I put your code in Developer Tools > Template and {% if outside is number and inside is number %} was never true.
If I don’t put float before, outside and inside where never numbers.
I’ve tried with {% set outside = 'unknown' | float %} and it is not a number
I’ve done this sensor:
close_windows:
entity_id:
- sensor.temperature_out
- sensor.temperature_in
value_template: >-
{% set outside = states('sensor.temperature_out')|float %}
{% set inside = states('sensor.temperature_in')|float %}
{% if outside is number and inside is number %}
{{ (outside + 0.5) > inside }}
{% else %}
{{ states('binary_sensor.close_windows') }}
{% endif %}
Everyone here is focusing on 'unknown' when the real issue is that {{ '7' is number }} is false. It’s a string. So even if we did have a number you’d get the same outcome everytime, which is what OP is seeing.
{%- set invalid = ['unknown', 'unavialable'] %}
{%- set outside = states('sensor.temperature_out') %}
{%- set inside = states('sensor.temperature_in') %}
{%- if outside not in invalid or inside not in invalid %}
{{ (outside | float + 0.5) > inside | float }}
{%- else %}
{{ states('binary_sensor.close_windows') }}
{%- endif %}
2 Likes
Yes you’ve replied before me 
Will try that, thanks
Putting it all together here (with the typo corrected):
sensors:
open_windows:
entity_id:
- sensor.temperature_out
- sensor.temperature_in
value_template: >-
{%- set invalid = ['unknown', 'unavailable'] %}
{%- set outside = states('sensor.temperature_out') %}
{%- set inside = states('sensor.temperature_in') %}
{%- if outside not in invalid or inside not in invalid %}
{{ (outside | float + 0.5) > inside | float }}
{%- else %}
{{ states('binary_sensor.close_windows') }}
{%- endif %}
EDIT
The lion’s share of this thread has been to devise a means of mitigating the root-cause of this issue which was answered early in the thread.
Question: One automation triggered at each restart, why?
Answer: Because the automation’s trigger relies on resources that disappear moments before restart.
The true ‘fix’ is that the state of the sensors shouldn’t go from known to unknown moments before restart. The orderly shutdown of integrations should not cause the entity states to effectively be lost.
Unfortunately, resolving that is an architectural matter (and beyond the average user’s control) so what’s left is to create templates (or whatever) to detect and mitigate the issue when it arises. Basically, it’s a workaround.
2 Likes
I have tested the last code and if that code works, the automation is still triggered… I can see in the History tab that if the sensor is on before restarting, it goes off when restarting and then on again. If sensor is off before restarting, it goes on when restarting and then off again…
I’m wondering if last state is restored at boot for binary_sensor based on templates.
I’ve also tried to turn off the automation when event stop is firing but it does not work.
Guess I need to less restart HA 
Here is my last code:
- alias: Notification - Ouvrir les fenetres, fait bon dehors
initial_state: true
trigger:
- platform: time_pattern
minutes: "/10"
condition:
- condition: template
value_template: >-
{% set outside = states('sensor.temp_out') %}
{% set inside = states('sensor.temp_in') %}
{{ (outside|float + 0.7) <= inside|float }}
- condition: state
entity_id: binary_sensor.temp_out_falling
state: 'on'
- condition: template
value_template: "{{ now().month >= 5 and now().month <= 9 }}"
- condition: state
entity_id: input_boolean.open_windows
state: 'off'
- condition: state
entity_id: group.all_person
state: 'home'
action:
- service: notify.all
data:
title: "Open"
message: "Windows!"
data:
push:
sound: default
- service: input_boolean.turn_on
data:
entity_id: input_boolean.open_windows
I solved my issue by triggering my automation every 10 minutes and the temp check is done in conditions
The Solution was posted a long time ago but you chose not to use it. Checking every 10 minutes is an inefficient workaround.
1 Like
I have tested all the code that has been given here and I thank you all for your help but none worked. The code is fine and is completely logic but each time I restarted HA I got a notification because the automation was triggered (due to state being unknown for whatever reason). Even when using {{ states('binary_sensor.open_windows') }} when one of the entity’s state is not a number.
I have concluded that a trigger with a template or a trigger with a binary sensor based on a template was not a good idea here. Even if it is not efficient, it now work really fine: I do not have anymore a notification when HA is restarted and it work as expected