Yes, that’s an automation. I keep my automations as documented here:
1 Like
Thanks for the tip Troon, I’m working through your code it it’s making sense, just need to edit bits to include my TRV temp setting.
1 Like
For future reference, a Time Trigger also accepts an input_datetime.
trigger:
- platform: time
at:
- input_datetime.time_1
- input_datetime.time_2
- input_datetime.time_3
- input_datetime.time_etc
3 Likes
Are there 4 or 5 daily Start Times in your requirements?
Can be any where from 5-7 but also separate ones for scheduling for weekdays & weekends.
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
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!!
I’m confused about the day variable declaration. What’s that doing?
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
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?
Yeah, so no reason not. Would even make a lot more sense to me 
Thanks Timo, Was just checking it won’t break the code for the automation. 
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 .
1 Like
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 !!
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
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
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
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
Thanks Troon, that’s what I thought but thought it’s better checking before doing it all manually!!
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