Rest_command with variable URL using GET

I’m at a loss here, I’ve search and found some solutions to similar issues but can’t seem to find the solution to my problem. What I currently have is an input_select and a rest_command

    name: 'Fan mode'
      - Automatic
      - Low
      - Middle
      - High
      - Vacation

    url: ",{{fanmode}}"

Then I’ve got an automation:

- id: set-fan-mode
  alias: 'Adjust Fan Mode'
    - platform: state
      entity_id: input_select.fan_mode
    service: rest_command.set_fan_mode
      fanmode: >
        {% set mapper =
            { 'Vacation':'NOTHOME',
              'High':'LOW' } %}
          {% set state = states('input_select.fan_mode') %}
          {% set fanmode = mapper[state] if state in mapper %}
          {{ fanmode }}

Changing the state results in two logbook entries, one saying that the Fan Mode has been changed. The second saying that my automation has been triggered. Then after that, nothing happens and I see an error in the home assistant log: “Uncaught TypeError: Cannot convert undefined or null to object”. I’ve tried adjusting the automation from ‘data’ to ‘data_template’ to no avail. What am I missing here?

This proves that rubber ducking works: data_template is the correct part and my command was incorrect: it was supposed to have lowercase ‘cmd’ rather than uppercase ‘CMD’ in it :sweat_smile:

You definitely need data_template instead of data. Also try:

{% set fanmode = mapper[state] if state in mapper else 'AUTO' %}

Or maybe get rid of the if ... part and add a condition to the automation:

    condition: template
    value_template: >
      {{ trigger.to_state.state in ('Vacation',
                                    'High') }}

BTW, you can also change:

          {% set state = states('input_select.fan_mode') %}
          {% set fanmode = mapper[state] if state in mapper %}
          {{ fanmode }}


          {{ mapper[trigger.to_state.state] }}
1 Like

Thanks for especially this piece! I also didn’t know about the conditions yet, that’s pretty great :slight_smile:

FWIW, not sure how input_select.fan_mode could be anything but one of the specified values. So checking shouldn’t be necessary.

Well, the input_select can’t be another value so I don’t have to check that one, but I also update the input_select state with another sensor (REST call). The result of the REST call can be NaN. So that’s why it’s nice to know :slight_smile:

Wait, you have something that sets the value of an input_select to something other than one of the defined options? That shouldn’t be possible, at least via the input_select.select_option service. So how are you updating it?

No, it tries to set it to one of the possible values. However the REST endpoint that it uses to set the value can return a 0,1,2,3,4 or NaN. I’ve added the condition there to only update the input_select when the value is within 0…4.

1 Like