I’d like to share my little openHAB rule that periodically checks for the new openHAB unstable build.
The script visits openHAB Jenkins page on Cloudbees (this REST API endpoint to be specific) every midnight and then compares the build number with my local build.
A few remarks:
I’m running openHABian on Raspberry PI 3B.
The solution should work on any linux-based setup though.
I’m using Unstable (SNAPSHOT) openHAB build (here you’ll find more on that)
You can modify the rule so it sends a notification/email/whatever to you.
Or you can go one step further and programmatically update your openHAB… from openHAB!
Well, I didn’t think it’s a good idea at the time but YMMV
rule "Check for openHAB distro updates"
when
Time is midnight or
Item OH_CheckForUpdates received command ON
then
OH_Status.postUpdate("Checking...")
var String cloudbeesUrl =
"https://ci.openhab.org/job/openHAB-Distribution/api/json?tree=lastSuccessfulBuild[number]"
var String currentBuild =
executeCommandLine("/etc/openhab2/scripts/check-oh-build.sh", 2000)
// logInfo("update", "currentBuild: " + currentBuild)
var response = sendHttpGetRequest(cloudbeesUrl)
var lastBuildNumber = transform("JSONPATH", "$.lastSuccessfulBuild.number", response)
// logInfo("update", "lastBuild: " + lastBuildNumber)
if (Integer.parseInt(currentBuild) < Integer.parseInt(lastBuildNumber)) {
OH_Status.postUpdate("Update available: #" + lastBuildNumber)
// Do something with that information
} else {
OH_Status.postUpdate("No updates")
}
OH_CheckForUpdates.postUpdate(OFF)
end
Aaand that’s it!
Not sure if it’s very useful, but at least it’s a good excercise on:
One small comment:
I would use a mapping like mappings=[ON="Check now!"]in the sitemap for the switch, to make it look like a button instead of a switch.
I know it’s some silly optical thing, but it is a thing.
You could make the rule slightly simpler, at the cost of no longer checking exactly at midnight, by using the HTTP binding cached configuration. You could then just have a OH_Version Item with the transform on it and trigger your Rule when OH_Version changes. Something like:
http.cfg
openhabVersion.url="https://openhab.ci.cloudbees.com/job/openHAB-Distribution/api/json?tree=lastSuccessfulBuild[number]"
openhabVersion.updateIInterval=518400000 // every 24 hours, I'd use something smaller like every two or four hours
items
String OH_LastBuild "OH: Status [%s]" { http="<[openhabVersion:518400000:JSONPATH($.lastSuccessfulBuild.number)]" }
rules
// I've never called executCommandLine to populate a global val like this, if it doesn't work use a System started rule
// The version of OH will not change while OH is running so we only need to call this script once
val lastBuildNumber = new Integer(executeCommandLine("/etc/openhab2/scripts/check-oh-build.sh", 2000))
rule "OH's Build Status Changed"
when
Item OH_LastBuild changed
then
val currentBuild = new Integer(OH_LastBuild.state.toString)
if(currentBuild < lastBuildNumber) {
OH_Status.postUpdate("Update available: #" + OH_LastBuild.state.toString)
// alerts go here
}
else OH_Status.postUpdate("No updates")
end
You can remove the check Item from the sitemap since OH will automatically check.
It used to be a problem placing shell scripts in the OH scripts folder but am not certain it still is. The problem is that folder was intended to be for OH scripts, not generic shell scripts and the start script that runs OH used to go and change the permissions on all the files in the conf folder stripping off the execute permissions. Because of that I recommend putting all scripts like this into ~openhab/bin or the like. For an apt-get installation ~openhab is /var/lib/openhab2 unless you created the openhab user yourself prior to installing OH.
Also, the permissions on the script probably don’t need to be all that open. I would do:
chown openhab:openhab check-oh-build.sh
sudo chmod ug=rwx,o=rx check-oh-build.sh
```
This will set the ownership of the file to openhab and give everyone execute permission but only the openhab user or group has write permissions. I make sure my login user is a member of the openhab group and all works out well.
Theoretically, since the shell script is a one-liner it could be just written as the command send to executeCommandLine but we all know how finicky it can be to get a command like this to run right with the @@ and escaping the quotes and such.
Great posting!
I setup the http binding and cfg per above, but I keep getting this in my logs and can’t seem to figure out why.
2017-12-04 21:54:06.612 [INFO ] [b.core.service.AbstractActiveService] - HTTP Refresh Service has been started
2017-12-04 21:54:06.613 [ERROR] [b.core.service.AbstractActiveService] - Error while executing background thread HTTP Refresh Service
java.lang.NullPointerException: null
Was really into implementig this and could not get it working.
Checked the problem and the complete procedure is a mixing of @kubawolanin and @rlkoshak
// previously confused with lastBuildNumber
val currentBuild = new Integer(executeCommandLine("/etc/openhab2/scripts/check-on-build.sh", 2000))
rule "OH's Build Status Changed"
when
Item OH_LastBuild changed
then
val lastBuildNumber = new Integer(OH_LastBuild.state.toString)
if(currentBuild < lastBuildNumber) {
OH_Status.postUpdate("Update available: #" + OH_LastBuild.state.toString)
// alerts go here
}
else OH_Status.postUpdate("Updated version")
end
I’m not surprised if there are errors in the code I posted. It was intended as notional approach, not as a completely tested set of rules known to work.
I have not blaimed anyone, just find it not working and posted a solution. Sorry i am pretty new to post contributes because i have not too muck programming skills. I just wanted to help someone like me that would have liked to use this rule ;(
First i run into some problems with the code suggestions from @rlkoshak but finally I got it fixed… and it helped me to understand things better… so here is my working example:
http.cfg file
# configuration of the first cache item
openhabVersion.url="https://openhab.ci.cloudbees.com/job/openHAB-Distribution/api/json?tree=lastSuccessfulBuild%5Bnumber%5D"
openhabVersion.updateInterval=518400000
Frame label="openHAB Update" {
Text item=OH_Status
}
.rules file
val currentBuild = new Integer(executeCommandLine("/etc/openhab2/scripts/check-oh-build.sh", 2000))
rule "openhab build status changed"
when
Time is midnight or
System started
then
val lastBuildNumber = new Integer(OH_LastBuild.state.toString)
if(currentBuild < lastBuildNumber) {
OH_Status.postUpdate("Update available: #" + OH_LastBuild.state.toString)
Thread::sleep(3000)
sendTelegram("bot1", "openHAB has been started. There is a new update available!\n\nCurrent Build Number: " + currentBuild + "\nNew Build Number: " + lastBuildNumber)
}
else {
OH_Status.postUpdate("Updated version")
Thread::sleep(3000)
sendTelegram("bot1", "openHAB has been started and is performing on the lastest build.")
}
end
Is there a way to read out the date of the file /var/lib/openhab2/etc/version.properties to get the date/time of the latest update which was made on the openhab server?
I can read out three times with “stat”. access-time / modification time / ctime (or something like this)
access-time is unusable for me.
What is the difference between the two others? I have read a description about it, but i don´t know which time is the right one, when i want to check for latest openhab-update?
In my case modification time and the last time (ctime?) is not the same.
modification time is 2nd january, ctime is 3rd january. I made an update on 3rd january.
But what i have read in the description, modification time should have been the right one???
In your exec-command there is also this command --> %z
8 don’t think anyone is suggesting this approach be used by typical users of OH. For the most part it is users on the Snapshots who will be doing this and they will discover and report the problems you mention as their upgraded system generates errors. Those running the snapshot are, by definition, alpha testers. It is unreasonable for an alpha testers to expect always a fully documented and automated upgrade process. But the approach above does help make their lives a little easier all the same.
