@cporourke I don’t really see how it would stop using security. Is it able to communicate at all? Maybe when you moved it to the new location it’s now not contactable?
You could try a reinitialisation of the device - in Habmin, select the thing, in the top right menu select advanced mode and then select reinitialise.
If it really has stopped using security for some reason it must be included in range of the controller with the controller plugged in to the computer.
I think i found the error after “Item AlarmState received command” i needed a Thread::sleep(500) so the state could change before checking the state in the rule
So apparently it’s more complicated than I thought. I’m now using the zwave jar you built a few days ago in a separate openhab install (i.e. different controller, different location, different lock). When I initially tried to install the lock (a kwikset 910) I got the familiar error.
I then removed all nodes from this controller and tried including the lock again and this time it worked. I then removed the lock and added additional devices to the controller. I tried adding the lock again. Secure lock inclusion worked. I then removed the lock, added 9 devices, and the lock included securely again (see below)
I then configured my 9 devices and removed/included the lock again. It included securely without issue.
The behavior in my experiment is very strange and it proves my secure lock inclusion issues are not solely related to the number of included devices prior to lock inclusion. Perhaps an update to the binding fixed things.
This error is not from the development binding.
Yes. Somewhere along the lines, you managed to change binding versions - the first attempt is with the old binding (which simply won’t work), and the new one is with the new binding (which works).
Also, please post logs as logs - not images. Format using the </> button and they are readable, and processable in the log viewer.
Chris, is alarm_raw ready to be tested? I see it in the binding (I had added it to the db), but even after reinitializing or deleting/readding locks, it is not showing up as a channel. I even tried stopping OH and removing the things from the jsondb. Locks are BE469s.
As best as I can tell, it should be included for the BE469. I assume you’re using the version from yesterday?
I had updated on Saturday and was on 2.1.0.201708201145, so it was in the binding because I updated the db 
. I didn’t notice the update yesterday, so now I’m updated to 2.1.0.201708272249 and waiting for the devices to initialize. Thank you!
Well, the code wasn’t merged until the 24th which is after the 20th, and before the 27th 
Let’s see though…
Yeah, I updated the db before the code was even merged. It sure would be nice if the reinitialize button wasn’t hidden…
The reinitialise button won’t change the thing - it just does the low level interrogation. If you enable advanced mode, then it’s visible though - right?
Not if the device hasn’t initialized after a restart of the binding 
. We’ve previously discussed.
I thought in the past I had been able to pull in db changes for a device by just reinitializing and not deleting the Thing. Maybe I’m not remembering correctly.
That’s correct - but why restart initialisation if it’s already initialising?
I think not, but I’m not 100% sure to be honest. I think it will only update the thing definition when the thing type changes which reinitialisation should do (I think). I’ve not looked at how it’s implemented in the deeper depths of ESH though either.
I believe it was the reinitialize that pulled in the db updates. They were not pulled in after a restart. I used my NGD00Z for months after barrier_operator was changed to barrier_state and that change never showed up (lots of restarts). I’ll know for sure if the reinitialize pulls in the db update in an hour or so when my locks come up.
The reinitialise button itself does nothing in relation to the database. All it does is to set the initialisation state to the beginning, and to delete the XML file.
The thing definition is read in when the binding sets the thing type, which is after the manufacturer information is recovered (about 1/3 of the way through the initialisation). This is not performed on every restart - but sometimes.
The database configuration parameters are always updated without having to update the thing - they are largely independent.
Is it possible to manually initiate a network heal instead of waiting for it to do it at night?
I thought it was an option in the controller thing, but I’m not sure now? This mostly only updates the neighbors list - it probably doesn’t really help routing if you’re having routing problems.
Not in Habmin2, but would be nice 
.
Does a binding restart initiate a heal, or is it just getting the neighbors from the device (INIT_NEIGHBORS)? After restarting the binding, devices report an updated Last Heal Time, at least for mains powered devices. Maybe that’s not accurate?
Yes - the same code is used at the end of the initialisation as used in the ‘heal’. As I keep saying though - the heal doesn’t really do a lot more than update the neighbors, and I wouldn’t expect it to help routing much (if at all).
Can you explain then what is the point of a heal? How do I know if I am experiencing routing issues and how would I then resolve them?
The heal will help provide some information regarding neighbors etc which is one of the indicators of a good network. It also sets up some routes between devices where two devices need to communicate directly, but the routing is managed by the controller itself.
In the medium term I hope to be able to add some new features to help with understanding the network and the RF links, but this will be a little while off yet.
