OpenHAB2 exec absolutely does not work

Setup, Configuration and Use Runtime
,
1

Hi guys
sorry for my English

I installed openhab2 on raspberry pi3

A task:

  1. Run python program by pressing the Switch to the UI
    Python program using GPIO
  2. Python program using UART

All two program works in console.

But

Switch  Sw_1  "Switch_1" {exec=">[OFF:python /etc/openhab2/scripts/myprog/ser.py] >[ON:python /etc/openhab2/scripts/myprog/ser2.py]"}

Nothing happens.

Exec binding I installed from Paper UI

Maybe problem is permission. Because i dont see openhub user.
Maybe addon directory, because i dont see to.

what am I doing wrong?

thanks you all.

2

It appears from your items file that you are not using the 2.0 binding.

If you want to use the “legacy” binding then you need to enable the “compatibility layer”.

Othewise, there is now an Exec 2.0 binding that you may consider using instead.

3

could you give an example item with Exec 2.0 and runing python program?

4

I nearly have the same problem. As I understood you have to use channels in Exec 2.0.

I tried the following (as I already described in this post ):

I’ve defined the following things:

// switch on with parameter '-t'
Thing exec:command:it14On  [command="pilight-send -p kaku_switch_old -i 14 -u 1 -t"]
// switch off with parameter '-f'
Thing exec:command:it14Off [command="pilight-send -p kaku_switch_old -i 14 -u 1 -f"]

and tried this in my items file:

Switch test1 { channel="exec:command:it14On:run", channel="exec:command:it14Off:run"}
Switch test2 { channel="[ON: exec:command:it14On:run], [OFF: exec:command:it14Off:run]"}

But when I push the button both commands are executed.

As workaround I trigger ON / OFF execution in a rule at the moment.

rule "IT14"
when
	Item Intertechno14 received command
then
	if (Intertechno0.state==ON) {
		executeCommandLine("pilight-send -p kaku_switch_old -i 14 -u 1 -t")
    } else {
		executeCommandLine("pilight-send -p kaku_switch_old -i 14 -u 1 -f")
    }
end

But I hope someone have an idea and can explain how to bind two exec commands to one switch.

5

I have the following setup and it works just fine:

.things
Thing exec:command:speedtest [ command="/usr/local/bin/speedtest-cli --simple", interval=3600, timeout=60 ]

.items
Switch		Speedtest_Run			{ channel="exec:command:speedtest:run" }
String		Speedtest_Output 		{ channel="exec:command:speedtest:output" } 
Number		Speedtest_Exit			{ channel="exec:command:speedtest:exit" }
DateTime	Speedtest_LastExecution	{ channel="exec:command:speedtest:lastexecution" }

The command is executed once an hour, or on demand if I toggle the Run switch.

6

OK, I am completely lost why thie exec binging model needed to be changed, but, as it got changed, i guess it was needed.

I had those things defined in the old November relase version of this exec binding. I am completely lost - how am i supposed to convert it into new model?

Switch PlugOne “Lamp One” (FF_Living, FF_Lights, FF_Lights1, FF_Lights2, Lights) [ “Switchable” ] { exec="<[/opt/openhab2/conf/scripts/hs200.sh@@192.168.10.42@@9999@@check:1000:REGEX((.*?))] >[ON:/opt/openhab2/conf/scripts/hs100.sh@@192.168.10.42@@9999@@on] >[OFF:/opt/openhab2/conf/scripts/hs100.sh@@192.168.10.42@@9999@@off]"}

I have created only 3 things for now, to test this, with no items made yet to use `em. I do not understand how those 2 separate things are supposed to accomplish what an item definition above was doing.

Thing exec:command:plugoneon [ command="/opt/openhab2/conf/scripts/hs100.sh 192.168.10.42 9999 on"]
Thing exec:command:plugoneoff [ command="/opt/openhab2/conf/scripts/hs100.sh 192.168.10.42 9999 off"]
Thing exec:command:plugonestatus [ command="/opt/openhab2/conf/scripts/hs100.sh 192.168.10.42 9999 status",transform=“REGEX((.*?))”]

So, those scripts, if run, will toggle a plug switch on, off, and get status. I assumed, from reading a documentation, that next step is to create an item that will invoke execution of a script defined as a ‘thing’.

So what happens now - openhab2 apparently runs those ‘things’ automatically without me asking it to do it - as i hear my switch to click from time to time now, with no items yet crafted it is quite unacceptable - why does it run those scripts on its own initiative?

there are also those lines in the log:
2016-12-19 22:43:48.406 [WARN ] [home.core.thing.binding.ThingFactory] - Could not create channel ‘run’ for thing type ‘exec:command:plugoneon’, because channel type ‘exec:running’ could not be found.
2016-12-19 22:43:48.408 [WARN ] [.thing.internal.GenericThingProvider] - Could not create channel ‘run’ for thing ‘exec:command:plugoneon’, because channel type ‘exec:running’ could not be found.
2016-12-19 22:43:48.410 [WARN ] [home.core.thing.binding.ThingFactory] - Could not create channel ‘run’ for thing type ‘exec:command:plugoneoff’, because channel type ‘exec:running’ could not be found.
2016-12-19 22:43:48.410 [WARN ] [.thing.internal.GenericThingProvider] - Could not create channel ‘run’ for thing ‘exec:command:plugoneoff’, because channel type ‘exec:running’ could not be found.
2016-12-19 22:43:48.411 [WARN ] [home.core.thing.binding.ThingFactory] - Could not create channel ‘run’ for thing type ‘exec:command:plugonestatus’, because channel type ‘exec:running’ could not be found.
2016-12-19 22:43:48.411 [WARN ] [.thing.internal.GenericThingProvider] - Could not create channel ‘run’ for thing ‘exec:command:plugonestatus’, because channel type ‘exec:running’ could not be found.
20

What does all this mean and is there a way to get rid of this stupidity and revert back to an old syntax?

7

No, there is no way to get rid of it.

The important thing to know/study is that OH2 does not work in the same way as OH1. This is not only related to the Exec 2.0 binding, it relates to any binding

Whereas in OH1 many bindings adopted the concept of including ON, OFF or whatever as a delimiter to execute one part or another of an items definition, in OH2 this does not exist anymore.

The best way forward is to familiarise yourself with the concept of Things and Channels before jumping into the gritty nitty of the configuration of the bindings you want to use.

The last lines you mention are a bug and a fix is ready to be merged.

8

@Paul_Atkin,

Could you solve the problem? I’m using the same HS110 and I have no Idea why they are toggling my plug on and off by themself.

How can I create an item that uses 3 things (ON, OFF, STATUS) ?

9

OK, there are at least 3 threads on this topic. I am trying to put something together. There are multiple things that do not work right now but there is a way to work around all that with rules. It is quite like pulling a tooth via ones butt, but, may be done.

The setup I have included Alexa controlling house via groups and directly to switches via hueemulation together with the openhab app on the mobile. To make it work with the interface is relatively straight forward, but voice control and control via groups does not work at all. So the approach is to use combination of things defined as below for commands:

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]

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

Thing exec:command:mikelight [command="/opt/openhab2/conf/scripts/hs100.sh 192.168.10.46 9999 %2$s", interval=0, timeout=5, autorun=true]
Thing exec:command:mikecheck [command="/opt/openhab2/conf/scripts/hs100.sh 192.168.10.46 9999 check", interval=1, timeout=5]

Then items for HS100 should be made as strings:

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”}

You can see above i am exposing those strings to hue emulator and into groups. So, what i am working on now is to craft a rule that will actually issue commands to this string from an actual ‘Switch’ item as in this configuration above you can issue a direct command into that string item, or flip it via interface but it refuses to receive commands from the group level.

Also, what is worse - this string refuses to issue an ‘OFF’ command to the HS100 device if you had device originally in the 'OFF" position but them flipped it to ‘ON’ manually. It is a total bummer as Alexa says ‘OK’ to the command but light stays on.

for that I will try to craft a rule to look at statuses and issue a series of OFF/ON commands to deal with this non-sense.

10

ok, it is 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

11

OK, I am completely lost why thie exec binging model needed to be changed, but, as it got changed, i guess it was needed.

I don’t see why Exec is a better fit as Things and Channels, but several reasons why the 1.x is and will always be easier to use (YMMV). You can still use the 1.x binding and it’s documented (just as all the add-ons) at docs.openhab.org

http://docs.openhab.org/addons/bindings/exec1/readme.html

12

and i forgot one last piece of this stupid puzzle.
you need to teach HS100.sh script to understand on and ON in all shapes, as well as 0 and 100:

check_dependencies
check_arguments

case “$cmd” in
100)
cmd_switch_on
;;

ON)
cmd_switch_on
;;
on)
cmd_switch_on
;;
0)
cmd_switch_off
;;

OFF)
cmd_switch_off
;;
off)
cmd_switch_off
;;
toggle)
cmd_switch_toggle
;;
check)
cmd_print_plug_relay_state
;;
status)
cmd_print_plug_status
;;
emeter)
cmd_print_plug_consumption
;;
*)
show_usage
;;
esac

13

No sh$t there is a lot of what is documented, it just does not work and if you try to push it into the mix by force instead of supplied v2 binding - whole openhab2 hangs. IF this exec binding 1.x would work no one would have to deal with this non-sense. it does not work anymore with any openhab2 builds posted after mid-november. At least i tried it several times and every time it would end up with totally incapacitated install that had to be manually erased and reinstalled from the scratch.

14

Is there an issue open reporting that the Exec 1.x binding does not work under OH2?

Do you have

legacy = true

in your addons.cfg? And

binding = [<all of your other binding IDs>,] exec1

there as well?

15

yes, I had all that. legacy string, manual binding and dropped war file into the folder. It killed whole thing.
As of opening reporting issues, etc - no clue. The issue would look like openhab.log posting 3-4 front lines stating ‘loading’ but no interfaces would be up and running - no basic, no paper-ui, and whole thing would be frozen, with java session up and running. i never had any desire to investigate more. I just figured no one ever did any QA or tests for this stuff.

Solution i posted above for ver 2 binding works for me now and i do not want to spend any more time on this or update this installation as long as it still works and turns my lights on and off. that is what i need it for.

1 Like
16

Seriously? I need >40 lines of code what I could do in one line before??
Who had the idea to call this an improvement?

1 Like
17

I’m stuck with the same problem. Openhab 1.0 I could do this with 1 line of code, now it’s like I’m writing a kernel driver. I just want to press a switch and send a switch command and have it send a code using 433utils. Who honestly thinks this is a better solution?

18

Same issue here. Any ideas?

19

I just went back to openhab 1, sorry

20

I had issues in getting the OH2 Exec binding to work as well. I used the workaround with executeCommandLine: and it does what it is supposed to do.

rule ertrag
when
		Time cron "0/30 * * * * ?" // this one cycles every 30 seconds. 
	then		
			val solar =  executeCommandLine("/opt/scripts/pvstatus.sh", 5000)
			PV_Ertrag.postUpdate(solar) 			
end