Cool. Can I get that version from the link in post #1?
Yep - let me know if you spot any issuesā¦
Iāll give it a try now.
I mainly drive EVs, and our main driver has a lifetime 347 Watt*h/mile (~$0.028/mile).
You probably mean zwave 
ā¦ currently one dead node, but the Enerwave motion sensors are fiddly and have always had issues being marked as dead. I think the dead node code is contained for now, but that thereās still room for improvement. The only thing that stands out to me is the broken SCENE_ACTIVATION for Leviton Vizia+ devices, which should only affect a small subset of users. The recent improvements to the startup were great for large networks. Logging is looking better too. Iād say the binding is the closest yet, by far, to being ready for a merge. And itās going into snapshots, so thereās still time to get some more changes in before a release. Iād ship it!
Look good so far. No duplicate nodes in the inbox, and all the channels linked to items are still there after rediscovering a node. So, it looks like you eliminated the side-effects we saw last night.
I canāt speak for whether the Unknown Node issue is resolved. I have not tried to include any new nodes.
I forgot to mention this. Logging is much better, IMO. Log files are not filling up nearly as fast for large networks, making it easier to analyze things.
Maybe this is some other problem, because i switched to the 17th july version, and still see this in the log:
2018-07-18 23:30:57.482 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 34: Invalid item type defined (DecimalType). Assuming DecimalType
The binding is running rock solid for 3 full days now. I have 3 networks, 130 nodes. I would also second the previous posts and consider this version as the best one so far and would also like to see it merged to the snapshot. Thank you very much!
1 Like
HAHA. What did you replace it with, if you dont mind me asking? Yea the poll was set for 1 day, thats the most I can make it. Is it an issue with kwikset door lock or openhab? I cant find any evidence of people complaining about this here. But I have found evidence that says they have great battery life with other automation system (e.g. vera, smarthing, etcā¦)
I replaced it with a Schlage BE468CAM605, which Iām not happy with either. 
I also have an August lock, which I really like, except for the way it looks. Cosmetically itās butt ugly.
One day doesnāt seem like it would cause a problem. The latest version of the binding allows 2 days and 10 days. Iām not sure when that was added.
No idea. I donāt have any experience with other platforms. I donāt see how it can be openHAB. Other than the polling interval, openHAB (and the zwave binding) shouldnāt have any impact on the battery life.
One thing I noticed with mine was when I only had a couple zwave devices, the lock was always the first hop to and from the controller. This caused my battery to die very quickly. I installed a zwave light switch right by the door, and that issue seems to have gotten better.
I was going to make the same comment. Itās also possible to manually configure the routing to prevent anything from going through the frequently listening battery powered devices. Zensys Tools can be used for this. Definitely something to use with caution!
To be honest, Iām surprised that the locks would be used for routing. They use FLiRS which is inherently slow (it will add a large delay - normally 1 second, but it can reduce to 250ms - into every message) and as a battery device I thought were not meant to be used in the mesh.
I confirmed in the ZWave documentation that FliRS devices do not act as repeaters -:
WakeUp slaves and FLiRS nodes cannot operate as repeaters as they are sleeping most of the time to
conserve battery.
1 Like
Iāve been running this for a little over a week now with no issues. Included in my network are a door lock, two garage door openers, and a siren which all require security and all work properly. Also included in my network are several devices not in the production database but are apparently in the database here and work fine, such as my fan speed switch.
I think documentation will be the key to success when it comes to security. For example, the only way I knew that I had to use the habmin inclusion function for secure devices was a random post in this 3000+ post thread. I spent 2 days scratching my head walkin around with my z-stick wondering why it wasnāt working.
Sometimes it is wise to read the docs
Secure inclusion must be started from the binding directly (ie with the controller plugged in to the USB and Online*).
As @sihui points out, it is documented. Thereās quite a lot of documentation- some is āokā, maybe some not so much 
. Documentation is often obvious when you know itās there, but maybe also hard to findā¦
Soā¦ I would welcome any updates to the documentation. I do agree that it can be improved, but I also think it would be useful for updates to come from a users perspective rather than just from me as I may have a different perspective on it 
.
The only mention of it is here: https://www.openhab.org/addons/bindings/zwave/#inclusion-and-exclusion, and that assumes someone reads that far down.
It is a safe assumption that most existing users are never going to see that. Theyāve been including and excluding devices forever, and wonāt be reading instructions on the matter since they already know how. Since secure inclusion is very specific, and very different than the way users may have been doing it all along, it will need to be made obvious. Otherwise it will just create a slew of people asking why it doesnāt work.
So I think the instructions as written in there are good. Itās a matter of bringing it to peopleās attention. Release notes and a pinned post here people can be directed to would probably get the job done.
Another issue today is the documentation makes no mention that secure devices are completely unsupported in production right now. Hence why everyone with a new secure device comes here wondering why it doesnāt work :). But that issue will become moot once this binding is rolled out.
Really? I donāt agree that this should be considered the norm. If so, you are effectively saying that writing documentation is worthless. I really hope thatās not the case 
As I said, I know that once you know itās there, itās obvious, however itās a complex system, and if people are having problems they should read the docs. An excuse like āthat information was on page 2ā doesnāt cut it.
If people donāt read the docs, then Iām also pretty sure they wonāt read the release notes. Additionally, pinned messages are fine (assuming itās possible - ZWave isnāt the only binding in town) but the vast majority of OH users are not regular users of the forum.
I can understand reading the documentation can be a chore, but letās try and get it in reasonable shape, and then if people ignore it, thatās their own responsibility. Any assistance with the docs is welcome.
Of course thatās not what Iām saying. This is a change to the binding and something that operates totally different than all other existing devices people use. It would not be good practice to simply assume people will go read the entire manual over again. The major differences must be made clear in release notes. Thatās what Iām trying to say. Assuming people wonāt read release notes is also not good practice 
For example, all one has to do is search on various secure devices here. Countless threads of people wondering why it doesnāt work. Why? Because the documentation makes no mention of it being currently unsupported, despite instructing people how to do it. Then theyāre directed to a post with 3,300 replies to experiment with getting it working. This is compounded by migration from other systems. For example, Vera has no other steps or processes for including secure devices. Users wouldnāt even know there is a such thing, and wouldnāt even know that section of the manual here applies to them.
The support topics in the forum are generally a great indicator of what may be lacking in documentation. If the same problem is constantly coming up in the forum, there is probably an opportunity to make documentation more useful.