How to solve Exec binding problems

Yes.

2.x version bindings always use { channel=“channel id” } and 1.x version bindings always use a unique string.

1 Like

Hi

please help me

i want just to have a switch which will run the python scripts according to the wished state.

python /etc/openhab2/scripts/play.py ON_6.txt
python /etc/openhab2/scripts/play.py OFF_5.txt

Could you please explain how to create the item with the exec binding?

Please read the readme docs here as a starting point.

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

thanks @rlkoshak

i am getting my button in the UI but nothing is triggered.

My things

Thing exec:command:AC1_ON “TV” [ command=“python play.py /etc/openhab2/scripts/ON_6.txt”, timeout=15, interval=0, autorun=false ]
Thing exec:command:AC1_OFF “TV” [ command=“python play.py OFF_5.txt”, timeout=15, interval=0, autorun=false ]

My items

Switch LivingRoom_AC_command "Turn On" <switch> (Lights) [ "Switchable" ]{ channel="exec:command:AC1_ON:input", channel="exec:command:AC1_OFF", autoupdate="false" }

My sitemap

sitemap home label="SMH"
{
    Switch item=LivingRoom_AC_command label="Interrupteur" mappings=[ "ON"="ON", "OFF"="OFF" ]
    
}

should i use REGEX((.*))???

please could you advise. i am totally stucked

How should I know? You haven’t provided a number of key pieces of information, the most important of which is what does the script output?

As I say above in the original posting, the main point of this entire thread is you must know what the script is outputting to know what the error is:

Wish I’d found this thread a week or two ago. The tip about @@ and spaces might have solved why I couldn’t get the exec binding working the way I first wanted.

In the end I simplified my problem to help track down the issue and get it working. All I was trying to do was extract the OH versIon number from the system so I could put the text on my sitemap (borrowed the idea from someone elses post). It’s a simple grep piped to awk with a print $2 nothing fancy or complicated.

But I couldn’t get exec to work. So I switched to the command line did more testing there and then stuck it in .sh script. Really wasn’t what I wanted for a one liner exec but going back in to OH I could then call the script and it worked. :smiley:

@nakh_Home I would recommend that if you can you use something like MQTT rather than the exec binding and rules.

I was initially reluctant to go that route myself but once I got fed up of the coupling and rules I was having to write I bit the bullet and deployed Mosquito on my server. In reality it was very easy, not much more required than apt-get install mosquito couple of config changes in Mosquito and OH and it was a beacon of information for events happening inside OH.

I think IanJ above also reached the point of pain trying to use exec binding to post state changes:

do you know of anything that can manage the proliferation of things/items/scripts/rules/sitemaps?

Now if I want to add a new switch I do the basics in OH to create the item and I don’t need any rule changes to publish its event changes. Just go to the client implementation I have that is interested in the new switch and add a new subscription to it’s list.

I haven’t used MQTT to update OH although I think you might be able to…? I found this Python module does what I need to send data back to OH.

It’s also a better pattern to reduce your coupling from server to clients. Over time I’ve found more and more reasons why I want another client doing ‘something’ and with this method and a simple Python script it’s easy. Plus MQTT and the Python module take care of the comms over TCP meaning if my client is on the same server or different my OH doesn’t care, no ssh key sharing.

@FrankR I would also consider changing your approach. Drop the use of exec binding and link up with MQTT and the OH Python module to push data back, I see you are already using py scripts. I do try and keep my clients as dumb as possible and put business logic in OH so if you want the data collection triggered by OH just create a switch item that your rpi client monitors via MQTT subscription, send back the data when requested and clear the switch.

Sorry this seems to have changed in to “don’t use exec binding” but that was not my purpose, indeed I think it’s exactly what I need for my OH version string. Just wanted share that simplifying your exec binding to external scripts is often a quicker way to get it working as @rlkoshak has suggested. But where possible also consider why you’re using it whether there is a different tool in the box that might be more appropriate.

2 Likes

Hey Rich,

I was a bit confused the last minutes, while debugging with the help of this topic.
Shouldn’t it be ~openhab/.ssh?

At least this woked for me without the / and it seems (from my search through stackoverflow) that it is correct without it.
Or is openhabian (which i am using) special in this context?

Yes, that is a typo. It should be ~openhab/.ssh

There is nothing special about openHABian. It is just raspbian with some helper scripts.

I am stumped on ssh connections and may be overthinking this here.

I have a script that send commands via an ssh connection to a rooted wink hub. It is very simple and works very well on my old setup.

wink.sh

#!/bin/bash

ssh root@winkhub "/usr/sbin/aprontest $@"

Simple. I have it setup with key pairs and it normally runs as my pi user.

However, I am having a heck of a time even getting

sudo -u openhab ssh root@winkhub

To work. Running straight from terminal, I get the following:

Permission denied (publickey).

I have copied my entire ~/.ssh directory to /var/lib/openhab/.ssh

But still getting the error. I changed ownership but didn’t mess with permissions since I wouldn’t think they are needing to be changed.

Stranger still, when I try to run the command from the OpenHab switch, I get the following output:

23:25:14.206 [INFO ] [smarthome.event.ItemStateChangedEvent] - Outlet_Power_Out changed from Could not create directory '/var/lib/openhab/.ssh'.
Host key verification failed.
Could not create directory '/var/lib/openhab/.ssh'.
Host key verification failed. to Permission denied (publickey).
Permission denied (publickey).

That directory already exists?

The biggest problem is that the winkhub doesn’t have an auth.log file for some reason and I am unable to find any information related to where any auth messages are kept in there. (It is a bit of a niche and not much info exists for rooted wink hub 1’s) The only thing I can see is an a log called all.log and even then I don’t see the auth failure, only that it failed before auth completed:

Mar 13 04:33:13 flex-dvt authpriv.info dropbear[19686]: Child connection from 192.168.10.98:52878
Mar 13 04:33:14 flex-dvt authpriv.info dropbear[19686]: Exit before auth (user 'root', 0 fails): Exited normally

Anyone have any thoughts here?

EDIT: Just thought of something as I was shutting down for the night and tested it. If I add the following to the beginning of the wink.sh script:

#!/bin/bash
sudo -u pi ssh root@winkhub "/usr/sbin/aprontest $@"

(i.e. adding sudo -u pi)

I am now able to run the command by way of:

sudo -u openhab /home/pi/oh_custom_scripts/wink.sh -m 9 -u -t 1 -v ON

Haven’t tested how this works from OpenHab directly, but will tomorrow. It is a bit convoluted, but hey, if it works, I won’t complain. Still interested in why I am having problems in general with the ssh connection using openhab if anyone has any advice.

This is an ssh key issue and not specifically a problem in openhab, you’re just seeing it manifest there. Until

sudo -u openhab ssh root@winkhub

works at the command line then it’ll never work in openhab runtime.

If you want logins without passwords to work you need to share public keys between the specific users on each device. Your last test suggests that the user ‘pi@openhabPC’ and the user ‘root@winkhub’ have shared public keys. So it should work from within openhab now because you’re effectively changing user within the script to run the command as ‘pi’.

You mentioned copying .ssh folders around but that sounds a little dangerous to me. I don’t know if the keygen ties itself to the user and name somehow but I wouldn’t be surprised. If you want to fix it cleanly then I would suggest take the ‘/var/lib/openhab/.ssh’ out and then you should keygen as the ‘openhab’ user, transfer openhabs public key to root@winkhub and install under knownhosts, transfer root@winkhubs public key and install it in openhabs knownhosts.

I think you will also need to change the openhab user though as its shell is /bin/false, don’t know if it will work as a temporary change or would need to be permanent…? If permanent then it’s another discussion about security and ‘openhab’ user suddenly having shell access and therefore better to leave it as a shell script switching to ‘pi’ user :slight_smile:

User openhab has it’s own home directory, this is per default /var/lib/openhab/
To use private keys, you have to create /var/lib/openhab/.ssh/, change permissions to 700, ownership is openhab:openhab. Then at least copy the private key (!) file to this folder (id_rsa), and change ownership to openhab:openhab, permissions to 600.
For security reasons it’s not allowed to simply share private keys between users.

Not always a safe assumption when dealing with ssh keys. Typically you want to make sure that only the user has any permissions and everyone else has no permissions (i.e. -rw-------). This is vital for id_rsa (or whatever your private key file is named). If it has read permissions for group or other then ssh will reject the key with an error.

If you installed OH using apt-get/yum then yes, there should be a /var/lib/openhab and /var/lib/openhab/.ssh is where you should have copied your ssh certs to.

I’m not sure that would help if it got that far. I don’t think the ssh is getting far enough in the process to even reach out to the wink hub yet.

I’m pretty sure it does not. There is nothing in the private key that ties it to a specific user (unless it is encrypted) and the part in the public key is basically a comment as far as I can tell. I routinely copy around my .ssh folder when first setting up my RPis until I can get to where I have my own account and remove the pi account.

I don’t think it is necessary, but if one wanted to generate new keys, sudo -u openhab would be sufficient. You don’t need the openhab user to have a shell either to ssh on the openhab server and since it is sshing as a different user on the wink, the only user that needs a shell is root on the wink.

Question below solved by adding interval=0 to the related thing

@rlkoshak
thank you very much for all of your effort.
I’m migrating since some years of stable run from openhab 1 to 2 and have completely rewritten my config.

I struggle only with exec :slight_smile:

My configuration brings a reboot loop. If I comment this thing out, it’s stops. Otherwise the raspberrypi reboots all the time.

Maybe some of you guys have an idea. So here we go with my configuration:

Thing

Thing exec:command:test [command="sudo reboot", autorun=false]

Item

String test { channel="exec:command:test:input"}
String test_args { channel="exec:command:test:output"}

Sitemap

   Switch item=test label="Test"
   Text item=test_args

visudo

openhab ALL=(ALL:ALL) NOPASSWD: /etc/kodi, /sbin/reboot

I think you have a slight misunderstanding of the purposes of the various channels.

In this case you do not have any command line arguments to pass to the command so you don’t need the input channel linked to an Item. You don’t care about the results from the reboot so you don’t need the output channel linked to anything either. You just need one Switch Item linked to the run channel. Sending command ON to that Item will cause the script to run.

got it, is it somewhere documented? I could not find a OH2 exec documentation with an example based on item, without a thing.
Or do someone else have a working example?

There is a description of the Channels and an example in the binding readme.

With the Exec2 binding you cannot have an Item without a Thing. You create your Thing and then Link Items to the appropriate Channels on that Thing.

Hi All,

I’m having difficulty getting a command to run. I’ve:

  1. Changed the owner so openhab has permission
sudo chown openhab /sys/class/backlight/rpi_backlight/brightness
  1. Updated my /etc/sudoers.d/common_users
openhab ALL = NOPASSWD: /sbin/reboot, /sbin/shutdown, /bin/bash
  1. Tested in terminal as the documentation says:
sudo -u openhab bash -c "echo 50 > /sys/class/backlight/rpi_backlight/brightness"

The commnad works fine but when I add it to the running channel in the PaperUI which I then use in a switch item nothing happens. I’ve also replaced all spaces with @@ but I’m still stuck.

My item looks like this:

Switch Switch_Bright_50  "Brightness 50"  { channel="exec:command:brightness50:run" }

Anyone have any ideas as to where I’m going wrong?

Logs? What’s the content of the output channel?

Hi Rich,

Apologies, this is what my logs say:

15:34:03.438 [INFO ] [arthome.event.ItemStatePredictedEvent] - Switch_Bright_50 predicted to become ON
15:34:03.470 [INFO ] [smarthome.event.ItemStateChangedEvent] - Switch_Bright_50 changed from OFF to ON
15:34:03.478 [INFO ] [smarthome.event.ItemStateChangedEvent] - exec_command_brightness50_run changed from NULL to ON
15:34:03.528 [INFO ] [smarthome.event.ItemStateChangedEvent] - exec_command_brightness50_run changed from ON to OFF
15:34:03.533 [INFO ] [smarthome.event.ItemStateChangedEvent] - Switch_Bright_50 changed from ON to OFF
15:34:03.556 [INFO ] [smarthome.event.ItemStateChangedEvent] - exec_command_brightness50_exit changed from NULL to 1
15:34:03.576 [INFO ] [smarthome.event.ItemStateChangedEvent] - exec_command_brightness50_output changed from NULL to Sorry, user openhab is not allowed to execute '/bin/bash -c "echo 50 > /sys/class/backlight/rpi_backlight/brightness"' as openhab.
Sorry, user openhab is not allowed to execute '/bin/bash -c "echo 50 > /sys/class/backlight/rpi_backlight/brightness"' as openhab
15:34:03.587 [INFO ] [smarthome.event.ItemStateChangedEvent] - exec_command_brightness50_lastexecution changed from NULL to 2019-05-22T15:34:03.518+0100

.items

Switch Switch_Bright_50 "Brightness 50" { channel="exec:command:brightness50:run" }

PaperUI

OK, the output is clear.

“… user openhab is not allowed to execute '/bin/bash -c …”

So there is likely a problem with the sudoers config.

Wait, why would you sudo -u openhab? That runs the rest of the line as the user openhab. You are already running as openhab so at best the sudo is redundant. But in this case it seems you are trying to run this command as root. So remove the “-u openhab” from the command.