Shell_command fails

Configuration
1

I’ve had to reinstall a previously working installation and am having a problem with shell_commands not executing. Same valid YAML, valid command for user homeassistant in the activated virtual enviroment. I set up a test to see if the shell_command was executing at all:

shell_command:
  test: touch /tmp/hass-shell-command-test

the file doesn’t write. But there’s no error reported by the log:

2017-05-22 22:17:57 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: service_call_id=3047287024-3, service_data=, domain=shell_command, service=test>

It’s being called by Alexa (successfully, Alexa Service Simulator gets the expected response) as an intent:

alexa:
  intents:
   test:
      action:
        - service: shell_command.aten2
        - service: shell_command.marm3
        - service: shell_command.test

This is a command that requires no permissions and any user should be able to run it. What would account for shell_command failing to execute and failing to generate an error?

2

I just set up this exact shell command and it is working fine.
My recommendation on troubleshooting this configuration is to break it down into parts.

Part 1: Can I get the system to do what I want
I will create a shell script file to do what I want it to do. Make the script file executable, then execute the script to ensure it does what I want it to do. I do all this from the terminal, not from home assistant. I’m always careful to include full paths in these scripts because I’m not always sure the environment that the script will be executed under. I also usually log something to a file so I can see that the script ran.

Part 2 : Can I get HA to do it
I create a shell_command object that runs by script file, and an automation that calls my script shell_command object. Then I expose the automation to the User Interface. Then I open the user interface and trigger the automation from there. Then I go check the results. Did the script run? Did it do what I expected

Part 3 : Can I trigger the automation that I want.
Here I will add a simple notification to the trigger. That way I will know if that the trigger executed when i get the notification. Here I would use Alexa or whatever other automation means I wanted to trigger the automation.

Part 4: Put it all together.
Now that I have each part working separately, I can add them all together to a working automation.

3

agreed with @treno - my guess would be user/permissions on the shell script or the file in /tmp

4

Yeah, I don’t think it can be permissions at the level of the test I’m running – the /tmp directory is 777 and any users can touch a file – this is what makes it a valid test if the shell_command is actually firing. There may be a permissions issue that’s keeping HA itself from executing ANY shell command, which is what I’m hoping someone in this forum has come across.

5

Thanks, Treno, that’s good solid practice. But that’s the problem: I took not only my irsend commands that I want to fire but also my “touch /tmp/make-a-file-to-show-me-you-are-working” through all those steps: I can run them in the environment, as the Homeassistant user.

HA clearly thinks it fired my shell_command, (though is that shell_data= object supposed to be blank?) but it didn’t touch a file. So I’m guessing that either there’s a permission issue at a higher level that’s stopping HA from executing ANY shell command, or the content of the command is getting lost before it fires.

What I’ll try now though is externalising that touch command in a bash script and see if it’ll run that.

6

have you tried running it through bash?

e.g.
/bin/bash -c “script.sh”

Also from memory if you turn up the log level you get more info on the calls.

7 
alexa:
  intents:
   test:
      action:
        - service: shell_command.aten2
        - service: shell_command.marm3
        - service: shell_command.test

I’m wondering if the “test:” part here causing some weird problems? indentation compared to previous row is just 1 space and compared to next row it is 3 spaces.
Just guessing, as having experienced my share of weird HA errors caused by erroneous indentations in my config files…

8

Would be interested to hear your findings -I cannot get Home-Assistant to execute any shell_commands. I am assuming it is permissions but everything I’m executing has 777. It works in the command line

sudo /usr/bin/omxplayer /usr/share/sounds/alsa/FrontDoorOpen.m4a

shell_command:
play_sound: sudo /usr/bin/omxplayer /usr/share/sounds/alsa/FrontDoorOpen.m4a

When I call the service from the DEV Tools ->Web UI
2017-05-23 16:48:28 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: service_call_id=1978433296-21, service_data=, service=play_sound, domain=shell_command>
2017-05-23 16:48:28 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_executed[L]: service_call_id=1978433296-21>

9

I use this with my pi and omxplayer

  play:
    command_on: 'omxplayer /home/pi/mp3/play.mp3'
    command_off: 'omxplayer /home/pi/mp3/play.mp3'
10

Do you put that in your configuration.yaml?

11

Yes, as a command line switch but the same should work for shell command.

12

Tried this, but all attempts to route around the issue with an externalised bash script failed, as I suspected it would given touch wasn’t working. The issue was deep inside HASS, python, or the virtual environment.

In the end, I had to bite the bullet and clean install without an adequate diagnosis of what went south.

It MIGHT have been the use of these instructions to set up homeassistant as a service run by user @pi instead of homeassistant (my subsequent clean install which has been beautifully stable and carefree used the pip3 install method here instead. Whether the install itself had permission issues or I screwed them up with subsequent package installs that presumed the more conventional homeassistant user, I don’t now know.

My other guess was that my python installation was FUBARed by an ill-advised attempt to install certbot with apt-get, and the subsequent attempts to get around an “illegal instruction” message by pulling upgrades from the Jessian testing repository. (Yeah, I hear you, but I was desperate…) For anyone coming across this thread in a similar situation, let my shipwreck be your lighthouse: Use the wget method here to install certbot-auto on a debian 8 pi install, not apt-get. This is the only set of instructions you need.

And if anyone encountering this weird inability to run a shell command either used that @pi user install or the apt-get certbot routine, drop a comment here. One I’m curious, and two, I’d love to know what advice I followed to steer people away from: I don’t wish this particular nightmare on anyone.

Apple Pi Baker FTW, btw. My clean install cost me a day’s work, and I’m backing that puppy up.

13

That didn’t help this particular issue, but spiffy – I’ll give that a try.

14

Try replacing everything after play_sound: with

touch /tmp/shell-command-is-working.txt

Run it, and do

ls /tmp

If you see a file named shell-command-is-working.txt the problem isn’t the one reported here of shell_command not executing, it’s something in your syntax or permissions. The one really useful thing this disaster taught me was a good solid test for whether shell_command is working or not!

If you DON’T see that text have a look at my final report on why I think my installation was failing and see if any of it matches your situation.

15

Thanks, but alas no. The yaml here was a very robust and proven file that had worked in a previous install, and it verified valid. test: was one of a dozen alexa intents at the same level of indentation, and all worked insofar as Alexa found and fired them and reported back happy. What was failing was between HASS and the operating system – the shell_command just didn’t fire.

17

I was just looking at your config and want to make sure your indentation is correct.

a38888afd3.png" width=“614” height=“236”>

18

@RobDYI thanks for the help that worked -> Stupid was missing the single quotes.