Good (insert greeting for your timezone) !
I was given a Zemismart ZM85ML-1Z that the owner could not get to work.
LOL, I added it to HA with zigbee and blam using CCA it worked, Every day.
But I would like to make it better, and would like to put limit switches on the blind (Ikea Parsoll) so that it stops at the exact right spot.
But I cant seem to find an option for that? is it called something I missed?
Hi Everyone,
Here is some more information>
The problem I am having is that 29 seconds up is perfect.
BUT
29 seconds down is way to much due to the weight of the blind speeding up the decent, that needs to be more like 25 seconds.
So i was thinking that a magnet glued to the end of the rod at the bottom would be able to set off a door and window sensor, giving the exact position of close and open.
So just trying to figure that part out, thnaks for your time!
Hi there,
I had to replace my velux control unit to the one being used through homekit. So I adjusted my CCA automation for it using the “new” device and noticed that while the shutter of my window closes, it does not open again. I did not change something other than the device which was updated because of the KIG300 unit to be used.
Checking further I saw the debug message CCA Config issue: Please revise the position values and take the tolerance values into account. The values must not overlap -
I don’t really know what this message tells me precisely moreover what to do to fix things.
Obviously running the shutter through the KIG300 unit changed something in the position reporting or something. Both, the shading and the tolarance value are 0 but am I looking at the right position there? I’m totally not sure so I hope to be able to get some help here.
Here is what I have configured which was working before when using the KLF200 device but stopped with the KIG300 one:
description: ""
use_blueprint:
path: hvorragend/cover_control_automation.yaml
input:
blind: cover.treppenhaus_rollladen_roller_shutter
auto_options:
- auto_up_enabled
- auto_down_enabled
- auto_brightness_enabled
- auto_shading_enabled
time_up_early: "06:45:00"
time_up_early_non_workday: "07:30:00"
time_up_late_non_workday: "12:00:00"
time_down_early: "17:00:00"
time_down_early_non_workday: "17:00:00"
time_down_late: "21:45:00"
default_brightness_sensor: sensor.gw1100a_solar_lux
brightness_up: 15
brightness_down: 50
workday_sensor: binary_sensor.ist_heute_ein_arbeitstag
sun_elevation_up: 6
drive_delay_fix: 5
sun_elevation_down: -0.5
shading_position: 0
shading_brightness_sensor: sensor.gw1100a_solar_lux
shading_sun_brightness_start: 20000
check_config: true
auto_up_condition:
- condition: and
conditions:
- condition: numeric_state
entity_id: sensor.gw1100a_outdoor_temperature
above: 0
- condition: numeric_state
entity_id: sensor.gw1100a_hourly_rain_rate
below: 0.1
- condition: state
entity_id: input_boolean.es_regnet
state: "off"
for:
hours: 0
minutes: 0
seconds: 30
shading_min_temperatur1: 21
auto_global_condition: []
shading_azimuth_start: 100
shading_elevation_min: 20
shading_waitingtime_start: 600
shading_waitingtime_end: 1200
auto_down_force: input_boolean.es_regnet
individual_config:
- prevent_shading_end_if_closed
- prevent_opening_multiple_times
- prevent_closing_multiple_times
shading_sun_brightness_end: 5000
shading_forecast_sensor: weather.herxheimweyher
shading_forecast_temp: 20
cover_status_helper: input_text.status_rollladen_treppenhaus
cover_status_options: cover_helper_enabled
workday_sensor_tomorrow: binary_sensor.ist_morgen_ein_arbeitstag
drive_time: 90
ventilate_position: 0
shading_azimuth_end: 250
time_down_late_non_workday: "23:00:00"
auto_shading_start_action: []
auto_shading_end_action: []
shading_min_temperatur2: 21
shading_temperatur_sensor2: sensor.gw1100a_outdoor_temperature
shading_forecast_type: weather_attributes
shading_weather_conditions:
- sunny
- partlycloudy
- cloudy
- clear
- windy
- windy-variant
reset_override_config: reset_timeout
reset_override_timeout: 120
time_up_late: "12:00:00"
resident_config: []
is_shading_end_immediate_by_sun_position: true
shading_temperature_hysteresis2: 1
position_tolerance: 0
Thanks a bunch in advance! 
Hi All,
Just following up on my request regarding the time it takes to drive the roller blind up (29 sec) and to drive the blind down (25 sec)
I was reading the setting again and there is a section under the “additional conditions” section
“Additional Condition For Opening The Cover”
and
“Additional Condition For Closing The Cover”
These seem like they would allow me to add the upper and lower magnet door sensors to the cover control logic, am i reading this right?
Chris
EDIT:
after reading this, it says the input must be FALSE. so no go there.
It seems strange there is no setting to be able to use the limit switches.
I’m migrating my roller shutter automation from HomeMatic to HA. So far CCA looks great, thanks for this!
I have one use case, for wich im not sure, what options to use: In HomeMatic I have an automation, that immediately opens all shutters on any smoke detector going off (Terrace doors and the balcony door. This way I don’t obstruct any potential ways out of the house without any need for manual interference.)
Trigger is any HomeMatic smoke detector. Thy are also grouped.
How do I replicate that behaviour in CCA. thx a lot
Hi Guys,
I have performed the update of the script to Version 2025.08.15 and since then I do not get any openings of the blinds in the morning.
Before this was working fine, but I had other problems with shading.
According to the logs I get:
But the blinds are not moving at all.
Of course in the settings the following is acticated:
Are there any ideas? Do other have the same issue?
Settings:
alias: Cover Control Automation (CCA) Eltern
description: ""
use_blueprint:
path: hvorragend/cover_control_automation.yaml
input:
blind: cover.og_eltern_raffstore
auto_options:
- auto_sun_enabled
- auto_ventilate_enabled
- auto_up_enabled
- auto_shading_enabled
- auto_down_enabled
individual_config:
- prevent_opening_multiple_times
- prevent_closing_multiple_times
- prevent_shading_multiple_times
cover_status_options: cover_helper_enabled
cover_status_helper: input_text.helper_cca_raffstore_eltern
workday_sensor: binary_sensor.workday_sensor
shading_brightness_sensor: sensor.garten_sonnensensor_3_differenz_temperatur
close_tilt_position: 0
open_tilt_position: 100
ventilate_position: 0
shading_position: 0
shading_tilt_position: 50
position_tolerance: 2
brightness_time_duration: 60
brightness_up: 200
brightness_down: 600
shading_azimuth_end: 320
shading_azimuth_start: 150
shading_temperatur_sensor2: sensor.ikirch559_temperature
shading_forecast_sensor: weather.forecast_home
auto_up_force: input_boolean.alarm_wind
contact_window_opened: input_boolean.turgriff_eltern_offen
contact_window_tilted: input_boolean.turgriff_eltern_gekippt
lockout_tilted_options:
- lockout_tilted_closing
- lockout_tilted_shading_start
- lockout_tilted_shading_end
auto_ventilate_options:
- ventilation_if_lower_enabled
- ventilation_after_shading_end
drive_time: 65
time_down_early: "17:00:00"
time_down_early_non_workday: "17:00:00"
time_control: time_control_input
ventilate_tilt_position: 73
shading_sun_brightness_start: 8
shading_sun_brightness_end: 3
cover_tilt_config: cover_tilt_enabled
shading_forecast_temp: 22
check_config: false
time_down_late: "21:00:00"
time_down_late_non_workday: "21:00:00"
shading_min_temperatur2: 18
shading_waitingtime_start: 120
shading_waitingtime_end: 300
shading_elevation_min: 10
shading_temperature_hysteresis2: 2
sun_elevation_up: 3
sun_elevation_down: 5
shading_forecast_type: daily
default_brightness_sensor: sensor.ikirch559_solar_radiation
shading_tilt_position_1: 60
shading_tilt_position_2: 70
shading_tilt_position_3: 80
shading_tilt_elevation_3: 48
contact_delay_trigger: 1
contact_delay_status: 1
shading_temperature_hysteresis1: 2
workday_sensor_tomorrow: binary_sensor.workday_sensor_tomorrow
time_up_early: "05:30:00"
tilt_delay: 5
shading_tilt_elevation_2: 35
shading_config:
- shading_temp_comparison_independent
- shading_compare_forecast_with_sensor2
shading_weather_conditions:
- clear
- sunny
- cloudy
- partlycloudy
time_up_late: "05:40:00"
Thanks
i think the “force feature” should be the thing your are looking for!
@Herr.Vorragend any feedback on this?
Would be highly appreciated if you could at such a wait template.
BR
Philipp
Hello, I’ve been having a frequent problem lately where the shutters wouldn’t go up even though the azimuth was outside the set value; they just stayed down. I’ve now sent the problem, along with all the traces, to Google Gemini and received the following hint. Is the assumption about the logic problem in the blueprint correct, or do you have another idea what the cause might be? I know the AI isn’t always right, but it often makes the right assumption.
Absolut! Hier ist die Übersetzung deiner Analyse, die du in der Community posten kannst:
Hello everyone,
I’m having an issue where my blinds are not opening after the conditions for shading are no longer met. I’ve been debugging this and finally captured the key traces.
My problem was visible in the history: the input_text helper would correctly update to shading: 0, but the cover itself would remain in the shading position (50%).
Thanks to Gemini’s analysis, I’ve managed to capture the exact trace that shows the failure.
We found the “smoking gun” in the trace from 10:02:00 AM, which was triggered by t_shading_end_execution. This is the queued job that is supposed to actually move the blind.
Here is what happened in that trace:
t_shading_end_pending_3 trigger. This correctly queued an execution job by setting the "q" (queue) timestamp in the helper. My shading_waitingtime_end was set to 120 seconds.t_shading_end_execution (because now() was now past the queued timestamp).action/4/choose/4). Before moving the cover, it performs a crucial safety check (at action/4/choose/4/sequence/0/if) to see if the “end” conditions are still valid."result": false).The reason it failed is that in the 120 seconds between the “pending” trigger (the cloud) and the “execution” trigger (this trace), the sun came back out:
Azimuth > 210? → NO (it was 150.15).Brightness < 5000? → NO. The brightness was back up to 24136.3 lx.Because all “end” conditions were false at the moment of execution, the automation correctly aborted the cover.open_cover command.
Here is the logic flaw: After the automation aborted the job, it did not reset the helper state. The helper remained stuck with the "q" value, leaving it permanently in a “pending end” state (is_helper_shading_end: true).
This “frozen” state explains all the other traces I’ve seen:
t_shading_end_pending triggers (like the one at 13:06 for azimuth) also fail, because they see a job is already queued (is_helper_shading_end: true) and their logic is only to set the queue, not execute it.t_shading_end_execution trigger might run again, but it will fail the safety check every single time as long as the sun is out, leaving the helper stuck.The immediate fix for me was to drastically reduce the wait time.
I changed:
shading_waitingtime_end: 120
down to:
shading_waitingtime_end: 10
This closes the gap between when the cloud is detected and when the execution runs, preventing the sun from having time to come back out and cause the safety check to fail.
Long-term, it seems the blueprint logic should be updated: The else: path for the t_shading_end_execution branch (when the safety check fails) needs to update the helper to reset the queue ("q": 0) to clear the stuck state.
yes that could be, but its always a combination with azimuth/elevation and brightness, which stops the opening of the cover…if only one of them triggers the automation all is fine 
Did a couple of changes based on values I had with working instances, but still getting this error which I do not understand what value exactly is causing trouble. I also checked documentation and didn’t find anything there. Does anyone have a hint where to look at? Esp. since I did change the position values to the same ones like I have with working instances but here it refuses to run. I still get the
CCA Config issue: Please revise the position values and take the tolerance values into account. The values must not overlap - automation.flur_og_rollladen
message which I have trouble understanding and knowing where to look at and what I did wrong here which works with the other instances.
Thanks!
Is this perhaps a problem with the translation, or what is the issue? The description is quite clear. Your configuration of the positions and the tolerance overlap. See also the first two posts here in the thread.
Incidentally, it would be much easier if I didn’t have to guess and you showed me your configuration. 
Oh, I see you asked the question twice. Here I can see your configuration. And your shading position is identical to the default value for the close position.
It looks like you have activated the wrong option (lockout_tilted_closing).
I use Homematic actuators (BidCos and HmIP).
The question was already a few days old. Surely you now have traces of the misconduct, right?
Then there will be a trace for it and I can answer that for you. Manual control was detected at “GMT: Wednesday, 3 September 2025 17:53:09”. That is also the time when your roller blind was closed.
Your DriveTime is 90 seconds. That’s actually more than enough. Or how long does it take for HA to notice the change in position?
I think you’re misunderstanding something here. CCA relies on cover entities and correct integration into HA. It works with relative percentages rather than seconds.
But I think it’s great that you want to improve CCA. I welcome every pull request on GitHub.
Personal recommendation: Do not entrust your life to home automation.
If you must, then work with peerings in Homematic. Or bindings in Zigbee. Or associations in Z-Wave.
But don’t run it through software.
Trace, please.