Ok, so one good thing is that this is consistent with what I see here - I assumed I just didn’t have the configuration correct.
I will have another play over the next day or two and see what I can find. I’ve now tried a number different things so I don’t know what this device needs to trigger MC associations - it doesn’t seem to be compliant to the standard 
.
I just decided to punt - I did a reset on the z-stick. A reset on the door controller. I did a clean install of the latest snapshot, installed the secure zwave binding and managed to get it to show as secure. I think I probably had the door controller all whacked from including/excluding a zillion times.
BUT - it’s still not showing me any channels except Barrier State. So, progress of a sort… but still not quite there. Now what do I look for? I should be seeing a bunch of alarms, a way to open/close the door, etc.
THe png above shows security as true, which disagrees with the node XML. I have to agree with the xml here… as I don’t have channels.
network_cd7e559a__node_2.xml (8.3 KB)
That’s normal. Take a look at this thread:
These are two different things (we’d need Chris to explain it properly). The green checkmark in Habmin means it is securely included. Wahoo!
I’ve not seen your XML so hard to comment on what you’re talking about? Can you post it please? If it’s listing the secure command classes, then it has security.
In general, the green checkmark in HABmin is a pretty good indicator that it’s securely included. IF you want to be sure, then look in the logs.
What channels are you expecting to see that are missing?
My node.xml is uploaded in the above post.
I expected to see:
I’m confident @walterj means this <security>false</security>.
Those were channels someone had added in error, and they have been removed. It is explained somewhere in that thread. Here.
So the XML confirms that the device is securely included.
So, I don’t know what this says, but as has been said a couple of times, there is only 1 channel.
Ok, ignore this - it is not related to the secure inclusion. The XML shows that it is using secure command classes.
<secureCommandClasses>
<commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
<commandClass>COMMAND_CLASS_BARRIER_OPERATOR</commandClass>
<commandClass>COMMAND_CLASS_ALARM</commandClass>
<commandClass>COMMAND_CLASS_APPLICATION_STATUS</commandClass>
<commandClass>COMMAND_CLASS_ASSOCIATION_GRP_INFO</commandClass>
<commandClass>COMMAND_CLASS_VERSION</commandClass>
</secureCommandClasses>
Not sure how many other ways to say it - it IS securely included 
.
So, if I’m reading that correctly - I have to decode/encode a bitmask to control the garage door? I was hoping for something a little less self obfuscating - but I will give it a try over the holiday weekend I guess. I’m all out of cycles today. That image in the post I liked above though, looks like what other hubs see… so when did it get bounced down to a bit array? Firmware changes?
Is there an interface in the device recognition code where I could implement a class that would be loaded to break these out into individual alerts/status/switch channels? I only like to have to swim upstream once 
Maybe I could save the next guy a few headaches?
The device only provides barrier_state. No need to bloat the binding with more channels… just add items and rules to display the data to your liking!
OK. I’ll take your word for it 
Thanks (to everyone involved) for taking the time to reply. If it’s only got one channel… I’ll bit bang it as per the other thread and move on to the next thing that comes in the mail.
I hear you on the efficiency part - but it’s the sort of thing that APIs are designed to hide. I have to assume there are eventually going to be folks who don’t write code for a living wanting to control their garage door. Having to write up lamdas in Xtend might be a bit much. But, I’ve got it sorted out now for myself, anyway
THanks again.
I’ve not looked in detail at the Barrier state so I’ll take a look, but if there are multiple bits of information that make sense to break out, then I would agree that they should be. I’ll take a look at the command class…
So I guess all that we could propose is to a second channel -:
Is that what you’re expecting?
If there isn’t more than my expectation of a single door opener model that happens to use an overloaded byte as a state for all communication then I guess I wouldn’t worry too much about appeasement.
Most of my expectation was set by a one pic that supposedly was working but it was an older model from an openhab 1.x binding showing all those channels.
Long/short… don’t let my misunderstanding make work for you. I can make it work for me as-is. I’m sure you have bigger fish to fry. If I get to feeling punchy maybe I’ll take a stab at understanding the code well enough to try it myself.
Just confirming that these steps work perfectly for my Danalock V3, except that the Zensys controller didn’t let me change its security (a “resmissing received” error??) so instead I copied the Zensys security code into Habmin.
I sometimes get this too, but it usually works fine on the second try. The first time I tried putting in the key, I couldn’t get it to work at all. There seemed to be a trick to pasting it in… when pasting, delete the 00 and leave the whitespace at the end. Shutting the app down, pulling the stick, and starting over helps too, for a lot of things. Zensys Tools definitely has some bugs!
That’s the reason it is so hard to find in the net 
