Close/open curtain (cover, blinds) based on sun and weather

Blueprints Exchange
1

This opens the selected curtain when all of the configurable conditions are met:

  • Sun elevation above threshold
  • Sun azimuth (position on compass) in range
  • Temperature above threshold (prevent closing on cold days)
  • Weather is sunny or partly cloudy

When the first condition is not met any more, the cover is opened again. Opening will be skipped if it happens after a configured time to prevent opening cover at evening/night.

The closing position can be configured as well.

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

The source can be found here: Homeassistant blueprint to close/open covers depending on sun position and weather · GitHub

Credits: This was inspired by Manage cover with sun position (elevation and azimuth) so credits mostly to @mougeat !

7 Likes
2

Hi @daniel-sc,

Thanks for this. I have installed the blueprint and the var from hacs ad set up a boolean too.

Today I tested and got this:

Executed: 27 June 2023 at 5:28:08 pm
Result:

result: false

## conditions/0

Executed: 27 June 2023 at 5:28:08 pm
Result:

result: false

## conditions/0/conditions/0

Executed: 27 June 2023 at 5:28:08 pm

Error: In 'template' condition: TypeError: '>' not supported between instances of 'NoneType' and 'int'

## conditions/0/conditions/1

Executed: 27 June 2023 at 5:28:08 pm
Result:

result: false entities: - weather.tomorrow_io_sawa_home_daily

## conditions/1

Executed: 27 June 2023 at 5:28:08 pm
Result:

result: false

## conditions/1/conditions/0

Executed: 27 June 2023 at 5:28:08 pm

Error: In 'template' condition: TypeError: '<' not supported between instances of 'NoneType' and 'int'

## conditions/1/conditions/1

Executed: 27 June 2023 at 5:28:08 pm
Result:

result: true entities: []

And the automation stopped. Any ideas?

image

3

Maybe the position attribute of your curtain is not defined? You can check this in the template view by checking the result of {{ state_attr(“YOUR CURTAIN ID”, “position”) }}.

1 Like
4

Ok did the attribute test and got null when the curtain is open or closed. Yet in my curtain control I can see the percentage of opening.

When i check state of the entity, i have “current_position” with a value.

5

so I guess i have to replace “position” with “current_position” in the blueprint?

6

Its working! Thanks!!

7

@wgumaa thanks for the update! I’ll try to make this attribute configurable, in case other have the same issue!

1 Like
8

Thank you for the blueprint. Is it possible to add a function to use the temperature from a sensor/entity?

9

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?

10

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 :wink:

11

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.

12

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
13

Would it be easier to make a new blueprint with only the temp sensor ?

14

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

15

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
16

@Markus1995 actually I might need this myself :slight_smile:

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:

  1. Should actions during the configured (night) time be skipped or “delayed” until after the end time?
  2. 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?

17

I think your idea was the Best.

What do you mean with your second point?

18

@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?

19

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.

20

@Soulfly999 the latest blueprint version allows for selection of the “Temperature source”, which can be either a weather entity or a temperature device :slight_smile:

1 Like