Is there a way that my binding can detect the exact of version of the installation like karaf is displaying when I do a bundle:list ?
The reason I am asking that I would like to expose this information easily for support reasons to be able to ask users which bundle version exactly they are using. As the “standard” OH user doesn’t necessarily know how to use “openhab-cli console” and asking for the OH version in general isn’t necessarily exact enough it would be nice, if I can either expose that in the binding page or as a information in the thing or at least as an info in the log.
Any ideas or is there actually an easier way for a normal user to find out the exact bundle version he/she is using?
Take a look at org.osgi.framework.Bundle.getVersion(). The lastModified() method may work for you too. I haven’t tried it, but something like this should work…
Version bundleVersion = FrameworkUtil.getBundle(getClass()).getVersion();
IIRC, I’ve seen bundle versions flash past in either the zwave or zibee binding logs, so @chris may be using something like this.
Yes, I was logging this in the ZWave binding during binding startup. From memory this was (still is I think) in the bundle activator class, and it probably uses the calls you’ve posted.
It ends up not being so useful since invariably most of the logs don’t have the binding startup, so there probably should be a slightly better place to put it…
At least this is perfect starting point and I am already adding that to the nanolead binding (thanks @chris for discovering this in the first place). The static method then also allows us to access it from anywhere else in the in the binding.
@5iver / @chris
Do you know if there is any way to add dynamic content (like the version) the Configuration->Binding->Z-Wave-Binding - Page or is this by default all static content?
I just came up with another second best solution. Even though there seems no place where I can place dynamic content for the binding itself I already expose some information for the controller thing I discover. So I will try to add that as read-only property to the config of my thing. At least if the controller is found I can ask the user to look into those properties directly.
Do you recall if you have even seen this to popup in the logs? I implemented it and it doesn’t come up. Neither with my bundle nor with the zwave binding the message comes up (like “Z-Wave binding started.”. (log is set to debug).
Yes, I used to see it in the logs. I don’t normally look for it these days as logs don’t often start from a binding start.
Note that this is the bundle activator, so you also need to modify the manifest (see below). Given that bnd now writes the manifest, it won’t work unless you add this to the pom so that it’s added to the manifest.
Funny, in the meantime I searched through other people’s implementations in openhab and I found this in several occasions as well. I will give that a try as well and let you if that works.
Can you tell me a bit about the manifest file? I checked if any of the openhab-addons has a manifest and at least from what I can see, none of them has a manifest file. Even in your repo (https://github.com/openhab/org.openhab.binding.zwave) I cannot find it…
Is this somewhere documented how the manifest has to be created and where it has to be put?
The manifest file is a standard file in a JAR. It used to be explicitly set, but when things moved to using bnd in the last 8 months or so, it was removed, and is generated by bnd during the build (if you look in the JAR file, you will still find it).
I think all you might need to do is to add a file named bnd.bnd into the project root folder (ie along with your pom.xml file) and in it place the one line I posted earlier -:
Obviously you need to change this to point at the right class
If you then look at the JAR file once created, you should find the MANIFEST file and it should hopefully contain this line. If not, let me know and I’ll have another think to see if I’ve missed something as it’s possible there might need to be an addition to the pom as well if it doesn’t get picked up through the parent.
No - probably it no longer works in the ZWave binding. As mentioned I found this not so useful as it was only logging during binding start and I therefore didn’t notice that it stopped working when bnd took over the world.
The above ought to work though, but let me know if it’s not working and I will have a look here.
Thanks for the comprehensive answer, Chris! I’ll check this out eventually!
@5iver The above idea to address the Factory works like a charm and is also pretty easy. From now on, the bundle version is shown in the properties of the main (controller) THING of nanoleaf. That is a big step forward towards easier support different people.
Hmmm - this is not the thing properties - this is the thing configuration. Wouldn’t it make more sense to use properties instead? I think it makes a lot more sense since presumably a user cannot configure it?
You don’t need to use just these property names - you can use whatever you like in the properties. It’s a simple key/value pair that can be set, and you can give a property any name, and any (string) value.
thing properties (read-only, can be set dynamically)
binding configuration parameters (like for the things but for the whole binding, read-write)
binding description (read-only, cannot be set dynamically, only available for installed bindings).
We discussed at fosdem whether it would be valuable to retrieve some additional information about officially supported add-ons, even before installation: short description, logo, version(s), and perhaps even remotely - a json on the website at a well-known URL. If the user has authorized access to the remote repository, we can then (and only then) assume it’s ok to fetch things online.
binding configuration parameters (like for the things but for the whole binding, read-write)"
The idea wass in this case is that we have properties that are related directly to the binding and not the thing in particular. In my example I wanted to expose the binding version number towards the binding content but as it is not dynamically writable I did this as a workaround to the things. In case you have not yet setup or discovered any thing you would still not be able to detect the binding version.
If the above quote covers this that would be awesome (and I’d be the first jump on it ). Is it?
). Is it?