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.
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.
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.
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.
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?
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
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.
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.
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.
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!
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.
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.
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:
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?
