Exec Binding do not work

[Kai (Kai Kreuzer)]

I very much doubt that what you complain about is due to the new binding APIs. As explained here, looking at the files, it merely means that the overly complex binding configuration strings are moved into a separate file (the *.things file) and now follow a common syntax for ALL bindings. This still makes a lot of sense to me. If functionality is lost from a v1 to a v2, this is usually due to the implementation of the binding, and not due to the APIs.

[alexander.karls]

@Kai

I very much doubt that what you complain about is due to the new binding APIs. As explained here, looking at the files, it merely means that the overly complex binding configuration strings are moved into a separate file (the *.things file) and now follow a common syntax for ALL bindings. This still makes a lot of sense to me. If functionality is lost from a v1 to a v2, this is usually due to the implementation of the binding, and not due to the APIs.

@Kai: No, its not about the API in general, which is (after understanding how things are handled in OH2) straight forward. Its more about the specific loss of usability when it comes to exec. The old concept like exec=“OFF:/opt/something_off.sh, ON:/opt/something_on.sh” was a great way to trigger whatever you want, no matter what. Now, i can`t use this anymore in this way, i would have to deploy two things and couple them into an item or write a rule to get the same result as in the 1.9 version of the binding. THATS what i complain about
I use these execs in many ways, so, for me its currently a showstopper…

[watou (John Cocula)]

I do not see in the link you provided how the user can choose what type of item to update from an OH2/ESH binding as they can do with 1.x bindings. Is there more information you could provide specifically about how to achieve this in an OH2/ESH binding, and does this mean there is a defect in the current Exec 2.0 binding regarding loss of functionality compared to the 1.x Exec binding? It’s not about syntax so much as functionality, but if the configuration is spread across multiple files and is more cumbersome and error-prone, that seems like backward movement. In any case, I do not want to argue my points again here, so if you find my observations invalid, let’s leave it at that.

[kgoderis (Karel Goderis)]

To couple them you can either do as in

Exec Binding do not work

All, as with all 2.0 bindings, you should be aware that the configuration syntax has changed completely. You have to define Things, with Channels, and link those Channels to Items. The latest documentation you can find at https://github.com/openhab/openhab2-addons/tree/master/addons/binding/org.openhab.binding.exec Since there is no such concept anymore as “direction” in ESH/OH2 one has to work differently cfr the camera example. For each command you want to execute you would define a Thing, …

or work via a Rule as you suggest

[alexander.karls]

Could you please give some example? Or, better, an advise on my specific problem?

[alexander.karls]

Wrote a small tool to simplify the task of migrating scripts for the use in OH2:

Ohsmt - openHab script migration tool

Hi all, after following the discussions about the new exec binding in OH2, i decided to create a small migration tool for all those scriptheads like me. Feel free to use it, adapt it or to put some more ideas in it: ohsmt openHab Script Migration Tool What does it? ohsmt looks for linux shell-scripts (.sh) the are currently in use in any openHAB 1.x enviroment (and its exec binding) and creates new .things, .items and .rule-files for openHab 2.x within the default OH structure below $ope…

[HolgerL (Holger OpenhabUser)]

Hi,
can anyone please post an working example Thing/Item/sitemap for a simple switch which shall send an On/Off comand via Exec [command="curl … .
I spend hours trying different solutions, also with 2 separate things for the On and Off, but nothing worked as it should.

Why are such simpel things so complicated to implement?

Thanks, Holger

[DocFraggle (Christian Hailer)]

Hi, well, I found it rather easy…
I created a new exec thing in the Paper UI. I gave the thing a name and configured the command it should execute.
I set the interval to 0, so it’s executed only once. The other fields are the default.
Then, I created a link for the “Running” channel and defined my item in the conf file:

Switch Name <icon> (group)    { channel="exec:command:name-of-exec-thing:run" }

Define it in your sitemap, voila. When you trigger the switch the command is executed.

Christian

[alexander.karls]

Or just:

Things
Thing exec:command:licht_on [command="/opt/brematic/licht_sofa_on.sh, timeout=5]
Thing exec:command:licht_off [command="/opt/brematic/licht_sofa_off.sh, timeout=5]

Items
Switch licht_sofa_on {channel=“exec:command:licht_on:run”}
Switch licht_sofa_off {channel=“exec:command:licht_off:run”}

Rules
rule "Licht Sofa"
when
Item licht_sofa changed
then
if(licht_sofa.state == OFF){
licht_sofa_off.sendCommand(ON)
licht_sofa_on.postUpdate(OFF)
}
if(licht_sofa.state == ON){
licht_sofa_on.sendCommand(ON)
licht_sofa_off.postUpdate(OFF)
}
end

[watou (John Cocula)]

Is there no way to use a single Switch item?

[alexander.karls]

Not with the 2.x version of the exec binding. If you want the old style use 1.x version

[steve1]

@alexander.karls

Not with the 2.x version of the exec binding. If you want the old style use 1.x version

I’ve been investigating the code for the Exec 2.0 binding and there are definitely some quirky aspects to it. It seems like it should be possible to support a more straightforward switch behavior without extensive changes to the binding. For my investigation, I’m using the following thing definition:

Thing exec:command:switch_control [command="/tmp/switch_control.sh %2$s", interval=0, autorun=true]

The %2$s will be replaced with a value on the input channel. The “interval=0” specifier is an undocumented feature that disables periodic execution. The autorun option is “a boolean parameter to make the command execute immediately every time the state of the input channel has changed”.

My test item is:

String ExecSwitchTest {channel="exec:command:switch_control:input"}

The documentation says that the input channel is the “Input parameter to provide to the command”. Based on the description of the autorun configuration, I initially assumed this was driven by item state changes, since command events don’t actually represent an item change. However, the Exec binding only responds to command events for the input channel. After learning that, I tried sending a command to the item. Initially I had created a Switch item and sent ON/OFF commands. However, the code only responds to string commands and doesn’t attempt to convert non-string commands to strings like “ON” and “OFF”. After changing the item to a String and sending commands I was finally able to see my script executed with the command string as the argument.

In my opinion, there are some simple improvements that could be made to the binding.

• Support other item types and convert states/commands to strings for command formatting.
• Either make the input channel respond to state changes or fix the documentation.
• Make a missing interval option mean “no periodic execution”

With these changes I think we may be able to support a Switch with a single thing and an item bound to the input channel. It’s not quite the same as the OH1 in/out specifications but it’s better than defining multiple items and using rules to implement the same behavior.

[alexander.karls]

@kgoderis

[HolgerL (Holger OpenhabUser)]

Hi steve1,

very good, your solution works! Thanks very much.
Well defining the item as string and not as switch is really not the intuitive way one would go.
Maybe this can be improved for the release version.

Holger

[kgoderis (Karel Goderis)]

@steve1

In my opinion, there are some simple improvements that could be made to the binding.

Support other item types and convert states/commands to strings for command formatting.
Either make the input channel respond to state changes or fix the documentation.
Make a missing interval option mean “no periodic execution”

Some quick initial thoughts on this.

If we want to support other Item types, then we would have to create a new channel type per type of Item, since Channel Types have to be defined with an Item Type in mind. This would “pollute” a bit the channels and maybe more confusing after all. I reverted to the StringType as this is the most common denominator, and maybe the easiest one to convert to in Rules and Scripts. Conversion as you suggest is not really an option, but I will investigate how it can fit into the automatic conversion between Item Types that was introduced lately (smarthome/bundles/core/org.eclipse.smarthome.core.thing/src/main/java/org/eclipse/smarthome/core/thing/internal/ThingManager.java at 3ce6ba13cf330f7fe86336bbff7fdd289a1b6499 · eclipse-archived/smarthome · GitHub)

Make the binding do handleUpdate() is an option. I think that I only considered handleCommand() as that was the more logical approach, e.g send a Command, albeit through an external shell command/script. The reason the Autorun thing is there is to cope with those use case whereby you would have high-frequency execution due some Rule set up. I agree that the wording in the doc could rather be “a boolean parameter to make the command execute immediately every time a Command has been sent to the input channel”

A missing interval is something that is Ok with respect the current code base. If you do not specify it, then no periodic execution is scheduled in the scheduler.

K

[steve1]

@kgoderis

If we want to support other Item types, then we would have to create a new channel type per type of Item, since Channel Types have to be defined with an Item Type in mind.

Good point. I didn’t know that was a constraint but I agree that it wouldn’t be desirable to have a channel per item type. I see the ‘run’ channel is associated with a Switch item. Is it possible to pass the Switch command to the command formatter for that channel like you do for the input channel?

Having the input channel process String commands is fine with me if the documentation is clear about it.

[steve1]

@kgoderis, both the ‘input’ and ‘run’ channels can trigger execution of an Exec things script (I’ll refer to the thing’s command as a script to avoid confusion with an item command). With the following definitions:

Thing exec:command:switch_control [command="/tmp/switch_control.sh %2$s", interval=0, autorun=true]

String ExecInput {channel="exec:command:switch_control:input"}
Switch ExecRun   {channel="exec:command:switch_control:run"}

If send a command string, like “TEST”, to the ExecInput item, I see the script executed with the command string as an argument.

If I then send an ON command to the run channel, I again see the script executed with “TEST” as the argument. If I send an OFF command to the run channel, then nothing happens. Also, the run channel state is changed by the binding to indicate if the script is running or not.

What is the intended interaction between the run and input channels?

[kgoderis (Karel Goderis)]

‘run’ has to be used to trigger the execution of the thing’s command using the then actual value (.e.g state) of the input channel. You can thus set the ‘input’ once, but execute it multiple times by sending ON to the ‘run’ channel. Next to that, the ‘run’ channel is an indicator that the thing’s command is running, switching its state to OFF when the thing’s command has finished running

‘input’ is a means to set the input for the Thing’s command, using the %2$s format. It will not trigger the execution of the thing’s command, unless autorun=true, in which case the execution is triggered if the value send to the input channel is different from a previously set/send value

[steve1]

@kgoderis

‘run’ has to be used to trigger the execution of the thing’s command using the then actual value (.e.g state) of the input channel.

Thanks. That’s what I thought, but I wanted to be sure. Given a common use case will be using the exec binding with a switch, what do you think about adding a switch channel? It would similar to input with autorun=true but would pass its new state as the command line argument. It could update the run channel state in the same way as the input channel. However, a run command would still only work with input. That might be confusing. Maybe the running status should be a separate status channel instead of combining both the triggering and status into one channel?

[Paul_Atkin]

If send a command string, like “TEST”, to the ExecInput item, I see the script executed with the command string as an argument.

It was not my experience, until i mapped something into the ‘run’ channel i did not see script running at all. I tried to map ‘run’ only, then ‘input’ only - no way, it only runs shell script if both ‘run’ and ‘input’ are mapped to something, in my case it is a same item - switch. mapping to ‘String’ did not run the script either.

All this is totally counter intuitive. How was this contraption supposed to implement a simple execution of a script when we turn a switch ON and OFF? Script has to run upon both conditions, not only when it is getting ‘ON’ command.

All this makes no sense at all.