Exec binding channel transformation to link switch item to string channel

[kajarit (Teb)]

Hi All,
I wonder if this is supported in some way in the current stable (OH3) release, because I consider it logical, but could not make it work…

So I have created a thing using exec binding, and used “Add link to item…” on the “Input” channel to create a new item with Switch type. Note that the exec thing’s Input channel is String type, but the user interface allows this kind of linking, great.
After this when I change the switch item state the logs are showing the following DEBUG message:

Received not accepted type ‘OnOffType’ for channel ‘exec:command:switch1:input’

Okay, so the system doesn’t have an implicit conversion, noted.
Here comes the Profile settings for the link, as it states: “Profiles define how Channels and Items work together.”
So I tried to use the MAP profile for this by creating the map file with OFF=off and ON=on but no luck.

Question 1: How can I make this work without using a rule? Preferably by some profile or other “magic”

Question 2: If I try to link the String type channel, with an existing Switch type item, this couldn’t be done as the UI doesn’t lists switch items. But it allows to create a link when you create a new item (see above). Is this a bug or a feature?

[rlkoshak (Rich Koshak)]

@kajarit

Question 1: How can I make this work without using a rule? Preferably by some profile or other “magic”

I’m assuming the value coming from the script is “on” and “off”. If so, you’ve got the map backwards. They should be on=ON and off=OFF. Switch Items need the all caps version.

Even easier, if you have that power, would be to modify the script to return “ON” and “OFF” and then no transformation would be necessary I think. I could be wrong on that and you might need a map with just the default entry if ti doesn’t work.

@kajarit

Question 2: If I try to link the String type channel, with an existing Switch type item, this couldn’t be done as the UI doesn’t lists switch items. But it allows to create a link when you create a new item (see above). Is this a bug or a feature?

The ability of a Profile to link to an Item of a different type than what is expected by the Channel is relatively new. It’s likely that when the UI was updated to allow that, it wasn’t updated everywhere. You should probably file an issue on that. It should be consistent.

[rossko57]

@kajarit

“Profiles define how Channels and Items work together.”

But remember channels have bi-directional capability. The majority of profiles only modify the payload in the channel-to-Item update path. Transformation profile (as used with MAP) is one of those, it ain’t going to work to modify an Item command for exec input channel consumption, in the opposite direction.

@kajarit

when I chenge the switch item state

How are you doing this exactly? You need to send a command to the Item, the state is irrelevant to Exec.

@kajarit

How can I make this work without using a rule?

I don’t understand why people go to great lengths to avoid rules and/or intermediate Items, when its a straightforward application to achieve what you want. They don’t cost anything.

I think the summary of Switch Item to Exec input behaviour described here is still true (i.e. it doesn’t work)

Exec Binding do not work

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 u…

This is mentioned in the binding docs

Attention: Linking input to any other item type than String will result in erroneous behavior.

[kajarit (Teb)]

@rossko57

@kajarit

“Profiles define how Channels and Items work together.”

But remember channels have bi-directional capability. The majority of profiles only modify the payload in the channel-to-Item update path. Transformation profile (as used with MAP) is one of those, it ain’t going to work to modify an Item command for exec input channel consumption, in the opposite direction.

Oh, this is surprising, thanks for noting. I should read more documentations :), anyway it would help a lot to display somewhere in the profile selection the supported directions as this is not obvious, as work together suggests bi-directional operation, at least for me.

@rossko57

@kajarit

when I change the switch item state

How are you doing this exactly? You need to send a command to the Item, the state is irrelevant to Exec.

I’m using a simple toggle card UI element, which I think sends a command to the item.

@rossko57

@kajarit

How can I make this work without using a rule?

I don’t understand why people go to great lengths to avoid rules and/or intermediate Items, when its a straightforward application to achieve what you want. They don’t cost anything.

It’s about simplicity, and ease of use, nothing more. I think using a rule for a simple task like this is actually going to a great length it’s just unnecessary from user experience point of view.

Currently it’s working with a rule, but I think for the average user this is an overkill. Maybe in the near future we’ll be able to do bi-directional mappings with the MAP profile.

Thanks for your quick replies, great community!

[rossko57]

@kajarit

Currently it’s working with a rule, but I think for the average user this is an overkill.

The average user is not using Exec binding. It is quite a technical interface, over and above the internal channels action the user has to understand external stuff like permissions, shells, etc.

openHAB core purpose is Automation - it’s all about rules. If you can’t get to grips with rules, the system is just an overspecified remote control.

It’s not unreasonable to expect the Exec binding user to have to deploy rules to do more than trivial actions - the issue here is that sending on/off parameter appears to be trivial but turns out not to be.

Having said all that, the root cause is that the Exec binding only allows stringy ‘input’ (fair enough) but offers no built-in parsing and/or transformation to deal with non-stringy commands sent to the channel.

Many bindings do offer features like that, I’ve no doubt the Exec binding could be enhanced in a non-breaking way with an “inputTransformation” or such parameter (preferably with a ‘default’ option that simply transcribes ON or 21,56,35 commands to strings)

To get beyond wishing very hard, there’d need to be a formal Github enhancement request (I could not find an existing one). And then a developer interested in implementing it. I wouldn’t expect much priority, it’s just a convenience feature adding nothing that can’t be done by other means

OFF TOPIC - if you are new to Exec, beware it’s “one weird trick”. If relying on autorun to execute when posting a command to ‘input’ channel, note that autorun only triggers for different commands. Command sequence ON, ON, OFF will produce one ON run and one OFF run.