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).
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?
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!
By now I didn’t have a closer look at the blueprint, maybe it does things I’d like to have, but I need some input for understanding how to deal with things.
The sun reaches a point (azimuth/elevation/whatever) at a given time. This time can be calculated, as the sun does not move unexpectedly.
To make the movement of blinds predictable to the users, it makes sense to show the time some movement will happen to the users (and maybe even editable so one could shift it as wanted).
This also is expected to lower CPU usage. You need only a trigger at that time, instead of watching every minute (“Did the sun arrive at the point? Oh, it will be there in 5 hours? Fine, I’ll check again next minute, can’t expect it.”).
I’m searching how to get that time. You don’t calculate/use/expose that time already somewhere?
This is not really a concern. The blueprint uses the information about the sun’s position from the sun.sun entity which is already throttled by itself and are not stopped by not using the blueprint. You can look into the Sun component in HA core to see more details on how the throttling works.
The blueprints only outputs the calculated best position for your blinds, so no time or something.
The integration on the otherhand provides you with two entities with the start and end time when the sun enters and leaves the field of view of your window calculated on a 5 minute interval to reduce the amount of calculations.
Hoi @langestefan . Have you considered adding a function for an Awning? I’ve got the formula to calculate required extension (horizontal awning), just tossing up whether to add to this Repo, or to create a new Repo.
There is horizontal awning available, you can select it and it works quite good in my experience.
What’s missing from my point of view ist the roof windows that can be managed as an horizontal awning with 45° angle, but does not consider that the window is on a roof and the sun still reaches the windows and thus is “in front” even if the sun is already “behind it” based on the calculation (but in reality is still somewhere above the roof)
. The backlog seems to be very long and timely perhaps due to the new updates released for HACS recently.