I tried this wait template but it does not seem to wait.
It is supposed to wait until the current position of a blind is 20%
Can someone see what is wrong?
- wait_template: "{{ state_attr('cover.blind_kitchen', 'current_position') == 20 }}"
Try pasting the following into Developer Tools - Template and see what results you get:
{{ state_attr('cover.blind_kitchen', 'current_position') == 20 }}
{{ state_attr('cover.blind_kitchen', 'current_position') | float == 20.0 }}
Note that you might need to use “>” or “<” instead of “==” to get the desired result as if the cover is moving it could go from say “21.0” to “18.7” and skip "20.0 so your template never becomes true.
Am I supposed to put the template in the developer tools and then run the automation or will it just check the syntax? When I put it in it returns “False”
“==” should be okay I think. This is the position where the kitchen blind stop so the position should end up returning 20%
The Developer Tools - Template screen allows you to paste the template to see how it evalutes i.e. true or false in this case. You can use this to test if your code works without have to edit the automation and trigger it multiple times.
Juse paste in what I have provided above and see what the results are (note that you need the curly brackets around the exprerssion).
The first line is from your config and will tell us if this works, a common problem would be that “state_attr(‘cover.blind_kitchen’, ‘current_position’)” evalutes as text and therefore comparing this to “20” will result in an error.
The second line above converts this to a floating point number before doing the comparison.
Hopefully this should help you diagnose the problem.
It returns false with both suggestions.
Should it always return true if the template is working?
Copy-paste this into the Template Editor:
{{ state_attr('cover.blind_kitchen', 'current_position') is number }}
If it reports true then you can safely use this template:
{{ state_attr('cover.blind_kitchen', 'current_position') == 20 }}
If it reported false then its not a number and you must append the float or int filter to the template:
{{ state_attr('cover.blind_kitchen', 'current_position') | int == 20 }}
But what, if it stops at 19.9? You said it yourself, it should… 
I would work with “<=” or “>=”. Lowers the possibility for failure a lot. 
{{ state_attr('cover.blind_kitchen', 'current_position') is number }} returns true
{{ state_attr('cover.blind_kitchen', 'current_position') == 20 }} returns false
{{ state_attr('cover.blind_kitchen', 'current_position') | int == 20 }} returns false
{{ state_attr('cover.blind_kitchen', 'current_position') > 20 }} returns true
{{ state_attr('cover.blind_kitchen', 'current_position') >= 20 }} returns true
{{ state_attr('cover.blind_kitchen', 'current_position') < 20 }} returns false
Strange.
It’s not strange if the current value of current_position is greater than 20.
What is the value of the entity’s current_position as shown in the Developer Tools > States?
No of course not 
I just tried
{{ state_attr('cover.blind_kitchen', 'current_position') == 20 }} returns false
and it returns true when adjusting the blinds to 20.
But then I guess the issue is related to the wait_template
I just never saw that it didn´t return a status of exactly 20%
Solved:
It turns out that by choosing an end position this value actually returned immidiately after activation of the blinds. Eventually it then returned the correct position. All I had to do was delay the wait template a few seconds
It reports its current_position is 20 even if it isn’t actually at that position yet? 
If you added a delay prior to the wait_template then the wait_template is useless given that you said current_position is immediately set to 20.
Yes exactly. Actually it immidiately returns the “end” value but then very quickly starts returning the actual position along the movement.
That´s why it helped adding a small delay in front of the wait_template.
It sounds like a bug in the integration.
Which integration is used for this cover?
It is integrated through MQTT. It also shows this wrong value direct in Zigbee2mqtt.
So either the blind returns a wrong value itself or a bug in z2m I don´t know.
It´s supported
I would report this unusual behavior in the Zigbee2MQTT GitHub repository. Its not normal for it to momentarily report its intended position (like 20) before it starts moving to that position. It should only report its current position, not a future position.
I will do that