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.
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?
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:
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
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
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:
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.
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.
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.