Thanks for the quick response.
That’s a bit uncomfortable for curl calls and would mean to double the number of switches.
I am not sure if I get your point correctly - sorry 
Do you mean to couple them through a rule like:
if switch_ON receives command ON → Switch_BOTH.sendCommand (ON) and
if switch_OFF receives command OFF → Switch_BOTH.sendCommand (OFF)
??
Does this mean that these two bindings can work together?
@nibi79 just For information. U can direct use the Pilight binding without the use of exec. The advantage For me in using pilight direct is i receive direct update for all Pilight items even if i switch them with with the 433mhz remote control.
The 1.x Exec binding seems so much simpler and does not require rules to achieve basic functionality. I see serious usability problems with Thing bindings that are not actually about Things (like Exec, TCP/UDP, MQTT, etc.). I’ve made this point before a few times but I am unsure if anyone was really listening.
I hope there is a major overhaul that simplifies this mass of complicated configuration imposed by the new binding architecture. Better yet, if openHAB didn’t treat 1.x bindings as “red-haired stepchildren” by hiding them in the online distro, and allowed users to add binding config strings from the Paper UI, that would be a nice recovery from the current situation. Otherwise lots of users will come away frustrated and go find something simpler than openHAB, I’m afraid.
Thanks for this… Messing around with this since two days (as also posted here), ending up using the old binding. I really love the new concept for standard hardware like NetAtmo, Hue, Max! and so on. But when it comes to shell scripts (which was the great point to use a linux distro at all), OH2 sucks at this time. Ok, its nice that theres a stringent concept to follow now, but it must be considered that not each and every device is “thing-able”. Otherwise i see myself stuck at 1.9 for the future, with all the lack of no more z-wave database maintenance etc.
Yes, when a binding is really about Things, the new model is great. But when it’s about arbitrary data whose purpose and types are only known by the end user, the new model is an unnatural force fit at best, frustrating and unusable at worst. If openHAB (or Eclipse SmartHome) were to give “first class” support to both “item bindings” and “thing bindings”, that would be wonderful. As an active maintainer of 1.x bindings, I find the current situation especially “trying.”
Maybe some more documentation would help, too. The concept to create two things for one switch isn´t logical, so some examples should help…
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…
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.
To couple them you can either do as in
or work via a Rule as you suggest
Wrote a small tool to simplify the task of migrating scripts for the use in OH2:
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
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
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
Is there no way to use a single Switch item?
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.
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.