Thanks for clarifying.
Yep, wonder if we need to go back to our own state. I am not sure why the controller is marking devices failed that it is communicating with, but that is what I am seeing also. P.S. started over with a fresh z-wave network and all mains powered devices. The odd thing is that one of my devices marked down by the controller is quite close to it.
I donāt believe itās related to distance in any way. The controller is receiving messages from devices but choosing to keep them in the FAILed state - this isnāt a distance issue.
@Chris Here is the log file from changing wakeup, waiting a minute or so and then triggering a manual wakeup for the device. Itās Node 45. Let me know anything else you need to help identify whatās happening. - https://drive.google.com/open?id=0B77VHtwPft8eMHVseVhiamZadE0
Thanks.
@chris: I just encounter another issue with the new binding (2.1.0.201704232237). The nightly heal (one of the most important features for me in the binding) seems to work āin the wrong directionā. I observed several nodes (including my serial stick) to lose neighbours by the nightly heal process. As I am tracking the neighbor statistics with some self written tools in detail (I extract the neighbor data from the JSON and store it in a database daily for analysis purposes) I can definitely confirm that the result of the heal at 2am is not what is expected.
Example: Node 133 (Aeon Smart Switch ZW096, main powered, located 2 meters from controller and also close to about 25-30 other main powered nodes) used to have 29 neighbors. After the nightly heal just 2(!) neighbors were left over this morning, the other neighbors disappeared (timestamp of the heal wa 02:34am today). A manual mesh update helped me now to bring back 26 neighbors, but there seems to be something weird with the nightly network heal function.
The same issue with my node 1 (Aeon Z_Wave Stick Gen5). The node used to have 58 neighbors before I switched a week ago to the new binding version. It then got down, to 48, 36 and now onhly 30 neighbors left within 1 week.
Could it be that the implementation of the nightly heal process needs some review?
Yes - this I would expect. The system will not just keep increasing the number of neighbours - it will change dynamically due to RF issues.
I donāt believe so - thereās very little that the binding can do. It sends a command to the controller to tell it to UPDATE the neighbours. This will result in nodes coming and going - all perfectly normal.
I will continue observing things. But so far there were only nodes going, never coming.
And: Doing a neighbor node update with the Aeon Zensys Software or manual with Habmin brings back all lost nodes immediately. So I wonder if the nightly heal maybe asks all the nodes at the same time and therefore the network is stuffed in that moment?
I would need to check, but in general the controller only allows a single command like this to be sent to the controller at any time. The controller canāt handle multiple commands. So, I doubt that this is an issue.
If you want to send me a log of the nightly heal on your system please feel free and I will take a look.
@chris So hereās the interesting part. Once I got the devices to connect 2 days ago they are staying connected (Iām only getting battery levels from one though and it is still showing as pending for the change in wakeup time that I made ahead of getting them connected? Plus the one device giving battery gives me the optionto Reinitialize on the Advanced Menu and the other one that is Pending doesnāt?
This option is only available if the initialisation is complete, so it probably means the init is not complete on one device.
Thanks, Iāll try reinitiating the device then. Though it is showing itself as online.
Online doesnāt mean that itās not still initialising. Itās not related at all.
Thanks for clarifying.
Does anyone have any idea where we can identify the list of RAW alarm codes that are now showing up with the Alarm Status? Iām starting to see the reports (thanks @chris!!!) - but now I just need to know how to decipher these codes. For me, Iāve got a Yale YRD-246 that I canāt quite decipher.
Oh, and actually, I forgot. Bigger importance, I noticed that in the most recent bundle (2.1.0.201704232237) - User Codes are not visible in HABmin. Any change here that might have regressed the User Code function?
I completely re-wrote the user code functions to move it to the new autocoded command class. This has a bug due to unsigned values - so if you only have 127 or less codes, it works fine - more than this and we hit the bug, and your device probably has -1 codes 
I will look at this over the weekend.
Oh boy. Yes I am the lucky one. Iāve got the device with 200 codes. 
Well at least I put in all the codes I needed I think before this change. But it would be good to have access to further manage them.
Surprisingly I know you mentioned all the transacting would likely be hammering battery life with all those codes, but I must say itās survived pretty well during those times and all the testing previously. Only lost about 10% over the course of last 2 months.
I look forward to any updates though, and happy to test when ready. Will be away until Sunday though.
Good news. I guess itās all relative - it would last longer without this, and it only does this download when the binding starts, so if you donāt start tooooo often, then it shouldnāt be a major impact.
OK, seeing the heal magic a few posts above, I must change into this binding from the main lineā¦
Instruction says delete the things first. Is there a way of doing this without having to click-delete for each thing in habmin or paper?
You could stop OH, go into the json db files and delete all the zwave things and then restart - this should work, but might leave some links (although deleting through the UI also leaves links, so maybe itās no different).