Closed:
Open:
From that perspective it should just work OK.
Memo: the state changes from 0 to 100 immediately after the command to open and vice versa - but not when it gets to the end point of the respective movement.
Closed:
Open:
From that perspective it should just work OK.
Memo: the state changes from 0 to 100 immediately after the command to open and vice versa - but not when it gets to the end point of the respective movement.
Well, this looks as it should.
So I have no idea what is happening in the morning, sorry.
As no one else is reporting this issue, I guess that it’s something special with your setup. And I still think that - for whatever reason - the cover group is not reporting the attribute current_position 0 at this point of time.
That assumption appears to be correct. Although the correct state (closed/opened) is reported back after the respective action.
Over time one of the roller shutters erroneously changes its state over night with the effect that the entire group fails to operate.
What is the particular reason to ask for the state before running the action? Why not run the action regardless of the current position/state?
Because a lot of people are doing any manual stuff with their blinds and they don’t want that the automation overwrites their manual stuff.
So let’s say you drive, for whatever reason, the blind to 40%. If the automation ignores it, it would open or close the blind with the next trigger. But maybe you want the blind to stay at 40% for the next two hours. Or you need a special %-level for your movie theatre and don’t want the automation to close/open.
Therefore the automaton is only doing anything for some defined levels.
But if you don’t need or want this, just open the blueprint and delete the corresponding lines.
Hi @Eimeel
would you please be so kind and let me know where I can find the reference to the query of the open/closed state within the blueprint?
I am not familiar with blueprint programming but am certain that I can manage to comment these lines out in the local application.
Thanks in advance.
Best regards
In Version 2023110101 delete lines 686-690. But I have no idea if this creates any side effects.
Better solution is to add another condition (to the or-condition starting with line 686) with the corresponding (incorrect) state of your blinds during the morning.
Hi @Eimeel
Thank you for your continous support.
Are you sure with the lines 686-690?
I think I found the lines in 935 - 940???
"alias": "Checking for opening",
"conditions": [
{
"condition": "template",
"value_template": "{{ auto_up }}"
},
{
"or": [
{
"condition": "trigger",
"id": "t_bo_1"
},
{
"condition": "trigger",
"id": "t_bo_2"
},
{
"condition": "trigger",
"id": "t_bo_3"
},
{
"condition": "trigger",
"id": "t_bo_4"
},
{
"condition": "trigger",
"id": "t_bo_5"
},
{
"condition": "trigger",
"id": "t_bo_6"
}
]
},
{
"or": [
{
"condition": "template",
"value_template": "{{ state_attr(blind, 'current_position') | int(default=101) == ventilate_position }}"
},
{
"condition": "template",
"value_template": "{{ state_attr(blind, 'current_position') | int(default=101) == 0 }}"
}
]
},
Version: 2023110101 only contains 920 lines
I guess you should update.
Did your adjustment of the code with regarding to the tilt position work?
I want to start with this blueprint and shading blinds (Homematic) in the next days. If you had success with the adaption, I would be glad, if you could share your last version.
I haven’t been able to test this yet because our house is being renovated. At least I haven’t noticed any negative side effects so far. That’s already a success
When I’m back at home, of course Icould share my code at end of the week.
Hi @Eimeel,
I tried that but it told me the version you recommended was already installed.
I am (yet) not familiar with editing blueprints.
Can you please help me how to edit the blueprint and locate the correct section to comment-out?
As there is no update function for blueprint you have to options:
a) Just delete the blueprint and re-install
b) open the file in the blueprint order, delete everything and copy&paste the code from GitHub.
The correct setion to uncomment is still mentioned at Extensive roller shutter control including shading (brightness, sun position, temperature, forecast) - #69 by Eimeel
Hi @Eimeel,
please help me. I deleted the automations and the blueprint and installed it from the link above. I then edited the blueprint and mine ends with line 1081:
What am I doing wrong here?
Oh, wow. Seems that importing blueprints is killing some line breaks. Sorry.
So it’s lines 826-832
- or:
- condition: template
value_template: '{{ state_attr(blind, ''current_position'') | int(default=101)
== ventilate_position }}'
- condition: template
value_template: '{{ state_attr(blind, ''current_position'') | int(default=101)
== 0 }}'
But if you delete these lines and something strange is happening: I won’t provide any support for this.
Hi @Eimeel,
I commented the lines out with a leading #.
At least this morning the roller shutters opened as expected.
Thank you!
Hi Eimeel, first of all: thank you for this blueprint!
I’ve justed started testing it and there’s a problem. I’m testing with a door having a shutter outside and and an opening sensor. Up and down is working without issues in the mornings and evenings. When shutter ist up during daytime and I open the door, all is fine. When I close the door, the shutter closes to 0%. That’s strange behaviour. Here’s my config:
id: '1701160626332'
alias: 'Beschattung: Büro'
description: ''
use_blueprint:
path: jmerifjKriwe/automatic_blinds_shading.yaml
input:
blind: cover.beschattung_buro_empfanger
shading_blinds_position: 45
shading_outdoor_temperatur_sensor: sensor.temperatursensor_temperatur
shading_min_temperatur: 24
brightness_sensor: sensor.illumination_average
shading_sun_brightness_in: 10000
shading_sun_brightness_out: 5000
forecast_temp: 24
door: 'true'
brightness_down: 20
brightness_up: 80
time_up_early: '07:30:00'
time_up_early_non_workday: '08:00:00'
time_down_early: '16:00:00'
shading_elevation_min: 7
shading_elevation_max: 90
shading_azimuth_in: 185
shading_azimuth_out: 315
shading_min_temperatur2: 24
ventilate_position: 100
auto_shading: true
window_sensor: binary_sensor.fenstergriff_buro_offen
Trace:
Any ideas?
Yes, I do
It’s because of this:
- alias: Blinds - closing after ventilate
and:
- condition: trigger
id: "t_bc_4"
- condition: template
value_template: "{{ auto_ventilate }}"
- condition: template
value_template: "{{ state_attr(blind, 'current_position') | int(default=101) == ventilate_position }}"
- condition: template
value_template: '{{ (window_sensor != [] ) and (states(window_sensor) == ''off'') }}'
I’m only able to guess which state the automation currently has. And I use the current_position for this.
So the quick fix for you is to change ventilate_position to 99.
But I have to find a real fix for it. Which is quite quick if I would duplicate code but I don’t like this idea so I have to think about it.
Works for me. Thanks!
@Eimeel
many many thanks for this great blueprint.
I understand that you made it complete for your use cases and you are not going to extend it anymore.
The good news is that your code is well structured and pretty easy to understand. And that helped me to apply some amendments which I needed:
Thanks again for this great and handy blueprint!
@Lupo what is the erroneous change of the shutter? if it is a small variance of some percent you might consider introducing a ‘tolerance’ in the conditions.
- condition: template
value_template:
"{{ (state_attr(blind, 'current_position') | int(default=110) <= closed_position + position_tolerance)
and (state_attr(blind, 'current_position') | int(default=110) >= closed_position - position_tolerance)}}"
please notice in the code snippet that I’ve introduce variables for open_position and closed_position as well. and I set the default to 110 to avoid overlaps with tolerances