New Update
Attention: If the delay for ventilation was already activated with yesterday’s update, this must unfortunately be done again with this version. I have done a little rearranging here.
2024.03.12-02:
- Added #20: Allow ventilation not only in closed state, but also when the position is below the ventilation position.
- Bugfixes when comparing positions
Ventilation Bugfix-Update:
2024.03.14-01:
- Fixed: Ventilation mode could always be started by mistake.
- Fixing helper length check. Thx to crandler.
Am I doing something wrong?
The way I see it, there shouldn’t have been any shading today. However, a few minutes ago my blinds were closed.
alias: CCA Büro Mike
description: ""
use_blueprint:
path: hvorragend/cover_control_automation.yaml
input:
shading_forecast_sensor: weather.nuernberg
blind: cover.shellyplus2pm_3ce90e2f49dc
time_up_early: "05:30:00"
time_up_late: "07:30:00"
closed_position: 31
time_down_early: "22:00:00"
time_down_late: "22:30:00"
default_brightness_sensor: sensor.lichtsensor_buro_mike_illuminance_lux
brightness_up: 180
workday_sensor: binary_sensor.workday_sensor
contact_sensor: binary_sensor.fenster
ventilate_position: 31
shading_cover_position: 50
shading_azimuth_start: 76
shading_azimuth_end: 176
shading_temperatur_sensor1: sensor.hausfront_temperature
shading_min_temperatur1: 15
shading_brightness_sensor: sensor.lichtsensor_buro_mike_illuminance_lux
shading_sun_brightness_start: 4500
shading_sun_brightness_end: 180
auto_options:
- auto_up_enabled
- auto_down_enabled
- auto_brightness_enabled
- auto_sun_enabled
- auto_shading_enabled
close_position: 31
shading_position: 50
time_down_early_non_workday: "22:00:00"
weather.nuernberg:
forecast:
- datetime: "2024-03-15T00:00:00Z"
condition: rainy
wind_bearing: 222.57
wind_gust_speed: 35.2
uv_index: 3
precipitation_probability: 51
temperature: 16
templow: 10
wind_speed: 18.5
precipitation: 0.6
Could it be that the forecast is being ignored?
An update to the latest version is necessary here. A bug has been fixed in version 2024.03.12-01.
But many thanks nonetheless. I have found another error.
Hi, sorry to bother you again, but i discovered an new behavior since the latest update. Before the behavior was if the contact sensor was “on” the shutter would move to the ventilation position when closing, now it moves to closing position.
I added some traces.
Thanks again
https://drive.google.com/drive/folders/1TPLFzm2vzzEafwgeoL3USWpuKbCU8pkr?usp=sharing
The user crandler just told me the same thing a few seconds ago. I have actually programmed this mode out. How stupid. I only had one eye on manual opening and closing. I’ll include that again.
The blueprint isn’t working well for my Homematic Device (HM-LC-Ja1PBU-FM).
service: cover.set_cover_position
and
service: cover.set_cover_tilt_position
are doing their job fine, but if both are executed at the same time (like going from closed position to 20% open and 50% tilt), the “set_cover_position” will start moving the blind, but will be overridden some seconds after by the “cover.set_cover_tilt_position” command. That makes the blind stop at around 3-4%.
For this reason, there is a service for homematic devices that let the actor work correctly:
service: homematicip_local.set_cover_combined_position
data:
position: 20
tilt_position: 50
target:
entity_id: cover.wohnzimmerjalousie
I already had to rewrite the Eumel Code to make to implement this service. I would do that again with a fork of your CCA project. The downside is, that I will miss new features as my CCA fork would stay static.
Did anybody encounter similiar problems?
Hi,
thank you for all the work on this blueprint, very nice indeed!
I have a question regarding this config requirement: shading_azimuth_start should be lower than shading_azimuth_end
I see a problem when the window orientation is just crossing azimuth 0 deg, so the start is somewhere below 360, but end is above 0.
Or am I missing something?
Thank you,
Peter
You could use the Additional Actions for this. I have built this in for such purposes. Some Shelly’s also behave strangely.
I would just have to add a switch to deactivate the normal commands.
I don’t know what part of the world you live on. Then perhaps there could be situations that I haven’t taken into account.
But do the blinds you mentioned really need shading? Does the sun shine into your windows from this angle?
I can have a look at that. If necessary, you’ll have to build a template sensor that somehow takes the shift into account.
Hi, I live in Central Europe, so this is not some curious part of the world, but I assume this has to do more with window orientation, but maybe I’m really missing something obvious 
So, if you have a window oriented towards west or north, and you want to shade the blinds when the sun is shining to the windows, you set azimuth_start to ~300. But doesn’t setting of azimuth_end (which is then max 365) open the shades at night?
Thanks,
Peter
Sun will be down after sun azimuth ~300° 
not really, in summer, for example in Berlin, July, sun goes to Azimuth 300 at 20:36, but sunset is 21:30 and dusk at 22:19 (SunCalc)
But anyway, the question is, if you set shading_azimuth_end to 360 and it’s night at that time, would the blinds open?
Thanks,
Peter
Sounds like an pretty good solution to me! Thank you!
There’s an option:
Individual Configuration: Prevent the end of shading when the cover is already closed
PS: 323° max. on dusk end (-6°) in Berlin at summer solstice (21.06.2024)
Hi,
I think I discovered an edge case today. The automation was triggered at by early up at 7:00:00 and was waiting for the random delay (5sec) to pass. at 7:00:03 the automation was triggered by sun. This restarted the automation and the roller shutter remained closed.
BTW: thanks for this awesome automation!
triggered by time (07:00:00)
triggered by sun (07:00:03)
id: '1710668503725'
alias: 'Cover: EG Esszimmer'
description: ''
use_blueprint:
path: hvorragend/cover_control_automation.yaml
input:
blind: cover.firstfloor_dining
auto_options:
- auto_up_enabled
- auto_down_enabled
- auto_ventilate_enabled
- auto_sun_enabled
time_control: time_control_input
time_up_early: '07:00:00'
time_up_early_non_workday: '08:00:00'
time_up_late_non_workday: '09:00:00'
time_down_early: '18:00:00'
time_down_early_non_workday: '18:00:00'
time_down_late: '21:00:00'
time_down_late_non_workday: '21:00:00'
drive_time: 30
position_tolerance: 1
workday_sensor: binary_sensor.is_workday
contact_sensor: binary_sensor.firstfloor_dining_window_open
ventilate_position: 20
check_config: true
auto_up_action: []
individual_config: []
shading_brightness_sensor: sensor.weather_brightness
shading_forecast_sensor: weather.forecast_home
shading_forecast_temp: 25
shading_min_temperatur1: 20
shading_min_temperatur2: 20
shading_temperatur_sensor1: sensor.weather_temperature
auto_global_condition: []
auto_up_force: binary_sensor.firstfloor_living_smoke_detector_alarm
ignore_after_manual_config:
- ignore_shading_after_manual
cover_status_options: cover_helper_enabled
cover_status_helper: input_text.firstfloor_dining_cover
Hi there, first of all thanks for the blueprint! nice work!
I’m trying to understand something, i have the blueprint set up for a windowcover. open en close works fine, but i want to play with the ability to close the cover with sun setting.
I’ve set a an open and close timing, but does the close time has any effect on the auto closing set with sun-elevation etc?
Like today, there was a high sun, temp went up in my office, but the cover did not close to 25% as set.
Any idea what i do wrong?
Yes, that really annoys me too. I’ve been trying to get to grips with it for days. Unfortunately, changing the automation mode in restart to queued is not enough.
In my local test environment, I now check whether the automation is already running. But I don’t currently have a way to test it. It’s difficult to reproduce.
condition:
- condition: template
value_template: "{{ state_attr(this.entity_id,'current') | int(99) == 0 }}"
Is it possible that you are confusing the shading mode as sun protection with the sun control when closing?
Code is ready, but not yet published.