That’s correct - the binding doesn’t delete the nodes (it can’t - ESH blocked this functionality a while back!).
The response from the exclude was ignored due to a bug, so the node wasn’t removed from the controller. When you did a discovery again, it was still in the controller list (by controller, I mean the list of nodes in the binding - not the stick) so it got added again. However, the exclude really did work ok, so when you restarted and the binding read the list of nodes, it was gone…
Are you really sure you’re running the security version - or that you don’t have multiple versions running? This bug doesn’t seem to appear in the security version - only the master as far as I can see (I did a search for I18nProvider in the development branch and it doesn’t seem to exist).
Hmm. Strange. I stopped OH2, recopied the 2.2 binding over and now the error is gone. I had copied the one from post 1713 the first time. But maybe I had bad download or something.
But now that I’m back looking more into my OH2 setup etc, I noticed I can’t seem to control my lock. It shows secured in Habmin, but it does show a red x for listening. I went and manually used the lock to try and wake it up, but uncertain why I couldn’t control it. Habmin shows it online and secured.
So following up on my attempts along with @nolan_garrett - I’ve been successful using OpenZWave Control Panel in a docker container to get the job done.
@mhilbush - thanks for the input, it appears the creator of the image forgot to adjust for instructions on docker hub vs local testing he was likely doing to build it initially. I’ve been doing the same lately for some side projects. In my case mine was /dev/ACM0 too. It was fairly easy to get up and running, but the security part took a little more thought mapping in the options file.
So along with the same lines as Nolan’s instructions, the idea is to stop OH2, pull your stick, plug it into the host for the container (preferably one that can be brought within proximity to the device) - include using the OZWCP, then plug back into OH and startup. I can happily report I’ve now got the new secure node running alongside the rest of my setup with no fuss. I’m posting outside this thread (as it’s big enough!) and so as to hopefully not detract much from the core focus of folks who are successful here.
@chris i’m trying to understand a few features to fully understand my zwave network. This thread + google searches didn’t really come up with any definate answers so i hope you can help me out with a quick explination.
I’m running your latest Oct snapshot of zwave binding. My Z-Wave Network Viewer looks like this within HABmin:
No - not in their own right. In an RF environment, especially in the home where there are lots of noise sources, walls, multipath issues etc, it will definitely happen…
However, clearly if a device has no route through to another device, then it’s a problem.
As an example, node 29 has a one way link to node 1. This means node 1 can receive node 29, but node 29 doesn’t directly receive node 1. However, nodes 18, 19 and 26 can all act as repeaters - ie there are green lines (bi-directional links) linking node 29 and node 1 through these 3 devices, so this is a good link as the controller has 3 options for routes to node 29.
Ok, so kinda strange. I know in the past I was able to control my lock, but had let my time with OH2 slip and now back looking at everything, upgraded OH2 and the Binding here to the latest, even removed my lock from HabMin and re-added it.
However, Habmin is not reporting the either door status or battery level, yet everything seems correct in Habmin and not seeing any issues. Habmin even says it did it a heal on the lock device this morning. Its been over a day without any door or battery status.
And the batteries in the lock are fresh new batteries. I can manually enter lock codes to lock and unlock the door.
Lock shows healed as of 2:55 am this morning.
The batteries in the lock may have been previously dead for a week or more. Is it possibly I actually need to unpair and repair the lock to the controller?
Good morning! @chris - in the device database, will it matter if the alarm command class is marked as Sec as opposed to only UnSec as long as the Device is securely included ? Or will alarm command class data be sent unencrypted if only UnSec is marked?
I’ve just made a new version of the binding available (same link as before).
This changes a few things, so please let me know if there’s any issues.
The main thing this adds is a new stage in the device initialisation to handle the ZWavePlus Lifeline association group automatically. The binding will automatically set this to report to the binding, even if it’s not set in the database. It also will remove other devices from the lifeline group to ensure that it’s set to report to the binding. It will also use the multichannel association if there are multiple endpoints and the normal association group if there’s no endpoints other than the root.
The above was implemented to try and resolve issues with devices that are now starting to use a new concept that ZWave has defined. Many devices seem to be buggy in this respect so it’s not been the easiest to get working, and will likely still have issues with some devices (namely, older V1 Qubino devices seem to have issues still).
I haven’t seen any new issues so far. Still get these though, when saving an association, healing, etc…
2017-11-12 13:33:28.982 [ERROR] [marthome.io.rest.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at 'things/zwave:device:07cb40a2:node8/config' for thing 'zwave:device:07cb40a2:node8': null
I was hoping the latest ESH update included in the snapshot build (I’m on 1078) would have the extra logging, but ESH PR 4403 is still open.
Thanks for the feedback @5iver. Yes, I’ve not updated the logging for the REST exception. I’ll try and do that in the next few days but I’ve been working to get the major updates to the ZigBee binding done so I can get a consolidated update released…