Exec Binding do not work

steve1 · January 5, 2017, 5:00pm

The code has changed over the last month or two so you might see different behavior if you have an installation from around that time or before.

The latest code will trigger execution from the input channel if autorun=true and the item is a String item. No need to bind the run channel in that case.

I agree that the switch use case should have direct support.

Paul_Atkin · January 5, 2017, 5:11pm

ok, I got it almost working.

So, thing had to be defined as this:
Thing exec:command:pluglight [command="/opt/openhab2/conf/scripts/off.sh %2$s", interval=0, timeout=5, autorun=true]

Item is defined as this:
String PlugOne “Lamp One” {channel=“exec:command:pluglight:input”}

adding autorun changed the behavior - now in the basic UI i flip the mapping from on to OFF and it run associated script every time and it passes OFF and ON every time. I checked that - it is easy - here is off.sh script:

#!/bin/sh
echo deleting on ;
rm /opt/openhab2/conf/scripts/testfiles/on ;
echo creating off ;
touch /opt/openhab2/conf/scripts/testfiles/off ;
echo 1 >> /opt/openhab2/conf/scripts/testfiles/off
echo $1 >> /opt/openhab2/conf/scripts/testfiles/off
echo 2 >> /opt/openhab2/conf/scripts/testfiles/off
echo $2 >> /opt/openhab2/conf/scripts/testfiles/off
echo 3 >> /opt/openhab2/conf/scripts/testfiles/off
echo $3 >> /opt/openhab2/conf/scripts/testfiles/off

I am now trying to fix other scripts and check what parameter value gets passed. my old scripts needed only lower case ‘on’ and ‘off’ - this new thing passes uppercase. but it seems to be getting there.

Paul_Atkin · January 5, 2017, 5:23pm

I sort of got it to turn on and off now. But i am still at a complete loss how I am supposed to marry status check with this switch object. Here is a working config i have now for the TPLink hs200:

Things file:
Thing exec:command:pluglight [command=“/opt/openhab2/conf/scripts/hs100.sh 192.168.10.42 9999 %2$s”, interval=0, timeout=5, autorun=true]
Thing exec:command:pluglightcheck [command=“/opt/openhab2/conf/scripts/hs100.sh 192.168.10.42 9999 check”, interval=1, timeout=5]

Items:
String PlugOne “Lamp One” {channel=“exec:command:pluglight:input”}

Sitemap:
Switch item=PlugOne mappings=[“on”=“on”,“off”=“off”]

So all this above allows to go into basicUI, find ‘Lamp One’ in there and toggle it off and on and it turns off an on fine, very good. Half way there.
Now, what should be done to update status of ‘Lamp One’ in the interface using this other thing ‘exec:command:pluglightcheck’ when lamp switch is flipped by hand?

OK, i solved that too.

items:
String PlugOne “Lamp One” {channel=“exec:command:pluglight:input”}
String PlugOneState “Plug One Status” {channel=“exec:command:pluglightcheck:output”}

things:
Thing exec:command:pluglight [command=“/opt/openhab2/conf/scripts/hs100.sh 192.168.10.42 9999 %2$s”, interval=0, timeout=5, autorun=true]
Thing exec:command:pluglightcheck [command=“/opt/openhab2/conf/scripts/hs100.sh 192.168.10.42 9999 check”, interval=1, timeout=5]

sitemap:
Switch item=PlugOne mappings=[“ON”=“ON”,“OFF”=“OFF”]
//Text item=PlugOneState label=“Plug One State [%s]”

rule:
rule “Plug One”
when
Item PlugOneState changed from ON to OFF
then
postUpdate(PlugOne,“OFF”)
logInfo(“Network”, "Switching Plug Off: " )
end

rule “Plug Two”
when
Item PlugOneState changed from OFF to ON
then
postUpdate(PlugOne,“ON”)
logInfo(“Network”, "Switched Plug On: " )
end

This way it flips PlugOne in the sitemap according to the status. All works, switch switches, all good.

Paul_Atkin · January 5, 2017, 6:18pm

This solution has issues. When you flip switch by hand - say, it was OFF and you set it to ON by hand - it updates status on the screen correctly, so interface shows ‘ON’. When you press ‘OFF’ on the screen - this thing DOES NOT execute the script!

I think it presumes that actual channel is still at ‘OFF’ so there is no change and it does not run anything. If you then flip switch to ON and then to OFF - in the interface - only then it works. It is unacceptable, as with Alexa voice command it is infuriating - you tell it to turn it off and it does not do it.

How can the input channel status be updated? String associated with it does not seem to do anything.

steve1 · January 5, 2017, 7:12pm

@Paul_Atkin, have you tried binding both the input channel of the thing that controls the lights and the output channel of the status check script to the same item (similar to Karel’s earlier example in this topic)?

A command sent to the item will be processed by the input channel (assuming autorun=true) and will trigger the control script to run. The result of the periodically polled check script should be written to the item state via the output channel.

@kgoderis, since the ‘autorun’ option only applies to the input channel, wouldn’t it be better to support that type of configuration? For example, I have seen this in the documentation…

Contact Garage { channel="zwave:21:command=sensor_binary,respond_to_basic=true" }

Applied to Exec…

Thing exec:command:switch_control [command="/tmp/switch.sh %2$s"]
Thing exec:command:switch_monitor [command="/tmp/switch.sh check"]

String ExecInput { channel="exec:command:switch_control:input,autorun", channel="exec:command:switch_monitor:output,interval=1" }

(warning: there may be syntax errors in these examples since I don’t have access to my OH system at the moment.)

Paul_Atkin · January 5, 2017, 7:34pm

Does not work.

with ‘interval=1’ added it generates error like shown at the end of the response. if ‘interval’ removed error not shown, but in both cases system behaves as this: you flip switch manually, it changes on the screen. if you click on the interface to flip it - it jumps, say, from ‘ON’ to ‘OFF’ as instructed, then jumps back to ‘ON’, actual switch does not change.
so it still does not work. i suspect it is due to the value of “exec:command:pluglight:input” that gets stuck to what was set by the interface and not updated by the actual manual change of the device.

Item is defined as this:

String PlugOne “Lamp One” [ “Switchable” ] {channel=“exec:command:pluglight:input”, channel=“exec:command:pluglightcheck:output”}

2017-01-05 14:29:01.083 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'My_House.items’
2017-01-05 14:29:01.092 [ERROR] [el.item.internal.GenericItemProvider] - Binding configuration of type ‘channel’ of item ‘PlugOne’ could not be parsed correctly.
org.eclipse.smarthome.model.item.BindingConfigParseException: UID must have at least 4 segments.
at org.eclipse.smarthome.model.thing.internal.GenericItemChannelLinkProvider.createItemChannelLink(GenericItemChannelLinkProvider.java:82)[131:org.eclipse.smarthome.model.thing:0.9.0.201612221226]
at org.eclipse.smarthome.model.thing.internal.GenericItemChannelLinkProvider.processBindingConfiguration(GenericItemChannelLinkProvider.java:72)[131:org.eclipse.smarthome.model.thing:0.9.0.201612221226]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:312)[121:org.eclipse.smarthome.model.item:0.9.0.201612221226]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:284)[121:org.eclipse.smarthome.model.item:0.9.0.201612221226]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.processBindingConfigsFromModel(GenericItemProvider.java:167)[121:org.eclipse.smarthome.model.item:0.9.0.201612221226]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.modelChanged(GenericItemProvider.java:347)[121:org.eclipse.smarthome.model.item:0.9.0.201612221226]
at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.notifyListeners(ModelRepositoryImpl.java:207)[120:org.eclipse.smarthome.model.core:0.9.0.201612221226]
at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.addOrRefreshModel(ModelRepositoryImpl.java:120)[120:org.eclipse.smarthome.model.core:0.9.0.201612221226]
at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.checkFile(FolderObserver.java:270)[120:org.eclipse.smarthome.model.core:0.9.0.201612221226]
at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.access$1(FolderObserver.java:264)[120:org.eclipse.smarthome.model.core:0.9.0.201612221226]
at org.eclipse.smarthome.model.core.internal.folder.FolderObserver$WatchQueueReader.processWatchEvent(FolderObserver.java:145)[120:org.eclipse.smarthome.model.core:0.9.0.201612221226]
at org.eclipse.smarthome.core.service.AbstractWatchQueueReader.run(AbstractWatchQueueReader.java:122)[96:org.eclipse.smarthome.core:0.9.0.201612221226]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_112]

steve1 · January 5, 2017, 7:54pm

Where did you put the interval=1? Hopefully it was not in the output channel binding string. That was a proposal to Karel about a different way of specifying the channel options. The interval=1 for the check script should be in the thing definition as shown in the Exec binding documentation.

steve1 · January 5, 2017, 10:50pm

I tried using the two channel approach and it works mostly as expected.

// Things
Thing exec:command:switch_control [command="switch_control.sh %2$s", interval=0, autorun=true]
Thing exec:command:switch_monitor [command="switch_control.sh check", interval=1]

// Item
String ExecSwitch {channel="exec:command:switch_control:input", channel="exec:command:switch_monitor:output" }

Binding the item to a Switch in the sitemap makes the script run when the switch is changed. When the output channel is polled, the item state is set to the return value of the script, which in this case is “ON” or “OFF”. The UI then updates the visual Switch representation accordingly.

The only slightly surprising behavior I saw was that when the command was sent to the item bound to the input channel, the item’s state was also set to the command value immediately (like autoupdate in OH1). I would have expected the state to not change until the output channel is polled. However, this shouldn’t cause a serious problem in most cases.

kgoderis · January 6, 2017, 8:12am

String ExecSwitch {channel=“exec:command:switch_control:input”, channel=“exec:command:switch_monitor:output”, autoupdate=“false” }

steve1 · January 6, 2017, 11:03am

Ah, thanks. I didn’t know that was also supported in OH2.

Paul_Atkin · January 6, 2017, 1:52pm

i have removed ‘interval’ completely, where to put - it was put in the item as you posted it. it is irrelevant.

issue is not with the ‘interval’. issue is with the channel “exec:command:pluglight:input” that refuses to execute shell command as it presumes its status is still unchanged while switch state was altered manually.

I have to leave to the business trip tomorrow - is there any solution to this non-sense or my house will be left for an another week with not working switches? Is there anything that can be done to make this work?

AGAIN.
I just did exactly the thing how we explained it above and removed all rules.

Thing exec:command:pluglight [command=“/opt/openhab2/conf/scripts/hs100.sh 192.168.10.42 9999 %2$s”, interval=0, timeout=5, autorun=true]
Thing exec:command:pluglightcheck [command=“/opt/openhab2/conf/scripts/hs100.sh 192.168.10.42 9999 check”, interval=1, timeout=5]

String PlugOne “Lamp One” [ “Switchable” ] {channel=“exec:command:pluglight:input”, channel=“exec:command:pluglightcheck:output”,autoupdate=“false”}

sitemap:
Switch item=PlugOne mappings=[“ON”=“ON”,“OFF”=“OFF”]

So, one more time - it indeed shows the Switch in the sitemap. it indeed changes the state on the sitemap when you flip it manually. What you did not do - and what i see in my case - AFTER you flip switch manually and after it switched on the sitemap interface screen, say, from OFF to ON - i try to press OFF on the screen and it DOES NOT DO THAT!

it does not go to OFF position - it stays on ON position. Only way to make it go to OFF position is to press ON on the screen and then press OFF.

This stupidity will not let this switch be correctly voice controlled if anybody presses button manually. Is there any solution to this?

PS. correction - it is on the properly working mobile app interface button does not even press for OFF. on the PC web Basic UI interface button presses happily and status changes to OFF on the screen but an actual switch does not trigger and if you refresh the page it reverts back to ON position where it in fact remains.

watou · January 6, 2017, 1:56pm

You could revert to the 1.x Exec binding, correct?

Paul_Atkin · January 6, 2017, 1:58pm

no, not correct. In this new build old exec binding is not included, but if I try to manually move old package into ‘addons’ and activate legacy 1.x support - whole openhab2 system hangs indefinitely and only way to resolve that is to delete whole install and go from the scratch. i do not have stamina and time to reverse engineer this whole contraption.there is nothing in logs, it just hangs.

If i only could revert to old binding i would not even spent 5 min of my time fighting this stupid stuff. This openhab nightmare gets into a full time job just to maintain the config. Whole thing started from the forceful announcement that new portal is coming and everybody will lose remote access via old way, so new code has to be deployed. And only way to deploy new code is to wipe out clean an entire old install - again, it all worked incrementally since May for upgrades, but, no, this time it all went kaput. Before that my house was on an actually early October build with 0 issues. Then I did put on this newer Dec 10th or something and it has been nightmare ever since and wife now demands all switches to be torn out from the walls.

steve1 · January 6, 2017, 2:14pm

Just to clarify, if you put it in the item channel binding, that’s the wrong location. It should be in the Thing declaration. I think you may be trying to use an example of a proposed change I was describing to Karel.

I’ll do some more investigation on the input channel issue you’re describing. Please let us know if you learn more on your end.

Paul_Atkin · January 6, 2017, 2:18pm

nope, not in the item, it is in the thing - I posted an exact copy of config above. I suspect the issue, again, with using 2 diff channels and refusal of the ‘input’ channel to run any script if it presumes its active status did not change.
if my presumption is right or wrong i do not know, but it seems unless ‘check’ channel somehow communicates with ‘input’; channel we are stuck here.

try to replicate setup i posted above, flip switch manually and confirm pls if you get same behavior or not.

Paul_Atkin · January 6, 2017, 2:39pm

Also, is there any way at all to define an item as a Switch instead of defining it as a String for exec binding?

I cannot push commands from a rule into a String item using sendCommand clause from the rule - I just tried and it did not do anything.

steve1 · January 6, 2017, 10:32pm

@Paul_Atkin, I understand your issue given the item is controlled both by OH2 and manual switch operation.

I’ve created an issue with some recommendations about how to improve the Exec 2.0 binding. Everyone, please add anything I missed.

kgoderis · January 10, 2017, 8:54pm

Paul,

Can you please put the binding in a TRACE log level, and then post some of the log files so that these can be dissected?

Tx
K

steve1 · January 11, 2017, 11:32am

@Paul_Atkin, for FWIW I was able to create a simple rule to send commands to the String item.

String ExecSwitch

rule "Send command to ExecSwitch"
when
    Item ExecSwitchTrigger received update
then
    sendCommand("ExecSwitch", ExecSwitchTrigger.state.toString())
end

steve1 · January 11, 2017, 11:35am

If you have an interest in seeing an improved Exec binding, I suggest you subscribe to the GitHub issue I opened and participate in the discussion. See the link I posted above.