First start of OH snapshot 1140 using zwave 184.108.40.206712100924…
Exception in thread "Thread-190" java.util.ConcurrentModificationException
and after a few hours…
Exception in thread "Timer-129" java.lang.NullPointerException
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.
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 v220.127.116.11712100924)
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.
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?
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
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?
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.
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.
For anyone who might be struggling with the same issue:
I had a working zwave network. I recently upgraded to stable openhab 2.2 (used to be on 2.1). I had used this experimental binding before. After I upgraded all of my zwave nodes seemed to be initializing correctly. However none of the nodes were working. I could find no errors except complaints about not being able to find node 255. I could get them to work by deleting them in openhab and adding them again. However, that did not seem to be a nice route because I have 30+ nodes. The solution was to install the experimental binding again. After that all my nodes worked again.
The solution was to install the experimental binding again. After that all my nodes worked again.
You can’t swap back and forward between the development, and main bindings - they use different configurations. If you swap, you must delete all your things and add them back into the binding again so they pick up the correct definitions.
I’ll be preparing to move to zwave with security soon, I understand that the development and standard branches are incompatible with each other, but what makes it so? Is there anything we can do (or I can start looking into) to automate the transition?
I renamed a lot of command classes (i.e. most of them!) to be inline with the zwave standard. This means that all thing files are now different. In theory, you might be able to rename some of the configuration and it might work ok - or it might not as the database export is different. I probably wouldn’t recommend trying to write a converter - it will likely be error prone, and it will leave the thing configurations in some sort of unknown state, so if there are any problems, we really wouldn’t know what to do.
Theres’ not need to exclude/include - just delete the thing, hit the discovery button, and add the new thing.
Well. Merry X-Mas! And, now I have time to try this out!
I was curious to try out the alternative binding to use the Secure Inclusion feature.
Wondering if anyone had any pointers as to what I may be doing incorrect.
Openhab 2.2: Main Branch, using Chris’s beta z-wave binding jar (18.104.22.168712100924 as per “list | grep ZWave”).
No other bindings. Was a fresh install. Added the z-wave jar to the addons folder and it picked it up on restart.
Yale YRD210: With Mainstream branch (previous install), using the mainstream z-wave binding, it detects it properly, mfg and all with channels, excluding security.
With the beta z-wave in the addons folder, the only way I can get secure inclusion to work is low powered inclusion only. That shows up in HABadmin as “Using Security - Check”. But the device is unknown still. Manufacturer shows up properly as 0129"ASSA ABLOY", Type/ID: 0004:0209
I have excluded the device, deleted, and re-added several times.
From the log I can gather this:
[Error] alization.ZWaveModeInitStageAdvancer - Node 11: SECURITY_INC status=complete
[warn] wave.discovery.ZWaveDiscoveryService - Node 11: Device discover could not resolve to a thingType! 0129:0004:0209::83.32
I’ve used the lock, pushed buttons etc to try to get the device to do something on the network, and have been waiting hours, but no luck. New user codes entered in, do not get pushed to the device (shows up in Web Interface as pending). And I do not have any device feedback channels to assign to Items. I set the device to communicate every 10 minutes, but assuming since it’s not refreshing I am assuming this is not applying.
I also noticed that when in HABmin, in Things, clicking on the Unknown device takes a long time to load. Clicking on the controller is quick.