This is a good idea! I’m not sure though, how to implement a selector that can use either the temperature from the weather service/entity or a thermostat, as they are different domains?
I would think either one or the other not both, did you that mean? I simple use a xiaomi tempereature sensor LYWSD03MMC with atc-firmware but the temperature between the weather service and sensor are mostly different 
Agree to some extent. The weather service I use “Tomorrow.io” seems accurate enough for my needs for this automation. I do have have 2 external sensors; one that measures air temperature and one is a thermometer mounted on the wall.
The problem with the thermometer is that during the morning its in the shade. In the afternoon its in direct sunlight and as it heats up from the sunlight, the readings are way above the real temperature.
So having the option to add a sensor would be good.
I think we all agree on the optimal solution from a user perspective: when configuring the blueprint we’d like an input “temperature source”, that offers a list off all temperature entities and all (available) weather entities from which the user could select one (either temp or weather).
For me it is not clear if this is technically possible. In case it is not, what feasible alternative solutions are there?
3 Likes
Would it be easier to make a new blueprint with only the temp sensor ?
I think separate blueprints would be possible, but are bad from a user perspective (need to change the blueprint when switching from sensor to weather…) and hard to maintain. But, of course, if someone else wants to give it a try, I’d be delighted.
In the meantime, I’ll see if someone has a good solution for the combined input: Blueprint input: select weather or temperature entity
Is it perhaps possible to extend the blueprint in such a way that an earliest time can be optionally set? E.g. for the bedroom that the roller shutters do not move before 8 a.m.
1 Like
@Markus1995 actually I might need this myself 
Something similar is already implemented for evenings, where a “open” action is skipped after a specific time. E.g. do not open the shutter when already at sleep.
To get it consistent and understandable, there are some decisions to be made:
- Should actions during the configured (night) time be skipped or “delayed” until after the end time?
- Should open and/or close actions be addressed?
My naïve idea would be “delayed + both open and close action” but I’m not sure this covers all/most use cases and is technically feasible. Thoughts?
I think your idea was the Best.
What do you mean with your second point?
@Markus1995 with the second point I mean: It is rather clear that during the configured night time one should only prevent “open” actions (as one does not want to have the curtain open while asleep). About “close”, I’m not so sure. One the one hand, one could say that this is OK, as it only keeps the room dark, on the other hand, one could be annoyed/waked by the motor moving. Does that make sense?
Now I understand it. I would block both directions of movement of the shutter. So that, as you said, it does not interfere during sleep.
@Soulfly999 the latest blueprint version allows for selection of the “Temperature source”, which can be either a weather entity or a temperature device
1 Like
Nice Blueprint, trank you!
What about the „regular“ open and close automations? Eg in the morning open and in the evening close.
What about open windows that prevent the cover from closing.
For the first I have a seperate automation wich controls the open/close logic and sets a binary helper for activating an deactivatig the automation for the sun protection.
Additionaly I have a second binary helper to control the sun protection in general. So there is just one switch to enable and disable.
@kreuzundkwer thanks for the feedback!
What about the „regular“ open and close automations? Eg in the morning open and in the evening close.
This should not interfere with this automation, as it is “stateless”, i.e. only closes, when all conditions are met and opens when the first condition is not met any more. Actions are idempotent, hence it should be no problem if the curtain already is set to the target position (through another automation or manually). Furthermore an additional configuration for a “night time” is currently in the making, this would block/defer all actions during a configured time, which should additionally help to assure no interference with another automation.
What about open windows that prevent the cover from closing.
This is not covered yet. Possible solutions that come to my mind:
- With a separate automation, you disable the automation from this blueprint depending on your sensor.
- We define an additional (optional) input for this blueprint, that selects a binary sensor and blocks/defers any action when it is “off” (on?) - analogous to the above described “night time”.
Any thoughts?
1 Like
Hi @daniel-sc !
Thanks for this great blueprint, I’ve been wanting to make something like this for some time now…
Unfortunately, I have an issue with my automation.
First to be sure there is an issue and not that I am doing something wrong please tell me what conditions have to be met for the cover/curtain open fully again after being closed to the target position?
I am asking this because I cannot get the automation to open the cover to 100% when sun goes down.
Thanks!
@dedabrane thanks for the feedback!
First, always when the cover is moved, it is either set to the target position (close) or to 100 (completely open).
For the open to happen, the automation needs to be triggered by one of its triggers (temperature change, sun change, …) and the current position (as reported by state_attr(curtain_entity_id, 'current_position')) must be smaller or equal the target position. Furthermore before the trigger all conditions for “close” (sun position, temperature, weather), had to be true - i.e. it only opens when the first condition switches to false.
Additionally (though probably obvious), there is one more relevant point: If the open would happen between the configured time for “Skip opening after this time” and midnight. (This is currently reworked, to defer the open in this case until after the night…).
From this one can conclude the following scenarios where an open is not happening:
- Manually running the automation
- Missing the first condition that violates the “close” state (e.g. ha is offline, …)
- The open would have happend between “Skip opening after this time” and midnight.
My scenario is: Another automation closed the curtain (eg 10pm). In the morning all conditions are met to set the curtian to the target position (eg 20%). In summer this could be at 7am, but I want the curtain not to open before 10am.
Otherwise, my target position is 0% (closed). All conditions are met, nothing happens. At 10am the other automation opens the curtain and I have no sun protection.
If you integrate a start and end time for the night, this would be a great solution.
Disableing and Enableing is possible but feels not so good. An optional binary input sounds good 
Also the possibility to configure night time with an external automation or configuration.
@daniel-sc thanks for the info.
So just to be sure I understand (sorry for being dumb), let’s say these are the settings in the automation:
Sun azimuth position start: 220
Sun azimuth position end: 300
Sun elevation to start: 60
Temperature threshold: 35
Closing position of curtain: 50
Skip opening after this time: 22:00:00
Weather conditions: sunny, partlycloudy
In the morning blinds position is at 100.
Sun reaches the start azimuth and elevation at about 14:00 and as it is summer the temperature on the selected sensor is well above 35.
Assuming all conditions are true the blinds should close to 50 at about 14:00 h.
So two questions now:
Do the blinds need to be closed by this automation, meaning does the automation need to be triggered in step 1 (close) for the open to work?
And second: given this situation above, what condition should change for the open action to be triggered?
Again, sorry for the dumb questions, I just want to be sure I tested the whole automation before saying something’s not working
Thanks!
Hi @dedabrane to answer your two questions:
No, the open does work even if another automation closed the blinds or when they were manually closed.
The open action will be triggered by any condition that changes - e.g. sun elevation < 60 or temperature < 35 or weather cloudy etc. Note that only the first changed condition triggers the action, so if e.g. at 15:00 the weather changes to cloudy, the open action is triggered. If afterwards at 15:10 the temperature drops to 30, there is no further open action (independently if the curtain was manually or by some other automation closed in the meantime!).
Hi @daniel-sc
Thanks for the answers, It’s clear now how it should work.
Now, I tested the automation today and here’s the result:
When sun position went over the set start positions the blinds closed as they should.
Unfortunately, I miscalculated the sun elevation at the time that blinds should open and the set value was higher than it should have been. Just for an example, I set the elevation value to 50 but at the aprox. time that blinds should open sun will be at 10, so the elevation threshold of < 50 was met a lot earlier.
So at the time the elevation became < 50 the blinds opened.
I suppose this is ok and by design meant to be this way.
But then in an attempt to correct the settings, I changed the elevation setting to 10 and closed the blinds manually to a position below the setting.
As the sun position changed to over the azimuth end setting and below the elevation setting I hopped that blinds would open again. Instead, nothing happened and automation trace shows that condition check failed.
Is this ok behavior?
If not, how can I check which condition did not pass?
If I look at step details there is now way I can recognize what failed…
Thanks!