New component for review: input_timetable

A short clip with a demo can be found here.

The PR Add input_timetable integration is in the queue for 10+ months, so trying to see if anyone is willing to help with the review.

Many (many) thanks in advance!

Additional details:
This is a new integration which should help using fixed automation rules, while controlling their behavior through this new entity type.
The “input_timetable” entity has an on/off state based on the time periods provided as input by the user. It preserves the time periods during reboots.
A typical usage will be to create a static automation rule, which will behave according to changes in the time periods of the timetable, without the need to change the rule itself.

The reason for trying to have built-in component (and not through HACS) is the user-experience. For example, it’s not possible to add a helper element to the UI without changing the frontend codebase (e.g. home-assistant/frontend#7687).


I hope this makes it in to the core. It would considerably simplify my scheduling.

1 Like

That is really cool! I have a bunch of places that I could use that to simplify my automations.

1 Like

Do you need us to test it for you?

1 Like

First of all, it is a good idea, liked it. Second, can you raise events based on time table rather than using templates? Templates are a bit difficult to manage but triggers are much more easier.

1 Like

There is no specific ask for testing, but I really appreciate it!
You are more than welcome to use it (see instructions here and here).

I’m using it for a year now, and there is also extensive testing in the code (100% code coverage :slight_smile: here)

The ask is for doing a code-review which might help with merging this PR into core.

1 Like

I completely agree that templates are more complicated.
The use of templates is only in the “action” section, and its purpose is to have a single rule to do both actions (turning the lights on and off), instead of having 2 separate rules.

Here is the rule description with a template:

  • Trigger: timetable state was changed ==> Action: (template) if timetable is “on” turn the lights “on”, otherwise turn the lights “off”.

It’s completely reasonable to skip the templates altogether, and use 2 rules instead:

  • Trigger: timetable state becomes “on” ==> Action: turn the lights “on”
  • Trigger: timetable state becomes “off” ==> Action: turn the lights “off”

Since the triggers are plain “state” based (no templates in the tigger section), I’m not sure if adding events can help. However, please let me know if I’m missing something here.

1 Like

I didn’t notice that there are triggers available for timetable component, if that is the case, it is perfect.

From my personal view, i am managing all these with multiple time helpers but i would like to control them over one table, my life would get simpler :slight_smile:

1 Like

My main motivation for adding this time helper was to create a variable-length list of time events (which can grow or shrink) without the need to change the configuration (e.g. add another time helper and change the relevant automation rules).
This way I can offload some of the configuration responsibilities to other family members who are less tech savvy :wink:

1 Like