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!
I guess, have not had chance yet? Or did try to, but no luck? Nevertheless, I have some news. Got little longer time to play around today … out of curiosity inserted home assistant hass.io sd card into raspberry. Z-Wave controller stayed plugged in, untouched. Hass booted up, configured ZWave port and there were both binary sensors channels - reacting/showing the trigger state. Was little jealous, thought of coming back and asking if I can steal the debug info somehow so it would help.
So did insert back the old openhab card, booted it up. And getting both binary1 and binary2 events. No other changes done on openhab. Have had it restarted with system:shutdown numerous times.
And it is even not with the most-most recent debug versions (since I had it ‘downgraded’ last week)
219 | Active | 80 | 126.96.36.199711192127 | ZWave Binding
So sorry for our hours spent trying to fix it. and confused what has changed, why it’s working now