Ah, thanks a lot (to @sihui as well), I didn’t know that. Might explain some problems I’ve been having. Side question: Is there a way in oh to see which devices are considered battery powered and not? I can’t find any obvious way…
Not directly, but this isn’t really what you need to know. What you want to know is if a device is included in mesh routing and this is available in HABmin device attributes.
1 Like
I’ve resent the logs. Showstopper in the context of this thread 
Thanks - so I did have them, but couldn’t tie up your name here with the name on any logs 
Have you tried a more recent version of the binding than the logs show? If not, I’d suggest to try an updated version - in fact, I’d suggest to try the latest anyway and grab a new set of logs from that.
There have been a couple of changes that might solve the problems I see in your log - both were made after the logs were created.
The behaviour is the same with bindings released up until 3rd March. I was keeping an eye on this thread if any update seemed relevant (2 updates since were only for the association group drop downs, and then the device database/ multilevel switch reports).
Ok, but please can you grab an updated log with the latest binding. There have been more changes than this (I don’t always mention all changes) and there has been a large change to the way encapsulated messages are handled. I had hoped this would fix your problem, but even if it doesn’t the old log makes it hard to correlate things.
Mmh, that’s strange: After reading this post I checked my devices, and I discovered that currently all my battery devices have the routing flag set - e.g.:
So I have to exclude and reinclude them all?
Yep, same here. Makes me think that information isn’t really accurate…
I had read this in the manual, “During normal use the Multisensor may be powered either by batteries or by USB connection. However, because the power source that is being used to power the Multisensor at the moment of its first inclusion into the Z-Wave network has a bearing on the settings that are established during the inclusion process, it should be decided in advance whether USB power or battery power will be the intended power source during normal operation. That intended power source should then be used to power the Multisensor when it is added to your Z-Wave network. In other words if you intend to power the Multisensor by USB over the long-term, then you should power the Multisensor by USB when you include the Multisensor into the network. Likewise, if batteries will be your long-term power source, then use batteries to power the Multisensor at the time of inclusion.”
What this doesn’t directly say is that when on Battery Power the MultiSensor “Cannot be used as a repeater node”.
Difference between USB and Battery Power and Recommendations (Multisensor 6 ZW100)
I thought that I had only powered the device with batteries, so I should have been good. I may have had a corrupt network on my Z-Stick. Anyway, things are much more stable today after redoing everything.
Thanks for the info.
I’m not sure why routing would show true - normally, if a device is not listening, then it also can’t route, but the listening flag is correct. Normally I think both are set the same - if it’s listening, then it’s routing, and if it’s not listening, then it also doesn’t get involved with routing.
You could take a look in the XML to see if that shows the same - it should, but maybe there’s a bug in the binding. I checked the code and everything looks ok, but you never know.
According to my XML files all devices are routing but device 1 (which is the controller, right?). For example my Sensative Strip really doesn’t talk when it’s not at gunpoint, but here it says it’s routing.
I’ve had a bit more of a read, and I think this is ok. The binding doesn’t use this flag at all - it’s the listening flag that is used to detect battery devices in the binding, and probably the controller.
The routing flag seems to indicate that the device can route - not necessarily that it’s a router (ie that it can act as an intermediary). It’s perfectly ok for a battery device to use routing, so this is fine.
@chris never want to pressure you, but any feedback on the 3 items I listed? If this lock won’t work, I’ll need to return it and want to ensure I don’t pass by the return limit. Short synopsis of the items from above here:
- Association group appearing for device that does not support or has none
- COMMAND_CLASS_DOOR_LOCK not found
- Can’t successfully Remove ZWave devices now from the controller
1 Item I forgot from last post as well, I haven’t seen a way to add in Security Codes for the new lock (Yale YRD246) like I saw for the old lock (Schlage BE469).
Just wanna say that this worked great for me including a Danalock yesterday. Even did it with my OpenHAB2 and Z-wave controller ~4 meters away so no need to dismount it from the door. Unlocking and locking is immediate despite people saying it can take upwards of 10(!) seconds. Great job!
1 Like
Sorry - I’ve not had a chance to look at this (you only posted it yesterday ;)).
- Association groups should come from the database - in this case there is an association listed in the database for this device so presumably whoever added the entry thinks it supports associations.
- I don’t know why this would be - either something to do with the secure inclusion not being correct so it doesn’t know of the lock class, or just something missed with the initialisation due to timeouts or something. I’d try removing (or renaming!) the XML file so that it does a re initialsiation.
- There might be a bug here - I need to look more.
Security codes gets added to the UI if the device supports certain classes - again, maybe the initialisation had an issue with this device.
Touche, somehow I thought it was 2-3 days ago. Which still isn’t anything to heckle at, sorry
Ok those sound like solid/logical explanations. I’ll see if I can get this removed again and do a secure inclusion properly. It does seem the security class wasn’t fully recognized as I had a question mark on the security section. Should have checked there. I just got excited since it seemed to show the correct name and such.
I just found something else that might be contributing to this with some permissions debacle in the Docker container. Seems they made some changes to the user it runs as. I’ll report back when I get some further testing.
This directly indicates that the binding thinks there are no secure classes supported, and given that door lock, and the code classes are only permitted in secure mode, this probably explains it.
Ok ya now I’m going nuts. I tried a few more times to include/exclude. I’m now I’m piling up useless devices that won’t go away in OH either. 
So I’ll send you the logs from the failure to secure include. Is there anything that could stick out as a reason for the lack of secure include? I want to say form my rudimentary view of the logs, that the node isn’t responding or sending the ACK in time?
Also - I notice that my device is being picked up as a YRD220 vs the YRD240 that it is. Likely not much too different, but is it possible that due to some device differences this is my issue? Do I need to share an XML to get it in the DB before it will recognize properly?
Send over the log and I’ll take a look. I doubt the device type matters - all the initialisation of security is done before the device type is known.