This feature will be included in the next version.
1 Like
Of course, this varies from person to person and also depends on how you’ve organized your configuration.
I use packages and different directories for the entities.
If you already have a template trigger sensor, feel free to adapt the code example to your version.
This was a display issue in the Trace Analyzer — all 7 conditions are calculated internally (showing true as a bypass when no sensor is configured), but the Trace Analyzer couldn’t distinguish “not configured” from “condition met.” The next blueprint update adds shading_start_conditions_active, which the Trace Analyzer uses to correctly label non-configured conditions. Your automation was working correctly the whole time.
The trace captures sensor values at the exact moment the automation ran, not your current live values. Please compare the sensor values shown inside the trace with the thresholds, not today’s live readings. If you’re using the Trace Analyzer, the new version will also clearly show which conditions were actively configured vs. which ones were bypassed as “not configured.”
Yes, in theory I’d need more information, as described in the FAQ. But you’d be better off waiting for the new version, which will be released in a few days. I’m quite confident about this.
I’ve been a bit quieter in this thread over the past few months. There was a reason for that. I’ve redesigned the logic and priorities in the Blueprint. I’ve now implemented multiple levels with different priorities.
The JSON Cover Status Helper will become mandatory. And I’m storing all levels in the helper.
Why am I saying this?
Because it makes it easier and more stable to control when CCA should move to which position.
Please wait until the next release. I won’t be fixing the current code anyway. I’ve been working in a different direction for three months now.
┌─────────────────────────────────────────────────────────────────┐
│ Layer 1: FORCE │
│ ├─ force != "none" → return force state │
│ ├─ Examples: Rain protection, wind protection, frost │
│ └─ Variable: state_force │
├─────────────────────────────────────────────────────────────────┤
│ Layer 2: LOCKOUT │
│ ├─ window == "open" → return "lock" (100% open) │
│ ├─ Purpose: Prevent closing on open windows │
│ └─ Variable: state_window == "open" │
├─────────────────────────────────────────────────────────────────┤
│ Layer 3: VENTILATION │
│ ├─ window == "tilted" AND allow_ventilate → return "vent" │
│ ├─ Purpose: Allow air flow through tilted windows │
│ └─ Variable: state_window == "tilted" + resident_allow_vent │
├─────────────────────────────────────────────────────────────────┤
│ Layer 4: PRIVACY │
│ ├─ resident == 1 AND closing_trigger → return "close" │
│ ├─ Purpose: Privacy / darkness when resident is sleeping │
│ └─ Variable: state_resident + resident_closing_enabled │
├─────────────────────────────────────────────────────────────────┤
│ Layer 5: SHADING │
│ ├─ shade == true AND allow_shade → return "shade" │
│ ├─ Purpose: Sun protection during hot periods │
│ └─ Variable: state_shade + resident_allow_shading │
├─────────────────────────────────────────────────────────────────┤
│ Layer 6: BASE │
│ ├─ return base ("open" or "close") │
│ ├─ Purpose: Time-based schedule (morning/evening) │
│ └─ Variable: state_base + resident_allow_opening (for "open") │
└─────────────────────────────────────────────────────────────────┘
3 Likes
Hi,
i am very impressed by the Automation. But one question. Why is my shading not ending and the shutter going up?
I thought if one condition is not met in the set time shading is ending and the cover is going up. But my covers coming down exactly with the set conditions, but never going up again.
Unfortunately, my crystal ball is currently being cleaned. 
(sorry)
To answer that, I’d need a little more information.
Please take a look at the FAQ. There you’ll see what information you can provide when submitting a support request.
Oh, I’m very excited to see when the new version will be released.
1 Like
I’ve focused less on features and more on bulletproofing. I’ve tested a wide variety of scenarios myself using virtual cover devices.
All that’s left is to make the decision to release it and finalize the documentation.
I’ve taken another week off and need to get a handle on the outstanding issues.
3 Likes
Hello,
I just started with CCA and managed to setup the time controlled settings for two covers.
The next thing would be sun protection for one of the covers. How do I achieve different positions for different sun azimuths? E.g. azimuth 186° cover position 60%, azimuth 207° cover position 38% etc.
Is this possible?
CU
Jens
As already mentioned, even sensors which are not configured are shown in the conditions. But there seems to be another bug:
The analyzer shows that the only OR condition is the weather forecast.
Which isnt true, as you can see at the bottom under "shading conditions:
The the information shown on second screenshot matches my config.
btw, nice tool! Makes things a lot easier.
So I live in South Africa around 25 degrees south latitude, it can get pretty hot here during the day. Our way of thinking about blinds is a bit different from shall I say the European way 
We typically close blinds when the sun shines directly into the home (to keep the home cool in the summer), and close when the sun does not.
So… while the normal CCA automation as shown above is to open in the morning and close in the evening, the way I need to use blinds is probably the exact opposite.
Would this be possible using CCA?
I have the same case, is there some usefull function? Regards Chris
check out the “sun protection part” this is based on the sun parameters! This should do the think you are looking for!
Otherwise yo also can close the covers in the morning and open them in the evening
Brightness Hysteresis – redundant when Start/End are separate values?
quick question about the shading brightness config:
We already have separate Start (e.g. 35000 lx) and End (e.g. 25000 lx) values, which by themselves create a 10000 lx dead band. Adding a Hysteresis on top just widens that band further.
For the temperature sensors the hysteresis clearly makes sense – they only have a single threshold. But for brightness with two thresholds, the hysteresis feels redundant.
Is there a use case I’m missing, or could this parameter be removed for the brightness case?
Thanks!