Merging this less than a week before 2.2 is released is really not a good idea. I will look at it once I get back from holiday and after 2.2 is released.
I will also close this thread after the merge as I agree, it’s really a bit unmanageable.
As a meta comment, that’s a problem with 100% of forums I’ve ever seen that use NodeBB… It takes the worst bits of vBulletin (no deep threading, so there’s no conversational context) and adds the worst of dynamic live-loading, leaving a mess that makes it impossible to find information or track stuff. The single most frustrating thing I’ve dealt with in trying to learn OH is the forum software and the staggering inefficiency of finding information in the busier threads. Number two is the memory leak that is killing my 2.2 install every 24 hours, give or take. Which makes it a little concerning to hear a 2.2 release is that close…
1 Like
The forum here is Discourse - I think that’s different than NodeBB?
The big problem with this thread is it’s 2200 messages long and contains all sorts of stuff now, so it’s a bit of a mess…
Anyway, speaking of “all sorts of stuff” - your comments are also off topic 
. I’d suggest that if you have a serious issue with the 2.2 snapshot then it’s probably best to report it if not already done so as reporting it in this thread will be very unlikely to get it resolved…
I’m having issues with the 12/10/17 binding. My BE469 deadbolt lock no longer reports manual or keypad locks and unlocks. Th only changes showing in the log are changes made remotely. Is this just me or are other people reporting the same issue?
I have 2 BE469s that lost security when the binding went to 2.2. After reincluding them, they receive commands but no longer report alarms. I expect this is related to one/both of these issues…
Running with build #1138 and your December 10th dev branch of the z-wave binding. I am no longer seeing any startup issues with polling. 
I guess I just updated at the wrong time.
I don’t think anything has changed here so either there was an issue in the core, or you should keep an eye out for this returning. The issue can only really be in the core I think.
Yeah, I will keep an eye out. It seems like there has been a flurry of activity in preparation of the next stable release. If I see it happen again I will try and debug it more. One commit that stuck out to me that could have fixed it is https://github.com/eclipse/smarthome/commit/76547cf81203b63be7a0c6f119adc3c0f8956ab0 but I could be way off.
First start of OH snapshot 1140 using zwave 2.2.0.201712100924…
Exception in thread "Thread-190" java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextNode(HashMap.java:1437)
at java.util.HashMap$ValueIterator.next(HashMap.java:1466)
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.doDynamicStages(ZWaveNodeInitStageAdvancer.java:1013)
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.access$10(ZWaveNodeInitStageAdvancer.java:1009)
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer$1.run(ZWaveNodeInitStageAdvancer.java:203)
and after a few hours…
Exception in thread "Timer-129" java.lang.NullPointerException
at org.openhab.binding.zwave.internal.protocol.ZWaveNode$WakeupTimerTask.run(ZWaveNode.java:1423)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)hey @chris I will switch to the dev version once it is merged in the 2.3 nightly.
will you close this thread with a short “how to” ? 
Currently I have on my list to delete and readd all things… however I am not sure if this binding version allows full manual thing config (including working config parameters). If this would work I would probably switch to manual thing files.
cheers
Hi Chris and everyone else here on openhab.org!
First post here. I recently bought me a Rpi3 and a RaZberry2 z wave module and have been reading pages upon pages on the different combos of operating systems and smarthome software available for this hardware. I finally decided to go for the OpenHabian solution. A few attempt and failures later and i’ve come so far that i have my Openhab2 v2.2.0 system up and running with functional Z wave module (linked to light on/off Switch).
Then i tried linking my Danalock V3 with no luck. It was linked up sortof but not in a working state. Googling and reading more i feel like i’m starting to home in on a solution here. Ive installed the test binding linked in the first post (dated 10th December 2017) using the karaf console. Here is what i did step by step:
bundle:list # found the ZWave v2.1.0 startID
bundle:stop (startID of ZWave v2.1.0)
bundle:uninstall (startID of ZWave v2.1.0)
bundle:install (downloadlink to the testversion linked in first post here)
bundle:start (startID of ZWave v2.2.0.201712100924)
Then i restarted my Rpi and opened Paper UI. There i find the old Zwave binding still installed and there is no sign of the test version i just installed. What am i missing here? Can someone please guide me along the way here because i cannot find the solution to this just by googling the topic.
Try uninstalling the production zwave binding from PaperUI. Did the development binding get copied to the addons directory? Just copying it into addons will install it.
Yes i uninstalled the original Zwave in Paper UI. That did work but i had to restart the Rpi3 for it to show up as not installed.
Ok so i wasn’t really sure that this was relevant, but yes i found this mentioned somewhere else (it could be on this forum).
Im not sure if i did this or not. Because i found no instruction how to. So here is what i did:
I downloaded the software to my Windows7 pc. Then i found the 3 shared folders on the Rpi in the “Explorer network window” (don’t no the proper name on this in English). I copied the downloaded software into the folder named:
\ \OPENHABIANPI\openHAB-share\openhab2-addons (note that this is from windows explorer)
I guess you are going to tell me this is not the right folder for this file?
I just looked through the documentation and could not find anything either, but the FAQs have this…
I’m not all that familiar with openhabian, but it sets up some Samba shares…
http://docs.openhab.org/installation/linux.html#file-locations
http://docs.openhab.org/installation/linux.html#network-sharing
http://docs.openhab.org/installation/openhabian.html
So, the binding should be in the right place. With the production binding removed, what do you see with bundle:list |grep -i zwave?
228 | Active | 80 | 2.2.0.201712100924 | ZWave Binding
Looks good! Is there any problem now?
Yes it has looked like this all the time since i installed it.
Btw the links you provided gave me a hint on what i’ve missed during configuration of the system.
I totally missed setting up the Samba share. I will have a look at this tomorrow. Now i’ve got to get a few hours of sleep
Edit: So i just looked over the installation overview for Openhabian
The following features are provided by the openHABian images out of the box:
Hassle-free setup without a display or keyboard, connected via Ethernet or Wi-Fi
openHAB 2 in the latest stable version
Zulu Embedded OpenJDK Java 8 (newest revision)
openHABian Configuration Tool including updater functionality
openHAB Log Viewer (based on frontail)
Samba file sharing with pre-configured to use shares
Seems like Samba should come preinstalled on the openhabian image and the share-folders works so everything looks ok at first glance…
What could go wrong and causing the OpenHab system to not check the content of the addons folder?
You are running the current version of the development binding, so I’m not sure what you think is wrong. Although, we’re getting a bit off-topic, so should probably head to another thread.
Using Zensys Tools to set the associations, I was just able to get my BE469s to start sending alarms again! One of the locks needed a complete reset/inclusion… it would function perfectly, but would never respond to anything for the Association CC. The other just needed the association to the controller set. Also, ESH has the extra logging that Chris put in (since snapshot 1140), so the Exception during HTTP PUT request for update config error has more debug info.
just upgraded to 2.2.0 release build in combination with the dev build for lamella support (from: OH2 Z-Wave refactoring and testing... and SECURITY) and I am seeing the exact same issue when starting OH2.2:
2017-12-19 09:22:06.317 [WARN ] [ig.xml.osgi.XmlDocumentBundleTracker] - The XML document '/ESH-INF/binding/binding.xml' in module 'org.openhab.binding.zwave' could not be parsed: The XmlConfigDescriptionProvider must not be null!
java.lang.IllegalArgumentException: The XmlConfigDescriptionProvider must not be null!
at org.eclipse.smarthome.core.binding.xml.internal.BindingInfoXmlProvider.<init>(BindingInfoXmlProvider.java:60) [113:org.eclipse.smarthome.core.binding.xml:0.10.0.b1]
at org.eclipse.smarthome.core.binding.xml.internal.XmlBindingInfoProvider.createDocumentProvider(XmlBindingInfoProvider.java:141) [113:org.eclipse.smarthome.core.binding.xml:0.10.0.b1]
at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.acquireXmlDocumentProvider(XmlDocumentBundleTracker.java:181) [109:org.eclipse.smarthome.config.xml:0.10.0.b1]
at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.addingObject(XmlDocumentBundleTracker.java:206) [109:org.eclipse.smarthome.config.xml:0.10.0.b1]
at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.parseDocuments(XmlDocumentBundleTracker.java:350) [109:org.eclipse.smarthome.config.xml:0.10.0.b1]
at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.processBundle(XmlDocumentBundleTracker.java:336) [109:org.eclipse.smarthome.config.xml:0.10.0.b1]
at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.access$3(XmlDocumentBundleTracker.java:331) [109:org.eclipse.smarthome.config.xml:0.10.0.b1]
at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker$2.run(XmlDocumentBundleTracker.java:307) [109:org.eclipse.smarthome.config.xml:0.10.0.b1]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
@sihui: did you see any negative impact - thus far everything seems ok on my system.