Another "Issues Running Script With executeCommandLine/ Exec Binding" Topic

Hi all,

I am trying to run a command that turns on my TV. I’ve searched around and have seen lots of solutions, none of which have worked for me. There were some solutions that involved changing permissions and I’m not sure if I properly tried any of those. Here’s what I have done:

Switch tvSwitch “TV” [ “Switchable” ]


rule "tv on"
        Item tvSwitch changed from OFF to ON
        var string results = executeCommandLine("echo on 0 | cec-client -s -d 1", 6000)
        logInfo("execTest", results)

Log Entry After Switching tvSwitch to ON
2017-06-28 21:54:34.902 [INFO ] [ipse.smarthome.model.script.execTest] - on 0 | cec-client -s -d 1

I also tried putting the command in a .sh file and running the .sh script instead. No luck.
I have also tried putting creating a Thing with the exec binding and attaching that to the tvSwitch item. The log output from that is:

Log Entries Using Exec Binding
2017-06-28 22:04:59.245 [TRACE] [hab.binding.exec.handler.ExecHandler] - The command to be executed will be 'echo on 0 | cec-client -s -d 1’
2017-06-28 22:05:59.393 [DEBUG] [hab.binding.exec.handler.ExecHandler] - Exec [OUTPUT]: 'on 0 | cec-client -s -d 1’
2017-06-28 22:05:59.471 [DEBUG] [hab.binding.exec.handler.ExecHandler] - Transformed response is ‘on 0 | cec-client -s -d 1’

Like I said, I've seen a lot of similar issues on various forums but can't tell if I've really directed my efforts well enough to try all the different solutions. If someone can try walking through some of the trial-and-error process here with me I'd really appreciate it.

The good news is it is executing the command in the first place and no errors are being generated. The bad news is it is treating “on 0 | cec-client -s -d 1” as the string to echo. In other words it is not piping the output but treating the whole thing as one big string to echo.

One thing to remember when using the Exec binding, it does not behave the same nor does it have the same capabilities as when running in the shell.

In this case I would try the following for the command to see if it works:

"echo 'on 0' | cec-client -s -d 1"

What was the output when you ran the shell script?

Hi Rich,

I’ve seen you help out several other people with similar Exec Binding / executeCommandLine issues before so thanks for chiming in here!

I put single quotes in like you suggested and the output doesn’t change much:

2017-06-29 13:54:52.787 [DEBUG] [hab.binding.exec.handler.ExecHandler] - Exec [OUTPUT]: ''on 0' | cec-client -s -d 1'
2017-06-29 13:54:52.803 [DEBUG] [hab.binding.exec.handler.ExecHandler] - Transformed response is ''on 0' | cec-client -s -d 1'

Sorry for the formatting following… not sure why it’s not displaying correctly.

Regarding the output when running the shell script:


echo on 0 | cec-client -s -d 1


Thing exec:command:tvOn [command="/etc/openhab2/scripts/", interval=15, timeout=5, autorun=false]


2017-06-29 14:01:50.116 [TRACE] [hab.binding.exec.handler.ExecHandler] - The command to be executed will be '/etc/openhab2/scripts/'
2017-06-29 14:01:50.189 [DEBUG] [hab.binding.exec.handler.ExecHandler] - Exec [OUTPUT]: '* failed to open vchiq instance'
2017-06-29 14:01:50.203 [DEBUG] [hab.binding.exec.handler.ExecHandler] - Transformed response is '* failed to open vchiq instance'

OK, not we are getting somewhere. The script actually worked. The openhab user doesn’t have permission to open what ever a vchiq is. You will need to add the openhab user to the appropriate group or add openhab to sudoers and run the command with sudo.

One last thing to try to get it to work with executeCommandLine/binding is to use double quotes but escape them:

"echo \"on 0\" | cec-client -s -d 1"

You may also try replacing the spaces with @@.

"echo@@'on 0'@@|@@cec-client@@-s@@-d@@1"

OK, I suspected it would have something to do with permissions and this is where I was least confident as I tried different solutions I found. I just tried this to add openhab to sudoers:

sudo adduser openhab sudo

I wasn’t sure if sudo needed to go before both echo and cec-client, so I tried it both ways. With sudo just before echo I get this:

2017-06-29 14:33:13.007 [DEBUG] [hab.binding.exec.handler.ExecHandler] - Exec [OUTPUT]: '* failed to open vchiq instance'

Plus the “We trust you have received the usual lecture…” message repeated several times.

With sudo in front of both echo and cec-client, I don’t get any [OUTPUT] message, just the “We trust…” message repeated many times…

I tried many different combinations of @@, ", and ’ on the command in Exec Binding, executeCommandLine, and shell script without the output being very different from what we’ve already seen.

Edit: Oh, I also tried putting sudo in front of the command attached to the Thing so:

[command="sudo /etc/openhab2/scripts/" ...

First run:

sudo -u openhab ls

from a terminal. This will let you acknowledge and get rid of that message. It only appears the first time you run sudo as a given user.

Second, adding openhab to the sudo group may not be enough because you also have to configure it so the openhab user does not have to enter a password to run sudo commands.

Do you have to run the command with sudo when running it as a regular user? If not then there is some other group that your regular user belongs to that needs to be added to the openhab user. I have no idea what resources these command access or how they work so you will have to figure that part out. You should run these commands as root through sudo only as a last resort.

Finally, if you do have to run it as sudo, then you should user your shell script and put the sudo before the call to your shell script.

Hmm, I ran that first command but the “We trust you…” message is still appearing. The message always ends with “
sudo: no tty present and no askpass program specified’”, maybe I should have mentioned that.

It sounds like that is the password problem you were referring to? I tried just changing the password requirements for the cec-client command, but that didn’t work.

openhab ALL = NOPASSWD: /usr/bin/cec-client

Then I allowed openhab user to run all commands without a password and that fixed it!


But, I assume that’s not a good idea? I guess this means either I have the wrong directory specified when I changed password permission for cec-client or the process is actually using some other process that openhab user is also restricted from? At least now I know that it is a permissions/password issue, though.

When I run the command as pi I do not have to use sudo, fyi, not sure if that matters at this point.

See my edit in previous post, I had actually already tried sudo before the call to the shell script.

Also, my tvSwitch Item has been constantly and spotaneously switching between OFF and ON through this whole process… but maybe that’s an issue for another time…

I’m not sure this will work:

sudo -u openhab sudo ls

but I’m pretty sure this will work:

su openhab
sudo ls


  1. log in as root
  2. as root, log in as openhab
  3. as user openhab, run sudo once
  4. exit shell from user openhab
  5. exit shell from root

Hmm that didn’t work either but when I change my permissions to allow openhab user to run anything without a password, I don’t get the message anymore. I guess the last part of the message was the important part? “sudo: no tty present and no askpass program specified’”

@Udo_Hartmann, does su exist on raspbian? It doesn’t on Ubuntu so I assumed it doesn’t on raspbian as well. It could be installed but I think the idea is you should never be running a terminal as root so they remove su.

If you want a shell as another user you should be able to run:

sudo -u openhab /bin/bash

That will give you a bash shell running as the openhab user.

I don’t want to come across as testy. And my current frustrations come more for other threads I’ve dealt with this week than yours. But I have to say details matter. I do not include superfluous information in my postings.

From my previous posting:

Do you have to run the command with sudo when running it as a regular user? If not then there is some other group that your regular user belongs to that needs to be added to the openhab user. I have no idea what resources these command access or how they work so you will have to figure that part out. You should run these commands as root through sudo only as a last resort.

So yes, this is vital information. We should not be messing around with sudo in the first place.

But just for completeness I’ll mention what is going on here. Jump down past the line for the next steps.

Did you run it from a terminal like I asked, or did you run it from openHAB? The no tty present error usually is caused when trying to execute sudo not from a shell and that user is not configured to allow that. But if you ran that command from a terminal shell running as the pi user that error should not have occured.

No, this is a completely different problem (really a slightly related problem). One that we will not try to solve because you don’t need to run as sudo anyway. Please remove openhab from your sudoers. (I really hope you are using sudo visudo to edit the sudoers file.

Look at the permissions on /usr/bin/cec-client. What is the group who owns this file? Is openhab a member of this group?

Does this cec-client have a configuration? In particular, does it have to be pointed at a serial device or some other physical device (i.e. something in /dev like /dev/ttyUSB0)? Check the permissions on this device. Is openhab a member of the group?

If all else fails, add the openhab user to all the same groups that the pi user is a member of.

Sorry about that, I understand it being frustrating for me to not understand the importance of details like that.

I did run that command from a terminal (SSH) and then tried running it on the pi rather than via SSH, just to be sure. I just now removed openhab from sudoers and removed the password permissions I set in sudo visudo. This is now the output when trying to execute the .sh script with sudo via executeCommandLine (I did not include sudo going forward):

2017-06-29 16:36:11.058 [INFO ] [ipse.smarthome.model.script.execTest] -
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.
sudo: no tty present and no askpass program specified

Here are the permissions for cec-client:

lrwxrwxrwx 1 root root

So the owner and group are both root but I assume I don’t want to make openhab user a member of root (if that’s even possible)?

I am not sure about the cec-client’s use of serial devices. The interaction with the TV is done through the HDMI port but I didn’t see any information about there being permissions for HDMI.[quote=“rlkoshak, post:11, topic:30711”]
sudo -u openhab /bin/bash

I used this to try running the shell script as the openhab user and the script ran fine; does that make sense to you? I would have guessed that the permissions problem we are hunting would have prevented that.[quote=“rlkoshak, post:11, topic:30711”]
If all else fails, add the openhab user to all the same groups that the pi user is a member of.

I tried adding the openhab user to all of the same groups as the pi user and consistently got this in the output:
2017-06-29 17:39:27.898 [INFO ] [ipse.smarthome.model.script.execTest] - * failed to open vchiq instance

We are not going to use sudo so remove all references to sudo from your script and openHAB configs. Sudo should only be used as a last resort. Since you do not need to run sudo to execute the script as the pi user, you don’t have to as the openhab user either.

The permission problem has to do with that one command and the resources it uses. That wouldn’t prevent you from running /bin/bash.

I know nothing about any of these programs or scripts. But a just did a google search for “vchiq” because it is mentioned in the error. The first result was entitled What is /dev/vchiq in Raspberry Pi?. The first line in that particular question points to /dev/vchiq and the first reply to this guy’s question is a long explanation of what it is.

So now that I know what device it is complaining about I did an ls -l /dev/vchiq on my Pi which tells me:

crw-rw---- 1 root video 246, 0 Jun 28 11:53 /dev/vchiq

So all you need to do is add the openhab user to the video group to gain read write access to this device.

Google is your friend.

Note that adding a user to a new group often does not take effect until after you restart the shell. So in the openHAB case you need to restart the service after adding it to a new group.

Thank you very much for your help, Rich. I added openhab user to the video group and restarted and it’s working now. I put in a lot of Google time but just didn’t know enough about what I was doing to make sense of it; I learned a lot through your help here and am much better prepared to do my research next time. Cheers!

1 Like

In fact, afaik even on ubuntu su is installed (at least it was when I used ubuntu last time), try sudo su as command, but there is no password set for root, so it’s not possible to use su directly to become root.

Raspbian is derived from debian, not ubuntu, e.g. there was no raspbian with upstart…

You are absolutely right. su iris there. I guess I got so used to solely using sudo I somehow came to believe su what removed.

And I didn’t mean to imply that raspbian came from Ubuntu but that they both share a parent in Debian and would therefore be the same in this particular regard.

:slight_smile: You’re welcome, this detail (don’t use su) is one of the changes, canonical made to debian (I can only guess, but I doubt that ubuntu and debian share big parts of code any longer, I think, the biggest part is apt…)