Schedule trigger

Until the OP can answer the question I posted above, namely how the action will determine which schedule/time caused the automation to trigger, this Feature Request doesn’t improve on the current way scheduling can be accomplished.

I don’t quite see why that’s important. In my limited use of automations, I haven’t found it useful to determine which trigger has triggered the automation. If the automation triggers, it just needs to run the actions, right?

I admit I’m surprised by your response. You’ve made a Feature Request to handle multiple schedules within a single automation yet you “haven’t found it useful to determine which trigger has triggered the automation”.

Let me break it down for you:

  • The example you posted contains multiple schedules.
  • Each schedule is a separate trigger.
  • When the action’s code is executed it must determine which schedule was triggered in order to perform the desired operations (for example, turn these lights on at this time or those lights off at the other time).

If your answer is that you don’t need to determine which schedule because all the schedules end up performing the same operations (for example, just turn on some lights) then you’ll need a separate automation (with its own schedules) to turn the lights off. That’s two automations, one for turning lights off at a certain time and the other for turning them off at a certain time. That’s exactly what can be achieved now (examples posted above) without using your Feature Request.

The best way to fully understand what I’ve explained is for you to solve your own challenge:

  1. Monday and tuesday I want the heating on from 6:00 to 7:30 and then 18:00 through to 21:30.
  2. Wednesday, the kids are home early and I want the heating from 6:30 to 7:30 and from 12:00 to 21:30.
  3. Thursday the cleaner comes from 11:00 to 13:00.
  4. Friday I want the same as monday.
  5. Saturday and sunday I want heating from 8:00 to 21:30.

Now post an example of the single automation that will handle this using your proposed schedule platform. Most importantly, complete the example’s action section where it will turn the heating system on/off at the designated times.

1 Like

I see, I’ve misunderstood your posts. Perhaps something along the lines of:

- alias: Scheduler example 
  trigger:
  - platform: schedule
    state_0: 15 # Could either be numerical values or on/off/true/false
    state_1: 18 # Should support more than 2 states in the case of numerical values
    state_2: 20 # Perhaps doesn't need this at all, and just use to_state below
    - days:
      - weekdays # Should also accept all, weekends, or just mon through sun
    - times:
     - "6:00"
       to_state: state_1
     - "7:30"
       to_state: state_0
     - "21:30"
       to_state: state_0
    - days:
      - mon
      - tue
      - thu
      - fri
    - times:
      - "18:00"
        to_state: state_2
    - days:
      - wed
    - times:
      - "12:00"
        to_state: state_2
    - days:
      - thu
    - times:
      - "11:00"
        to_state: state_2
      - "13:00"
        to_state: state_0
    - days:
      - weekends
    - times:
      - "8:00"
        to_state: state_2
      - "21:30"
        to_state: state_0
  conditions: []
  actions:
  - service: climate.set_temperature
    value_template: {{ trigger.to_state.state }}

Something along those lines.

1 Like

I don’t what that is, but it’s not how Home Assistant’s automations work.

It’s one thing to request the addition of a new platform (like schedule) but now, 24 posts into this thread, you’ve revealed that your request requires a significant modification to how automations work. It’s not just a whole new platform it’s a whole new automations.

Maybe there’s a volunteer developer willing to change the whole automation model to implement this one Feature Request (I doubt it). Even if there is, then comes the challenge of convincing balloob that the end-result is worth the upheaval.

IMHO, the juice isn’t worth the squeeze.

Hi, maybe iam the only one here, but i totally see your point @Hitisj.
There is no easy and user friendly way to handle a shedule withouth digging into code and make a lot of changes. Despite your usecase, a simple GUI scheduler is always needed in a home automation software. I’ve no clue why there is even a discussion about it.

A lot of people here tend to post a working solution to a post about improving the current solution. Not quite sure how this helps. Speaking about Home Automation, the question is not how you can achieve something, its about achieving it easly. Sadly the developer do not care so much about userfriendly software, at least thats my opinion, but rather on unimportant programm stuff and refactoring.

Furthermore the implementation wouldn’t be a change to the whole automation. For a simple implementation you can generate timebased automations from the frontend configuration.

I also have this feature at my fritzbox. I’ll have a look at the link @Misiu provided. Maybe someone want to help implementing it?

There was some attempt a while ago, but it was closed due to architecture discussions.

1 Like

Unimportant program stuff? Really? You think this whole system just works magically?

1 Like

Just about every aspect of automating Home Assistant currently requires the creation of an automation or as you phrased it ‘digging into code’. The Automation Editor is the first example of a GUI-based tool for creating automations. It has its limitations but, if someone volunteers to improve it (and the changes are approved), it will get eventually get better.

The same is true for a GUI-based scheduler. Home Assistant may eventually get one and until it does you have to create one or more automations. If that’s unacceptable then there’s always the option of using Node-Red’s BigTimer (or other scheduling node). However, that comes with its own learning curve.

It helps because there are cases where the Feature Request is created by someone who is unaware there are existing solutions or has a superficial understanding of them. Showing them how to achieve their goal using existing techniques can, at times, obviate the need for the Feature Request. Alternately, it can demonstrate that the Feature Request has either oversights or drawbacks and requires further development.

1 Like