[SOLVED] EXEC Binding simple example not working

Hello everyone!

I am trying to send commands to my openhabian through the user interface. So what I want is that if I turn on a switch then it should send the command to my openhabian which is running on a raspberry pi! I know I have to do it through the exec binding and I am trying a really simple example which is mentioned on this page: https://www.openhab.org/addons/bindings/exec/

But for some reason the simple command is not being sent.

This is my demo.things:

Thing exec:command:apc [command="ls", interval=15, timeout=5]

This is my demo.items:

String APCRunning {channel="exec:command:apc:run"}

And this is my demo.sitemap:

Switch item=APCRunning

So as you see its pretty basic and the only thing I am trying here is to send the ‘ls’ command. Later I would try to get to more complex stuff such as running python scripts on the raspberry pi but right now I cannot see anything on the terminal window which I have opened on putty when I try to turn the switch on.

If anyone can help. It would be super cool.

Many thanks.



The run channel is intended to be linked to a Switch Item. I’m not sure what happens, if anything, when linked to a String.

I don’t think it’s going to tell you what you want anyway; the intended use of run is tomonitor script execution. You might kick the script off, and have a rule triggered from run changing to off when script completes and reults are available.
That’s generally all over in milliseconds i.e. you’re not going to see it.

There is a lastexecution channel which should be updating every 15 seconds for you.

I think if you want the output of your “ls” to arrive somewhere you’d have to pipe it there explicitly.

Okay thank you for your help. So that really isn’t important to see anyway. So I moved towards a real test. I made a simple python script and tried to run it by using a switch.

Here is the .things

Thing exec:command:apc [command="python /etc/openhab2/scripts/led.py", interval=15, timeout=5]

Here is the .items

String python_test {channel="exec:command:apc:run"} 

And here is the .sitemap

Switch item=python_test

But it still doesn’t work. Also, when I do this directly by the command line and type:

sudo -u openhab python led.py

Then it works but when I try to toggle the switch then it does not.

Any suggestions?

Thank you!

Like rossko57 said, you just link the run channel to a Switch, not a String. The run Channel can be used to kick off the script (when not using interval) and it tells you when the script is actively running.

The interval means it will run every 15 seconds and the timeout means it will wait at most five seconds for the script to return.

As described in the docs, the output Channel has the results of the script’s last run. This Channel needs to be linked to a String Item.

So that means that if I change .items to:

Switch python_test {channel="exec:command:apc:run"} 

And .things to:

Thing exec:command:apc [command="python /etc/openhab2/scripts/led.py", interval=0]

It should work?

But sadly it is not working still. The problem is just annoying.

If anyone can help with the solution. I’d be grateful.


Give us a bit more to work with. How do you know, what is supposed to happen? Do you see the switch command in events.log? Anything related in openhab.log?

I wonder what is in that channel.

Well I have a test setup of an LED and I am toggling it on and off, so I can physically see it if the python script is triggered. That is how I can know.

And this is the log from the event.log. Doesn’t tell me a lot to be honest. May be you can make more out of it?

LED thing is great :grinning:
Note that many exec problems come down to access permissions - the console is not the same user environment as openHAB.
Not sure how that works with access to hardware.

I would make very sure to put a timeout in your Thing. I’m not sure what the default is, or if there is one.

The events log does actually contain useful info.
We can at least see command ON arriving, example 06:55.370
The ‘prediction’ we ignore, that’s just autoupdate interfering.
Later there’s a command OFF - that I’m sure is coming from you working the UI.
Of note is a missing update to ON or OFF that would indicate the binding at least thinking the script is running.

Still wondering what is in openhab.log at the time, and what is in string channel output.

1 Like

OMG. A timeout was the thing which was making my life miserable for the past full day. Thank you so much. The script works now and the LED is blinking and now I can move towards writing my original script.

Just an after thought, could there be a way to turn off the script as I close the switch? So Just a way to send “CTRL + C”. Would a rule do the trick? Because right now it goes on indefinitely. Of course my script is written that the LED will blink indefinitely.


Not sure what happened there then; I suppose a very old indefinite script had all the resources so nothing else worked properly.

Not with exec binding. It’s really really not meant for an indefinite process.

You can write more scripts … one to start some external process, one to stop it.
Or of course one script with a start/stop parameter.

If you are thinking running a script that indefinitely listens for some event … see above about using exec to control a service via an intermediary.

There might be other ways to go about this, if you can say more about the target event/switch. This is the kind of thing openHAB does for a living.

1 Like

Based on the docs, I would expect the OFF command to be coming from the binding. It is supposed to sendCommand ON to the Switch when the script starts executing (if it is defined to execute on an interval) and then to OFF when the script is done executing. ~3.5 seconds does seem a bit long to run a python script but I don’t know all the details.

If you know Python it would be easy to add this script to https://github.com/rkoshak/sensorReporter and send messages to it using MQTT.

Not commands from exec binding, Rich - state updates.
I.e command ON, exec tries to start script and updates to ON if successful. Fails to start, no update.

Hmmm, it’s been since OH 2.0 B2 that I’ve worked with the Exec binding directly. I have a recollection that it issued an OFF command, but maybe it changed or I’m just remembering incorrectly.

Maybe some changed behaviour due to autoupdate getting cleverer.
Once you (the user or rule) would send command ON and shortly get state ON regardless (via autoupdate).
Now the bindings have a power of veto, which is where the NULL prediction in event.log comes from.

That has nothing to do with binding issuing command OFF when done though; I did not think that happened but have to try it out now!

1 Like

Interesting play results. It is important to observe channel and Item types match - the docs have a bad example.

If you use the thing interval parameter to run your script periodically:
The run channel is updated ON and OFF each run. (not command)
The string result goes into output channel state, as you’d expect.
The lastexecution channel gets (periodic) datetime update as you’d expect.
I didn’t look into input-%2 business with this.

If you use the thing autorun=true parameter;
Sending an update to input channel does not trigger - disappointing, docs misleading.
Sending a command to input does trigger, hurrah.
Important - the command is used for %2 script parameter, NOT the current input state.
Sending command ON to run triggers the script, that’s of note.
But - important, the last command sent to input is remembered and used for %2 script parameter in this case, not the state. This is nasty.
run state updates ON then OFF as you’d expect
output and lastexecution update as you’d expect.

With both interval=0 and autorun=false
Sending command ON to run triggers the script, hurrah.
Sending command or state to input does not trigger, hurrah.
run state updates ON then OFF as you’d expect
output and lastexecution update as you’d expect

But this is really nasty - the %2 parameter passed to the script is taken from last command to input, completely ignores input state.

If there has not been a command to input since boot, the execution fails with a formatting error on %2. In this case, run does the usual on/off like a normal run, but output is not updated. Nor is exit number, sadly.

I will think on this %2 ; it may be intended but is not nice, and if so docs are misleading.

I never managed to get anything in exit channel, I suspect you need to have a script that runs but errors. Possibly it’s different depending on nix/win environment etc.


Bonus effect; because input channel never uses state, and naturally output channel never responds to commands, you can use the same Item for both in and out.

String execRaw "out [%s]" {channel="exec:command:myexec:output", channel="exec:command:myexec:input", autoupdate="false"}

Send it a command with the text wanted as parameter %2, read the result in same Item state.


We should update the docs.

From an overall perspective this makes some sense. An update shouldn’t get forwarded to the binding and cause something to happen. Only a command should do that.

Given that the input Channel needs to be linked to a String Item, wouldn’t the only valid command one can send to it be a String? So shouldn’t they match? Maybe I’m missing something.

Oh I think I got it. You could send a command to the input Channel, then update the state of the Item but that updated state won’t be used, the previous command would be used. Indeed, this is nasty. We should file an issue.

We should be able to update the input Channel without causing the script to execute and we should be able to kick off the script using the latest state of the input Channel, not just the command. The binding must remember the command internally for reuse instead of reading it from the input channel.

The logic becomes a little tricky though because when a command is sent to the input Channel, the Item may not have changed state to that command yet when the binding runs the script. So the binding needs to track which Channel received the command and if it came on the input Channel use the command and if it came on the run Channel use the input state.

That should address the no command since boot problem too, as long as restoreOnStartup was used or there was some other update to the input Channel (e.g. a System started Rule).

This should be fixed too. If the binding itself failed to run it there should be something in output or the exit Channel to tell us something went wrong.

1 Like

Like you, not convinced this input command is a bug. It IS consistent with general binding behaviour - in autorun mode.
It just feels weird when using run control mode.

I already have a docs issue open on the horrid example rule, intend to do more on this too now.

I’m inclined to accept the behaviour and just document it clearly. It is functional. Opinions gratefully heard!


Sorry for bothering you again. I ran in to another problem. I have a python script which is accepting arguments. I can send arguments simply by appending it at the end of the command. Just like:

Thing exec:command:apc [command="python /etc/openhab2/scripts/led.py 12", interval=0, timeout=5]

here 12 is the number of seconds for which the script will run.

The problem I have is that I have added a text box in the openhab user interface through a webapp. Now what it does is that it takes some input number and saves it in a string item. I am sure that the number which I input is being saved and updated in the item because I am displaying it for test purposes.

So what I need is that I want to send this STRING ITEM as an argument to my python script. Can it work or any work around can be found? Any ideas?

Many thanks.

Make an exec thing for your script. Use %2 substitution for your param. Use autorun true. Send your param as command to input channel.