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

That would work for me, I’d definitely have no issues with parsing a string (I tried to find your old post on that but obviously didn’t look hard enough :wink: )

Thanks!!!

Ok, so can I ask you to open an issue on github, and provide at least one example receive message of this type. Given it’s probably encrypted, I really need the unencrypted version - this will start with SECURITY_RXD.

Not my post - but @5iver seems to be the (new :slight_smile: ) expert on the matter… See the following post -:

Happy to do it. Do I need to run in something other then DEBUG? I don’t see any messages like that, but I am seeing this which appears to be showing the userid (3) associated with the Type 19 Alarm Report (unlocked on keypad by userid):

2017-08-05 08:29:40.640 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 87: ALARM report - 19 = 3
2017-08-05 08:29:40.640 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 87: Alarm Type = null (19)

Debug should be fine. The message should be just before this. You should see the incoming message, followed by some security stuff, and in there somewhere just before the messages above should (I hope) be the decoded data.

Here is an unlock with keypad:

2017-08-05 10:42:03.954 [ZWaveNode                 ] - NODE 183: Decapsulating COMMAND_CLASS_SECURITY
2017-08-05 10:42:03.954 [ZWaveSecurityCommandClass ] - NODE 183: SECURITY_RXD 71 05 13 01 00 FF 06 06 01 01 
2017-08-05 10:42:03.954 [ZWaveNode                 ] - NODE 183: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2017-08-05 10:42:03.954 [ZWaveCommandClass         ] - NODE 183: Received COMMAND_CLASS_ALARM V3 NOTIFICATION_REPORT
2017-08-05 10:42:03.955 [ZWaveAlarmCommandClass    ] - NODE 183: NOTIFICATION report - 19 = 1, event=6, status=255, plen=1
2017-08-05 10:42:03.955 [ZWaveAlarmCommandClass    ] - NODE 183: Alarm Type = ACCESS_CONTROL (19)
2017-08-05 10:42:03.955 [ZWaveController           ] - Notifying event listeners: ZWaveAlarmValueEvent
2017-08-05 10:42:03.955 [ZWaveThingHandler         ] - NODE 183: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2017-08-05 10:42:03.955 [ZWaveThingHandler         ] - NODE 183: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2017-08-05 10:42:03.955 [ZWaveAlarmConverter       ] - Alarm converter processing NOTIFICATION
2017-08-05 10:42:03.955 [ZWaveAlarmConverter       ] - Alarm converter NOTIFICATION event is 6, type OnOffType
2017-08-05 10:42:03.955 [ZWaveAlarmConverter       ] - Alarm converter NOTIFICATION event is 6, channel alarm_general is not implemented.
2017-08-05 10:42:03.955 [ZWaveAlarmConverter       ] - Alarm converter processing NOTIFICATION
2017-08-05 10:42:03.955 [ZWaveAlarmConverter       ] - Alarm converter NOTIFICATION event is 6, type OnOffType
2017-08-05 10:42:03.955 [ZWaveThingHandler         ] - NODE 183: Updating channel state zwave:device:07cb40a2:node183:notification_access_control to 6 [DecimalType]
2017-08-05 10:42:03.960 [ZWaveAlarmConverter       ] - Alarm converter processing NOTIFICATION
2017-08-05 10:42:03.960 [ZWaveAlarmConverter       ] - Alarm converter NOTIFICATION event is 6, type DecimalType
2017-08-05 10:42:03.960 [ZWaveThingHandler         ] - NODE 183: Updating channel state zwave:device:07cb40a2:node183:alarm_number to 6 [DecimalType]
2017-08-05 10:42:03.966 [ZWaveTransactionManager   ] - NODE 183: Commands processed 1.

Side question: why are the alarm_number numbers different from the notification report numbers (21=1, 22=2, 18=5, 19=6, 26=11)?

Here you go: https://github.com/openhab/org.openhab.binding.zwave/issues/650

I included @5iver’s logs as well as what I think gives you the message received you are looking for. Let me know if you need add’l lines from the log.

Thanks!!

There are two different things - well, more even…

Firstly, there’s a difference between alarms and notifications. The (old) alarm command class just has a single alarm type. The notification command class has a notification type, and an event type (sort of a sub type). The notification command class also reports what’s called a V1 alarm type (so the old type) which is what is reported as 19 in the log above.

Depending on the type, it reports different things. In the alarm it reports the alarm type, and in the notification it reports the event.

SECURITY_RXD 71 05 13 01 00 FF 06 06 01 01 

In your log above, we have notification type 6, which is access control, and event type 6 which means keypad unlock, or we might have event 5 which is keypad lock (again, it’s an access control notification). In all with the notification class, there are around 150 event types…

So, I guess the convoluted answer is that we are ignoring the V1 event type and using the notification types in this example. The way the binding is written is it will try to use the highest version.

Thanks.

I see now! The event from my BE469 was alarm v3 (Received COMMAND_CLASS_ALARM V3 NOTIFICATION_REPORT), and the event from @rgerrans’ lock was alarm v1 (Received COMMAND_CLASS_ALARM V1 NOTIFICATION_REPORT). The 1.10 binding must have not used ALARMv3, since I was getting the alarm v1 reports and had to change my rules after moving to this binding. Which reminds me… I should post a topic on how I scraped the 1.10 binding log to get user codes.

@chris,

Could I request that these messages be changed to debug level in the next binding:

2017-08-05 11:54:30.578 [WARN ] [rialmessage.IsFailedNodeMessageClass] - NODE 80: Is currently marked as failed by the controller!

Sure - I’ve updated the code…

1 Like

Thank very much to all of your. I installed this binding. Here is the procedure

1, check the version. The binding-zwave - 2.2.0.SNAPSHOT.jar was installed with the openhab 2.2 snapshot. But it doesn’t support secure inclusion for locks.
user@server:~$ ssh -p 8101 openhab@localhost
openhab> bundle:list -s | grep zwave
186 | Active | 80 | 2.2.0.201708041402 | ZWave Binding | org.openhab.binding.zwave
2, uninstall the binding-zwave - 2.2.0.SNAPSHOT.jar at Paper UI / Add-ons / BINDINGS
3, downloaded this development binding-zwave - 2.1.0.SNAPSHOT.jar at this thread.
4, move the jar to the openhab server /etc/openhab2/ with samba

sudo systemctl stop openhab2.service
sudo mv /etc/openhab2/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar /usr/share/openhab2/addons
sudo chown -R openhab:openhab /usr/share/openhab2/addons/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar
sudo systemctl start openhab2.service

After restarting, openhab may install the binding-zwave by itself, and will show up at Paper UI / Configuration /Bindings. But it doesn’t show up at my situation.

5, Login the karaf terminal to check the version again. The status of 194 is Installed not Active.
user@server:~$ ssh -p 8101 openhab@localhost
openhab> bundle:list -s | grep zwave
194 | Installed | 80 | 2.1.0.201708041056 | ZWave Binding | org.openhab.binding.zwave

6, Try to start it manually, find the problem, and fix it.

openhab> bundle:start org.openhab.binding.zwave
Error executing command: Error executing command on bundles:
Error starting bundle 194: Could not resolve module: org.openhab.binding.zwave [194]
Unresolved requirement: Import-Package: gnu.io

openhab> feature:install openhab-transport-serial
openhab> bundle:start org.openhab.binding.zwave
openhab> bundle:list -s | grep zwave
194 | Active | 80 | 2.1.0.201708041056 | ZWave Binding | org.openhab.binding.zwave
openhab>

Take a look through the posts from the last day or so… starting from here…

How often is the database of zwave devices updated in the snapshot? I’ve got some devices that are in the database but aren’t being recognised by openhab.

osgi.identity=“org.openhab.binding.zwave”; type=“osgi.bundle”; version:Version=“2.1.0.201708041056”;

http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/653

NODE 16: Device discovery could not resolve to a thingType! 0118:0311:0103::2.36

Binding installed from the marketplace if that makes any difference?

I normally update the master every few days, but this branch every week or two. However as the date on the file shows, it was last updated yesterday.

Cool, so it should appear in the next version of the zwave binding binary that you release?

OK, I’ve been messing around with this for a while (months), and still haven’t gotten it working. Over the last few days I’ve made a big push, but no luck so far. So… looking for some help.

Basics:

  • Openhab 2.1.0 running on a Centos server. Updated this morning.
  • Zwave downloaded from the head of the thread today (0804 version) and installed and activated; other zwave bindings gone. A Network Security Key is set.

openhab> bundle:list | grep -i zw
217 | Active | 80 | 2.1.0.201708041056 | ZWave Binding

  • I have about 60 devices in the ZWave network. All the non-secure items work fine
  • I have a Kwiset 916 lock that I’m trying to get securely added. I’ve pulled it from the door, and it’s sitting about a foot from the USB ZWave controller, so range isn’t an issue.
  • I set debug logging for the zwave component: log:set DEBUG org.openhab.binding.zwave

So, what I’ve tried… Excluding the lock from the network, and then, via Habmin, putting the zwave controller in add mode. The device is found, but then the red ‘zwave.event.inclusion_securefailed’ box pops up. It’s identified as the 914TRL, which seems to be normal. The ‘Using Security’ Attribute is a red x. I’ve tried this about 10 times, including start/stop openhab, or let things sit to be as quiet as possible, or any other variations I can think of.

I have a debug trace, but it’s pretty long… if it’s helpful and someone can suggest a place to put it I can provide it.

I don’t know what else to try. Help, please?

Probably - this particular device has some issues that I need to resolve first, but it’s not too far away.

Fab, thanks. I’ve got four of them if you want any debugging outputs or anything.

I have the same lock and was able to get it included securely. I have a Aeon zstick and I think I did the inclusion directly with the stick vs. using Openhab. I had to drop it off my network yesterday so will be (hopefully) adding it back today so will try from Openhab and if that doesn’t work directly with the stick and will report back