Yes - I will update the binding every few days - probably tomorrow I think now…
Perfect. Btw, I’ve been adding a lot of nodes to my controller now . Most of them show up as unknown devices and their thing need to be deleted and rediscovered to show attributes properly. After a simple delete and rediscover they show up fine. If needed I can provide debug logs, just let me know.
I had a look through your log and have a few comments.
Polling - am I correct in assuming you’re using a non-default poll period? I see polling every minute or so - at least in some devices. I’d question why this is needed? You should be able to configure most devices to send data when there are changes rather than polling. When you have a lot of devices, this will for sure slow things down.
The OH2 binding needs to throttle back polling to reduce the impact, but if I were you I’d take a look at whether or not you really need to poll - mostly, it should not be needed.
Association Configuration - make sure you don’t configure more than one association group. I know many people add multiple groups - for example they will put the controller into the lifeline group since that’s what OH does by default. Then they see that they want to receive switch status, so they add to group 1 and 2 (just an example) - now we have duplication since the binding will send the data to the lifeline group, and to group 1 and group 2.
I see a lot of duplication in your logs and this will also slow things down on larger networks -:
Timeouts - devices not responding is always going to delay things and it would be worth understanding some of these timeouts if you can. A timeout is 5 seconds so it is likely the main cause of your issue -:
It would be worth trying to look at these to understand why device 37 doesn’t respond to this request - it acks the request, so it’s alive, but it never sends the data respond. If we know what this is, we can stop the binding from polling, and this again will improve responsiveness.
These are just examples - I don’t really see any ‘bugs’ as such although I’ve not looked in detail at all 15MB of log ;).
I think that probably the polling is causing most of the problems. In OH2 I decided to poll all channels since by default this only happens every 30 minutes - if polling is causing timeouts, and it’s happening every minute or so, then this will for sure start to impact the overall responsiveness of the binding.
I will try and look at ways to improve this, but I’d also suggest looking at the logs yourself to see if you can optimise your network…
Thanks a lot. You’re the best.
Where can I set the polling parameters? All I set in PaperUI was the port and network key, rest is by default. I see only Default Wakeup Period, but this is, I presume, for battery operated devices and it’s set for an hour.
I do not see such setting as refresh interval, it used to be in OH1.X defined on the item level.
Node 37 is Fibaro Binary sensor with two contacts and 4 thermometers. It’s in the middle of the network, defined as {channel=“zwave:device:controller:node9:sensor_binary1” }
I noted that the Parameter 11, Interval between forcing to send temerature report was set to strange value of -56 (as reported by Habmin, btw, how is it possible for the parameter that has values 0-255), so I adjusted it to default 200s.
@chris - Thanks for your hard work on this, very excited to see secure inclusion now in beta.
I’ve been unsuccessful in getting my lock to work (Yale YRD220). It was previously added to OH2, but of course not in secure mode. I followed the instructions above (remove devices and controller, uninstall binding, install new biding in addons), then did inclusion through HABmin and the lock says it’s paired. However OH2 shows it as unknown.
Any thoughts on what’s going on? I’ve tried multiple times but didn’t see anything obviously wrong to my eyes. A copy of the logs during secure inclusion are available here (it’s node 20): https://www.dropbox.com/s/d3ghmgbavo1xamu/Node%2020%20-%20YRD220.log?dl=0.
Interesting - I wonder why I’m seeing requests more often then 
. I might need to take a deeper look at your log… I did find one device (node 68) that’s using a non-default value (10 minutes) but that’s not going to make a lot of difference…
Polling time is set in the thing configuration - it’s applicable to all channels at the moment although I’ve just changed it not to poll channels that have no items linked…
So this device here? Strange that it seems to be requesting SENSOR_MULTILEVEL when this command class doesn’t appear to be supported in the root endpoint. Can you email me your XML file for node 37?
Looking deeper, I guess that the device is reporting it supports this class and the binding is requesting it during the initialisation, and the device isn’t responding to it - the XML should show this…
It’s presumable a bug somewhere with the treatment of signed and unsigned values (200 is also -56 when printed as a signed 8 bit value).
I did just find one bug in your log -:
Unfortunately it will make your problems worse - the above shows that we requested a request for node 37 multi-level-sensor, and at roughly the same time received an unsolicited report from node 3 multi-level-sensor, and the binding correlated these which it shouldn’t have! Good one to fix - but not going to help you I’m afraid…
I’ll make some changes to the way polling works tomorrow and we can see if that helps in the first instance. I think most of your issues are more related to initialisation still from what I’ve seen so far…
I have some ideas to improve the initialisation but it’s not implemented at the moment - in the OH1 binding if a transaction doesn’t respond we keep retrying. In this new code, we can differentiate between the device not responding at all, and it not supporting a request, so we can move on quicker.
Your system is a good test case 
- thanks for the input.
So this is the lock saying “completed” - or is there a popup in HABmin saying the secure inclusion completed?
I’ll take a look at the log, but one thing to try is to delete the thing, click on discover again, and add it back - don’t exclude the device and re-include it. I think there’s something not working well about updating the inbox once the device info is known.
I’ll take a look at the log, but you might wnat to try the above…
Ok - cool. Just loaded up your log so I won’t bother looking at that now… I need to take a look at the discovery handler then…
@chris, I’d like to try out the refactored OH2 binding but I think I need the device ID - 0002:0209 - presented by my YRD220 lock added to the database (it shows up as unknown in HABmin). I’ve registered on your site but it says I need to contact you to get my access updated so I can edit?
I’ve updated your access on the database site so feel free to add these codes to the YRD220. I’ll likely do an update of the binding tomorrow so this should be able to be added…
Cheers
Chris
I screwed up and started over, I have openhab back, the jar in in addons and I can’t get security to work, how do I get the jar to load as the zwave binding?
Thanks for this code and info. Got my YRD120 working!
Read those two posts and you should be good to go (for an exisiting openHAB2 installation and for a brand new openHAB installation):
Thanks for introducing security!
Just some quick questions…
When installing I deleted all my zwave devices and unistalled the binding through paper UI.
Stopped OH2 and placed the new jar file in /usr/share/openhab/addons.
Then I just realized the I have zwave also in my addons.cfg, what should I do about that?
How can I tell that I have succeded in loading the correct zwave binding?
Whats the correct way of including devices with security enabled?
thanks
You need to remove it - otherwise you will have two copies of the binding.
Check in the Karaf console to make sure the correct binding is running - use the ‘list’ command to get the list of bindings.
It’s the same as without security - just enable discovery. I highly recommend using HABmin for this though as it will provide a popup if secure inclusion worked or not.
1 Like
ok, I can’t seem to get to the Karaf console to run the commands. This is a premade image for the pine64…
Did you try and ssh into the Karaf console?
ssh openhab@localhost -p 8101
password is habopen
Chris, how do you intend to notify us about binding recompiles with the updated database? I know this will eventually be automated via apt-get when it’s in the main branch, but until then?
I’ll post here when I update. I will be doing an update tonight so if you grab tomorrow (or this evening if you’re in the US) it will have the new database additions.