I created an automation to shut down my heatings (Fritz DECT 302) in case a window in the room was opened (Shelly DW2) and it works fine. However, I do not like the coding and would appreciate a way to include variable instead of copy and paste it 9 times for all my rooms/heatings…
Any Idea to produce a variable automation for all heatings or a script?
All the best and kind regards for your help
Benedikt
but ended up with the failure when reloading automations.yaml
Logger: homeassistant.config
Source: config.py:508
First occurred: 22:59:20 (1 occurrences)
Last logged: 22:59:20
Invalid config for [automation]: Entity binary_sensor.tfk_{{ trigger.entity_id | replace(“climate.” is neither a valid entity ID nor a valid UUID for dictionary value @ data[‘action’][2][‘if’][1][‘entity_id’]. Got None Entity climate.{{ trigger.entity_id | replace(“climate.” is neither a valid entity ID nor a valid UUID for dictionary value @ data[‘condition’][0][‘entity_id’]. Got None. (See /config/configuration.yaml, line 48).
Any idea how to overcome this?
All the best and kind regards for the fast help
Benedikt
However, the following State Condition, which also employs a template in entity_id, cannot be easily replaced by a Template Condition. It use the for option which isn’t supported by a Template Condition.
The required Template Condition will need to not only check if the entity’s state is on but that it hasn’t changed in at least 30 seconds by check if the entity’s last_changed value is older than 30 seconds.
I wand the heating (climate entity) to turn of (zero heating, no preset mode) when the window is opened. All windows have door-window contacts (Shelly DW2) and the heatings are controlled by AVM Fritz DECT 302 valve controllers. The delay of 30 seconds was an idea to prevent the trigger from being fired in case of just a short opening (e.g. to ask the kids to come in).
Furthermore, the DECT 302 uses two preset modes (i. e. temperatures to set) in case the heating is on: eco (16 degree in my case) and comfort (21 degree in my case). Preset modes are scheduled during the day to only heat the rooms in times we are normally at home and in this room.
Two issues I needed to overcome are:
When the preset mode changed due to schedule in a situation with an open window, the heating will go to eco/comfort again even if the window is open. So I wanted the automation to again shut the heating off in this case.
When closing the window (action: climate turn on), the turn on action forces the heating to the comfort mode regardless the schedule. Therefore, I needed to check the schedule und change preset mode to eco if necessary (otherwise when opening and closing the window during “eco time”, the heating will be in comfort mode after closing).
The automation initially posted by myself fulfills al these needs but I didn’t like the idea of having separate hard coded automations for every of the 9 rooms.
If there would be a smart way to include all rooms in one automation, this would be great
All the best and kind regards
Benedikt
Possible status attributes of one exemplary heating:
Ok…
I believe #2 is already covered in your automation as it was.
I believe the only one that is an issue is the #1.
But if the thing is that a scheduled task changes the preset and at the same time as you have the window open to call in the kids, that sounds like a very unlikely event.
But I guess it all depends on how often you call on your kids.
As Taras suggested, you can overcome this limitation with checking the last change of the entity, but if I was you I would try with just checking the state without the for: 30 seconds and see if it really is a issue.
Sorry, maybe I did explain it too complicated.
The 30s delay is needed NOT to start the action because it makes no sense to start the shutdown mechanism if we’re e.g. leaving one room (some windows are door-window combination) to the garden or just shortly opening the window to call the kids in.
#1 addresses the situation when you start the shutdown (open longer than 30s, e.g.
window tilt position during whole night or during daytime) but the schedule changes the preset during that time (e.g. going to bed earlier than the preset change in the evening). In that case, the heating would start again in eco or comfort (depending on the schedule) even if the window is open.
Here’s a more compact version of your automation. Review and test it to confirm it meets your requirements. Report any problems you may encounter with it (I don’t have the means to test its operation).
Thank you a lot!
It works great, except for timedelta condition.
When there is a change in preset mode during open window, it does trigger the automation but it doesn’t fulfill the three conditions. When removing the condition with the timedelta, it works fine.
Another observation: The automation fires again afer being triggered the first time by itself. I guess this happens since every turn on/off action represents also a change in preset mode, thereby triggering “preset” again (luckily without any action since no condition fulfilled.
This is the first and correct execution triggered by closing the window. Then its triggered twice again (I guess by ‘turn on’ and by changing the preset to ‘eco’):
I corrected the example I posted above. In the last Template Condition, it should be checking if the result of the subtraction is greater than 30 seconds. In the original example I had set it to less than 30 which is incorrect.
The automation’s action controls the state of climate entities that the automation also monitors in its trigger. Therefore it’s natural for the automation to trigger itself. For example, when a window is closed (and remains closed for at least 30 seconds), it will trigger the automation which will proceed to set the climate entity to eco mode (if schedule.heizung_eg is off). If this causes the climate entity’s state to change, it will trigger the automation again.
OK, thank you, I got it
Another question:
Is it necessary to have the “from” argument in case of the “window” trigger?
Why I’m asking: Sometimes I found the door-window contacts in status “unavailable” which didn’t bother me since they still immediately changed status when e.g. opening the window. However, in that case the automation wouldn’t be triggered, right?
Correct. It won’t be triggered by a state-change from unavailable to on or off. If you want it to be triggered by state-changes from unavailable, remove the from option.