Example of status update for Exec Binding device

Setup, Configuration and Use 1.x Compatibility
3

Sorry, i am using openhab2 and code above does not work at all - it does not switch anything and does not react to a manual change of the device`s state.
I created this line with name PlugTwo, placed it into items file, made mapping to the basic UI, i can click on the item in the UI - it changes state there - nothing happens to an actual device and nothing gets executed.
I already tried this method initially and the one and only method that actually worked was a combination of the item description i posted with a rule having execution commands. As nothing gets printed in the log at all i am not sure what to do with that.

Am I correct to presume that a reference given to the link Exec Binding · openhab/openhab1-addons Wiki · GitHub’ applies to old openhab and new openhub2 works in absolutely different way?

6

Hi,

I would really appreciate if anybody who worked with openhab2 could confirm what at TRACE log level should be written in the log for exec binding module coming to life. I have removed now for 3 times and reinstalled from 3 different builds openhab2 from the scratch and every time i see this stuff int he log and i believe it results with exec binding not initialized, so it never gets active and never runs anything. I tried to do some requests from API screen and it seems to be correct.
Why is this happening? It seems any 1.x binding refuses to install - even if org.openhab.core.compat1x gets installed fine. And i get it with any available offline zip for openhab2. Is it a bug or a feature?

2016-10-30 23:58:51.804 [DEBUG] [n.PoolingHttpClientConnectionManager] - Connection manager is shutting down
2016-10-30 23:58:51.804 [DEBUG] [n.PoolingHttpClientConnectionManager] - Connection manager shut down
2016-10-30 23:58:52.098 [INFO ] [internal.service.FeaturesServiceImpl] - Changes to perform:
2016-10-30 23:58:52.098 [INFO ] [internal.service.FeaturesServiceImpl] - Region: root
2016-10-30 23:58:52.098 [INFO ] [internal.service.FeaturesServiceImpl] - Bundles to install:
2016-10-30 23:58:52.098 [INFO ] [internal.service.FeaturesServiceImpl] - mvn:org.openhab.binding/org.openhab.binding.exec/1.9.0-SNAPSHOT
2016-10-30 23:58:52.098 [INFO ] [internal.service.FeaturesServiceImpl] - mvn:org.openhab.core/org.openhab.core.compat1x/2.0.0-SNAPSHOT
2016-10-30 23:58:52.098 [INFO ] [internal.service.FeaturesServiceImpl] - Installing bundles:
2016-10-30 23:58:52.099 [INFO ] [internal.service.FeaturesServiceImpl] - mvn:org.openhab.binding/org.openhab.binding.exec/1.9.0-SNAPSHOT
2016-10-30 23:58:52.100 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.binding.exec (200): Starting destruction process
2016-10-30 23:58:52.100 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.binding.exec (200): Not an extended bundle or destruction of extension already finished
2016-10-30 23:58:52.100 [INFO ] [internal.service.FeaturesServiceImpl] - mvn:org.openhab.core/org.openhab.core.compat1x/2.0.0-SNAPSHOT
2016-10-30 23:58:52.104 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.core.compat1x (201): Starting destruction process
2016-10-30 23:58:52.104 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.core.compat1x (201): Not an extended bundle or destruction of extension already finished
2016-10-30 23:58:52.106 [DEBUG] [org.eclipse.osgi ] - ServiceEvent REGISTERED - {org.osgi.framework.hooks.resolver.ResolverHookFactory}={service.id=319, service.bundleid=0, service.scope=singleton} - o
rg.eclipse.osgi
2016-10-30 23:58:52.113 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.binding.exec (200): Starting destruction process
2016-10-30 23:58:52.113 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.binding.exec (200): Not an extended bundle or destruction of extension already finished
2016-10-30 23:58:52.114 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.core.compat1x (201): Starting destruction process
2016-10-30 23:58:52.114 [DEBUG] [ell.impl.action.osgi.CommandExtender] - org.openhab.core.compat1x (201): Not an extended bundle or destruction of extension already finished
2016-10-30 23:58:52.114 [DEBUG] [org.eclipse.osgi ] - ServiceEvent UNREGISTERING - {org.osgi.framework.hooks.resolver.ResolverHookFactory}={service.id=319, service.bundleid=0, service.scope=singleton}

  • org.eclipse.osgi
    2016-10-30 23:58:52.114 [INFO ] [internal.service.FeaturesServiceImpl] - Starting bundles:
    2016-10-30 23:58:52.114 [INFO ] [internal.service.FeaturesServiceImpl] - org.openhab.core.compat1x/2.0.0.201610290946
    2016-10-30 23:58:52.122 [INFO ] [g.apache.aries.spifly.dynamic.bundle] - Bundle Considered for SPI providers: org.openhab.core.compat1x
    2016-10-30 23:58:52.122 [INFO ] [g.apache.aries.spifly.dynamic.bundle] - No ‘SPI-Provider’ Manifest header. Skipping bundle: org.openhab.core.compat1x
    2016-10-30 23:58:52.122 [DEBUG] [mpl.info.InfoBundleTrackerCustomizer] - Ignore incorrect info null provided by bundle org.openhab.core.compat1x
    2016-10-30 23:58:52.135 [INFO ] [internal.service.FeaturesServiceImpl] - org.openhab.binding.exec/1.9.0.201610280119
    2016-10-30 23:58:52.136 [INFO ] [g.apache.aries.spifly.dynamic.bundle] - Bundle Considered for SPI providers: org.openhab.binding.exec
    2016-10-30 23:58:52.136 [INFO ] [g.apache.aries.spifly.dynamic.bundle] - No ‘SPI-Provider’ Manifest header. Skipping bundle: org.openhab.binding.exec
    2016-10-30 23:58:52.136 [DEBUG] [mpl.info.InfoBundleTrackerCustomizer] - Ignore incorrect info null provided by bundle org.openhab.binding.exec
    2016-10-30 23:58:52.145 [INFO ] [b.core.service.AbstractActiveService] - Exec Refresh Service has been started
    2016-10-30 23:58:52.146 [INFO ] [internal.service.FeaturesServiceImpl] - Done.
    2016-10-30 23:58:52.147 [DEBUG] [.eclipse.jetty.server.HttpConnection] - org.eclipse.jetty.server.HttpConnection$SendCallback@2c81139b[PROCESSING][i=null,cb=Blocker@30b325a4{null}] generate: FLUSH (null,[p=0,l=131,c=3276
    8,r=131],false)@COMMITTED
    2016-10-30 23:58:52.148 [DEBUG] [org.eclipse.jetty.io.WriteFlusher ] - write: WriteFlusher@20bbb520{IDLE} [HeapByteBuffer@3e4ab7f1[p=0,l=6,c=1024,r=6]={<<<\r\n83\r\n>>>\n\n\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x
    00\x00\x00\x00…\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00},HeapByteBuffer@718f10ef[p=0,l=131,c=32768,r=131]={<<<event: message\nda…ensionEvent"}\n\n>>>\n\nnsionEvent"}\n\n,…\x83r\xE2P\x12.\x8d\x93
    "\x83\x13\x1b\xC6\t)}]
    2016-10-30 23:58:52.148 [DEBUG] [org.eclipse.jetty.io.WriteFlusher ] - update WriteFlusher@20bbb520{WRITING}:IDLE–>WRITING
7

Ah, sorry! I forgot to take notice of the fact that you run openHAB2.

The exec-binding is for openHAB1, but it is supposed to work for openHAB2 as well as long as you install/activate the compatibility layer (ref. http://docs.openhab.org/addons/1xaddons.html).

8

OK, after another reinstall and placing jar into addons and chnaging syntax for items exec binding works now fine.
:slight_smile:

It is not fine, it is still odd. :slight_smile:
Switch PlugTwo “PlugTwo” { exec=“OFF:/opt/openhab2/conf/scripts/hs100.sh@@192.168.10.42@@9999@@off, ON:/opt/openhab2/conf/scripts/hs100.sh@@192.168.10.42@@9999@@on”}
Switch PlugOne “PlugOne” { exec=">[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] <[/opt/openhab2/conf/scripts/hs100.sh@@192.168.10.42@@9999@@check:1000:REGEX((.?))]" } [ “Switchable” ]
Switch Kitchen “Kitchen Light” { exec=">[ON:/opt/openhab2/conf/scripts/hs200.sh@@192.168.10.41@@9999@@on] >[OFF:/opt/openhab2/conf/scripts/hs200.sh@@192.168.10.41@@9999@@off] <[/opt/openhab2/conf/scripts/hs200.sh@@192.168.10.41@@9999@@check:1000:REGEX((.?))]" } [ “Switchable” ]

Fro those 3 items “PlugTwo” works fine and i can craft as many samples as needed.
Then it gets crazy - in the configuration as given i get “PlugOne” regognized as an item, it works fine and updates its status.
‘Kitchen’ item is not existing, its link in the UI is not rendering and causes an error upon refreshing screen saying there is no such item.
Then if i comment out “PlugOne’ - 'Kitchen” appears and works fine. Needless to say those are 2 different devices looking at 2 different scripts. Also, if i reverse an order of those 2 things - put ‘PlugOne’ after ‘Kitchen’ - i get working ‘Kitchen’ but i lose ‘PlugOne’.

Does anybody know what is all this about? Is exec binding written to support update for only 1 device? Or do i mess up syntax again somewhere?

PS. This is crazy.
if you switch around order of elements in the itmes - both work. Like these below.
Switch PlugOne “Plug 1” { 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]"}
Switch Kitchen “Kitchen Light” { exec=">[ON:/opt/openhab2/conf/scripts/hs200.sh@@192.168.10.41@@9999@@on] >[OFF:/opt/openhab2/conf/scripts/hs200.sh@@192.168.10.41@@9999@@off] <[/opt/openhab2/conf/scripts/hs200.sh@@192.168.10.41@@9999@@check:1000:REGEX((.?))]" } [ “Switchable” ]

9

These are things I notice right away:

  • You mix items with “old format” (item 1) and “new format” (item 2 and 3)
  • You have something funny at the end of the line on item 2 and 3 ([ “Switchable” ])

I suggest you remove all but one item, and keep that according to the “new format”. You may also try as setup with only an output binding and the only an input binding to narrow down the problem area.

10

I guess, [“Switchable”] is used cause of homekit, if so, please move it before your binding/channel definition.

11

([ “Switchable” ]) clause is the code word for hue emulator to expose those devices to amazon Alexa which was the whole point to spend so much time fighting with openhab2 glitches. otherwise i would simply buy some hardware solution, but, openhab2 is the only solution to mix all those animals together and it seems to work as expected now. I hope i will not run into more issues - just ordered a dozen of devices, ut they all are Z-Wave, so hopefully their integration will go easier.

I am still on the fence with Z-Wave for light switches. I kinda like how i can use both openhab via Alexa and an embedded app on the iPhone/Android for TPLink devices. But all those exec binding glitches are not for the faint of heart and it all seems and looks extremely raw, more in the alpha state then beta. Very tricky and not documented.

12

yes, i figured that part out this morning as well - here is how correct items ended up looking:

Switch PlugOne “Plug One” [ “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]"}
Switch Kitchen “Kitchen Light” [ “Switchable” ] { exec=">[ON:/opt/openhab2/conf/scripts/hs200.sh@@192.168.10.41@@9999@@on] >[OFF:/opt/openhab2/conf/scripts/hs200.sh@@192.168.10.41@@9999@@off] <[/opt/openhab2/conf/scripts/hs200.sh@@192.168.10.41@@9999@@check:1000:REGEX((.?))]" }

A glitch with openhab2 refusing to see items if same order of clauses is used for ON, OFF action still persists, btw. I have only 3 devices from TPLink, so, will see tomorrow how third one will act up, for now i have only 2 installed.

13

now with new ver 2 of EXEC binging nothing of what was above works no more. If anybody can assist and translate those spellings of items above into the new channel model it would be most appreciated as i cannot make it work at all anymore.

14

Paul,

For the record, in the Exec 2.0 binding the @ is not (yet) supported. I know this is a work-around on Mac OS X, but being a Mac OS X user myself I strangly never had the problem with execution of commands, and never had to use @ to fix the problem. However, if needed this can be added back in.

See my other post in the other thread, constructs like >[ON:/… can not be used in OH2.

in .things:

Thing exec:command:kitchenlight [command=“/opt/openhab2/conf/scripts/hs200.sh 192.168.10.41 9999 %2$s”, interval=0, timeout=5]

Thing exec:command:kitchencheck [command=“/opt/openhab2/conf/scripts/hs200.sh 192.168.10.41 9999 check”, interval=1, timeout=5]

in .items:

String Kitchen “Kitchen Light” [ “Switchable” ] {channel=“exec:command:kitchenlight:input”}
String KitchenState “Kitchen Light Status” {channel=“exec:command:kitchencheck:output”}

Now build a Rule that sends a “on” or “off” string to the Item “Kitchen”. If you want to process the actual state of your Light, then work with the KitchenState Item in a similar way

15

thanks, i will try that.

is it expected from openhab2 to ‘initialize’ those ‘tings’ and run those scripts inside those things ? As that has happened to me - i created those 2 things pretty much exactly same as your ‘exec:command:kitchenlight’ and upon restart of openhab and then on some intervals my light was turned on, without any item pointing or referring to that thing. was that expected? if not, how can it be prevented? .

16

use interval=0 to disable automatic execution of the command

:wink: I think you are bit confused with respect to Things, Channels and Items here. Very short summary: Things are things that do stuff, and communicate with Items through Channels.

The Things in the Exec 2.0 binding only have one purpose: control,… the execution of a defined command. Nothing more, nothing less. inputs and outputs for/from these commands are ‘piped’ to your Items via the Channels

[I know, OH2 is confusing :wink: ]

17

OH2 is more than confusing, its messing things up big time. don´t know why there was such a big change needed, cause bindings like the old exec made OH so flexible. Got some similar problem as Paul here:
In OH1, this was my single line setup for a stupid wallplug. The plug doesn´t supply status, so its only ON or OFF, no matter what state the plug got from manual switch via remote control or by hand:
.items:
Switch Light_GF_Living_Couch “Steckdose Sofa” (GF_Living) { exec=“OFF:/opt/brematic/licht_sofa_off.sh, ON:/opt/brematic/licht_sofa_on.sh” }

licht_sofa_on.sh:
cat licht_sofa_on.sh
!/bin/bash
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
}

licht_sofa_off.sh:
cat licht_sofa_off.sh
!/bin/bash
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
}

As you can see, there are two scripts needed to do the full task of switching on and off, just because i need to send two different strings with netcat to the controller (Brematic). How can i do this with OH2?

See, the concept with things is pretty straight forward. I wanted to torture myself and do the whole migration setup from OH1.8.3 to OH2.0 with paper UI and habmin, just to see how hard it would be. For Netatmo, Max!, Hue and Network, everything went very well and quite easy - in fact, better then i suspected it to be. But now i struggle with the exec binding and here you can “feel”, that OH2 is still not out of beta. I´m a long time user of OH, terminal is no struggle for me, but i really wanted to use the GUI for once. But as it seems, there is actual no way to solve this only from clicking.

18

ok, one step further, answering my own questions again. about the external ON or OFF: my fault, just use variables in bash script:
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

so now i can call this one script with external variable $1 ON or OFF. Works fine. But: How can i use this in things?

My thing and its logs look like this now:
2016-12-24 21:45:59.996 [ItemAddedEvent ] - Item ‘SteckdoseSofa_Input’ has been added.
2016-12-24 21:46:00.477 [ItemChannelLinkAddedEvent ] - Link ‘SteckdoseSofa_Input-exec:command:322f4bc9:input’ has been added.
2016-12-24 21:46:13.324 [ItemCommandEvent ] - Item ‘SteckdoseSofa_Input’ received command NULL
2016-12-24 21:46:13.325 [ItemStateChangedEvent ] - SteckdoseSofa_Input changed from NULL to NULL

So i´m guessing, that the command

/Users/alexanderkarls/Downloads/brematic/licht_sofa.sh %2$s

in the thing is wrong. BUT HOW THE HELL can in pass ON or OFF and vice versa?

22

Would you be able to walk through the thing settings?

I.e. what are the interval and timeout, and in which measurement? why do you have the %2$s in the kitchenlight, and what does it do? Its obvious one is for input and one for output, but further examples would be useful.

And to be blunt, don’t mind helping to work on documenting this as we go…

23

I have exactly the same problem migrating my execs from OH to OH2.

Have you solved it? If yes, could you post your solution?

Thanks in advance!

24

I don’t know if it helps, but after trying to figure out how to get:

exec:command:office_desk_backlight_switch “TP-PlugSwitch” [command=“/bin/tplink.exe --ip 192.168.yy.xx --action %2$s”, interval=0, timeout=5, autorun=false]

to be invoked when an item bound to it switches, I went to a model where I use a rule, and fire on the value changing in the rule.

However, from looking at the OH2 exec specs, it looks like the above thing should allow me to invoke the program with the appropriate command line, but nope.

Ideas?

25

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

1 Like
26

Confused, isn’t this using the rules to switch on and off?

27

@Paul_Atkin … Hi, I am coming across a weird issue. When I try to create the 2nd Exec:Command line (pluglightcheck) in PaperUI, am getting the following error: Cannot run program “Thing”: error=2, No such file or directory. Any idea what could be the issue here?
Thanks