multiple time-based triggers and startup/reload combined

[fleXible]

Hi,

first of all, thanks for the amazing component. It's exactly what I was looking. No extra docker dontainer like AppDaemon but also based on Python. Finally it is possible to properly compute in automations thanks to the type-stable store and retrieval of state attributes!

My current use-case is to have the brightness of a light be changed, depending on the time of day and state of the sun.

The ugly way:

binary_sensor:
 - platform: tod
   name: morning
   after: '08:00'
   before: '10:00'
 - platform: tod
   name: day
   after: '10:00'
   before: '18:00'
 - platform: tod
   name: evening
   after: '18:00'
   before: '21:00'

sensor:
  - platform: command_line
    name: light_brightness_cmd
    command: 'python3 /config/shell-scripts/set-brightness.py' # extreme customization needed for control
    value_template: "{{ value_json.info.brightnessValue|default('unavailable', false) }}"
    scan_interval: 30
  - platform: template
    sensors:
      light_brightness:
        value_template: "{{ states('sensor.light_brightness_cmd')|float }}"
        attribute_templates:
          brightness: "{{ states('sensor.light_brightness_cmd')|float }}"
          brightness_scaled: "{{ (states('sensor.light_brightness')|float * 100)|int }}"

And on top of that, there is an automation to determine the current time of day, assign and rescale the brightness value and, using another py-script, adjusting it. It's way to complicated for the result.

My idea was now to a time_trigger like
@time_trigger("once(08:00:00)", "once(10:00:00)", "once(18:00:00)", "once(21:00:00)", "once(sunrise)", "once(sunset)" put whatever fancy logic and calculations in a set_daytime() function and store the results as state&attributes in a dummy entity.

My problem now is, I would need set_daytime() also be executed at reload&restart for proper initialization.

Any idea?

[craigbarratt]

Ah - I didn't think of that, since I overloaded @time_trigger with no arguments to handle the startup/reload case.

Here's a quick fix. Just have a 2nd function that handles the startup/reload trigger, and call the same function:

@time_trigger
def set_daytime_on_startup():
   set_daytime()

You could add a function argument so your function can tell the difference between startup and a time trigger.

I'll plan on adding a "startup" time-spec option to @time_trigger so it can be used alongside the other time specifications.

Note also that you could collapse your four hour-based arguments into one using cron:

@time_trigger("cron(0 8,10,18,21 * * *)", "once(sunrise)", "once(sunset)")

BTW, I just released a new version that supports Jupyter, making it much easier to write, debug and test code and logic. It's way easier to use that than saving / reload.

Cheers.

[fleXible]

Thanks for the quick reply. I am already knee-deep in jupyter and debugpy debugger looking at the inner workings of your component.

I was thinking of using a second function with a seperate trigger, but wanted to be sure, there was no easier way.
By the way, similar problem quickly arises, when different event type/expression combinations are needed.

You're right regarding the cron notation but I prefer having each definition separate.

To make processing of multiple time_triggers / trigger types easier in the called function, I propose for @time_trigger:

• trigger_type is always set to time
• add keyword argument time_spec set to the datetime of the definition responsible and maybe None for startup/reload

[craigbarratt]

Good suggestions. I'll add them to my todo list.

[craigbarratt]

"startup" is now a valid @time_trigger argument with commit 59a5461. I ended up using trigger_time as the datetime for the trigger time that caused the trigger.