Command_line sensor using a template

I have many command_line sensors in this form that all work well using virtually the same command - only the line name is different. In this case “central”.

  - sensor:
      name: TFL Central Line
      unique_id: tfl_central
      command: >
        curl https://api.tfl.gov.uk/Line/central/Status?true 2> /dev/null
        | jq '{"name": .[].name, "lineStatuses": [.[].lineStatuses[] | {"description": .statusSeverityDescription, "reason": .reason}], "lineTypes": [.[].serviceTypes[] | {"name": .name}]}'
      value_template: *line_state
      json_attributes: *line_attributes
      command_timeout: 55

But I want to use a macro to define the repeating command line like this

  - sensor:
      name: TFL TEST Central Line
      unique_id: tfl_test_central
      command: >
        {% set line = 'central' %}
        {% from 'command_line.jinja' import tfl_line_status %}
        {{ tfl_line_status(line) }}
      value_template: *line_state
      json_attributes: *line_attributes
      command_timeout: 55

Macro:

{% macro tfl_line_status(line) %}

    curl https://api.tfl.gov.uk/Line/{{ line }}/Status?true 2> /dev/null | jq '{"name": .[].name, "lineStatuses": [.[].lineStatuses[] | {"description": .statusSeverityDescription, "reason": .reason}], "lineTypes": [.[].serviceTypes[] | {"name": .name}]}'

{% endmacro %}

In the template dev tool the macro returns the correct command

But the sensor itself is unknown

Any suggestions as to why this won’t work?
Thanks

Have you tried a macro that outputs something much more simple, like say just an “echo” command? To figure out whether Jinja imports even work at all for this integration/type of sensor…

Unknown typically means the sensor and it’s template is correct but it just hasn’t ran the query yet. Have you waited?

As a sidebar, you can likely turn this into a responding service with a command_line command and use template sensors instead. Then you can trigger whenever you want to only hit the APIs when you need them. Food for thought.

That method also allows you to test the service whenever you want and look at the response.

Yes, I’ve waited and done an update_entity to check.

Referring to your ‘sidebar’ because it seems like a good approach…

Did you mean to create a shell_command which provides a useful response (returncode, stdout and stderr)?

shell_command:
  tfl_test_command: >
      curl https://api.tfl.gov.uk/Line/bakerloo/Status?true 2> /dev/null | jq '{"name": .[].name, "lineStatuses": [.[].lineStatuses[] | {"description": .statusSeverityDescription, "reason": .reason}], "lineTypes": [.[].serviceTypes[] | {"name": .name}]}'

Here is the template I set up to hold the response

template:
  - trigger:
      - trigger: time_pattern
        minutes: 5

    action:
      - action: shell_command.tfl_test_command
        response_variable: tfl_test_command_response

    sensor:
      - name: TfL Test Command
        unique_id: tfl_test_command
        state: >
          {{ tfl_test_command_response.returncode }}
        attributes:
          stdout: >
            {{ tfl_test_command_response.stdout }}
          stderr: >
            {{ tfl_test_command_response.stderr }}

The problem with that seems to be that jq is not accessible however I’m (still) not as proficient in Linux as could should be so it could be anything.

However in any case I wonder if I have understood your suggestion correctly as I am not sure how I can ever pass a line name into the shell command, which would look like this (if I could):

shell_command:
  tfl_test_command: >
      curl https://api.tfl.gov.uk/Line/{{ line }}/Status?true 2> /dev/null | jq '{"name": .[].name, "lineStatuses": [.[].lineStatuses[] | {"description": .statusSeverityDescription, "reason": .reason}], "lineTypes": [.[].serviceTypes[] | {"name": .name}]}'