Question about EXEC Binding in OH2

Setup, Configuration and Use Runtime
1

I got a question about the exec binding in OH2, which i already asked here. I don´t understand how to migrate my old exec binding triggered scripts to OH2 and need some advice. The bash-script looks like this:

cat licht_sofa.sh 
!/bin/bash
value="$1"

if [ $value == "ON" ]; then

an () {
echo "TXP:0,0,10,5600,350,25,1,3,1,3,1,3,1,3,1,3,3,1,1,3,1,3,1,3,1,3,1,3,1,3,1,3,3,1,1,3,3,1,1,3,3,1,1,3,3,1,1,3,1,3,1,3,3,1,1,16,;" | nc -u 192.168.188.25 49880 &
pid=$!
sleep 1
kill $pid 2>/dev/null >/dev/null
}
echo An
an

else
aus () {
echo "TXP:0,0,10,5600,350,25,1,3,1,3,1,3,1,3,1,3,3,1,1,3,1,3,1,3,1,3,1,3,1,3,1,3,3,1,1,3,3,1,1,3,3,1,1,3,3,1,1,3,3,1,1,3,1,1,1,16,;" | nc -u 192.168.188.25 49880 &
pid=$!
sleep 1
kill $pid 2>/dev/null >/dev/null
}
echo Aus
aus

fi

If i call the script from shell with variable ON or OFF, the device (a Brennestuhl wallplug which get a put from the Brematic controller on my network) switches from ON to OFF or vice versa.

In OH1.x i call this script from .items-file like this (note that for ON and OFF, there are two scripts needed in OH1.x):

Switch	Light_GF_Living_Couch	"Steckdose Sofa"	(GF_Living)	{ exec="OFF:/opt/brematic/licht_sofa_off.sh, ON:/opt/brematic/licht_sofa_on.sh" }

In OH2, i define a new thing and call the variable-active script:

Thing exec:command:wallplug [command="/opt/brematic/licht_sofa.sh", interval=0, timeout=5]

But how can i send ON or OFF to the script?
Referring the docs, an item can look like this:

String APCRaw "[%s]" (All) {channel="exec:command:apc:output"} 
Switch APCRunning { channel="exec:command:apc:run"}
Number APCExitValue {channel="exec:command:apc:exit"}
DateTime APCLastExecution {channel="exec:command:apc:lastexecution"}

Normally i would guess that my item has to look like

Switch LichtSofa { channel="exec:command:wallplug:run"}

but in this way, i can´t get the switch to toogle its state. What am i doing wrong?

PS / Hint:
There is no chance to get state switches state from the controller. So the best option would be to call maybe ON first, each time the script is fired. So you got a chance of 50% that the switch goes on or off. Otherwise i should also be possible to read the state from persistence in some way

2

Hi @alexander.karls

How about using two switches (both with “run”).
One for licht_sofa_on and one for licht_sofa_off:

Things
Thing exec:command:licht_on [command="/opt/brematic/licht_sofa_on.sh, timeout=5]
Thing exec:command:licht_off [command="/opt/brematic/licht_sofa_off.sh, timeout=5]

Items
Switch licht_sofa_on {channel=“exec:command:licht_on:run”}
Switch licht_sofa_off {channel=“exec:command:licht_off:run”}

Then you need a third switch which changes the other two according to its state:

Rule

rule "Licht Sofa"
when
	Item licht_sofa changed 
then
	if(licht_sofa.state == OFF){
		licht_sofa_off.sendCommand(ON)
		licht_sofa_on.postUpdate(OFF)
	}
	if(licht_sofa.state == ON){
		licht_sofa_on.sendCommand(ON)
		licht_sofa_off.postUpdate(OFF)
	}
end
1 Like
3

Thanks @NCO,
thats what i feared already. Compared with the old binding this tripples the effort of simply switching a wallplug on or off. In my case thats a lot of more work than before, as i´m a extreme exec user (putting SNMP values to devices, sending SMS to GSM Wallplugs via webservices, switching Brennenstuhl wallplugs and so on). Maybe the best shot would be using the old binding, but on the other hand, that´t not what i wanted to do… Decisions, some many decisions…

4

Hi @alexander.karls,

I agree and I am not happy with it either.
However, if you have this setup done once, it’s quite simple to spread it out.
Fortunately I just have about 10 exec items I need to transform (with I did not do completely yet due to the effort).

On the long run I see that it makes sense to harmonize the different bindings, so the change makes sense - even though it’s a PITA on the first look. :wink:

5

maybe i´ll write a small perl script that does the dirty work so that one only has to enter the items unique name once and then the things, items and rules get autocreated in the correct folders. that should simplify the whole process

6

Got it done, look here: