A lot of information thank u.
I’m working in the gui but not understand really automations 
I need simple auyomation
When it starts rain the blinds go up.
This question starts with a sensor that shows rain the moment it occurs in your location, or rather short before. A weather forecast, even on hour level, may not be accurate enough. In the Netherlands, Buienradar and Buienalarm integrations can do quick predictions. Where you live other integrations may exist.
A personal wetherstation like Netatmo has rain sensors that work with a collector. if a small cup fills up with rain, it toppples over and sends a signal. This is sent to cloud and updates about every five minutes. That may also be late, but better than nothing. Last but not least there are rain sensors that work like the one on your car. They work pretty much instant, but because there are no screen wipers, they may be very late detecting rain has stopped. I do not have one like that, but I included an example what that could look like in the example below too.
All thise sensors will automate about the same, and you can have multiple of those work together. That will look something like this (each trigger reacts on a different source of rain detection, either one will lift the screens). Any sensor you do not have, you can of course remove from the script:
alias: Screens up when rain is detected
description: ''
mode: single
trigger:
- platform: numeric_state
entity_id: sensor.buienalarm_precipitation
above: '0'
- platform: numeric_state
entity_id: sensor.buienradar_precipitation
above: '0'
- platform: numeric_state
entity_id: sensor.netatmo_regen_meter
above: '0'
- platform: state
entity_id:
- sensor.daily_rain_counter
not_to: 0
- platform: state
entity_id:
- binary_sensor.rainsensor_is_wet
to: 'on'
condition: []
action:
- service: cover.open_cover
data: {}
target:
entity_id:
- cover.keukenscherm
- cover.slaapkamerscherm_links
- cover.slaapkamerscherm_rechts
- cover.zolderscherm_links
- cover.zolderscherm_rechts
Note that for daily_rain_counter, which is a number too, I used “state” and “not_to”. That to illustrate how to handle a sensor that counts rain per day. This trigger captures any new rain, but not the counter resetting to 0. If that was done the same as buienradar (which has the amount of rain for now), it would only detect the first rain of the day.
1 Like
Ok thanks for youre help.
Now i inderstand a little bit.
I will try this.
Can you please explain how you made the zonnescherm card with manual controls?
Hi there,
after browsing the internet for a while, I came across this very interesting thread. I’m trying to automate my awning, and it isn’t quite an easy task. I thought that just by monitoring when the wind speed was higher than a certain value, I could simply close the awning but after a while I come to learn that that specific condition didn’t cut it.
@Emphyrio could you shed some light on how you are using the statistics sensor? I would love to learn from you, as I’m interested in eliminating spikes too. In the past I tried counting to three after initiating that thread, but although this has helped me quite a lot, I still feel it sometimes does not cut it.
Thanks!!!
I just started that (similar) question. Perhaps this is of interest to you as well?
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 
I have uploaded my code to:
I hope that other people could have use it.
3 Likes
Hello Emphyrio,
Thank you very mutch!! I will try it out
Greetings