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

If you open a ticket on my website I’ll take a look - I’d avoid posting it publicly due to security issues.

I figured that was what you meant, but doubted it since it completely wipes your network.

This device only has the one channel, Barrier State (barrier_state).

It does sound like you are doing everything correctly. Others have had issue with secure inclusion, and have resorted to using other software for the secure inclusion. This also allows you to access your devices much easier, if they are already installed. If you look through this thread (it may take a few days :smile:), you will find them. Here’s a recent one:

It’s definitely worth investigating further, though. You may have found a new bug, or will be able to provide info that will fix the trouble others have had. Although, there seemed to be a possible correlation with having >20+ devices, so this sounds slightly different.

mkey … so I did it again.
Associations showing empty on UI.
Walked by sensor - triggered, nothing in logs.
Linked item to channel - nothing (probably not needed, but since associations were missing anyways).

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

1 Like

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.


Not sure how many other ways to say it - it IS securely included :wink: .

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?

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

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.

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

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

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.