Automatic restart of "resolved" bindings (Debian/Linux)

Tutorials & Examples
1

Hi there,

as I’ve got some issues after upgrading to openHAB 2.5.6 (some bindings are always “RESOLVED” after restarting the openHAB service and won’t come “ACTIVE” in order to run properly), I came up with a solution for this I want to share with you.

As the only way to restart a binding is via KARAF’s bundle management we need to tackle the fact that it needs a password. Of course we’re approaching an automated solution where there’s no user interaction whatsoever.

Therefore you need to install sshpass first;

apt-get update
apt-get install sshpass

If you like, you can already run a first test (the default <YOUR_SSH_PASS> can be found here) and check the installed bindings;

sshpass -p "<YOUR_SSH_PASS>" ssh -p 8101 openhab@localhost bundle:list

If that works, you’re halfway there!

Next, we’re going to set up a shell-script (… in order to run it regularly via crontab - but more on that later on). Choose a path <YOUR_PATH> on your machine that suits your needs, create a file and name it <YOUR_SCRIPT>.sh. Of course it may be improved, but for now it does the work!

#!/bin/bash

# get all openhab bindings that are "resolved"
resolved=$(sshpass -p "<YOUR_SSH_PASS>" ssh -p 8101 openhab@localhost bundle:list | grep 'Resolved')

# get the length of $resolved in order to determine if any resolved bindings have been found
resolved_size=${#resolved}

# do the magic if resolved bindings have been found
if [ $resolved_size -gt 0 ]
then 
    # loop through all the resolved bindings, line-by-line
    while IFS= read -r line; do
        # this is the whole line
        binding=$line
        # this will be the resolved binding's id
        binding_id="${binding:0:3}"
        # do some output, just in case...
        echo "Sending SSH command to restart Binding ${binding_id}"
        # send command
        sshpass -p "<YOUR_SSH_PASS>" ssh -p 8101 openhab@localhost bundle:restart "${binding_id}"
    done <<< "$resolved"
else
    echo "No resolved bindings found. Everything's fine!"
fi

Save the file and run the following command on it, so it becomes actually executable.

chmod +x <YOUR_SCRIPT>.sh

If you like, you can run the script and see if it works - browse to <YOUR_PATH> and set command;

<YOUR_SCRIPT>.sh

If everything works and all bindings are ACTIVE, the output will look like;

Password authentication
No resolved bindings found. Everything's fine!

Last, but not least, you want to add a cronjob for this via;

crontab -e

And putting a new line (e.g. that’ll run the script every minute, but feel free to set this however you need it - a “translator” can be found here);

* * * * *       <YOUR_PATH>.<YOUR_SCRIPT>.sh

That’s all!

2

I would call that a workaround. A solution would prevent the issue from occurring.

A workaround can be useful while a proper solution is developed.

2 Likes
3

I recommend an alternative approach and instead configure ssh certificates. Google for one of the many many tutorials that explain how to generate ssh certificates. Create a pub/private key pair. Then add the public key to /var/lib/openhab2/etc/keys.properties following the example for the karaf user already in that file.

This approach doesn’t require installing something new (sshpass) and it doesn’t require storing your password in bash scripts or Rules and such.

The only change to your script would be to remove the “sshpass -p YOUR_SSH_PASS” part. In general certificates are considered more secure and it’s easier to use. And if you add the keys to your login account (e.g. openhabian) you don’t have to enter the password for logging in from the command line either. The keys do need to be in the .ssh folder for what ever account is calling this script.

I really like the fact that you are using cron to run this instead of trying to run it from an OH rule. Far too many people try to do everything in openHAB. If you are OK with running this script as root and less often, you can just drop the script into the /etc/cron.hourly or /etc/cron.daily folders (make sure to remove the .sh extension).

But please do take Bruce’s comment to heart and file an issue. This is indeed a work around and the root problem needs to be fixed.

Thanks for posting!

1 Like
4

Hi,
i actually see this differently. I’m providing a (possible) solution for an automatic restart of resolved bindings. I never said it would tackle the fact that openHAB has issues after upgrading / restarting its service. Also, as its not bound to a specific binding, nor a specific subset of openHABs core functionalities, I won’t consider it as a workaround.

And last, but not least (if we’re yet again at the point where we trying to find the right terminology) I wouldn’t call it a “solution” if something prevents an issue from occuring, that would rather be a “fix” in my eyes.

5

Hi Rich, many thanks for adding something useful to this. As already mentioned, my initial post should be a working base for everyone that is facing issues with bundles that may halt at certain times. I’m using certificates, but I don’t know how deep the reader base here is into this stuff so I chose to share a more a less “general and easier” approach.

I always try to get as much as possible out of openHAB. For example I have my Sonos speakers in a different VLAN, but openHAB is still able to communicate /w them.

You’re welcome!

6

It IS useful if accompanied by a GitHub issue to get the problem resolved. The developers will likely never know to fix it otherwise.

7

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.