I want to use this simple rule to check whether the openHab has a new release or not.
However I’m running openHAB in Docker, so when it wants to run the scripts it fails, because there is no basic linux commands in Docker - as far as I know. Did someone manage to get this rule work? Or has anyone a solution to copy/migrate these commands inside Docker (I’m not very familiar with this thing).
Also how updates work on openHAB? It can be updated with a package manager (apt, etc…), what is updated when you update like this? Binding updates released with alongside the distro update? Or does it have any other method which can be used to only update the bindings?
Your choices are:
- build your own Docker image with the commands you need built into the image
- set up something outside the Docker container that you send a message to which executes the command and returns the result
- not run OH in a Docker container.
The first option is frowned upon. Docker images should be as light weight as possible. Personally, the amount of effort required to make this work for Docker is far from justified to get a little line in the sitemap to tell when they’re is a new OH version.
Given that OH releases are at least six months apart and there are almost always breaking changes so blindly upgrading without reading the announcement and list of changes is dangerous at best. Better to subscribe to the Announcements Topic on the forum and get an email with as list of all the changes, particularly breaking changes, when there is an update.
If you want to do this for the snapshot then I’d argue you probably should be knowledgeable enough to answer these questions yourself to be running barely tested software. And given there is a new version of the snapshot every day you can just assume that there was a new version every day. There is no need for a notification.
Regardless, if you need to rely on the exec binding then the Docker image may not be a good choice. Or if the benefits of running in Docker are enough to use it anyway, then it is probably worth writing a python script or the like that you can send commands to over mqtt it something to execute the command line scripts.
As for upgrading, if you are running in Docker you download a new image and create a new container with the docket run command.
If you are running an installed version then apt-get upgrade will update oh and all of the bindings. You want to keep them all at the same version unless you really know what you are are doing. In which case you can download a binding individually and drop it in the add-ons folder.
I did exactly this because I also needed some small tools and wanted to integrate jython. As you can take the openhab image as base for your own image the effort was not very big.
I agree, that docker images should be lightweigt but personally I prefer to have everything that is needed by openHAB directly in the openhab image, as managing several images and there interaction is not without effort too.
That said, I certainly would not go as far as recommending to integrate a datebase or other permanently running services in the same image as openhab.
You don’t need to add anything to the image to integrate Jython (assuming you are talking about JSR223 Rules Development). JSR223 Jython with Docker openHAB
I forgot to answer your post, sorry!
Thanks for the hint, this works well! Right now a am undecided which way to go. Keeping the docker image small is more to the docker philosophy, on the other hand having the binaries needed to execute openhab all in the docker file makes it easier to start a new openhab container on an other machine, e.g.for testing…
I outsource anything that requires more than what comes with the official image to a portion script I took on another host that communicates with OH through MQTT. It was a natural work around as I already have a bunch of RPis running this script anyway to report sensor readings and trigger the garage door openers so it was a simple matter of adding a plug-in to execute a command line command in response to an MQTT message.
I do believe that binaries that are required by one of the official bindings should be included in the official image though, which is why I opened an issue to get around and ping added. Some day I’ll have a couple hours to sit and work on it.
Personally, I recommend against modifying the official container for all the official reasons and one big personal reason. When people ask for help I can assume certain things were not broken by a change to the container which saves a ton of time and effort.
I can understand the logic behind that approach. But having had a bunch of “external” machines reporting data to openhab myself, I am now trying to integrate as much as possible into openHAB itself, as I had quite some effort to maintain all machines.
The exception to the rule for myself are machines that can talk to KNX themself, which send their data to the bus. What I could think of would be a separate docker container, that acquires data and sends it to the KNX bus as well.
Regarding openHAB as docker container I am currently still in the testing and experimenting phase, but I am planning an switching to docker completely.
I do believe that binaries that are required by one of the official bindings should be included in the official image
Which would justify adding jython to the docker image for using it in JSR223 rules.
I have solved this problem with this rule. Now it has 0 errors, so it must have work.
However I’m curious that this only works with the daily snapshots, am I right?
Because in the version.properties file I have no version number, only “Release Build”
openHAB Distribution Version Information
build-no : Release Build
online-repo : https://dl.bintray.com/openhab/mvn/online-repo/2.2
openhab-distro : 2.2.0
smarthome : 0.10.0.b1
openhab-core : 2.2.0
openhab1-addons : 1.11.0
openhab2-addons : 2.2.0
karaf : 4.1.3
Can I make it to work with the Stable version as well? And only show new version, if a new Stable version is out?
You are running 2.2 release so if it is working for you then it is working with the release. However, working and useful may not be the same thing. You are running OH version 2.2 release and Kuba’s script checks for new 2.3 SNAPSHOTs. So yes, the scrip only checks for the daily snapshots.
There is no build number for release builds. The version number is openhab-distro and that is what you will need to check for changes.
You will have to significantly modify the original script as the stable releases are managed on bintray and not cloudbees so the URLs and data parsing and such needs to be different. I wouldn’t be surprised if it required a complete rewrite.
I’ll reiterate my comment from above though. This is a lot of work for not much benefit. There is a new release every six months or so. You will get an email if you subscribe to the Announcements topic when there is a new release. And since the original script only addresses the SNAPSHOT you will have to all but rewrite that script. Seems like a whole lot of work for not much benefit.
Thanks for your help!
Than I’ll skip this one, thought that versions change more frequently on the stable channel as well…