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.
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
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:
tap_action:
action: call-service
service: script.patiocover_manual_endtime
service_data:
duration_minutes: 60 # or 120 of 480 etc
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
- 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
I hope this information helps you in your endeavours 
I have uploaded my code to:
I hope that other people could have use it.
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.
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 
) . 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.
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 
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.
I somehow remember your name from the āotherā homeautomation site, and have used your script there for quite some time. Just need to get this working with OpenWeathermap sensors and a shelly 2Plus controller.
You can change all sensors I use from buienradar to other weather sensors.
which controler you use doesnt matter, all changable.
When I have the time and knowledge I want to change this script to a blueprint so itās easier adjustable.
cooldown functionality I use the delay timer for. 
Need to figure out how to install all this. Was used to just do a git clone, but it seems to be different in this place
I want to share my version of an automated awning.
I reduced the automation to 3 triggers and 1 choose building block with 2 options not to continue and 1 option to open/close awning and set a delay for next action.
In the dashboard it looks like:
All criteria are grouped together in a group binary sensor, only the group sensor is now used in the automation.yaml.
Ok, you need to convert all weather conditions into a binary sensor but this type of helper sensor is nowadays also available in the UI.
Hope this is helpful.
