I’ve managed to find a BE469 on eBay so have one heading my way. Now I just hope I can use it to solve the inclusion problems people are having with the Schlage devices or it will be a large waste of money ;).
@chris and @shadowmite my problem was not related (at least I don’t think) to Habmin or PaperUI directly. There was a duplicate channel id for the thing (CT32): zwave:device:4c9537c3:node11:battery-level. I could see this when I tried to use the REST ‘PUT’ command to update the ‘config_scale’ for all the temperatures. The error was something along the lines of “duplicate channel ‘zwave:device:4c9537c3:node11:battery-level’”. This is the same error I got when I tried to add the thermostat via the ‘.things’ file. So I changed the second one to zwave:device:4c9537c3:node11:battery-level1 (which is what it should be) and removed the link to my battery item and redid the PUT command. Now all my temperatures are in the right scale. and I think I can save in Habmin too… although I haven’t tried it and don’t think I will. I will try to put in a change for the device in the db… not sure if this is shadowmite’s problem too or not.
How much did it cost ya?
Probably too much - by the time I paid for the unit, postage and UK customs it was $180… Hence my hope that it helps me solve the problem or there will be much unhappiness ;). It’s another week or so away from arriving so let’s see…
@chris I don’t see anything that could be changed in the Zwave Device Database entry for the CT32 that looks like it would change the channel uid being duplicated. So maybe this is something to do with zwave binding, paperui, or habmin… or I don’t understand what I’m looking at 
To be clear, the channel uuid duplication is definitely not something I did by mistake. I have had this celsius problem on several fresh installs.
@chris – obviously a little late on the thread to save you any money, but I have a BE469 that isn’t currently paired to anything so I can help with more debugging info if you need it.
Thanks - unfortunately the security classes are pretty hard to debug remotely I think. The timing requirements mean everything has to happen within a few seconds of inclusion (ie 15 seconds) and this means lots of trial and error is likely required…
Anyway… hopefully when I get my BE469 it also won’t work properly, and I’ll be able to find the reason…
Chris, just sent a donation your way to help cover a bit of the cost. Thanks for all that you do for us!
1 Like
Donation made!! Thanks as always Chris!!
Maybe you don’t have a BE469, but if you’re here, it’s likely you’re using some aspect of this wonderful security enabled binding that @chris has slaved over reverse engineering to work without the need for the proprietary bridges that license a security module (I believe thats how it all works). If you’ve benefited, take a moment to Donate (Scroll to the bottom)! I’m sure Chris would appreciate even the smallest of donations that can quickly add up to the $ he spent of his own to help further this binding!
1 Like
One quick question as I got confused. I am currently using the normal Z-wave binding with Openhab2. I have included my devices in proximity to the Raspberry with the UZB stick then moved them to their final location. Some of them are too far away to reach the controller directly and I was under the impression that the mesh network will resolve this, however, these devices remain offline.
Is there no mesh healing in the normal Z-wave binding at all?
Do I need to use this development binding or is there a way to connect the offline devices with the standard binding?
Many thanks and best wishes,
Jonas
You would not need this binding unless you have OH2 and secure devices or would like to contribute to the testing (or development). If not, it would be best to start a new thread 
. If you have devices that can route, they will extend the mesh for devices that can’t communicate directly to the controller. If you have routing devices in place, and assuming the new devices are battery powered, try waking them up a few times to make sure they have completed initialization. If they are initialized, try doing a heal and waking them up so that they will learn their new neighbors.
Turning on debugging and watching the log filtered to the node in question will be very helpful. From Karaf console (X is the node in question):
log:set DEBUG org.openhab.binding.zwave
log:display zwave | grep “NODE X”
I am sorry if I hijacked this thread. I was under the impression mesh healing was not possible with the normal Openhab2 binding. If it does that is great. How can I do that and force a wakeup (all my devices so far are mains-powered so I suppose they all support routing)?
Many thanks,
Jonas
I think you need to wait for chris to chime in, but personally I think you need this binding to heal the network. The vanilla binding does not heal at all, but leaves this up to the controller, I believe. I never had any routing going on with the vanilla binding, after also walking around to include.
In the master OH2 binding, the network updates should still be done when the binding is initialised - ie at the end of the device initialisation. It’s not healed after this though. In this binding, it can also be done by starting a heal which will ask nodes to perform a neighbour update.
So in my situation (initialization was performed right next to the controller, but final location of the device is out of direct reach of the controller), what would you suggest to do? Delete the devices and re-include them from their final location (via routing), use the development binding?
I would go for this binding, it is the future after all… This means that you will have to follow the process in the beginning of the thread, which is a bit of work, but then again, you will probably want to do it later on anyway.
(This means you have to delete the devices, but not re-include)
A few observations on the older 2.1 release from June. If you recall, I hard reset my Z-Stick 2 accidentally a couple weeks ago. What I found was that once reset, security devices included immediately without issue or retries needed. I did these first. 4 devices in total included on the first try, one from halfway across the house.
Fast forward to today where I have all 70 of my nodes included and now want to add another NGD00Z-4 Garage Door controller. Now I can’t include securely again. 12 tries and no success, tried with Network Wide, High Power and Low Power inclusion modes. This seems to indicate to me that the more nodes you have in the network the less stable secure inclusion becomes.
I am going to upgrade to OH2.2 and the latest binding here shortly I think, after I’ve worked through this thread to determine if that will introduce any new problems for me.
I’m a bit confused by the versions you’re talking about since security wasn’t included in the 2.0 versions - only 2.1 development version has it…
Sorry - I was replying via email earlier and I see you’ve now updated the versions from 2.1 to 2.2. Just to note though that there is no 2.2 version - just 2.1 if you’re still talking about the development version.