Proposing Improvements to the exec binding

With the risk of having missed older discussions (I’ve only recently started using openHAB) I want to propose improvements to the exec binding.

I found numerous issue reports, topics where people try to use the exec binding. In general the suggested solution is to add extra rules and lines of other configuration to get it to work. In general these questions are about using the exec binding to control devices with things like a Switch. If you look at the code of the exec binding it seems to be created for monitoring some device (with a regular interval) and show the status as text. This doesn’t match with the use case to use it to control devices and explains the difficulty people have using the exec binding (my 2c).

This leads me to propose to enhance the exec binding with 1 or more things that are designed to control. This solution could be to have a new thing that contains channels for every type that has some state (i.e. a switch channel, a color channel, a dimmer channel, etc) or create a control thing for every state type, like a ControlSwitch with switch channel.

Does it make sense to add these kind things? And if so, how should they look like and with what kind of parameters?

That sound like an interesting binding. Are these skins things or user configurable?

I was actually looking at a shorter time frame to build the extension to the exec binding :wink: If you are willing to share the code as it is now I can see if I can make it into a binding.

If you just want to use a script as a reaction to a switch or similar, you don’t need the exec binding, you could simply use executeCommandLine in a rule. .

@ganesh.ingle Having predefined skins as things works if you have a large sets of skins available, but that is difficult because you need to think of all kind of use cases, otherwise someone wants to use the binding but no skin is available. Hence the question about user configurability (Although that might be difficult). On the other hand if a set of things are available mapping to openhab data types it’s more flexible, but also somewhat more work to get more complex combinations setup.

@job The idea is not to have a script or write rules, making it much easier to use. I’ve seen numerous people trying to use just the items/things to get it to work.