Setting up multiple / complex automation

Configuration
27

To simplify the task, this example relies on consistent naming of the various entities employed.

The 7 days of the week are represented by input_booleans using this naming convention:
input_boolean.day_1
input_boolean.day_2
input_boolean.day_3
input_boolean.day_4
input_boolean.day_5
input_boolean.day_6
input_boolean.day_7

The 10 temperatures, 5 for workdays and another 5 for offdays, are stored in input_texts using this naming convention:
input_text.workday_1
input_text.workday_2
input_text.workday_3
input_text.workday_4
input_text.workday_5
input_text.offday_1
input_text.offday_2
input_text.offday_3
input_text.offday_4
input_text.offday_5

The start times are stored in 10 input_datetimes, 5 for workdays and another 5 for offdays, using the same naming convention:
input_datetime.workday_1
input_datetime.workday_2
input_datetime.workday_3
input_datetime.workday_4
input_datetime.workday_5
input_datetime.offday_1
input_datetime.offday_2
input_datetime.offday_3
input_datetime.offday_4
input_datetime.offday_5

Here’s the automation that ties it all together:

Original but flawed version 
alias: 'Example 3'
trigger:
  - platform: time
    at:
    - input_datetime.workday_1
    - input_datetime.workday_2
    - input_datetime.workday_3
    - input_datetime.workday_4
    - input_datetime.workday_5
    - input_datetime.offday_1
    - input_datetime.offday_2
    - input_datetime.offday_3
    - input_datetime.offday_4
    - input_datetime.offday_5
action:
  - variables:
      day: "{{ 'input_boolean.day_' ~ now().isoweekday() }}"
  - choose:
    - conditions: >
        {{ (is_state(day, 'on')  and 'workday' in trigger.to_state.object_id) or
           (is_state(day, 'off') and 'offday'  in trigger.to_state.object_id) }}
      sequence:
      - service: climate.set_temperature
        target:
          device_id: d8c34b0dce275e2c56a9b1f68f0a6d19
        data:
          temperature: "{{ states('input_text.' ~ trigger.to_state.object_id) }}"

NOTE

The original version has a flaw that prevents it from working correctly. Use the revised version in the post below.

The automation’s trigger can be expanded to accommodate however many daily times are needed.

EDIT 1

Correction: Fixed day variable’s template.

EDIT 2

Use revised version posted below.

2 Likes
28

Thanks to everyone who has helped with solutions to my issue. I have a few solutions and will try all of them over the next few days and weekend and report back which one is more suitable and if I need any further help. Thanks again your help is much appreciated.

PS feel free to update while I work away!!

29

I’m confused about the day variable declaration. What’s that doing?

30

Honestly, the automation went through so many revisions that what you see there is a leftover from a previous version; it’s wrong and thanks for drawing my attention to it. I’ll correct the example; it should be this:

"{{ 'input_boolean.day_' ~ now().isoweekday() }}"
2 Likes
31

Would it be possible to have the temperature setting input_text.workday_1 as a input_number.workday_1? Reason being is you can then insure the user inputs a valid number and I can also set the minimum and maximum values for my TRV?

image

32

Yeah, so no reason not. Would even make a lot more sense to me :slight_smile:

33

Thanks Timo, Was just checking it won’t break the code for the automation. :slightly_smiling_face:

34

You’ll need to change the final line from

temperature: "{{ states('input_text.' ~ trigger.to_state.object_id) }}"

to

temperature: "{{ states('input_number.' ~ trigger.to_state.object_id) }}"

Apologies if that’s obvious, but you did say you were a beginner with this stuff :slight_smile:.

1 Like
35

Ahh thanks for pointing that out Troon, yes complete beginner only installed my first HS setup 2 weeks ago so any help is much appreciated !!

36

As explained by septillion, yes, with a minor change to the code. The choice of input_text or input_number is, in this case, arbitrary. An input_number has an edge because it automatically constrains values to numbers. An input_text accepts alphanumeric characters but can optionally be constrained with a regex pattern.

Anyway, the choice of what stores the temperature is a minor detail in the bigger challenge of composing an uncomplicated automation that meets your scheduling requirements.

Let me know if you need an explanation of how the automation works. You should become familiar with it so that you can modify it in the future to meet any new requirements.

1 Like
37

I’ve managed to further reduce the size of my version of this automation, and do away with the customization requirement by using groups instead. Probably even less user-friendly to read than before, but easily adjustable in terms of number of slots by adding or removing helpers to/from the groups and reloading groups — no adjustment is needed to the automation.

- alias: Hot water - tank target manager

  description: >-
    This automation updates the value of the target based on the values in the
    schedule. The action identifies which slot matches the current time, then sets
    the target to that slot's target value. Slots at midnight are considered unset,
    and ignored. Schedule helpers must be put into one of four groups:
    group.wdhw_times - time helpers for workdays
    group.wehw_times - time helpers for non-workdays
    group.wdhw_tgts -  target number helpers for workdays
    group.wehw_tgts -  target number helpers for non-workdays

  trigger:
    - platform: template
      value_template: >
        {{ states('sensor.time')+":00" in expand(('group.wdhw_' if states('binary_sensor.workday_sensor') == 'on' else 'group.wehw_')+'times')|map(attribute='state') }}

  condition: "{{ states('sensor.time') != '00:00' }}"

  action:
    - service: input_number.set_value
      data_template:
        entity_id: input_number.tank_target
        value: >
          {% set g = 'group.wdhw_' if states('binary_sensor.workday_sensor') == 'on' else 'group.wehw_' %}
          {{ (expand(g+'tgts')|map(attribute='state')|list)[(expand(g+'times')|map(attribute='state')|list).index(states('sensor.time')+":00")] }}

One of the four groups in groups.yaml:

wdhw_times:
  name: Workday hot water timeslots
  entities:
    - input_datetime.wdhw1_time
    - input_datetime.wdhw2_time
    - input_datetime.wdhw3_time
    - input_datetime.wdhw4_time
    - input_datetime.wdhw5_time
1 Like
38

Hey, I have quite a few helpers to add and most of them are duplicates with just the name / ID changing. Is there a quick way (yaml / copy & paste, etc) way to add helpers or do I have to do it manually via the UI for each helper? Thanks

39

I did mine manually via the UI: I don’t believe there’s a reasonable way to do it quicker.

EDIT: I was wrong, see @123’s response below. Maybe I should have read the docs…

1 Like
40

Thanks Troon, that’s what I thought but thought it’s better checking before doing it all manually!!

41

Yes, the entire family of input integrations can be configured in configuration.yaml. Making umpteen copies and customizing each name is fast and easy.

1 Like
42

Thanks, what would be the yaml code to add to the configuration.yaml for an input_number helper with these settings:

image
image481×587 18.6 KB

43

Think that would tell it all :slight_smile:

44

Thanks Timo, If I want to split the code for the input helpers in a separate file, e.g input_helpers.yaml, and not in the configuration.yaml file, how would I do that?

45 
input_number: !include input_numbers.yaml

For more information, refer to this:

46

Thanks Taras, I tried that but was looking for a way to have all my helpers in one file, rather than having input_numbers.yaml, input_text.yaml, input_datetime.yaml, input_boolean.yaml, etc.

Also, I can get one helper working but when I add another one I get the following error:

input_number:
  mode: slider
  name: Slider1
  initial: 30
  min: -20
  max: 35
  step: 1

input_number:
  mode: box
  name: Box1
  initial: 30
  min: -20
  max: 35
  step: 1

image