New component for review: input_timetable

[amitfin (Amit)]

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).

[tom_l]

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

[rccoleman (Rob Coleman)]

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

[tom_l]

Do you need us to test it for you?

[anon63427907]

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.

[amitfin (Amit)]

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 here)

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

[amitfin (Amit)]

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.

[anon63427907]

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

[amitfin (Amit)]

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

[dbrunt (Daniel)]

@amitfin I’ve been trying to piece this my HA but have hit a couple of roadblocks.
I have:
➜ / find config/custom_components/input_timetable

config/custom_components/input_timetable
config/custom_components/input_timetable/translations
config/custom_components/input_timetable/translations/en.json
config/custom_components/input_timetable/manifest.json
config/custom_components/input_timetable/__init__.py
config/custom_components/input_timetable/__pycache__
config/custom_components/input_timetable/__pycache__/__init__.cpython-39.pyc
config/custom_components/input_timetable/strings.json
config/custom_components/input_timetable/services.yaml

➜ / find config/www/timetable-card.js

config/www/timetable-card.js

My HA log shows:

2022-02-01 18:59:13 WARNING (SyncWorker_8) [homeassistant.loader] We found a custom integration input_timetable which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2022-02-01 18:59:23 INFO (MainThread) [homeassistant.bootstrap] Setting up stage 2: {'hacs', 'history', 'system_health', 'persistent_notification', 'ifttt', 'light', 'default_config', 'alexa_media', 'zeroconf', 'garbage_collection', 'remote', 'camera', 'sensor', 'bhyve', 'webostv', 'spotify', 'nest', 'motioneye', 'mobile_app', 'input_boolean', 'ble_monitor', 'tasmota', 'configurator', 'input_datetime', 'ssdp', 'media_player', 'panel_custom', 'input_text', 'browser_mod', 'accuweather', 'my', 'harmony', 'influxdb', 'esphome', 'dwains_dashboard', 'network', 'notify', 'traccar', 'group', 'automation', 'openweathermap', 'environment_canada', 'trace', 'localtuya', 'life360', 'python_script', 'battery_consumption', 'mqtt', 'cast', 'ipp', 'upnp', 'opengarage', 'coronavirus', 'media_source', 'cover', 'zigbee2mqtt_networkmap', 'waste_collection_schedule', 'sleep_as_android', 'map', 'scheduler', 'zwave_js', 'input_select', 'updater', 'astroweather', 'utility_meter', 'insteon', 'sonoff', 'alert', 'counter', 'device_tracker', 'sun', 'script', 'wake_on_lan', 'switch', 'logbook', 'tts', 'input_timetable', 'ffmpeg', 'stream', 'zone', 'var', 'unifi', 'energy', 'panel_iframe', 'nodered', 'neviweb', 'shopping_list', 'input_number', 'blueprint', 'hyperion', 'scene', 'waze_travel_time', 'dhcp', 'config_editor', 'usb', 'timer', 'binary_sensor', 'template', 'tag'}
2022-02-01 18:59:23 INFO (MainThread) [homeassistant.setup] Setting up history
2022-02-01 18:59:26 INFO (MainThread) [homeassistant.setup] Setting up input_timetable
2022-02-01 18:59:38 WARNING (MainThread) [homeassistant.setup] Setup of input_timetable is taking over 10 seconds.
2022-02-01 18:59:39 INFO (MainThread) [homeassistant.setup] Setup of domain input_timetable took 13.2 seconds
2022-02-01 19:15:06 INFO (MainThread) [homeassistant.components.analytics] Submitted analytics to Home Assistant servers. Information submitted includes {'uuid': '1ea829f89d2e4a0e8764bf4c484f24da', 'version': '2021.12.10', 'installation_type': 'Home Assistant OS', 'supervisor': {'healthy': True, 'supported': True, 'arch': 'aarch64'}, 'operating_system': {'board': 'odroid-n2', 'version': '7.2'}, 'integrations': ['webhook', 'analytics', 'history', 'image', 'system_health', 'tod', 'persistent_notification', 'threshold', 'ifttt', 'workday', 'remote', 'sensor', 'universal', 'webostv', 'motioneye', 'mobile_app', 'configurator', 'input_text', 'uptime', 'api', 'harmony', 'integration', 'network', 'onboarding', 'systemmonitor', 'openweathermap', 'mqtt', 'ipp', 'config', 'season', 'cast', 'opengarage', 'fan', 'device_automation', 'weather', 'media_source', 'cover', 'http', 'map', 'updater', 'climate', 'insteon', 'counter', 'alert', 'switch', 'tts', 'ffmpeg', 'zone', 'google_translate', 'auth', 'panel_iframe', 'select', 'recorder', 'input_number', 'blueprint', 'scene', 'waze_travel_time', 'dhcp', 'usb', 'stt', 'timer', 'hassio', 'template', 'bayesian', 'system_log', 'version', 'light', 'number', 'default_config', 'alexa', 'pushover', 'zeroconf', 'lovelace', 'camera', 'spotify', 'nest', 'input_boolean', 'tasmota', 'input_datetime', 'ssdp', 'media_player', 'panel_custom', 'accuweather', 'my', 'influxdb', 'esphome', 'lock', 'traccar', 'notify', 'rest', 'group', 'websocket_api', 'logger', 'automation', 'environment_canada', 'homeassistant', 'trace', 'life360', 'python_script', 'button', 'person', 'command_line', 'upnp', 'smtp', 'coronavirus', 'alarm_control_panel', 'ping', 'apprise', 'androidtv', 'html5', 'zwave_js', 'input_select', 'cloud', 'utility_meter', 'device_tracker', 'sun', 'wake_on_lan', 'script', 'logbook', 'statistics', 'stream', 'energy', 'unifi', 'search', 'time_date', 'shopping_list', 'frontend', 'calendar', 'hyperion', 'mjpeg', 'binary_sensor', 'tag'], 'custom_integrations': [{'domain': 'hacs', 'version': <AwesomeVersion SemVer '1.21.0'>}, {'domain': 'thermal_comfort', 'version': <AwesomeVersion SemVer '1.4.3'>}, {'domain': 'browser_mod', 'version': <AwesomeVersion SemVer '1.3.1'>}, {'domain': 'next_holiday', 'version': <AwesomeVersion SemVer '0.3.2'>}, {'domain': 'dwains_dashboard', 'version': <AwesomeVersion SemVer '2.0.5'>}, {'domain': 'localtuya', 'version': <AwesomeVersion SemVer '3.2.1'>}, {'domain': 'zigbee2mqtt_networkmap', 'version': <AwesomeVersion SemVer '0.0.1'>}, {'domain': 'waste_collection_schedule', 'version': <AwesomeVersion SemVer '1.14.0'>}, {'domain': 'scheduler', 'version': <AwesomeVersion SemVer '0.0.0'>}, {'domain': 'astroweather', 'version': <AwesomeVersion SimpleVer '0.0.18.3'>}, {'domain': 'input_timetable', 'version': <AwesomeVersion SemVer '1.0.0'>}, {'domain': 'var',.....
2022-02-01 19:27:38 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new automation.automation entity: automation.timetable_lights
2022-02-01 19:27:38 INFO (MainThread) [homeassistant.components.automation.timetable_lights] Initialized trigger Timetable - Lights

I am stuck here:

and here:

[amitfin (Amit)]

It looks ok.

The new entity is not part of the “Add helper” dialog, but it will be once the frontend PRs are merged (the PR for the helper is here). Meanwhile, you can add the input_timetable entities directly into the configuration.yaml file, for example:

input_timetable:
  light1:
  window1:

The UI configuration should look like this:

cards:
  - type: custom:timetable-card
    title: Timers
    toggle: input_boolean.timers
    entities:
      - entity: input_timetable.window1
        name: Window1

And then the rule goes like this:

- id: window_timer
  alias: window_timer
  trigger:
    - platform: state
      entity_id: input_timetable.window1
  condition:
    - condition: state
      entity_id: group.timers
      state: 'on'
  action:
    - service: cover.{{ 'open_cover' if is_state('input_timetable.window1', 'on') else 'close_cover' }}
      entity_id:
        - cover.window

[dbrunt (Daniel)]

Thanks! I had this in configuration.yaml but stopped when I did not see Timetable in the UI…

input_timetable:
  lights:

I’ve finished the lovelace card:

and added this automation:

alias: Lights
description: ''
mode: single
trigger:
  - platform: state
    entity_id: input_timetable.lights
condition: []
action:
  - choose:
      - conditions:
          - condition: state
            entity_id: input_timetable.lights
            state: 'off'
        sequence:
          - service: light.turn_off
            target:
              entity_id: light.office_light_2
      - conditions:
          - condition: state
            entity_id: input_timetable.lights
            state: 'on'
        sequence:
          - service: light.turn_on
            target:
              entity_id: light.office_light_2
    default: []

…and my office light 2 just switched off now!

[dbrunt (Daniel)]

and now it’s back on!

How would I change this card so it’s more legible!

Have you thought about incorporating Sunrise/Sunset as time options?

[amitfin (Amit)]

The UI is just an interim solution, until the real UI (here) will be accepted and merged into the frontend. Unfortunately, this interim solution doesn’t work well in dark mode.
BTW, the UI is the reason I’m trying to integrate the solution into HA (instead of HACS). The UI (frontend) is not extensibile like the backend (with custom components). The integrated UI provides much better user experience, in my mind. However, the PRs are sitting in the queue for more than a year, so I’m starting to give up. It’s not that anyone pushed back on this component, but someone from the core team should review and merge it. This is also the reason I’m hesitating to add additional features (like sunrise/sunset) so it won’t become too big and complex to review.

[dbrunt (Daniel)]

Thanks, I thought I saw something newer than what I have.
I’ve added a comment to both PR’s…

[anon63427907]

Yes, there are many sitting idle there, it is discouraging