Command line switch, command_state wont work

Configuration
1

Hello!

I am trying to create a command line switch to turn on/off PoE ports in my PoE-switch, my on/off script works fine, but the command_state-part does not. HA always shows the switch as “off”.
What have i done wrong?

State-script:
#!/bin/bash
.... code ...
# $status 1 = port ON
# $status 0 = port OFF
if [ $status = 1 ]; then
        exit 0
else
        exit -1
fi

Config.yaml-part
  - platform: command_line
    switches:
      poe_port_1:
        friendly_name: 'PoE Port #1'
        command_on: /home/homeassistant/.homeassistant/scripts/poe 1 true
        command_off: /home/homeassistant/.homeassistant/scripts/poe 1 false
        command_state: /home/homeassistant/.homeassistant/scripts/poe_state 1
2

Why are you returning exit codes rather than just outputting the status number?

3

I don’t use command line switches, but I do use a command line cover.
The documentation for a command line switch says that it uses return code 0 to determine the state.
BUT.
In my cover it is the value in STDOUT, not the return code that determines the value.
It would be worth a try to ECHO 0 in your status script and see if that solves the problem.

4

Ok, got it to work with adding “value_template: ‘{{ value == “1” }}’”, changed everything to:

State-script:
#!/bin/bash
.... code ...
# $status 1 = port ON
# $status 0 = port OFF
if [ $status = 1 ]; then
        echo 1
else
        echo 0
fi

Config.yaml-part
  - platform: command_line
    switches:
      poe_port_1:
        friendly_name: 'PoE Port #1'
        command_on: /home/homeassistant/.homeassistant/scripts/poe 1 true
        command_off: /home/homeassistant/.homeassistant/scripts/poe 1 false
        command_state: /home/homeassistant/.homeassistant/scripts/poe_state 1
        value_template: '{{ value == "1" }}'
5

Hi, im trying to setup a command line cover, but cant seem to get the state to update.

cover:
 - platform: command_line
   covers:
   garage_door:
    command_open: "curl --silent -X GET https://maker.ifttt.com/trigger/Garage_Opened/with/key/key?value1=Opened"
    command_close: "curl --silent -X GET https://maker.ifttt.com/trigger/Garage_Closed/with/key/key?value1=Closed"
    command_state: "/config/gogogate/check_garage_Sensor.sh"
    friendly_name: 'Garage Door'

 sensors:
    gate_gogogate2dash:
      value_template: >-
        {%- if is_state('sensor.gate_gogogate2', '0') -%}
        Closed
        {%- elif is_state('sensor.gate_gogogate2', '100') -%}
        Open
        {%- else -%}
        Closed
        {%- endif -%}

script

#!/bin/bash
R=`curl --silent -X GET http://10.0.4.6:8123/api/states/sensor.gate_gogogate2dash?
api_password=pass | jq -r '.state'`
if [[ $R == "Closed" ]]; then
echo "0"
  else
echo "100"
fi

I send an API call to update the sensor.gate_gogogate2 entity to “0” for closed or “100” for open. When i run the shell script, it works perfectly returning 0 & 100 when send an update to the sensor.gate_gogogate2 entity.

But somehow, the command_state: command just seems to be ignoring the value and not updating the status of the door ?

any ideas ?

6

Are you sure your script lives at /config/gogogate/…
If it really is there, then you probably have a permissions issue, or a path issue with the account that runs Home Assistant.
You can troubleshoot those kinds of problems by outputting data to text files to see what is happening.

7

Thanks Treno,

I finally gave up going down this route and removed the command_state: command.

I used the HA’s restAPI to update the cover status directly and it worked perfectly.

8

I think some of the confusion around this state_return using value_template is that it behaves differently with the value template. It doesn’t make sense but these appear to be the rules:

If you specify a template using value_json == and your command outputs a json formatted value you MUST return a status (exit 0) of 0 or the json value will not be used by home-assistant. I am not aware that this is documented anywhere. Be aware that debugging this can be difficult because non-zero returns allow the switch to go the default value (False!) which is the expected behavior, but there will be an error in the log. So that means you cannot have a command that returns the value both as a status and a json value (as I did), because you will only have your json read by home-assistant if the value returned is 0 (exit 0)

If you don’t specify a template, and just use the exit value, then that value is used by command_state as if command state did a value_template: ‘{{ return_value == 0 }}’. I am not aware if return_value can be used or not but saw it in this thread.

If you specify a template using value == then the value of “value” is the entire output of the command (apparently) not the return value. So if you output “on” the value of “value” should be “on”. In this case it is still unclear as to whether the exit value must be 0 or not, because my earlier testing which appeared to work was probably confused by the “default is False” condition of switches.

Hope that helps someone.

The documentation that does exist for this is spare and does not document the relationship between exit value and how home-assistant processes output, however what documentation that does exist is here under “Processing incoming data”: https://home-assistant.io/docs/configuration/templating/#processing-incoming-data

9

The following is working for me:
I have an external PHP script that turns lights on and off according to a schedule (I have not yet ported this to HA but I wanted to control it through HA at least) - so I did the following:

  light_schedule_switch:
    command_on: "/usr/bin/curl -X GET http://192.168.1.65/api/hue/v1/schedule/?on"
    command_off: "/usr/bin/curl -X GET http://192.168.1.65/api/hue/v1/schedule/?off"
    command_state: "/usr/bin/curl -X GET http://192.168.1.65/api/hue/v1/schedule/"
    value_template: '{{ value_json["light_schedule"]["state"] == "on" }}'
    friendly_name: Light Schedule Switch

With …/api/hue/v1/schedule/ returning the following JSON:

{"light_schedule": { "updated" : "2018-02-12 17:29:25", "state" : "off", "expires" : ""} }

Happy automating,
/Tonkin