Exec 2.0 : Updated : new functionalities to address your concerns

All,
@alexander.karls @SpaceGlider @demlstda @stefaanbolle @rlkoshak @danielwalters86 @aaronk6 @nibi79 @steve1 @Paul_Atkin

Anyone having questions or issues on the Exec 2.0 binding, I just created https://github.com/openhab/openhab2-addons/pull/1693 to address some (and hopefully most) of your concerns

Pls see the Readme.md in the pull request to get a feeling of what has changed.

Karel.

2 Likes

Thank you for that very last example Item. That alone I think clarifies a lot of confusion some users have had with how to use the binding.

I’ve done some testing and found an issue. I’ve also reviewed the documentation and code and recorded some comments and have made some additional suggestions. Issue details are at:

i just got back from business trip and did not look at the code or readme yet. Is there any need to re-test or is there still work to be done for an update of the switch state if it is pressed by hand?

Hi Steve, are there any updates to the code in just posted official openhab2 release for Exec binding or is it still under development for any changes related to the status update from a manual switch?
Also, i just got more time to map those ‘String’ objects as ‘Switchable’ for Alexa control - nothing of this works correctly at all. From BasicUI you indeed can click on those ‘String’ items and they perfom commands. But i think when this ‘string’ is exposed over hue emulation into Alexa - an external command to turn it on or off does not do anything, as it is a ‘string’, not a ‘switch’. and if you define in the items file this item as a ‘switch’ - it refuses to run a command file.

So, whole thing is still not operational at all. I wish somebody simply did a dedicated binding for TPLink switches as it seems this deviation into new channels method is problematic…

OK, i figured out what was going on - it was sending ‘100’ and ‘0’ commands from the Hue emulator instead of ‘ON’ and ‘OFF’, so i altered the shell script to process that. Now it is controlling the switch, but still refuses to send an ‘OFF’ command if switch is flipped manually into ‘ON’.
Also, a command issues to the ‘String’ via Alexa app works, but a command issues to a group this ‘String’ is a part of and propagated (according to logs) to the String item has 0 effect - i see it showing up but script is not executed.
So issue is still same as it was. Definitions are done as:

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:islandlight [command="/opt/openhab2/conf/scripts/hs100.sh 192.168.10.41 9999 %2$s", interval=0, timeout=5, autorun=true]

//Thing exec:command:pluglight [command="/opt/openhab2/conf/scripts/off.sh %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]
Thing exec:command:islandcheck [command="/opt/openhab2/conf/scripts/hs100.sh 192.168.10.41 9999 check", interval=1, timeout=5]

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

String Island “Island Light” (FF_Kitchen, FF_Lights, FF_Lights1, FF_Lights2, Lights) [ “Switchable” ] {channel=“exec:command:islandlight:input”, channel=“exec:command:islandcheck:output”,autoupdate=“false”}

Hi @Paul_Atkin. To minimize any confusion, I’m not the developer of the Exec binding. That would be @kgoderis. I’m just a another openHAB user. I recommend not using the Exec 2 binding for your use case. The binding might be more useful after some changes are made but it’s currently not straightforward to implement switch behavior where a a physical switch is also being used. I’ve gathered the suggestions that have been discussed here, have added a few and create an issue for it (see link in previous post). Feel free to participate in that discussion.

Makes sense, thanks.It is frustrating as it makes it possible to use TPlink HS100 switch with openhab.

I will try to figure out what can be done, if anything, to make 1.x version of the exec binding to work again.

ok, it is quite ugly but it works.

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]

Switch Pluggy “Lamp One” (FF_Lights, FF_Lights1, FF_Lights2, Lights) [ “Switchable” ]
(this switch is what you put into sitemap and into all groups)

String PlugOne {channel=“exec:command:pluglight:input”, channel=“exec:command:pluglightcheck:output”,autoupdate=“false”}

String PlugOneState “Plug One Status” {channel=“exec:command:pluglightcheck:output”}

(strings to communicate with the HS100)

and rules
rule "Plug One 1"
when
Item Pluggy changed from ON to OFF
then
// if ((Sensor2Lum.state<50) {
postUpdate(PlugOneState,“OFF”)
sendCommand(PlugOne,“OFF”)
logInfo(“Network”, "Switching Pluggy Off: "+PlugOneState.state )
// }
end

rule "Plug One 2"
when
Item Pluggy changed from OFF to ON
then
logInfo(“Network”, "Switching Pluggy On: "+PlugOneState.state )
// if (Sensor2Lum.state<50) {
postUpdate(PlugOneState,“ON”)
sendCommand(PlugOne,“ON”)
logInfo(“Network”, "Switched Pluggy On: "+PlugOneState.state )
// }

end

rule "Plug One 3"
when
Item PlugOneState changed from OFF to ON
then
logInfo(“Network”, "Switching Pluggy On: "+PlugOneState.state )
// if (Sensor2Lum.state<50) {
postUpdate(Pluggy,“ON”)
sendCommand(PlugOne,“ON”)
logInfo(“Network”, "Switched Pluggy On: "+PlugOneState.state )
// }

end

rule "Plug One 3"
when
Item PlugOneState changed from ON to OFF
then
logInfo(“Network”, "Switching Pluggy On: "+PlugOneState.state )
// if (Sensor2Lum.state<50) {
postUpdate(Pluggy,“OFF”)
sendCommand(PlugOne,“OFF”)
logInfo(“Network”, "Switched Pluggy On: "+PlugOneState.state )
// }

end

rule "Plug One"
when
    Item Pluggy changed
then
    logInfo("Network", "Switching Pluggy " + Pluggy.state + ": " + PlugOneState.state)

    PlugOneState.postUpdate(Pluggy.state)
    PlugOne.sendCommand(Pluggy.state)
end

rule "Plug One State"
when
    Item PlugOneState changed
then
    logInfo("Network", "Switching Pluggy " + PlugOneState.state + ": " + PlugOneState.state)
    Pluggy.postUpdate(PlugOneState.state)
    PlugOne.sendCommand(PlugOneState.state)
end

It would help if you actually tried it before posting - you would see that it does not work and does not control the switch.

it also produces this error:
2017-02-06 12:34:40.122 [INFO ] [lipse.smarthome.model.script.Network] - Switching Pluggy ON: OFF
2017-02-06 12:34:40.123 [ERROR] [.script.engine.ScriptExecutionThread] - Rule ‘Plug One’: An error occured during the script execution: Could not invoke method: org.eclipse.smarthome.model.script.actions.BusEvent.sendCommand(org.eclipse.smarthome.core.items.Item,
java.lang.Number) on instance: null

Thx for the illustration on methods invocation, it actually helped on some other item i dealt with.

I have the choice of typing examples up on my phone for illustrative purposes or nothing at all.

Take it or leave it.

As you did not do any typos on object names i presume this error below probably indeed serves quite a good illustrating purpose:

2017-02-06 12:34:40.123 [ERROR] [.script.engine.ScriptExecutionThread] - Rule ‘Plug One’: An error occured during the script execution: Could not invoke method: org.eclipse.smarthome.model.script.actions.BusEvent.sendCommand(org.eclipse.smarthome.core.items.Item,
java.lang.Number) on instance: null

Given that everything is called “plug” and ON and OFF is being sent to all of these Items I assumed they were all Switches. I see now they are Strings (because exec requires that?).

Everywhere you see .state use .state.toString (e.g. Pluggy.state.toString).

I’m not sure why it is not converting the state to a String for you (normally it does).

Is your hs-100.sh same as TP-LINK HS100 Smart Plug (WiFi)? ? The script works but I can’t get it to work in openhab2 with what you did.