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?
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.
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.
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.
How are you doing this exactly? You need to send a command to the Item, the state is irrelevant to Exec.
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)
This is mentioned in the binding docs
Attention: Linking input to any other item type than String will result in erroneous behavior.
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.
I’m using a simple toggle card UI element, which I think sends a command to the item.
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.
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.