Hi
I have an issue with the manual override:
Whenever the manual override is activated, it deactivates automatically after the set up time (30 mins in my case), however it reactivates automatically right after
See screenshot:
Please post issues related to the integration on the Github page: Issues · basbruss/adaptive-cover · GitHub
To understand what is happening you can provide some logs there with debugging on.
# add this to configuration.yaml to enable debug logging
logger:
default: "info"
logs:
custom_components.adaptive_cover: debug
Hi @iBims ,
I’ve the same problem, each 2/3 day I need to do a full open than a full close to “reset” the closing position.
Is a cover motor problem, in my situation the sunscreen cover aren’t horizontal but are “pivotting” at half height. When the cover is opening the cover motor is faster than is closing. This is depending by the cover weight, not by electronics or programming 
.
Have a nice day.
Have a nice day.
Does this automation work with raffstores (blinds that move up and down and also allows to set an angle for the fins/slats)? I tried the vertical cover but there are not options to configure the slats.
Do you mean the integration?
In the integration you can setup a service for the vertical and tilt movement separate for the same entity.
Ok will do!
thank you! Two services for one entity worked.
Hello team – in the old blueprint, I had the ability to define any condition of my choosing that needs to be met. I don’t think this is possible in the HACS integration anymore, is that correct?
I had a toggle that I could set via a physical button that would allow my wife to completely stop the automatic blind control for the remainder of the day.
That exists on the HACS integration as well. I have a “master” control that when toggled will go through and turn on/off the auto adjustments throughout the house.
The integration is pretty solid, it started a little shaky but has settled down now and works quite well.
Can’t believe it was right there and I just didn’t spot it 
Thank you!
So after fully transitioning from the blueprint to the integration, the one thing that still confuses me are the indoor low and high temperature thresholds, which didn’t exist in the blueprint. After some experimentation, I found out that, in order to disable indoor temps as a factor in controlling the blinds, I have to set the low temp slider to the lowest setting and the high temp slider to the highest setting. That seems to be the best way to ignore indoor temps altogether. Is that the correct way if I only want to have my blinds controlled by the position of the sun, not by any temperature factors?
If I am correct, it would perhaps be a useful enhancement to make these temperature settings optional, or at least set them to the aforementioned extreme values by default, so as to being ignored by default.
P.S.: I do need the climate settings enabled as I also want to only have my blinds controlled when it’s sunny or partially cloudy.
I guess you are overcomplicating things. The normal mode is quite similar to the blueprint. The climate mode you have enabled is not and works with advanced features and is aimed at indoor climate control.
To only control the blinds by certain weather states you can automate the toggle control switch based on the current condition, no need to hack around with parameters settings that could eventually do things differently than expected. This can all be done without using the climate mode.
I suppose that’s one way to do it, but why not separate the Climate and Weather controls and allow one to use the Weather controls independent of the Climate controls?
Because we can ask that for every additional condition/parameter/threshold.
The normal mode is just for giving the basic calculations values in a sort of raw way, so you can set it fully to your liking by controlling and automating with the help of the provided entities.
It’s re-creating the wheel for a small audience that might not need it. It’s very simple to write a script or template that acts on a click and instantly enables/disabled every Adaptive Cover toggle - that same system is then even easier to bake into your automation for using it however you want rather than being pigeonholed into whatever Bas put into the system.
I have all kinds of automation for my Adaptive Covers that just toggle that for temperature, cloud cover, desire, time of day. Quite honestly the best sensor in the extension is the “In Sun” sensor, once you know that you can almost ignore everything else (although I do use it as designed).
How am I supposed to align the compass when trying to find out my window’s Azimuth on osmcompass.com/?
I drew you the window in the picture from the first post.
The blue line is your window, you’re standing where the degrees are and look through the blue line on the street.
For your window, you’d need to bring “my blue line” parallel to the glass.
Sorry, not a graphics genius, and using a trackball didn’t help either… 
Hi @basbrus still using your integration and happy with it. Along the way I started using it not only for my venetian blinds (I just toggle the Auto switch when closed / opened accordingly, thats all).
Now I am going to use my vertical blinds as well for the other windows - but only when there is sun and an acceptable amount of wind. Currently I a simulating the weather and once it works good, I will use a weather station for that.
I got some points where I am not sure if I am using it wrong or there might be an issue:
For the vertical blinds, when the Auto button is on but no sun in front of the windows it seems that every minute or so the actor is triggered even there is no movement. There is a “click-click” from the actor and looking into HASS confirms that as the “last seen” from the actor updates every minute, sometimes multiple times per minute. On all other actors (same type, version etc) it updates approximately hourly. Are the target position values overwritten even though there is no change? I think this will not be good for the actors in the long run
I do not get how the “Sun in front” and Start and End time sensors differ. For my Venetian blinds the time is approximately the same (± 5min). For the vertical blinds they differ around 2 hrs. Did I get it right that all three sensor should be consistent, or is start and end based on other/less/more calculations than Sun infront, e.g. that one is considering the field of view and offsets and the other doesn’t?
I found this Blueprint and reading the description, I could not find an answer for my conditions.
I need an automation for sunscreens which incorporates the following conditions:
You should ask in the thread for the blueprint, I’m quite sure you’d get a more appropriate response.
I know, this isn’t exactly clear on a first glance, but this very thread has grown from blueprint to integration, and if I’m not mistaken, the blueprint got its own thread. 
Take a look here:
Btw. I personally can’t say if your questions are possible or not, sorry!
