hey, @Herr.Vorragend another person coming over from “Adaptive Cover”. The Blue print Looks amazing. From quickly playing with it the main thing i can’t work out is the shading settings. does it have the ability to set shading distance similar to how adaptive cover works so that i keep and area of my room in the shade at all times?
my use case is i have a Leather Sofa that is in a bright room so i aim to keep the sun off it as much as possible. is this possible or would that require some adjustments to the blue print? (if so im happy to added as a request on Github
currently it seems the blueprint only decides if shading should be on/off based on your values and then drives the cover to the set shading position + if cover has tilt, it will drive the tilt to one of the set positions based on current sun elevation.
Adaptive Cover had more advanced solutions here but was therefore not really reliable and constantly adjusted everything when not even necessary.
This is still an amazing Blueprint.
But this morning I was wondering why a cover was closed at sunrise and not opened. Maybe someone has a short explanation.
How should this be configured with a tilt-only cover that only supports actions like open_cover_tilt, and NOT actions like open_cover? I can get it to work by adding these commands to the additional actions section, but ideally I’d like it to just use tilt commands instead of the regular commands for the standard open/close actions.
Hoping there’s a way to do this and I just missed it. This blueprint seems super powerful but also a bit of a UX nightmare.
Since the newer Versions, my shutter doesn’t open immeriately If resident sensor gets off in the morning if it should be open. Other shutters in the house without Resident sensor Open normally.
Tomorrow I can send a trace. Someone else with that Problem?
Hello Herr.Vorragend, another great achievement with the new version of the blueprint! Is it perhaps possible to also set the values for open position and closed position alternatively via a template sensor? This would allow for flexible positions, such as a different closed position in winter with airflow to the windowsill to prevent freezing.
Q: Can I use CCA with covers that don’t have current_position?
A: Yes! Since version 2025.12.22, CCA supports alternative position sources:
Position Source Options:
Standard current_position (default) - Most covers use this
Alternative position attribute - Some integrations use this instead
Custom position sensor - Use any external sensor
Hi I don’t have any info from Motionblinds integration with my covers. As far I know, only action allowed are open.cover close.cover stop.cover.
How choosing between 2 and 3, it’s not clear to me.
thank you,
However, I have a problem:
I’m using Aqara (open/closed) and Shelly window/door sensors (open/closed/tilted).
When I open windows or doors, the blinds open.
When I close the windows or doors, the blinds don’t close.
What am I doing wrong?
I use Fixed Delay for exactly this purpose. I have about 20 CCA automations that control Homematic blinds. They are triggered simultaneously, of course, but there is a delay before execution.
Regarding your question about positions:
Yes, the positions within a roller blind must be unique. I don’t care about tilt. But shading, open, close, and ventilation must be different. That’s also what it says in the FAQ.
But I don’t see any problem here. Why would these statuses have identical values for you?
In this regard, CCA takes a completely different and much simpler approach. The usual algorithms are great, but they are not part of CCA. I always liked that about the Adaptive Cover approach. I also considered whether I could benefit from their calculations.
There are already similar requests for this on GitHub. I just don’t know if I should implement it. Or when.
Running an open source project is hard work and sometimes ties up even the last remaining free resources.
I see that Adaptive Cover hasn’t changed since the summer. I don’t think that’s really a bad thing. The developer’s absence is certainly well-founded. And when I see the rate at which issues are being created there, I understand a possible break all too well.
Just wait and see. It will definitely continue at some point. Otherwise, there are also forks that you could try out. Ultimately, everything could be merged again later.
According to CCA Trace Analyzer, your roller blind was moved to the shading position when it was actually opened in the morning. This is because a valid shading request was detected at your location at/around GMT Thursday, January 15, 2026, 07:25:16, but it was not yet permitted to be executed.
I am always open to suggestions for improvement. Of course, taking into account a high level of backward compatibility. You want individuality, which then also entails many input options. I am already happy that HA finally has sections.
You could help me here by showing me a trace. This probably has something to do with brightness/sun position. I made some changes here.
If you don’t have a trace yet, show me your configuration and tell me what the environmental conditions were like at the time of the status change.
Now we have these new options, and you really can’t use any of them? And you’re sure that MotionBlinds doesn’t have any position values?
Then there’s not much we can do.
Personally, I would replace the hardware immediately. Or you could just live with the Open+Close statuses and a very simple automation. Then you wouldn’t need CCA either.
Thanks for the reply! I see but somehow it didn’t work with fixed delay for me (maybe I have to play around more with it) but did it with random delay of 1min now.
Ok I have unique values now and everything works fine.
Example would be for Ventilation - I would prefer the cover to stay closed at 0% and only open the tilt to 35% but 0% is already closed position so I use 5% for ventilation and that’s also fine.
Btw. thanks for fixing the force action helper bug
Oh yes. I almost forgot to mention this in the forum. I fixed that a few days ago.
CCA 2026.01.14 - Force State Preservation Fix
Fixed force operations incorrectly updating helper status (#318): Force operations (force-open, force-close, force-ventilate, force-shading) now preserve the background helper state instead of updating it.
I’m also interested in this feature. But usability must also be maintained somehow.
CCA 2026.01.14 - Force State Preservation Fix