Make sure that you reset the device, or exclude it before trying to securely include it. If the device is currently included it will not work since the secure inclusion (ie key exchange) must happen within 15 seconds of the inclusion of the device into the network.
So the device doesnât think itâs included, but I think the controller does. I was unable to âremove device from the controllerâ using habmin. Anything else I can try, short of resetting the controller to default and having to reinclude my other 26 devices too?
Note also that the first log I provided was the initial pairing attempt with this lock, so it couldnât have had that problem yet.
Why do you say that? I think the device is included ok, but it MUST be excluded and then included securely. Both the logs you provided had the same node ID, so clearly it was not excluded between these two inclusions.
If you donât exclude, then it definately will not work.
To exclude a device, you must use the âExclude deviceâ option in the controller. Click this, then put the device into exclude mode.
Maybe - itâs hard to confirm. All I can say from this log is that the device acked the message relating to key exchange, but did not respond. This means that the RF link is working, but the device chose not to respond. This is normally an indicator that the device was already included and therefore itâs past the 15 second window.
There is a procedure on the device that, when performed, will blink a light a certain way if it thinks it is included in a network, and performing that task does not blink the light.
Also, I see no zwave traffic when I perform tasks on the lock that I would expect to generate traffic, like locking and unlocking with codes.
OK, I didnât know that excluding had to start on the controller thing - the include and exclude commands on the device are the same, so I wasnât sure how to put the device in exclude mode when it doesnât think itâs included. I started âexclude devicesâ from the zwave controller thing in habmin, and performed the task on the lock, and it gave me a success code!
So after that, I deleted the node27 thing, and started discovery again. It did not pop up again immediately, so that seemed to have worked. I then included it, and it showed up as node 28 (same display as 27 showed), with habmin reporting secure inclusion failed, and another âxâ failure on the lock itself.
Hereâs the log from that inclusion:
The device will not send these if the device is not securely included.
I donât see anything wrong in the log - the device is just not responding to the security messages.
As a matter of interest, is it any different if you try the version at the top of this post? I donât think it would help, but it might be worth a try.
Using version 2.3.0.201806262322 from the top of the thread-
Same behavior from my experience:
@chris One other thing I wanted to ask about.
In the course of my testing, Iâve been deleting some of my zwave things (mostly those d@mn Minimotes 
).
When deleting a zwave thing, if a node.xml file exists for the thing, is that file supposed to be deleted as part of the thing deletion. From what I can see in the version Iâm running, it doesnât appear that the node.xml file is being deleted.
Yes - they probably ought to be deleted when they are excluded - can you raise an issue and Iâll add this to the binding.
The issue I opened says to delete the xml wen the node is deleted. IIRC, excluding a node no longer deletes the Thing. Right?
Thanks.
Correct - the binding is not allowed to do this now 
. But it can still delete the XML when itâs excluded - I will likely implement both (ie delete when excluded, and delete when thing is deleted).
2 Likes
Hereâs a log file showing the initialization of the Minimote, node 96.
https://drive.google.com/open?id=17xgAD0-e1W8FAhSHrm9fnQrR0kpFA65p
The device is discovered and identified correctly as a Minimote.
However, after a few wake-ups, while it does receive the NIF, it doesnât seem to be going beyond that? Itâs not even clear to me whether its doing anything with the NIF. Seems odd (at least to me) that the receipt of the NIF is appearing in the log file before the WAKEUP notification is logged. But maybe thatâs normal. I also see that the NIF contains an unsupported command class (COMMAND_CLASS_ASSOCIATION_COMMAND_CONFIGURATION). Could this be causing a problem?
Iâve just updated the binding (link still at the top of this thread). Two points to note -:
- This version now has the ânewâ DEAD node code merged.
- The filename has changed to version 2.4-SNAPSHOT
There are still a couple of issues I will try to merge in the coming days, but if there are no major complaints with this version in the next week or two, then I will merge this into master.
Hi Chris, I have been frequently updating my zwave binding from this thread without any major issues. I just tried out the new version of the binding you posted and now see issues with node availability. About 1/3 of my nodes show as offline, I have approximately 60 mains devices and 1 battery device (Yale deadbolt). I can post a log file, I just need to first update my logging config for zwave to write to its own file as I have other noise in the main log.
Right now, I have only two dead nodes. So, it appears to sort itself out with time. These nodes will eventually wakeup and raise from the dead. Iâve seen no loss in functionality due to this. After a restart, devices of all types can show up dead. After a day or so, the mains piowered devices are alive and some battery devices are dead. Give it a few more days, and they seem to all get sorted, for the most part. I have not been able to identify anything in the logs, but it seem to be related to battery devices going to sleep and being marked as dead. Right after a restart, it looks like mains devices are being marked dead due to the amount of traffic.
I think one of the most important things to do in preparation for the merge is to find a prominent place in the zwave docs to educate people on the need for deleting Things. Not just for the upgrade, but for updating Thing definitions that have been changed. Maybe this would fit in the Device Database section, but itâs kind of buried.
Yes please - please email it over or raise a ticket on my site. It would be interesting to see if thereâs any similarity to @5iver logs.
Good idea - Iâll add something for this.
1 Like
I see in this commit that the Minimote was changed.
It was changed from
<property name="commandClass:COMMAND_CLASS_WAKE_UP">getSupported=false</property>
to
<property name="commandClass:COMMAND_CLASS_WAKE_UP">ccAdd</property>
I also see in the logs that the WAKE_UP_INTERVAL_GET is not working. I suspect this may be the reason why itâs not progressing through initialization?
WDYT?
@5iver I see you made the change to the Minimote database entry. This is what appears to be causing the WAKE_UP_INTERVAL_GET to fail during initialization (i.e. I donât think the Minimote supports this transaction).
Thanks.
will this version still work with the OH2.3 release ?
I made that change, but WAKE_UP_INTERVAL_GET was failing before this was done. I thought there was more progress made with this, but it looks to have just stalled out. This PR did not resolve the issue, and appears to have made it worse, so maybe it should be rolled back? Whatâs odd is that there must be another change involved, because I was able to initialize minimotes after this PR was put in.
Ah, yes, I do remember this issue.
If youâre ok, Iâd like to change it back to NOGET, then see what happens. I donât know if this is the reason why the devices arenât initializing, but it will remove one variable.
Interesting. Have you been able to initialize it (after deleting thing AND node.xml) with the latest dead node handling code?
I have three Minimotes. Two of them are white ones with the numbered buttons. Those will not initialize. One is a black one with the unnumbered buttons. That one initialized successfully. All three report the same firmware number. Which device(s) do you have?
I have the first gen (numbered buttons). I just deleted the Thing, deleted the XML rediscovered, and it came right back up. Maybe I need to restart after deleting the XML? How close is the minimote to the controller when you are waking it up, and have you tried it closer?
Hang on⊠somethingâs fishy here. The device works and Habmin shows it as initialized, but no XML was created. HmmmâŠ