How to solve Exec binding problems

Tags: #<Tag:0x00007f5c8286a4a8> #<Tag:0x00007f5c8286a368>

(Rich Koshak) #21

Wait. You cannot use Exec 1.x style config with the 2.x version binding. They are completely different and incompatible.

You either can create Things and link Items to the channels, or uninstall the Exec 2.1 binding and install the 1.x binding.

(Frank Rein) #22

Most of the problems are sitting in front of the screen :rolling_eyes: In this case in front of my screen.
I thought that my inv1 to inv4 items were 2.x style. But you tell me they are 1.x style, right?
No wonder that these items do not work while the inv5 item does a good job.
Thanks again @rlkoshak

(Rich Koshak) #23


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

(Nakh Home) #24


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/ ON_6.txt
python /etc/openhab2/scripts/ OFF_5.txt

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

(Rich Koshak) #25

Please read the readme docs here as a starting point.

(Nakh Home) #26

thanks @rlkoshak

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

My things

Thing exec:command:AC1_ON “TV” [ command=“python /etc/openhab2/scripts/ON_6.txt”, timeout=15, interval=0, autorun=false ]
Thing exec:command:AC1_OFF “TV” [ command=“python 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

(Rich Koshak) #27

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:

(Ray) #28

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.

(Jerome) #29

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?

(Rich Koshak) #30

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

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

(Mike Miller) #31

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.


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 dropbear[19686]: Child connection from
Mar 13 04:33:14 flex-dvt 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 script:

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/ -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.

(Ray) #32

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:

(Udo Hartmann) #33

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.

(Rich Koshak) #34

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.