Help with Schedule Implementation

I’m trying to set a schedule for an air purifier. As well as being on/off at certain time I need to change the Mode attribute of the air purifier at different times of the day.

My schedule is as follows (defined in UI so no YAML available):

My automation is as follows:

- id: "1736946889366"
  alias: Lounge Purifier Scheduler
  description: ""
  triggers:
    - trigger: state
      entity_id:
        - schedule.lounge_purifier
  conditions: []
  actions:
    - if:
        - condition: state
          entity_id: schedule.lounge_purifier
          state: "on"
      then:
        - type: turn_on
          device_id: f258b002dc83cd56d74794f10749b51c
          entity_id: 7dda71bdcbb662bae31c906906399da8
          domain: switch
        - device_id: f258b002dc83cd56d74794f10749b51c
          domain: select
          entity_id: 35f4b5b7ecb7c16b68ee79f273a351ad
          type: select_option
          option: "{{ state_attr('schedule.lounge_purifier', 'mode') }}"
      else:
        - type: turn_off
          device_id: f258b002dc83cd56d74794f10749b51c
          entity_id: 7dda71bdcbb662bae31c906906399da8
          domain: switch
  mode: single

However I get the error:
Error: Option {{ state_attr('schedule.lounge_purifier', 'mode') }} is not valid for entity select.air_purifier_1_mode, valid options are: Off, Auto, Eco, Max, Low, Med, High

What is going wrong here?

Device actions do not support templates. Do not use device actions, ever, if it can be avoided. They may be easy to create in the visual editor but makes code difficult to read.

Instead use a select.select_option action. (And while you are at it, replace the preceding device action with a switch.turn_on action.)

Thanks.

I had no idea about that limitation of the Device Actions, as you say, the UI sort of pushes you towards these now.

Works as follows:

alias: Lounge Purifier Scheduler
description: ""
triggers:
  - trigger: state
    entity_id:
      - schedule.lounge_purifier
conditions: []
actions:
  - if:
      - condition: state
        entity_id: schedule.lounge_purifier
        state: "on"
    then:
      - action: switch.turn_on
        metadata: {}
        data: {}
        target:
          entity_id: switch.air_purifier_1_power
      - action: select.select_option
        metadata: {}
        data:
          option: "{{ state_attr('schedule.lounge_purifier', 'mode') }}"
        target:
          entity_id: select.air_purifier_1_mode
    else:
      - action: switch.turn_off
        metadata: {}
        data: {}
        target:
          entity_id: switch.air_purifier_1_power
mode: single

It is a very arbitrary limitation, as many such limitation in HASS are. Feels like whomever wrote the device action parser simply forgot to add a line that passes any optional arguments through the template renderer and then never got around to fixing it. Most such bug reports filed through GitHub Issues sadly seem to never be read by anyone and much less fixed unless you do it yourself.

My understanding is that it’s by design.

Device-oriented trigger/condition/action was designed for novices. Select a device (virtual model of a physical device) and the UI is able to present its capabilities.

Templating is an advanced subject, requiring familiarity with Jinja, so it wasn’t included in a feature intended for a novice audience.

The way I look at it, novice users wouldn’t be affected either way if templates were supported, thus there is no reason for not supporting them.

Intermediate users however are harmed by the exclusion of templates, as they begin to learn more about HASS but cannot understand why this newfangled thing they just learnt about does not work when attempting to make their existing novice automations do more advanced stuff. Hence why I believe that templates should just work everywhere, always.

Having been both novice and intermediate user, I never felt “harmed” by it because I consciously chose not to use them.

It’s a feature for novices and, having progressed from that stage, I prefer to use the vast array of non-device-oriented triggers/conditions/actions.

In your linked post, you indicated your PRs were rejected. Can you post links to them? I’d like to see the reasons given. Or if you recall them, and don’t mind, please share them here. Thank you.