Change all Utility meters to new Tariff that have a Label

I have a helper sensor that outputs the current TOU for hydro rates “Off-Peak, On-Peak, Mid-Peak”

I want to create an automation that is triggered when this sensor’s state changes. When it changes I want to take the value it just changed to and update all my Utility Meters that have a label of “utility_meter_tou”

here is what I have so far but it does not seem to be working:

action: select.select_option
metadata: {}
data:
  option: "{{ trigger.to_state.state }}"
target:
  label_id: utility_meter_tou

But this does not seem to change any of the utility meters that have this label. What am I doing wrong here?

These Utility Meters have the tariffs set to these exact value the sensor above it outputting. So there is not a issue of the names are wrong from the sensor value not matching a value in the Utility Meter

That’s not how the tariffs feature is supposed to work. Your target needs to be select entities, not the sensor entities of your utility meters.

So either label the select entities instead of the utility meter entities, or create a template to change those entity domains from sensor to select and remove the tariff suffix from each one.

The helper sensor I created that outputs the “On-Peak, Off-Peak, Mid-Peak” all that does is triggers the automation when it changes, there are no issues with that sensor and it works as expected. When the automation is triggered it should take the value form that sensor and set all the utility meter selects to that value…

Each one of my utility meters have the tariffs On-Peak, Off-Peak, Mid-Peak on them and the primary meters are selects

Then what you have should work. Share the automation trace to debug what is not working. I particularly would want to see the content of the trigger variable.

Also, you can test the action in develop tools → actions. See if you can change the tariffs there. Use the UI method first, then once it works switch over to the YAML mode to see what the code looks like.

I can confirm I am able to change multiple labeled utility meters using the same code you posted.

Awesome I never knew about the automation trace, thank you that was quite helpful and it helped me find the error:

Option unavailable is not valid for entity select.dryer_utility_meter, valid options are: On-Peak, Off-Peak, Mid-Peak

for some reason '{{ trigger.to_state.state }}' is evaluating to unavailable. Why would that be evaluating to unavailable as its a helper and basically can’t be unavailable?

YAML if it helps!

id: '1733370568519'
alias: Hydro - TOU Change
description: >-
  When the helper for TOU changes to a new value, update the parent utility
  meter to the new TOU tariff
triggers:
  - trigger: state
    entity_id:
      - sensor.hydro_current_tariff
    to: null
conditions: []
actions:
  - action: select.select_option
    metadata: {}
    data:
      option: '{{ trigger.to_state.state }}'
    target:
      label_id: utility_meter_tou
    alias: Update All Utility Meters to New TOU
mode: single

You’d have to share your code for the helper. I assume it is a template helper, and depending on the template code it definitely can render to be unavailable.

You can set your automation to not be triggered by unavailable, but I would not recommend doing that because it is only going to mask the problem. You should instead solve it at the source, which is by fixing the template helper.

For learning purposes, here is how you would modify your automation to avoid those triggers, but to repeat: I would not advise doing this in your case.

triggers:
  - trigger: state
    entity_id:
      - sensor.hydro_current_tariff
    not_to:
      - unavailable
      - unknown

Looking at the history for the helper it has never gone into unavailable

{% set date = now() %}
{% set isHoliday = is_state('calendar.canada_on', 'on') %}
{% set isWeekend = date.isoweekday() in [6,7] %}
{% set isSummer  = date.month in [5,6,7,8,9,10] %}

{% if isWeekend or isHoliday %}
  {% set lookup = 'OOOOOOOOOOOOOOOOOOOOOOOO' %}
{% elif isSummer %}
  {% set lookup = 'OOOOOOOMMMMPPPPPPMMOOOOO' %}
{% else %}
  {% set lookup = 'OOOOOOOPPPPMMMMMMPPOOOOO' %}
{% endif %}
{% set map = {'O': 'Off-Peak', 'M': 'Mid-Peak', 'P': 'On-Peak'} %}
{{ map[lookup[now().hour]] }}

That’s my code for the helper sensor. Its been rock solid for a month in the history and never shows unavailable. Also I am manually changing the value to trigger the event so it should be available no as I am hard coding the output?

Is it possible because I am editing the helper that its unavailable?

Sorry for the last minute edit… using the Dev tools > States it returns the proper state.

I’m not sure what’s happening here. I assume you’re editing the state by overwriting it in developer tools → states? If so, that should be fine. I’m also assuming the state goes back to normal at the start of every minute, because that is when your template sensor should refresh.

Does the automation error out every single time you attempt to override the state,

Can you share the whole trace? You can use a site like dpaste.org instead of pasting it here.

Found the issue and possibly a bug…

Again I am still learning so maybe blame this non issue on me… I was changing my code on the helper sensor to change the output value of the sensor to get the automation to trigger… this always seems to result in {{ trigger.to_state.state }} resolving to unavailable.

BUT I had no clue you could change the state in the Developer Tools > States, I thought this was only used to look at the current value… DUH…

By changing it in the dev tools it works as expected!! THANK YOU!!! There was no error in the code as you said… I feel like such an idiot but at the same time why would editing the code which forces an new output for the sensor return unavailable? I feel like that is a bug no? Or is it known to not do that and it is a learning cure of the platform :slight_smile:

I was able to replicate the status of a template sensor briefly changing its state to unknown when the template is edited and saved from the UI.

It’s hard to say that it’s a bug, but I’m no expert.

I did also identify somewhat similar behavior with a template sensor that is defined in YAML instead of the UI. But in that case, after it is modified in YAML and then the template entities are reloaded, is seems like the sensor actually gets deleted for a split second because an automation will trigger and the from_state will be null (and I don’t mean from_state.state being null, I am actually referring to the entire state object being null).

Nowhere is it documented what should happen to the state of a template sensor for the split second after you change & save it. So it’s definitely undocumented behavior. But whether it’s a bug is probably a stretch.

Yeah I’m no expert either. I posted on their GitHub and let them figure it out…

Thank you for all the help BTW. really appreciate it!!

1 Like