Command line switch, state command with value template broken

Configuration
1

Hello there,
I use a command line switch to control the state of my own traccar server. Until recently (a few weeks perhaps?) everything was fine. But then the state of the switch stopped working. I still can use the “on” command, but then the switch falls back to “off” state and doesn’t update.

I tried checking the commands manually, which works fine, and checked the value template in the templating checker, which returns “false” which is fine, as i can’t give the commandline response to it as a value. But anyways: the syntax seems to be OK.

Here’s the code.

- platform: command_line
  switches:
    traccar_switch:
      command_on: "/usr/bin/traccar"
      command_off: "ps -eaf | grep traccar | grep -v grep | awk '{print$2}' | xargs kill"
      command_state: "ps -ef | grep traccar"
      value_template: "{{ 'java' in value }}"
      friendly_name: Traccar schalter

Please help me to see what is going on, and why HA stopped to show the state of my traccarswitch
Greetings

Blubbel

2

I might miss something myself, but what is “value” supposed to be in {{ 'java' in value }}

3

regarding to the documentation i understood “value” to be the return of the command_state: command.

And in the value template it is used jinja-conform for a check if the left statement is contained in the right. At least i understood it like that

4

Oh, right. And what’s the actual output of ps -ef | grep traccar when the app is running?

5

it returns:

pi        5165     1 95 18:22 ?        00:00:13 java -jar tracker-server.jar conf/traccar.xml
pi        5185  5142  0 18:23 pts/0    00:00:00 grep --color=auto traccar

which very clearly contains the string “java”. When not running the command returns only the second line

6

anybody here able to help me with this? i have tried n versions of command_state and value_template now. nothing seems to work.
the documentation is way to sparse to help me with this. I’m grateful for any hints how to produce working commandline switches with state

7

I’ll keep writing, to document my findings, also perhaps somebody runs in to the same problem.
First to know: I do NOT use Docker, my homeassistant is a clean core install on a minimal raspbian. So Problems between host and Container can’t be the issue.
Instead it seems to be the case that homeassistant uses sh as a shell which means many things do not work, and even whole scripts, called with /bin/bash fail at certain points (using of awk or xargs), to make it more complicated: Every of the following commands has been testet with the user running homeassistant, with bash an sh, and they always work. But if i want to use them as state or off command they behave different.

echo foo

works fine.

ps -ef

does work but is pretty useless

ps -ef | grep forecast

same

ps -ef | grep forecast | grep -v grep

fails with “grep not found”

pgrep -f forecast_server.py

works fine, but always returns 0, and i still haven’t found a way to parse the stdout response for “value”
and last:

pkill -f forecast_server.py

works in no iteration (with /bin/bash, as /usr/bin/pkill …)
Just

/bin/bash pkill -f forecast_server.py

gives me a slightly helpful hint: /usr/bin/pkill: /usr/bin/pkill: cannot execute binary file

Has anybody an idea how to find out what works in hass and what not without guessing? Or preferably a method to force hass to simply use bash. I would like to have it back like about december 2020, where it just worked with the setup in my first question. This starts to get really annoying. (I’m using the python-forcast thingie now, because the traccar does not like being killed, revived and killed again in rapid succession, but the commands were identical)

8

In a python venv?

always use full paths.
/usr/bin/grep

9

Thanks for your answer!

no, basic system python 3.9

Ah, Sorry, forgot to mention this: I tried with direct paths. But for every command i listed there is no difference in behaviour when using $command or /usr/bin/$command
just when using /bin/bash in combination it complains as aforementioned.

It really looks like there is a special reduced set of instructions, and even using /bin/bash $script.sh results in failure if using one of the “unknown forbidden words”