This was very helpful and confirms me in the current conversion of the blueprint.
Do you use the Cover Status Helper?
Can you show me the history of such a day? I probably don’t need traces for this. Because I can understand your assumption - at least in my head.
Regarding the blueprint conversion:
I would like to run a kind of background process that writes the target position to the helper. I can then use this when executing the individual actions to know where it should go.
Yes, I use a Status Helper. As far as I remember that one looked normal (meaning that it had just "open=true, all the rest false; but I might not understand everything in it in detail 
)
Regarding the history of such a day … I’ll check if/how I can access that and come back …
Not quite sure if this is what was intended to have/see, but it shows pretty much what happens:
At 7:10 while the shutter is still closed I open the window and the CCA goes to to venting. Wenn I close the window at 7:46 it goes back to its previos state closed. Then at 8:00 the timer triggers the regular open. And then nothing happens regarding shading, even though at that time azimuth/level are above 85/15, the brightness is already way above 35000lx and the indoor temperature above 23.6 and the forecast temperature and weather condition for the day are also matching. I then trigger the shading manually by switching on the helper for forced shading at 8:42. And that stays until 13:53 when the sun moves to the other side and the brightness goes down and triggers the end of the shading.
CCA Schlafzimmerfenster ausgelöst durch Zustand von Schlafzimmerfenster
13:54:25 - Vorgestern
CCA Cover Status Helper SZ wechselte zu {"open":{"a":true,"t":1715773988},"close":{"a":false,"t":1715751992},"ventilate":{"a":false,"t":1715749847},"shading":{"a":false,"t":1715755337},"locked":{"a":false,"t":0},"manual":{"a":false,"t":1715452789},"p":30,"v":4,"t":1715773988} ausgelöst durch Automatisierung CCA Schlafzimmerfenster Helligkeitssensor vorne Durchschnittliche Beleuchtungsstärke via template
13:53:08 - Vorgestern
CCA Schlafzimmerfenster Helligkeitssensor vorne Durchschnittliche Beleuchtungsstärke via template
13:38:05 - Vorgestern
CCA Schlafzimmerfenster ausgelöst durch Zeit change or manual update via template
09:00:00 - Vorgestern
CCA Schlafzimmerfenster ausgelöst durch Zustand von Schlafzimmerfenster
08:43:30 - Vorgestern
CCA Cover Status Helper SZ wechselte zu {"open":{"a":false,"t":1715752807},"close":{"a":false,"t":1715751992},"ventilate":{"a":false,"t":1715749847},"shading":{"a":true,"t":1715755337},"locked":{"a":false,"t":0},"manual":{"a":false,"t":1715452789},"p":100,"v":4,"t":1715755337} ausgelöst durch Automatisierung CCA Schlafzimmerfenster ausgelöst durch Zustand von CCA ShadeIt SZ
08:42:17 - Vorgestern
CCA Schlafzimmerfenster ausgelöst durch Zustand von CCA ShadeIt SZ
08:42:14 - Vorgestern
CCA Schlafzimmerfenster ausgelöst durch Zustand von Schlafzimmerfenster
08:01:29 - Vorgestern
CCA Cover Status Helper SZ wechselte zu {"open":{"a":true,"t":1715752807},"close":{"a":false,"t":1715751992},"ventilate":{"a":false,"t":1715749847},"shading":{"a":false,"t":1715666727},"locked":{"a":false,"t":0},"manual":{"a":false,"t":1715452789},"p":0,"v":4,"t":1715752807} ausgelöst durch Automatisierung CCA Schlafzimmerfenster ausgelöst durch Zeit change or manual update via template
08:00:06 - Vorgestern
CCA Schlafzimmerfenster ausgelöst durch Zeit change or manual update via template
08:00:00 - Vorgestern
CCA Schlafzimmerfenster ausgelöst durch Zustand von Schlafzimmerfenster
07:47:49 - Vorgestern
CCA Cover Status Helper SZ wechselte zu {"open":{"a":false,"t":1715686390},"close":{"a":true,"t":1715751992},"ventilate":{"a":false,"t":1715749847},"shading":{"a":false,"t":1715666727},"locked":{"a":false,"t":0},"manual":{"a":false,"t":1715452789},"p":80,"v":4,"t":1715751992} ausgelöst durch Automatisierung CCA Schlafzimmerfenster Schlafzimmerfensterkontakt via template
07:46:32 - Vorgestern
CCA Schlafzimmerfenster Schlafzimmerfensterkontakt via template
07:46:26 - Vorgestern
CCA Schlafzimmerfenster Sun via template
07:33:30 - Vorgestern
CCA Schlafzimmerfenster ausgelöst durch Zustand von Schlafzimmerfenster
07:12:04 - Vorgestern
CCA Cover Status Helper SZ wechselte zu {"open":{"a":false,"t":1715686390},"close":{"a":false,"t":1715721186},"ventilate":{"a":true,"t":1715749847},"shading":{"a":false,"t":1715666727},"locked":{"a":false,"t":0},"manual":{"a":false,"t":1715452789},"p":0,"v":4,"t":1715749847} ausgelöst durch Automatisierung CCA Schlafzimmerfenster Schlafzimmerfensterkontakt via template
07:10:47 - Vorgestern
CCA Schlafzimmerfenster Schlafzimmerfensterkontakt via template
07:10:45 - Vorgestern
I can confirm, the auto_shading_start_force does not trigger anything while auto_ventilate_force works as intended with Version 2024.05.15-02 of CCA.
Setting the input_boolean to true is not even shown in the traces.
@Herr.Vorragend
In the code at github starting at line 3108 we can see
############################################################
# ANCHOR: FORCE SHADING START
############################################################
- alias: "Forced activating of the sun shading"
conditions:
- condition: trigger
id: "t_si_force"
- "{{ auto_shading_start_force != [] and is_state(auto_shading_start_force, ['true', 'on']) }}"
but at the triggers starting at line 1786
########################################
# Triggers for shading start
########################################
- platform: template # Mandatory and optional triggers
value_template: >-
{{
is_shading_enabled and
default_sun_sensor != [] and
state_attr(default_sun_sensor, 'azimuth') | float(default=shading_azimuth_start) > shading_azimuth_start and
state_attr(default_sun_sensor, 'azimuth') | float(default=shading_azimuth_end) < shading_azimuth_end and
state_attr(default_sun_sensor, 'elevation') | float(default=shading_elevation_min) > shading_elevation_min and
(shading_brightness_sensor == [] or states(shading_brightness_sensor) | float(default=shading_sun_brightness_start) > shading_sun_brightness_start) and
(shading_temperatur_sensor1 == [] or states(shading_temperatur_sensor1) | float(default=shading_min_temperatur1) > shading_min_temperatur1) and
(shading_temperatur_sensor2 == [] or states(shading_temperatur_sensor2) | float(default=shading_min_temperatur2) > shading_min_temperatur2)
}}
for: "00:00:05"
id: "t_si_1"
- platform: state
entity_id: !input shading_forecast_sensor
to: # Trigger on all state changes, but not attributes
id: "t_si_2"
is maybe something missing like
- platform: state
entity_id: !input auto_shading_start_force
from: "off"
to: "on"
id: "t_si_force"
?
Absolutely right. Thank you very much.
It doesn’t work without a trigger.
I will fix that.
I have a question for you all.
The force function is supposed to force the roller blind into a state. For all other automatic functions, however, I also check whether there is a force status. The roller blind therefore remains in this one forced state.
So if you want any other action to happen afterwards, you have to reset the entity that created the force state.
Should it stay like this?
Or should I remove the other conditions everywhere so that a force can be overridden by, for example, daily closing?
I find this strange, as there is still a current force in some entity. It is not an event or a one-off thing, but a consciously decided state. A status that remains until it is reset.
Your opinion?
I would like to leave it as it is.
I think it makes more sense that way, anyway.
If one wants the automatic again, one just need to reset the boolean to false.
But if it stays true one can really keep a forced state with that, which would otherwise not possible.
And if you never need that and want the automatic take over always again, then you can easily automate the reset of the force switch with the “execute after xxxx” hooks of the CCA.
@Herr.Vorragend
Somehow the automatic opening and closing in combination with brightness sensors no longer works properly or not at all.
My earliest opening time on working days is 5:30 a.m. and the default brightness in my office is 180lx (Brightness Value For Opening The Cover). Today the blind was opened at 5:30 but the brightness on the sensor was 18lx at that time.
Same behavior last night on another blind. It was 28lx and the value for closing (Brightness Value For Closing The Cover) is 25. The blind was closed at Time For Drive Down - Late On Non-Workdays.
I am relatively sure that it has worked before with exactly this configuration.
Or am I misunderstanding the points and it was just a coincidence that it has worked before?
Brightness is not used in my config, but is part of the trace. Some traces from this morning, where shading was not executed although conditions were met. Please consider i have shellys 
No offense meant, but it would be really great if you could learn to read the traces in the GUI. Sorry. 
The abort occurred because your weather conditions “pouring” was not configured.
I am not currently aware of anything that should cause this.
You know this from the thread here by now: Show me a trace and I’ll try to help. But I can’t do anything without any information. Sorry.
would it be possible to change the weather forcast sensor from daily forcast to hourly forcast with an additional number field to select the forcast value. (select 2 for 2 hour forcast!)
I ask, because the last days it was mostly sunny only in the evening and night fully cloudy, same today, and the daaily forcast sais cloudy, so the covers didn’t close!!
And can you have a look at this trace: 600d90d9 - no forcastsensor, but stops there
After the cover didn’t close today, because of the forcast sensor, i eliminated him from the automation. After reloding i started it manually but nothing happens. It stops at the forcast condition! But it shouldn’t
Sorry, was this morning when rushing to work, but true point: i need to investigate for myself. I’m sharing these traces to just give some insights in use-cases and how it works.
What do you mean with “wether conditions pouring” was not configured ? Can you translate please ? Thank you!
In this case, the blind was not raised based on the brightness, but on the height of the sun. Your value of 0 was already exceeded.
current_sun_elevation = 0.37
sun_elevation_up = 0
Your weather sensor has returned the value “pouring”. According to your configuration, this value was not allowed for shading. That’s right.
It’s not because of CCA, but because of your weather forecast.
Thank you for the hint!
I use the force-close, force-open, force-shading and force-ventilation states as a trigger/button to bring the covers to the desired state. I have an automation that resets these entities after a second back to “off” and it would be logic for me, that the covers will stay at the forced position until another condition will request another position.
OK, my opinion: I currently do not use forces. There is no reason to use forces for me, if the automation works as I want.
Because of you are asking. A force for me should be something, that brings the covers to a specific position once. Therefore, if another condition became true, the forced position should be overwritten by the automation.
A workaround to meet both szenarios could be, to set a force-timer. So I would be able to define for myselve, how long a force should be valid.
The forced position should of course not indefinetely stay, but should it really do that unconditionally, respectively really overwrite the “true” state of the force switch entity?
I wonder why it should do that. If I don’t want the automation to stay in the forced position when another action gets triggered (ie. timer based closing) I just need to reset the switch entity to “false” (possibly immediately after reaching the forced position or with a timer based helper or …). That doesn’t trigger an immediate action but removes the condition that keeps the forced position and the regular automatic takes over again. But if I really want it locked in the forced position I can keep the force entity on “true” as long as I need it.