No - I’ll need to double check this, but for starters the arrows show the communication direction. So if an arrow points from node 1 to node 2, then it means that node 1 is in node 2 neighbour table. If there’s not an arrow on the same line at the node 1 end, then it means node 2 isn’t in node 1 neighbour table. If I remember correctly, it’s then coloured green if there’s arrows both ways, and red if not.
Grey nodes I think are then sleeping nodes.
Sorry - I’m not sure about that. It’s probably best to ask elsewhere. There’s a thread about the marketplace somewhere so someone might be able to help there.
@chris I’m testing to see if I’m still having battery issues with my Kwikset 914TRL so I installed it again today (I had taken it back to my Vera while I was dealing with some other migrations) and after installation I don’t see the user / code admin screen anymore. Is that still part of the binding?
Also, while I was able to link to the lock channel when I send a lock / unlock I get the error:
2017-08-01 09:06:02.997 [WARN ] [nal.converter.ZWaveDoorLockConverter] - NODE 87: Command class COMMAND_CLASS_DOOR_LOCK not found
2017-08-01 09:06:07.678 [WARN ] [nal.converter.ZWaveDoorLockConverter] - NODE 87: Command class COMMAND_CLASS_DOOR_LOCK not found
2017-08-01 09:06:07.840 [WARN ] [nal.converter.ZWaveDoorLockConverter] - NODE 87: Command class COMMAND_CLASS_DOOR_LOCK not found
Is it just that the lock didn’t fully include? Here is a debug log file (Node 87) showing an attempt to lock/unlock.
These sort of errors mean that the secure inclusion isn’t properly complete, or, at least the binding hasn’t downloaded all the secure information from the device.
Thanks. Good to go now. Did you ever figure out how to expose what user codes were used to unlock a lock? I can get the Alarm Type code that a user unlocked it but am not getting the additional Alarm Level data which contains the user code id?
@chris - so I’ve been plagued by something interesting in my lock (Yale YRD246). It has a one-touch locking feature from the outside. Upon just placing your hand on the screen, it will lock the door if not locked. It’s a great feature for convenience. Unfortunately, the lock appears to handle this lock with the same Alarm # as a manual lock using the knob on the inside. So it may it problematic for me to be able to tell the difference between an inside lock and an outside lock.
I just happened upon the documentation though, and I see that it uses the Alarm Level item to indicate the difference between these 2 locking actions. I know there has been talk about getting the Alarm Level added into a single item with the Alarm type so that we can tell who the user is entering the code. Might I ask you be able to do the same on the Manual Lock channel? This will allow me to tell the difference between manual inside and outside using the screen. In the chart below it’s called “lock and leave”.
@chris thanks for the reply. I have another zstick and a kwikset 910 lock as well. Next week I’ll put the zwave logging into debug mode (apparently starting openhab w/ start_debug.sh doesn’t put the zwave logging into debug status) and see if I can recreate the issue.
I was building the development branch from scratch because of some custom zwave xml for my ct80 thermostat. I’ll try to use your linked jar for my testing.
I’ve been tearing my hair out trying to figure out why security doesn’t work for me and I think I may possibly have an answer, although as yet it doesn’t make sense to me. Whenever I try a build newer than 2.1.0.201706121754 I have major issues with my locks having incorrect nonces and security failing.
What I’ve come up with is that on June 19th yrd-220 xml was edited and this changed:
I don’t want to cast suspicion in a wrong direction, but just for giggles - do you have any other devices included in your ZWave network already? Or is this the first device you’re attempting to add in?
If you have other devices, and it’s a relatively small number - you might like to try a hand at clearing your controller, and starting fresh. A few of us have had a similar experience where we’re unable to securely include devices when there are other devices already included. May not be the case for you, but if you find this to be the case as well, I think we might have enough of a quorum to try and find out what is the same/different between us.
Hmm, yes I’ve run into that too. Once I include a non-secure device I can no longer include a secure device… except with the version of the binding I’m running.
Anyways, even if I get secure inclusion working once I switch to a new version of the binding the security on the locks stops working. It’s annoying because I don’t really see a reason why in the code, just the xml.
Apparently I’m missing something somewhere…I have installed the new binding as described, it is working…I put the controller into inclusion mode, and added my linear garage door opener, but its not included in the security network so I can’t access it. How do I find the network key? And how do I get this info to the linear device?
In Habmin, enable Tools> Advanced Settings, find your controller and look under Z-Wave Network Settings to add/change/remove your key. Changing the key will require reincluding your secure devices.
I just upgraded from OH 2.1 Snapshot using the zwave package at the top of this topic in my addons directory to OH 2.2 build #1000 and I am getting the following log messages when starting OH.
Does anyone have an idea what I may have missed during the OH2.2 package update/upgrade?
2017-08-04 00:08:55.556 [ERROR] [org.openhab.binding.zwave ] - FrameworkEvent ERROR - org.openhab.binding.zwave
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [9]
Another singleton bundle selected: osgi.identity; osgi.identity=“org.openhab.binding.zwave”; type=“osgi.bundle”; version:Version=“2.2.0.201708020845”; singleton:=“true”
at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
previously my zwave binding was installed in the installed in the openhab2-addons directory and not PaperUI, before I upgraded to OH2.2 snapshoot I removed the zwave binding from the -addons dir. Then I upgraded to OH2.2 snapshoot and installed the zwave buinding from PaperUI. I believe this is the recommended procedure?
To use this refactored/development version of the Z-Wave binding, you should not have the “mainstream” version installed.
Uninstall the Z-Wave binding that comes with the OH2 distribution from PaperUI and then deploy manually the *.jar from the link in the first post of this thread.
I have the 2.2-SNAPSHOT.jar installed build #1000. I read in this post that the 2.2 zwave binding included changes from the zwave dev binding that you are suggesting. I could try to uninstall via PaperUI my current zwave binding however, I am certin after I manually deploy the test zwave binding you specified in the link that it will not work b/c it is a 2.1 binding. feel free to correct me if i am wrong. I just want to make sure you are understanding i am running OH2.2
Thanks, David