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:
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.
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.
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.
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…
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>
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.
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.
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.
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.