In the past weeks, I’ve been moving from Node Red to YAML. It has been a frustrating time because there’s nothing harder than to schedule [b]one automation[/] to happen on different times during the week.
The use case for this is that I wanted to schedule a ‘wake up light’. I want to turn on the lights slowly at 6:25 on weekdays, or on 8:00 on sunday. But only if I’m at home.
Currently, I have a non-working automation written that takes over 20 lines in very complicated condition logic. It does not work and it seems pretty overkill for what I’m trying to achieve.
Here’s the code I currently have:
- alias: Wake up light
trigger:
- platform: time_pattern
minutes: /5
condition: and
conditions:
- condition: state
entity_id: device_tracker.my_iphone
state: home
- condition: or
conditions: and
- condition: state
entity_id: sensor.workday_sensor
state: on
- condition: state
entity_id: sensor.time
state: '06:25'
- conditions: and
- condition: state
entity_id: sensor.time
state: '08:00'
- condition: time
weekday:
- sun
action:
- service: light.turn_on
data:
entity_id: light.living_room
brightnesst: 1
- service: light.turn_on
data:
entity_id: light.living_room
brightness: 255
transition: 900
- delay:
seconds: 902
- service: light.turn_on
data:
entity_id: light.living_room
brightness: 102
transition: 45
- service: switch.turn_on
data:
entity_id: switch.kitchen_led_strip
I don’t know YAML very well and so this code is hard to debug. To me, it sounds way easier to do it like this:
- alias: Wake up light
trigger:
- platform: schedule
- days:
- mon
- tue #etc
- time: '6:25'
- platform: schedule
- days:
- sun
- time: '8:00'
condition:
- platform: state
entity_id: device_tracker.my_iphone
state: home
action:
#etc
The reason this would be useful is that you don’t have to write 3 automations to make 1 thing happen. Also, if one of your entities, devices or schedules change, you don’t have to edit multiple automations to make it all work again. A schedule would also be quite useful for heating or cooling thermostats.
This seems like a very simple thing to accomplish, yet after 1,5 hours of writing code it still isn’t functional.
- alias: Wake up light weekday
trigger:
platform: time
at: '06:25:00'
condition:
- condition: time
weekday:
- mon
- tue
- wed
- thu
- fri
- condition: state
entity_id: device_tracker.my_iphone
state: home
Sunday:
- alias: Wake up light Sunday
trigger:
platform: time
at: '08:00:00'
condition:
- condition: time
weekday:
- sun
- condition: state
entity_id: device_tracker.my_iphone
state: home
Yes, I am aware of what I can do, but I don’t think it’s a very practical solution. For an ‘alarm clock’ type event like I described above where the trigger is the same every day, you’ve got a point. But I also think this can be used for heating schedules that might be a lot different. For example:
Monday and tuesday I want the heating on from 6:00 to 7:30 and then 18:00 through to 21:30.
Wednesday, the kids are home early and I want the heating from 6:30 to 7:30 and from 12:00 to 21:30.
Thursday the cleaner comes from 11:00 to 13:00.
Friday I want the same as monday.
Saturday and sunday I want heating from 8:00 to 21:30.
This cannot be done easily while I think it’s one of the most simple things to be automated.
As I also stated, if you ever want to edit a complex or an extortionately long automation (your entities, conditions or parameters change), you don’t have to edit 3 or 4 automations if you split them up like you did.
Okay, what about templates ?
Have 7 template triggers set for each day of the week.(entity id: sensor.time)
Then have template conditions (or) set for both Dow AND time
And then fire your actions
Place input datetime’s in the ui for each day and Robert is your avuncular relative
You can of course provide an alternative, I just didn’t know if you saw the one I provided. Wanted to prevent duplication of effort. Sorry if it came off the wrong way.
Either way, OP didn’t seem too interested in that as a solution unfortunately.
…if it helps… I appreciate being notified of my request being mentioned just to have seen that exchange. Well-played, gentlemen…
.
.
.
.
.
But in the interest of contributing to the thread- I have a different implementation for a ‘wake-up light’ utilizing the workday-sensor if anyone is interested… pretty easy way to handle M-F(+holidays) (except the part where… I didn’t have Oct. 14th off… and it considered that a holiday… and as such, the automation didn’t trigger…)
I also use the workday sensor for a specific automation. I don’t have all those holidays off, but I’d rather this automation not fire on one of my workdays than fire on a day I have off.
@123 While I am aware that splitting the automations for every day is an easy solution, it is not the solution I’m after. You see, should one of the entities, conditions or actions change, you now have to edit four to seven different automations. The maintenance involved (and possible errors that come with it) are the reason that a scheduler, in my opinion, would be a good idea.
Another advantage is that you can easily turn off the automation for an entire week, instead of turning multiple off by hand.
The third reason is that doing something twice or more is kind of pointless in my opinion (the conditions and actions are all the same).
@MithrasPan I’m using the Workday sensor too in other automations. This works when all days are equal, but in a scheduler-type way, they may not be.
I largely welcome duplication of effort.
Not literally, but to see 10 different solutions to one problem is fascinating.
To see people’s inherent biases towards this or that and how they overcome the limitations of the other. I learn more by cherry picking ideas and constructs, storing others bits as “maybe useful later”.
And then to see what the OP chooses, sometimes obvious, sometimes just influenced by their own biases (we all have them).
I tend to agree that having one place to go to change coding for one “automation” (not literal, in this case, more like a collection of grouped logic) is close to ideal (I get confused easily )
But I also think if it (say thresholds/enable/disable) can be accessed from the UI (and hence adjusted when away from home) then that avoids having to continually dig in to code, check config and restart automations/scripts - I’ll have one of those.
I have to say I don’t understand people’s obsession with switching heating on and off at given times, I just change setpoint.
House unoccupied 6 degrees, occupied during the day 19 degrees, occupied at night 16 degrees - but this shows my bias too, strongly influenced by Petro’s ethos about making things just part of the background (but I still allow users to screw it up if they feel the need )
Edit: I now have my own yaml scheduling sorted (both strict time observation and interrupted by occupancy) - but I STRONGLY believe that there should be a scheduling component native to HA
Edit2: and I don’t think it should necessitate the installation of another package (say appdaemon).
You keep increasing the number of required automations despite being shown examples requiring only two to implement a single schedule. Seven automations to implement one schedule would be an example of a very poor implementation.
In addition, a scheduler doesn’t necessarily reduce the amount of maintenance for additions and modifications. The magnitude of effort still depends on the nature of the changes. The primary advantage of a scheduler is typically its visual presentation of multiple schedules.
To be clear, I support the addition of a default scheduler. However, yours is not the first request for one and it appears that developers are in no rush to implement it. There’s a single discussion in the Architecture repo about developing a general-purpose scheduler. However, it started last February and the most recent comment was in July … so it’s not a pressing issue.
Until it ever materializes, you will need to use the automation techniques presented above (or Schedy). If this is not to your liking, then you may need to find a home automation solution with a scheduler that meets your needs.
On or off equals ‘changing the setpoint’ for me. Not home or asleep = 15 degrees, home = 20 degrees.
Yes, because I also give examples about how, in my opinion, hard it is to schedule heating for the times I outlined in this post: Schedule trigger - #3 by Hitisj. This would require at least 5 automations, as far as I can see, if I split them up like you pointed out in your post about it. I may have missed something though and since I’m relatively new at YAML, this might not be true. If that’s the case, feel free to correct me.
I’m glad we’re on the same page. The link you provides also gives some nice background information, thanks for sharing. Too bad they don’t want it as badly as I do.
I very much do appreciate the code snippets you shared to get my problem solved. That was not the point I was trying to make, however. The reason I keep bringing up the schedules instead of splitting automations is that I was trying to present a use case for schedules because I see a clear added value in it. I was not only trying something for my use case (a wake up light), but a broad solution that works well in many home automation problems.
In the meantime, I will split the automations but hope to see a scheduler in Home Asisstant soon. Or I might still give the overly complicated condition logic a try and will let you know how it goes.
I have collective heating and do not have a thermostat. As such, I purchased the EuroTronic Spirit Zigbee and use that as a thermostat with the generic climate component. I don’t believe it has scheduling built in. Besides, a ‘built in schedule’ ignores my presence as far as I can see.
The way I have it set up now is that an ‘input number target temperature’ gets set by an automation. When there is presence or the target temperature changes when there is presence, the temperature gets sent to the Eurotronic by another automation. If I leave the house, the heating gets set to 15 degrees C by a third automation.
I went for this approach because I want to have multiple heating setpoints. In the morning when I wake up, I don’t neet 20 C. Just wastes energy if I’m out of the house by 7:30 which I am on workdays. So I only heat it up to 18 C and the 20 C only gets set after 8:00.
You’re not wrong but let me explain why its advantageous at times to use more than one automation. It has to do with the trigger object.
When you create an automation with multiple triggers, the action section can use the trigger object to determine which one of the multiple triggers was responsible for triggering the automation. However, the trigger object doesn’t tell you if it was the first trigger or second one or nth trigger.
The way you determine which trigger was activated is to (for example) check the value of trigger.to_state.state or trigger.to_state.object_id. So if one trigger represents the start time and the other is the stop time, you have to inspect trigger.to_state.state to determine which one fired in order to call the correct service to either turn_on or turn_off the device (i.e. if the trigger object’s state value is 8:00 AM then that’s the start time but if it was 10:00 AM then that’s the stop time). If that sounds like you will have to duplicate the start/stop times in both the trigger and action sections, you’re right.
I could’ve combined the two automations I had presented into one but then the action section would become more complex and required templates to determine which trigger had fired. I would have had to duplicate the times, shown in the trigger section, in templates within the action. Keeping them as two separate automations (one for starting, the other for stopping) simplifies the task.
Your proposal faces the same challenge. The example you provided looks neat and tidy. Just one automation to handle multiple schedules. Very nice except it provides no details in its action section. Can you elaborate on how, in the action section, you propose to determine which of the multiple schedules and times was activated?
I’d like to add to this feature request.
I’m using generic thermostat (actually six of them) and it would be awesome to have a schedule trigger, but also a schedule editor card. It would be super useful if we could add a card to frontend (Lovelace) that will allow non-programmers (for example my parents) to edit temperatures easily.
Example use case:
from 8:00 AM to 4:00 PM set the temperature to 19 degrees and from 4:00 PM to 9:00 PM to 21 and from 9:00 PM to 8:00 AM to 20.
Right now I must write automations for each thermostat and if my parents want to change anything I must edit automations, restart hass.
Schedule trigger and schedule UI editor would be super useful.
)
)
