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
Thanks, what would be the yaml code to add to the configuration.yaml for an input_number helper with these settings:
Think that would tell it all
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?
input_number: !include input_numbers.yaml
For more information, refer to this:
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
It’s split by domain, not by random groupings of domains.
The documentation link, supplied by septillion, contains an example showing the correct format. For your convenience, here it is:
# Example configuration.yaml entry
input_number:
slider1:
name: Slider
initial: 30
min: -20
max: 35
step: 1
box1:
name: Numeric Input Box
initial: 30
min: -20
max: 35
step: 1
mode: box
Notice that it specifies the domain input_number: just once and not before each entity.
Also, if you split all input_numbers into a separate file then you don’t include input_number: at the beginning of the file.
Ahh, thanks, I was including the input_number: at the start
You can do that using “packages”:
Hey Guys
I am trying to get 123 solution work work.
I have made the helpers but there seems to be a problem with the code.
When the automation is run it does not change / set the temperature of the TRV.
I looked at the logbook and the automation is getting triggered by the time set in the input.datetime.workday_x helper (so that part is working):
However, when I check the:
> show trace > trace timeline
for the automation I see the following error:
I have tried to troubleshoot the issue but am not getting anywhere. In > developer tools > template > I added the code {{ [states('input_boolean. day_' ~ now().isoweekday())] }} and that works when I toggle the helper, so the first part of the code is working.
Also the next bit of code (is_state(day, 'on') and 'workday' in trigger.to_state.object_id) is working:
You can see it returns the value input_boolean.day_6 and correctly setting day “6” (which is today, Saturday).
When I combine the 2 codes i get this:
However, when I add the code "test": ('input_boolean.day_' ~ now().isoweekday()) I get the following error:
From this the only thing I can conclude there is an error with the variable ‘day’:
I really don’t know what else I can do so looking for help from the community, and thanks in advance!!
The following message is misleading:
Choose: Error: undefined
It simply means none of the choices in choose evaluated to True and so no action was taken. I reported this misleading message as an Issue in the Core repo nine days ago. Balloob created a PR to correct it and in the next version (2021.5) it will appear as:
Choose: No action taken
Your experiment is flawed and I have no idea why you chose to use dicts and lists in it to handle strings.
1 Like