How to automate my awning (sunscreen)

Interesting thread. Thanks for sharing. I will keep monitoring it, as it is still an ongoing discussion.

Is your wind sensor also an RFXCOM?

I have the problem where my backyard is facing east. So when the sun comes up the initial beams of light are too bright on a sunny day that we usually want to block those with the awning.

The problem is detecting this is happening. I have tried many things but nothing seems to work properly.

Until recently I used DarkSky, but since it’s discontinuing I switched to OpenWeatherMap. DarkSky had a pretty reliable cloud forecast. Based on that I could determine if it’s going to be sunny or not. It was not perfect, but it worked 80% of the time.
Now with the switch to OpenWeatherMap, I found that the forecast is very volatility and unusable. Other weather sources like WeatherBit are also unreliable.

I can’t use the irradiation of Buienradar since that would potentially give false positives on cloudy days (if I set the threshold too low). I am fiddling with time and a combination of irradiation so for example if its before 08:00 I check if the value is higher than 75, if it’s between 8 and 9 I check for a value of 225, it it’s later I check for 350. But even if I find the ‘sweet spot’ now, I don’t know how this will work in the spring or in the middle of the summer, since the sunrise time changes with the seasons.

The struggle is real.

I got myself an Aqara light sensor and put that in the windowsill. Is that perhaps an easier solution for your problem?

I am already in the process of testing with a motion sensor. It has the flaw of only reporting the light level when there is motion. But I think you are right and that this is a very nice way to determine if it’s too bright.

I did not know about these stand alone light sensors. I just ordered one. Thanks for the tip!

I have shared a template sensor here that might be helpful:
https://community.home-assistant.io/t/incident-angle-of-sunlight/444646

It calculates how perpendicular the sun is compared to your window, this may be useful in deciding how far to lower your suncreen.

1 Like

Hello Emphyrio,
You manual-control-button (‘Handbediening’) looks very nice, something I also need for my awning.
Could you explain of share this manual-control-button (‘Handbediening’)?
Thanks in advance!

Hi Jarno, I’m not sure what part you are interested in, there’s multiple parts to make it work. Here is the Lovelace YAML for the popup from the screenshot. If you need something else, please let me know.

action: fire-dom-event
browser_mod:
  service: browser_mod.popup
  data:
    title: 'Zonnescherm'
    style: |
      --popup-background-color: rgba(0, 0, 0, 0.8);
      --popup-padding-x: 0px;
      --popup-padding-y: 8px;
    browser_id: THIS
    content:
      type: vertical-stack
      cards:
      - type: horizontal-stack
        cards:
        - !include ../includes/blank-card.yaml
        - type: custom:button-card
          template: slider_cover
          entity: cover.patiocover_manual
          variables:
            slider_entity: "cover.patiocover_manual"
            naam: "Uitval"
        - !include ../includes/blank-card.yaml
      - type: horizontal-stack
        cards:
        - !include ../includes/blank-card.yaml
        - type: custom:button-card
          template: header
          name: 'Handbediening gedurende:'
          styles:
            name:
            - padding-left: 10px
        - !include ../includes/blank-card.yaml
      - type: horizontal-stack
        cards:
        - !include ../includes/blank-card.yaml
        - type: custom:button-card
          template: timer_hours
          entity: input_datetime.patiocover_manual_endtime
          variables:
            duration_minutes: 60
          label: '1 uur'
        - type: custom:button-card
          template: timer_hours
          entity: input_datetime.patiocover_manual_endtime
          variables:
            duration_minutes: 120
          label: '2 uur'
        - type: custom:button-card
          template: timer_hours
          entity: input_datetime.patiocover_manual_endtime
          variables:
            duration_minutes: 240
          label: '4 uur'
        - type: custom:button-card
          template: timer_hours
          entity: input_datetime.patiocover_manual_endtime
          variables:
            duration_minutes: 720
          label: '12 uur'
        - type: custom:button-card
          template: timer_hours
          entity: input_boolean.patiocover_manual_control
          label: 'Uit'
          tap_action:
            action: call-service
            service: script.patiocover_stop_manual
        - !include ../includes/blank-card.yaml
1 Like

I see a lot of redundancies in most of the automations of you guys. Like for example, why would you want to trigger your awning to open, based on that the sun is up, when a condition is that there needs to be at least 300 irradiance. I mean, why not just trigger it on irradiance > 300 to begin with, which is going to mean the sun is up and shining bright, combine that with inside temperatures, rain and wind sensors and you’re there.

@TheNr1Guest I see your struggles with this, why not do it like I said above?

Hello @Emphyrio ,

I’m very interested in your complete automation,

*Which card did you use for your awning? (manual control)

*How did you implement the times in your awning automation?
Did you have to install anything special for this? (add-ons, hacs, etc.)

*What do you mean by - !include …/includes/blank-card.yaml

*I am especially concerned about the part "manual operation during 1, 2, 4, 12 and off)

I could use this section in another automation.
Would you like to share these automations and cards?

I hope it’s not too many questions.
I am a newbee and I can still learn a lot from it.

Regards,
Henk

This is already what I’m doing. My problem lies in the need for a predictive behavior. “Will it be a hot and sunny day?” that you can ask at 1 AM in the night instead of “Is it hot and sunny now?”. I want my awnings to extend early in the morning because this will give my house better protection from the heat of the sun.

If I check at 6 AM the irradiance of Buienradar, it will be much lower than 350. That will only happen hours later. Too late for my need.

I managed to get a very nice behavior when using a light sensor that I put at the window where the awning will extend:

- name: Awning Sunny
  state: >-
    {% if is_state('cover.backyard_awning', 'closed') %}
      {{
        states('sensor.living_room_light_sensor') | int(0) > 3500 or
        states('sensor.buienradar_irradiance) | int(0) > 350
      }}
    {% else %}
      {% if now() < today_at('12:00') %}
        true
      {% else %}
        {{ states('sensor.buienradar_irradiance') | int(0) > 350 }}
      {% endif %}
    {% endif  %}
  icon: mdi:sun-wireless
  delay_off:
    minutes: 30

Granted this is still not a predictive behavior since I am still acting on the current state. But the current state is good enough that my awning extends pretty early in the morning and stays extended the rest of the day. There are more sensors at work here, this is just the sun part.

So when my awning is closed, I check the light sensor. This usually triggers it to open. I fiddled around with the 3500 value, but this works good enough for me.
If it extends in the morning, I don’t want it to close due to it being not sunny. This can happen because the awning will block the light sensor. This will then measure a possible value lower than 3500. Later in the day, even with the awning extended this value will be higher on a sunny day and then I can rely on Buienradar.

Hi @henkhoekema These are some custom Lovelace things that you are asking about. Years ago, I set up my Lovelace dashboards inspired by Homekit Infused. For this part with the awning, choosing a ‘manual time’, I am not using a ready made card. It is all configured using custom-button-card in a pop-up. The pop-up uses browser_mod.

So essentially:

  • There is a helper called ‘input_datetime.patiocover_manual_endtime’.
  • The buttons you see for '1 hour, ‘2 hours’, ‘4 hours’ etc. are custom buttons, with a tap_action:
  tap_action:
    action: call-service
    service: script.patiocover_manual_endtime
    service_data:
      duration_minutes: 60   # or 120 of 480 etc
  • That calls a script:
patiocover_manual_endtime:
  alias: 'Terrasscherm eindtijd bepalen'
  sequence:
  - service: input_datetime.set_datetime
    entity_id: input_datetime.patiocover_manual_endtime
    data:
      datetime: "{{ (as_timestamp(now()) + duration_minutes|int(default=0) *60) | timestamp_custom('%Y-%m-%d %H:%M:%S', true) }}"
  - service: input_boolean.turn_on
    entity_id: input_boolean.patiocover_manual_control
  - service: browser_mod.close_popup
  • Notice the other helper called ‘input_boolean.patiocover_manual_control’, which controls overall if the manual control override is active.
  • Then there is an automation to disable manual control at the endtime:
- alias: 'Terrasscherm handbediening uit'
  trigger:
    - platform: template
      value_template: "{{ states('sensor.time') == state_attr('input_datetime.patiocover_manual_endtime','timestamp')| timestamp_custom('%H:%M', True) }}"
    - platform: time
      at: "00:00:00"
  action:
    - service: input_boolean.turn_off
      entity_id: input_boolean.patiocover_manual_control
  • The input_boolean is simply used as a condition in the automation for rolling out the awning. It prevents rolling out the awning when manual control is active.

I hope this information helps you in your endeavours :wink:

I have uploaded my code to:

I hope that other people could have use it.

3 Likes

related: How to automate based on weather temperature forcast for current day? - #34 by bbccdd

Hello Emphyrio,
Thank you very mutch!! I will try it out
Greetings

Hello Emphyro,

I managed to implement it in my project.

Thank you.

I created a automation and lovelace card for controling my awning/sunscreen,
I hope that I can help and inspire others: GitHub - remb0/Sunscreen: Sunscreen-Awning project

I also have a wishlist with things like: actionable notifications, blueprint, shutter integration and other improvements.

1 Like

Hi Remco, i am still pretty new to HA and yaml and one potential template before this one I could “avoid” to let my desired values bounce over MQTT (ok, perhaps not the best solution :rofl:) . When I tried to implement your example I had some problems to implement your sunscreen.yaml file. After I added to my configuration.yaml file the line:

template: !include template.yaml

the syntax was a bit different than your file but is working for me. Below showing only the first lines:

- sensor:
    - name: sunscreen_blokkering_button_display
      state: >-
        {% if is_state('input_boolean.sunscreen_set_manual', 'off') %} True
        {% else %} False
        {% endif %}
      icon: >-
        {% if is_state('input_boolean.sunscreen_set_manual', 'off') %}
          mdi:check-outline
        {% else %}
          mdi:alert-outline
        {% endif %}

I am wondering what I should have done differently to be able to use your syntax. Curiosity killed the cat. With a better look to the RTFM noticed that there is also a legacy syntax, because I start from scratch I can continue with above syntax.

1 Like

So my syntax uses legacy and must be transformed to yours, Do I understand that right?

The legacy syntax is still allowed but caused me a bit of confusion to implement your sunscreen.yaml into places where I expected to do so. I am a bit too fresh in HA and yaml to dictate if you need to change this.

I like to have a clean configuration.yaml so I implemented the solution of a separate template.yaml with perhaps the benefit that in developer tools you see also this as template entities and are you able to do an YAML configuration reloading of only this part. If you do not see this yet, this might be an incentive to transform your code.

BTW for my sunscreen I am not working with sunrise/sunset but prefer azimuth and elevation (both available from SUN). This is due to the orientation of my house where the sun only touch my conservatory (“serre”) when it is over 150 degrees and I can stop when the elevation of the sun goes under 25 degrees due to a nearby forest.

I like your “irradiance” solution because a light sensor is harder to implement due to the drop of lux when the sunscreen closes.

At the moment I am trying to see how best to implement the “Cooldown” period to avoid a frequent movement of my sunscreen (“pingelen”) with a safety override based upon rain/wind; my sunscreen is 6x3meter with no support in the middle (but luckily with fixed side bars) so rain will collect in the middle to a small pool if I am not careful :swimming_man:

F.y.i I control my sunscreen with a Shelly 2.5; the device temperature can also be used in certain situations to control your sunscreen.