You need to uninstall the binding using PaperUI, and to add the new binding, AND the serial JAR (assuming it’s not used boy other bindings you have) into the addons folder.
Or, you can uninstall the running binding with Karaf - this leaves the dependencies installed and you only then need to add the zwave bundle into the addons. This is actually what I’m doing at the moment, but it does have a drawback in that when you restart OH2, the system will reinstall the zwave binding and you’ll end up with two copies running which you need to sort out through Karaf again.
No - if you uninstall the binding completely, then clearly it’s uninstalled. I said that this would happen if you just uninstalled the binding through Karaf.
If you uninstall the binding completely, then it’s as I said above -:
You need to uninstall the binding using PaperUI, and to add the new binding, AND the serial JAR (assuming it’s not used boy other bindings you have) into the addons folder.
Thanks for the adjustments done chris! Will give it a go now.
But correct me if I’m wrong, I think that in order to re-install with the latest binding version it’s simply a matter of entering Paper UI going to the Addons then Bindings and choose Uninstall on the z-wave binding. Wait a little bit and then press install again.
As it seems that you are also on the stable 2.0 release, you will face the same problem that I have. So: No, simple uninstall/install will not get you the latest binding version.
That is a bit confusing then. If I understand correctly, depending on which installation you have. For example the official release or unstable or stable then there can be different versions of the bindings? And you kinda have to know where to get the right version you are looking for?
Maybe I’m overcomplicating it. hmm.
I’m using unstable version. I think.
This is what I put in my sources list when we did that update thing going back a week or two.
My karaf says this:
Does that mean I can simply update the binding via the easy way in paper ui? Otherwise I’ll need to research more about this other way that you mention in your posts above, that about kinda moving files putting stuff manually in the addons folder etc.
Yes, you are using the snapshot version (aka unstable) of the runtime. If you continue to use this (and don’t switch to the 2.0 stable), everything is ok. Then you also automatically use the snapshot version of the zwave binding and can use “the easy way” through PaperUI uninstall/install.
Ah okay that is so to hear. Thanks for confirming that Stefan.
I really have huge knowledge gap when it comes to linux. I am using quite advanced features through everything invloved with openhab etc. (by reading the guides here) But very simple operations that you do every day on any windows compueter, many of those I have no Idea have to perform in the linux command line yet.
Using openhab is my first linux experience.
Anyhow, I’ll get things updated and restart the solution here at home and report back how things went with this new update to the binding.
Keep in mind that even if you are using the snapshot releases, it could take some time (1-2 days) until the changes in the binding have found their way to a new snapshot version. I still haven’t figured out how this procedure works in detail and especially not how to check if a change was integrated or not. Some kind of changelog like we had on cloudbees.
I think if you’re using a standard install outside of a package manager, then you can update the zwave binding as soon as I build it (I’ve certainly been able to do that). ZWave builds are done manually so I normally do it after I merge something. If you’re using a secondary package, then these are built nightly, so it might take longer…
Sorry Chris, but can you point me in the right direction where I can download the latest jar files manually? I searched on github, searched on bintray and also on cloudbees.
You shouldn’t need to download manually - if you’re using a standard snapshot build, it should download automatically as I believe the builds are distributed immediately.
However should you want to download the JARs manually, they are here.
today I changed from stable 2.0 to snapshot (for the whole installation, not only the binding). This is the version I’m using atm:
2.1.0~20170129232652 (Jan 29, 2017)
I didn’t delete the thing/xml of the smoke sensor, just made an apt update/upgrade.
Just a few moments ago I got an alarm triggered from the smoke sensor. So either your changes didn’t have any effect or are not yet integrated in the above mentioned version.
Ok - I’m not too surprised. From the log I looked at last I’d hoped it might not have been triggered, but the issue still remains that I’m unclear how to interpret the GET requests since it doesn’t make sense in the spec. Currently ZWave have replied to me about my request, but it wasn’t a helpful answer so I’m waiting for them to get back to me…
So I finally got the answer from sigma - it is not possible to poll units for their current status using the notification (alarm) command class. We can only know the notification status when a device sends a notification event.
I will therefore remove all polling of notification channels and we should be able to solve this issue.
On the downside, this means that we still have the issue with the initial state of the sensor, don’t we? You remember that the states were on ALARM when the device is included? Is this something that comes from the device or that the binding defines?
You suggested that one has to trigger the alarm manually to get the “real” state. But I guess not everyone wants to play with smoke and fire in the house.
Thanks for confirming that Stefan.