How to solve Exec binding problems

Tags: #<Tag:0x00007f433da55370> #<Tag:0x00007f433da55280>

When you execute a command from the command line, you are running in a shell and get to take advantage of all the features and capabilities built into that shell. You don’t have a full shell when you run from openHAB.

Often putting the command inside a shell script can address this.

Also make sure the Exec binding is configured correctly. You don’t present the full log line so I can’t tell what the error is coming from. It appears like it can’t find the xvfb-run command.

Thanks. So should I create a shell script which runs this command? I can’t really send you more logs, because there are no errors. This is what I just posted is the Output channel…

Well that is a pretty key piece of information. Then the error is coming from the command, not from the Exec binding.

I would try putting it in a shell script. If that doesn’t work all I can offer is to keep trying stuff. The Exec binding is one of the more challenging ones to get working correctly. You can replace the spaces with @@ for example. The double quotes might need to be escaped. There might be something else going on which is making it so that the openhab user cannot see the path to the command (e.g. running OH in Docker).

Hello

i am not that good at programming and i am trying to achieve a button/switch that restarts my mac. Did someone already do this?

Thank you!

Start here Jonas

thanks a lot! i will have a deeper look into this tomorrow! i tried several times before until i gave up. maybe it can be done this time :wink:

Hi! hm. unfortunately that does not work on a mac. the first command (adduser) is not supported by the mac bash-terminal. i’ll try to goolge my way to success once more :wink:

@rlkoshak So I have just revisited this as I wanted to migrate my exec v1 to exec v2 and I’ve found what the initial problem was:

When using the exec v2 thing if you have a header which has a space in then it doesn’t work.
For example:
-H Authorisation:Bearer Token

Now if I execute the same command in ssh and wrap it in apostrophes as so:
-H ‘Authorisation:Bearer Token’
Then it works

However this doesn’t work in the binding.
I’ve tried so many variations of wraps in quotes/apostrophes/escaped quotes/escaped apostrophes and also replacing the space with @@ but nothing works.

I don’t know how to file the issue or even find out why but with so many apis requiring authorisation like this now it’s stopping the exec binding from being utilised.

If anyone has come across this before and has a way of getting round it then it would be most appreciated.

There usual way to get around that is to write a shell script and call the shell script from the Exec binding.

I need to process variables from openhab in this, is that possible?

Also that’s all good, however shouldn’t we be aiming for things to ‘just work’… surely for new users that don’t have bindings for certain items this, the http binding and the tcp binding are major players??

I wouldn’t even know where to start with ‘writing a scipt’

The Exec 2 binding had an Input channel where you can pass a String to your command. You can build up the command using the executeCommandLine Action from a rule.

To be successful with any OH binding, you must have at least a basic understanding of the technology it integrated with. This is even more true for me level bindings like the ones you list.

If you don’t know the frost thing about how to work a shell script, than you really need to go learn about shell scripts to every hope to be successful with the Exec binding.

I don’t recommend inexperienced users to use any of those bindings at all. Those tires of bindings are for more advanced users who understand OH somewhat as well as the technology they interact with. If you want something that just works, you need to stick to bindings that work at higher levels like Zwave. If you need to go to the letter level bindings because there isn’t a higher level binding, then you will never have a case where “it just works”. You will have to do a good deal if the work yourself.

It should be able to pass single quotes to the shell though, which it doesn’t so interprets the space as a new argument and fails with a cannot resolve host.

curl -X POST url -H Authorisation:bearer refreshtoken -d {jsonstring}

It’s the space between bearer and the refreshtoken that is the issue.

The binding is not that difficult to use, and the v1 binding passes the command fine (albeit with @@ for the spaces, which doesn’t work for the v2).

Whilst I understand what your saying from a ‘normal user’ perspective bindings such as exec/http/tcp/mqqt should be the fundamentals of openhab. If a binding isn’t available, which seeing how many devices there are now on the market is most likely, these can be used to integrate pretty much anything that has some form of access. If these work then people can utilise them until such a time a binding is developed by someone with the knowledge.

For instance myself,
I have lightwave gen2, intesisbox for my air conditioning and Shelly, there are no working bindings (Shelly now has but haven’t migrated yet), and I have successfully integrated them with exec, tcp and http respectively, however I want to move away from the execv1 binding which I’ve seen are at some point listed for depreciation, but the v2 doesn’t work correctly.

I’m merely stating a bug and at some point(I know you are all volunteers) if someone could take a look it would be grand. I have myself put hours into successfully making a workaround for lightwave gen2 (see the thread) and 2 others now have a functioning, albeit clunky, way to integrate their devices, the execv2 is to make it cleaner and faster.
No one is developing a binding (as far as I’m aware) and I don’t have the knowledge, I have tried, to produce a binding.

And to say to stick to higher level bindings such as Zwave… please find me a uk double socket on Zwave, they don’t exist

You need to escape the quotes.

"this is my command with \'escaped\' quotes"

No, those bindings are plan b. The fundamentals of openHAB are the bindings that work with specific technologies and provide automatic discovery and a vastly simplified interaction and interface. These bindings (plus the serial binding) are what you need to resort to in cases where you want to interface with something that isn’t already supported by openHAB. In that case, you as the user have a much greater burden for understanding both the technology you are using (e.g. scripts in the case of the exec binding) and the technology you are interacting with. They cannot be made simpler because we cannot know ahead of time how they need to be used.

Shelly supports MQTT natively.

Then you should file an issue on github. See How to file an Issue.

What I said was, if you don’t want to have to learn more about the technology you are interacting with then you should stick with a higher level binding. Put another way, you must learn the basics of the technology you are using and interacting with (in this case how to write a simple shell script) to be successful in using any of these lower level bindings. They are low level. The complexities and details cannot be hidden from you. You have to know them and known how to use them. If you are not willing to learn this then you won’t be successful.

Just because “I want what I want” doesn’t change the fact that if you don’t know enough to know how to write a simple shell script, you don’t know enough to be successful using the Exec binding.

I am escaping them and from the log entry they seem to pass, however they don’t as the error is as if I’d put it in a terminal without them, yet testing the exact same command in a terminal or using the v1 binding it works

My command:

var String GetFeatures = "curl -X POST https://publicapi.lightwaverf.com/v1/features/read -H \'Authorization:bearer " + Access_Token.state.toString + "\' -H Content-Type:application/json -d {\"features\":[{\"featureId\":\"5c7d64783c570522afb151b5-24-3157331848+1\"}]}"

And the log:

curl: (6) Couldn't resolve host 'eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI4Y2YyZGUwOTAwMTQwOTczODRiZCIsImlzcyI6Imh0'

Like I said, if you think there is a bug here, please file an issue.

Most of us, when faced with a similar type of problem, put the command into a shell script and call the script from the exec binding.

I have filed the bug :+1:

1 Like

I guess that is the content of your token Item.
So, the curl parameter parsing has broken at the preceding space character, thinks that’s the end of the -H parameter and treats your token as a url.
The escaped ‘single quotes’ should be hiding that space, of course. So it’s the single quotes that are the problem.
This sort of weirdness pops up on Windows hosts.
I’d give it a whirl with (escaped!) double quotes.

@rossko57 Exactly that :+1:
I’ve tried literally everything,
Single quotes
Escaped single quotes
Escaped double quotes
@@
And all combinations of the above.
Nothing solves it

From ‘alot’ of reading trying to find something to give me a shot at solving it I believe it may be due to how the binding is submitting it to the shell along these lines: https://stackoverflow.com/a/51037900
Although that’s only a guess as I’m no programmer.

And I’m not using windows, it persists on a qnap NAS, openhabian and docker

@rlkoshak could you please give me an example thing / and script variable if possible.

I can fathom out the actual Bash script part as there is plenty of info about, but I’m struggling to find anything relating to openhab passing a variable to the script. I can see from the docs how to put the variable in the thing at the end of the ‘echo scriptpath variable1 variable2 etc’, however nothing on what representation is used within the script itself to use them variables.

1 Like

According to the docs:

the current (or last) command to the input channel (see below, example: %2$s )

So if your script is called foo.sh, the command field where you define what the exec binding calls would be /path/to/foo.sh %2$s.

Then you would send the arguments to the script as a command to a String Item linked to the input Channel of the Thing.

From the script side see https://tecadmin.net/tutorial/bash-scripting/bash-command-arguments/ or if you want to get fancy https://medium.com/@Drew_Stokes/bash-argument-parsing-54f3b81a6a8f.