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.
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
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
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…
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!