Exec Binding do not work

Hi,
I installed build from 29th November 2016, and I checked that Exec Binding is not working.
I checked that Binding is loaded with: bundle:list and it is loaded.
I don’t know what to check.

Many thanks for help.

Marco

Hi,
I found that new Exec binding changed to Thing, so I’m gointo to changing my config in according docs, but I don’t know how to implement this:

String CAM_01_MODE "ZoneMinder Function [%s]" {exec="<[curl -s -b /etc/openhab2/myscript/zm_cookie.txt  http://zoneminder/zm/api/monitors/1.json:5000:JS(ZM_getFunction.js)] >[*:curl -s -b /etc/openhab2/myscript/zm_cookie.txt -XPOST http://zoneminder/zm/api/monitors/1.json -d Monitor[Function]=%2$s]", autoupdate="false" }
Switch item=CAM_01_MODE label="ZM Mode - Ingresso" icon="ipcameraright" mappings=[Record=Record, Modect=Modect, Monitor=Monitor]

With this configuration of old exec binding, I can read the status of my IP camera with < part of the confing, and I can also send a command > to my IP camera related to value of the switch I have into Sitemap. How can Do this with new exec binding?

For now I resolved loading Exec Binding 1.8.3 and works fine, but I would like to move to new.

Thanks

1 Like

No one can help me?

Thanks

same problem

exec 2.0 does not work for me

1 Like

There’s no real need to switch to the exec2 binding. The new binding seems to have some issues here and there and if you follow the threads here, there are quite some people having trouble with the new binding.

So I would suggest to stay with the old binding until the new binding has evolved (lesser issues, better documentation, probably some tutorials etc.).

1 Like

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, e.g. 2 Things in total:

Thing exec:command:in [command="curl -s -b /etc/openhab2/myscript/zm_cookie.txt http://zoneminder/zm/api/monitors/1.json" transform="JS(ZM_getFunction.js)", interval=5, timeout=5]

Thing exec:command:out [command="curl -s -b /etc/openhab2/myscript/zm_cookie.txt -XPOST http://zoneminder/zm/api/monitors/1.json -d Monitor[Function]=%2$s", interval=0, timeout=5]

You then have to option to (1) either link a channel of each Thing to an Item, and bridge input and output that way or (2) create a small Rule that does the same trick. The choice between (1) and (2) depends on how your command is working, alternatively you could as well deal with this complexity in a shell script. I presume that (1) is possible in this example:

String CAM_01_MODE "[%s]" (All) {channel="exec:command:in:output", channel="exec:command:out:input"}

1 Like

hi Karel,

possibly my question concerns not only the exec binding but I’ve an unstanding problem, too.

in my case I’ve defined the following things:

// switch on with parameter '-t'
Thing exec:command:it14On  [command="pilight-send -p kaku_switch_old -i 14 -u 1 -t"]
// switch off with parameter '-f'
Thing exec:command:it14Off [command="pilight-send -p kaku_switch_old -i 14 -u 1 -f"]

and tried this in my items file:

Switch test1 { channel="exec:command:it14On:run", channel="exec:command:it14Off:run"}
Switch test2 { channel="[ON: exec:command:it14On:run], [OFF: exec:command:it14Off:run]"}

But when I push the button both commands are executed.

So is it possible to bind two exec commands to one switch for ON and OFF? Or have I trigger this by using a rule instead?

Is it possible to update to the latest OH2 snapshot and don’t update exec binding ? Use 1.9 ?

Old Bingings is just included.
You can enable the old one from PaperUI

Marco

Hi

Sorry for the delayed answer. In contrast with OH1, you can not refer to or filter on States (e.g. your example “test2”) in OH2 when defining items.

When you send ON to test1, then both commands will execute. If you send OFF, nothing will happen
"test2" has an invalid syntax.

What you could do is pass on a parameter to your script via the “input” channel, and use that to switch your it14 device on or off. Or, as you suggest, write a simple Rule to do this

Hi @kgoderis,

Does this mean there is no option to use ON/OFF for one exec thing in the items using just one switch??

Indeed, you will need to define a Thing for the “ON” command, and a Thing for the “OFF” part, and couple the input/ouput channels in an Item definition, except for the case whereby you can differentiate between ON and OFF in the command/script itself because in those instances you can send the ON and OFF as a parameter to the script itself.

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 :wink:
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.

@kgoderis:
Same here…

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.

3 Likes

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…