This might be quite a simple modification, but I can’t seemed to figure out. I have an automation that turns off certain lights in my home 3 hours after sunset. This works great during when we are not in daylight savings time as the sun sets later in the day, but when daylight savings starts, the same automation turns off the lights too early (sun is setting way earlier than before). The simple solution will be to create 2 sets of automations, one for EST (I am in US eastern time zone) and one for DST (daylight savings), and have a switch to turn off one set of automations based on daylight savings being active or not (I already have a sensor that monitors daylight savings state); but I keep on thinking that there must be a way to combine all conditions within one automation (ultimately, easier to handle). I also know that using rednode might be an option, but I rather do it, if possible and not much headache, directly into home assistant.
My current automation looks as below:
- id: driveway_OFF_3h_after_sunset
alias: "Driveway OFF - 3h after sunset"
trigger:
- platform: sun
event: sunset
offset: '+03:00:00'
action:
- service: homeassistant.turn_off
entity_id: switch.driveway_68
What I would like to accomplish is to extend the automation to also monitor a DST sensor (ON / OFF), so it will do the following:
If DST = ON --> turn off lights 5 hours after sunset
if DST = OFF --> turn off lights 3 hours after sunset
Any guidance on how to do this will be greatly appreciated.
Thanks @pnbruckner. I did try working with sun elevation instead, but I run into a different issue; if HA restarted (manually / automatically), the automation will trigger. Maybe my lack of knowledge, but will this be a good automation:
automation:
alias: "Exterior Lighting off when elevation =-60.0"
trigger:
platform: numeric_state
entity_id: sun.sun
value_template: "{{ state.attributes.elevation }}"
# Can be a positive or negative number
equal: -60.0
action:
service: switch.turn_off
entity_id: switch.exterior_lighting
I will like the automation to only run once (only after sunset and not before sunrise)
You have to look at the reason you want the lights off and at what time.
Sunset changes in a sinusoidal pattern through the year.
You are not turning lights on at a low light level and you say that in summer 3hrs after sunset is too early.
You could either set a ‘latest’ time and your sunset offset. And use the ‘latest’ of the two.
Or you could just set a time that is sensible to you and use the local time value.
At what time are they switched on ?
@Mutt, lights turn on @ sunset; which works fine for me the entire year (regardless of daylight savings or not); it is the turning them off that I will like to manage in a way that could account for daylight savings (sun sets earlier, so I will like to keep certain lights on longer)
Yes I appreciate that but I’m trying to determine if you had to flip the switch every night, without access to elevation or time what would cause you to turn them off ?
The way this works is, whenever sun.sun changes its elevation attribute will be checked, and if it’s below -60, it will trigger. However, once it has triggered it will not trigger again until the value goes to -60 or above, and then back below -60. So, except for that first trigger, it should only trigger once a day.
But I’m wondering if -60 is a reasonable value. (Remember, the minimum elevation changes throughout the year, too. It’s possible that during the summer it never goes that low, depending on where you live.)
So, the question is, when exactly do you want the lights to go off? I.e., what indicates they’ve been on long enough? Just how long they’ve been on? Time of day? Angle of sun? Some combination thereof?
Yeah, I think maybe you should think a bit more about what really determines when the lights should go off. I like the way @Mutt put it: “if you had to flip the switch every night … what would cause you to turn them off?” This might help make it clear what should trigger the automation.
But, in the meantime, to “brute force it” the way you wanted, you could do this:
- id: driveway_OFF_3h_after_sunset
alias: "Driveway OFF - 3h after sunset"
trigger:
- platform: sun
event: sunset
offset: '03:00:00'
- platform: sun
event: sunset
offset: '05:00:00'
condition:
condition: template
value_template: >
{% set dst = now().timetuple().tm_isdst == 1 %}
{% set offset_hrs = trigger.offset.total_seconds() / (60*60) %}
{{ dst and offset_hrs == 5 or not dst and offset_hrs == 3 }}
action:
- service: homeassistant.turn_off
entity_id: switch.driveway_68
@Mutt, 30 minutes after bedtime will be ideal (not sure why you would consider that vanal), but I don’t have (or have figured out) how to use a combination of sensors, sun elevation, time of the year, that works properly for me.
@pnbruckner, if I could get a combination of time (spacific time) and sun elevation (whichever happens first) as a condition to turn off certain lights, it will suffice.
As I expand how HA controls my house, I will look into other conditions to reach the ultimate goal of turning off the lights when the house detects that all its occupants are sleeping (a truly automated home)
I’m saying it’s banal because it most probably will be just a time.
If your saying 30 mins after bed then what time do you go to bed?
What bed lights are there?
If we wait till an an hour BEFORE bed time then wait for 1 bed light to go on, then wait for all bed lights to go off, then wait 30 mins more and switch the drive lights off
Yes, if you only look at for a specific light/example, then you are absolutely right. My idea is to extend the concept to other lights in the house that will also have the same base conditions (time of day, season of the year) and extend those simple rules to include in room motion detection, other light status, etc, to make the automation as useful as possible without driving my family crazy.
That is always the challenge (not driving the family crazy), but going back to my original question what is the best way to have multiple conditions, simple AND / OR trigger conditions, or… (not very good at templating or scripting).
NodeRed seems to also be quite useful, but I am trying to keep everything under the HA umbrella unless it is not possible (or doesn’t make sense)
Nodered has its place but yaml is all over HA so if you gain at least a basic understanding it will pay dividends.
Taking Phil’s code as an example and extending it for multiple triggers, ditto conditions and actions : -
- id: driveway_OFF_3h_after_sunset
alias: "Driveway OFF - 3h after sunset"
trigger:
- platform: sun
event: sunset
offset: '03:00:00'
- platform: sun
event: sunset
offset: '05:00:00'
- platform:state
entity_id: light.kidsroomlight
to: 'on'
condition:
- condition: state
entity_id: light.garagelight
state: 'off'
- condition: template
value_template: >
{% set dst = now().timetuple().tm_isdst == 1 %}
{% set offset_hrs = trigger.offset.total_seconds() / (60*60) %}
{{ dst and offset_hrs == 5 or not dst and offset_hrs == 3 }}
action:
- service: switch.turn_off
entity_id: switch.driveway_68
- delay: '00:02:00'
- service: light.turn_on
entity_id: light.mybedsidelamp
- condition:state
entity_id: light.herbedsidelamp
state: 'on'
- service: switch.turn_on
entity_id: switch.bedroommusicplayer
- delay: '00:20:00'
- service: switch.turn_off
entity_id: switch.bedroommusicplayer
These are largely made up entities but you get the idea. If you use dashes (denotes a list) it also works for singles, so I always use dashes.
Templates are a much longer story, you will need to read a lot, set some goals, ask questions and play a lot. The template editor is brilliant for that
Thanks @Mutt and @pnbruckner (missed your previous post, I was reading on my phone).
The example provided is perfect as a reference; and yes, I still need to clearly define why/when I will want certain actions to happen (lights to be turned off for example), but I have to start polishing my current automations one at the time (been using a HA sporadically for over a year now, and is has gown a lot more than I expected).
NodeRed is great for certain aspects (I have it monitoring MQTT messages from WallPanel app, to determine when do I need to charge the fireHD tablets that serve as control panels around my house), but I am trying to first get more comfortable with HA and YAML, then I can start working with NodeRed.
As most people int his forum, I know that this journey will never end; but I like learning and hopefully giving back to the community at some point not in the too distant future.
A couple of points
Polishing your automations : currently you understand what they do, you know how they work. Supposing someone gives you code that reduces your 20 lines down to 5, is that better? Do you still understand it? Can you change it to ‘adjust the time’?
I polish my automations / scripts by making them fit a spacing ideal and using a common format, space is not an issue. Readability, consistency and reliability is. Don’t do elegance for elegances sake.
I don’t use node red, I haven’t mastered yaml yet.
Yaml has let me do everything I want to do.
When I hit a wall, I ask a question and someone like Phil gives me a hand.
When I’ve got to a point where yaml can’t do what I want, I’ll probably go to appdaemon rather than nodered. But I’m nowhere near needing it yet.
Yaml is core, yaml is fully supported, nodered and appdaemon aren’t even official addons, they may get dropped tomorrow (they won’t but you get my drift)
Another tip, try not to tag people, some don’t like it, dunno why but it’s just a rule that you NEVER tag anyone you don’t know will be okay with it.
A tag to credit them for something is generally okay but I know a member who has blocked individuals because of it. Phil will be okay with this and you are talking to me so it’s not an issue.
Sorry, I just re-read this and I didn’t explain the expanded code.
ALL triggers are OR (any ‘one’ can trigger the automation)
CONDITIONS are by default ANDED (they ALL have to be true)
But you can have OR conditions
This light has to be on OR that door open
AND you can mix the two, read the docs on conditions
Actions are just things you want to HAPPEN and happen in the listed sequence.
A condition in the action section ‘blocks’ all actions below it - unless true
There are other things like waits and delays but they are best explained as you need them
After much playing around with HA and automations in YAML; I decided to revisit NodeRed for the same purposes, and it made things a little easier for me, as I can reuse some rules for other purposes. You could accomplish the same with YAML, but it is a lot of code for me to maintain. What I ended with in NodeRed is the following:
For now I am still testing both implementations: YAML and NodeRed, but the NodeRed implementation might be simpler for me to maintain in the long run. Hopefully this helps someone in my same situation.
