OH2 Z-Wave refactoring and testing... and SECURITY

Add-ons Bindings
,
2057

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.

door_controller_GD00Z-4
door_controller_GD00Z-4.png696×336 23.3 KB

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)

2058

That’s normal. Take a look at this thread:

2059

These are two different things (we’d need Chris to explain it properly). The green checkmark in Habmin means it is securely included. Wahoo!

2060

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?

2061

My node.xml is uploaded in the above post.

I expected to see:

2062

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.

2063

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.

image
image1746×650 29.1 KB

2064

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 :wink: .

2065

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 :slight_smile:

Maybe I could save the next guy a few headaches?

2066

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!

2067

OK. I’ll take your word for it :wink:

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.

2068

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 :slight_smile:

THanks again.

2069

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…

2070

So I guess all that we could propose is to a second channel -:

  • Channel 1 showing the position
  • Channel 2 showing the state

Is that what you’re expecting?

2071

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.

2072

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.

2073

@chris thank you for that. I don’t know that.:muscle:

2074

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!

1 Like
2075

That’s the reason it is so hard to find in the net :rofl:

2076

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 | 2.2.0.201711192127 | ZWave Binding

So sorry for our hours spent trying to fix it. and confused what has changed, why it’s working now :roll_eyes: