I only have one trigger and action for the - platform: state, entity_id: input_select.bc_hydro_rate1 as per Troon’s example. The other two are for the email triggers: one for bc_hydro_bill_is_ready and one for bc_hydro_higher_rate which change the input_select.bc_hydro_rate to Step 1 or Step 2 respectively. When the automation triggers on email, the input_select changes thus retriggering the automation a 2nd time. I did it this way to allow me to manually change the input_select in case the email triggers fail and still have it change the utility meters.
The first two Numeric State Triggers can be consolidated. An if-then determines which of the two triggers fired. If it’s the Numeric State Trigger, the two service calls use a template to set the correct step number. Basically it reduces the amount of code by at least a third.
Something like this then?
Summary (55 lines instead of 73)
alias: BCHydro - Rate Change (New)
description: ""
trigger:
- platform: numeric_state
entity_id:
- sensor.bc_hydro_bill_is_ready
- sensor.bc_hydro_higher_rate
above: 0
id: Email
- platform: state
entity_id:
- input_select.bc_hydro_rate
to:
- Step 1
- Step 2
from:
- Step 1
- Step 2
id: Select Step
enabled: true
condition: []
action:
- if:
- condition: trigger
id:
- Email
then:
- service: input_select.select_option
data:
option: >
{{ iif(trigger.entity_id == 'sensor.bc_hydro_bill_is_ready', 'Step
1', 'Step 2') }}
target:
entity_id: input_select.bc_hydro_rate
else:
- service: input_number.set_value
data:
value: >
{{ states('input_number.bchydro_step_' + iif(trigger.to_state.state ==
'Step 1', '1', '2') + '_rate') }}
target:
entity_id: input_number.bchydro_current_rate
- service: select.select_option
target:
entity_id: >
{{ area_entities('Tariffed Utility Meters') | select('match',
'select') | list }}
device_id: []
area_id: []
data:
option: "{{ trigger.to_state.state }}"
enabled: true
mode: queued
max: 2
Yes and, if you want, you can trim a few more bits off.
alias: BCHydro - Rate Change (New)
description: ""
trigger:
- platform: numeric_state
entity_id:
- sensor.bc_hydro_bill_is_ready
- sensor.bc_hydro_higher_rate
above: 0
- platform: state
entity_id:
- input_select.bc_hydro_rate
to:
- Step 1
- Step 2
from:
- Step 1
- Step 2
condition: []
action:
- if: "{{ trigger.platform == 'state' }}"
then:
- service: input_select.select_option
data:
option: >
Step {{ iif(trigger.entity_id == 'sensor.bc_hydro_bill_is_ready', '1', '2') }}
target:
entity_id: input_select.bc_hydro_rate
else:
- service: input_number.set_value
data:
value: >
{{ states('input_number.bchydro_step_' ~
iif(trigger.to_state.state == 'Step 1', '1', '2') ~ '_rate') }}
target:
entity_id: input_number.bchydro_current_rate
- service: select.select_option
target:
entity_id: >
{{ area_entities('Tariffed Utility Meters') | select('match', 'select') | list }}
data:
option: "{{ trigger.to_state.state }}"
mode: queued
max: 2
1 Like
The “tilde” operator is new for me!
You can use + if you know all the values are strings. Jinja also provides the ~ operator , which will ensure all values are converted to string first.
I learnt slugify in my version. Every day is a school day here.
1 Like
I don’t think that’s a good use-case for slugify but I may be wrong…
Command Line Options
With the package, a command line tool called slugify is also installed.
Summary
It allows convenient command line access to all the features the slugify function supports. Call it with -h for help.
The command can take its input directly on the command line or from STDIN (when the --stdin flag is passed):
$ echo "Taking input from STDIN" | slugify --stdin
taking-input-from-stdin
$ slugify taking input from the command line
taking-input-from-the-command-line
Please note that when a multi-valued option such as --stopwords or --replacements is passed, you need to use -- as separator before you start with the input:
$ slugify --stopwords the in a hurry -- the quick brown fox jumps over the lazy dog in a hurry
quick-brown-fox-jumps-over-lazy-dog
It’s not that one, it’s the one listed here:
Turns e.g. Step 2 to step_2.
1 Like
This is the perfect use case for slugify. It’s designed to remove nonascii characters, exactly what an entity_id requires.
1 Like
“Hey ma! Guess what I learned in school today?”
One of the few Feature Requests I have posted that was eventually fulfilled.
2 Likes
I wish I understood how/when/why for the different formats ( >, >- and | )
For instance, the UI formats this one this way:
- service: input_number.set_value
data:
value: >-
{{ states('input_number.bchydro_' ~ trigger.to_state.state|slugify ~
'_rate') }}
target:
entity_id: input_number.bchydro_current_rate
but another this way:
- service: select.select_option
target:
entity_id: >
{{ area_entities('Tariffed Utility Meters') | select('match', 'select')
| list }}
device_id: []
area_id: []
but I entered as "{ . . . }"
All equivalent. The - is whitespace control and makes no difference here.
I use single-line with quotes for simple short templates; multi-line with >.
This website explains it all:
Yes and no! Sometimes the editor when switching YAML to Visual to YAML changes to >- and others to just >
My example above was:
- service: select.select_option
target:
entity_id: >
{{ area_entities('Tariffed Utility Meters') | select('match', 'select')
| list }}
device_id: []
area_id: []
But now it changes it to this:
- service: select.select_option
target:
entity_id: >-
{{ area_entities('Tariffed Utility Meters') | select('match', 'select')
| list }}
device_id: []
area_id: []
Is it the time of day or the way I am sitting in my chair??? 
It doesn’t matter in such cases. I don’t know why such things happen, but the amount of whitespace doesn’t matter. HA will trim whitespace anyway, and even parse it to the right data type.
I never worry about it as I toggle it back and forth to let it decide and as long as I can save it then everyone should be happy. It was just a “What the heck? Make up your mind!”
Thanks for the link to the info!
P.S. The trace engine seems to sometimes have a different opinion on ’ vs ". I’ve seen “{{ ‘…’ }}” displayed as ‘{{ '…' }}’ so I’ve changed it to ‘{{ “…” }}’ only to have the automation/script editor change it to "{{ "…" }}'. Just a little confusing. I now only use “{{ … ‘…’ … }}” and try and ignore what I see in trace.
I exclusively use > at all times. There’s no reason for anything else unless you’re in the markdown card, or a notification.
1 Like
The UI automation editor exclusively uses '{{ '' '' }}' at all times. '' is an escaped single quote. Regardless what you use, if you go to the UI editor and then back, it will be '{{ '' '' }}'
1 Like