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

shawnmix · April 14, 2017, 1:31pm

I will add, that I believe this is the reason I had so much trouble attempting to SECURE include a lock recently as well. The Stick didn’t properly include it the first attempt, and so subsequent attempts failed even though I “removed” the device. I found after finally resetting the Stick, that I was then able to SECURE include the lock. It’s an ugly annoying problem, but it comes with the world of “open source” and “roll your own” solutions since there isn’t licensing of ZWave specific protocols and such. If that were the case, I’m sure Chris would have basically avoided all the “testing” we’ve been doing. But it would have been at a cost.

shawnmix · April 14, 2017, 1:38pm

@chris I’m looking to test a new method for getting a secure inclusion going and wanted to run it by you/all, and validate my understanding. If I input the same key into ANY openHAB instance ZWave binding, I should be able to securely communicate with the SECURE included devices? Is there anything that needs to happen or be ported from install to the next, like the ZWave device XML’s or anything?

Goal: Get a secure inclusion completed with a zstick, through some sort of portable/remote device.

Rationale: I’ve got a server system in the basement, which runs my OH server. A server box with power and ethernet connections, isn’t really portable to allow inclusion of Security Class devices. I’d like to be able to pull the ZStick from the main OH system, plug it into a small portable board (Pi Zero, CHIP, Pine64, etc), and then use that mobile platform to get the ZStick to securely include the Security Class device.

What I’ve found is that if something comes up and causes an error, or if I decide to do some testing on items, or I happen to accidentally blow everything away on my system again (for whatever reason), I have to re-include these devices. It’s a hassle trying to figure out how to disassemble things like door locks to bring them down to the basement for inclusion, or my recent adventure with a Garage Opener which is soldered to the board for the garage opener, forcing me to disassemble the whole garage wall opener button and the controller, just to get it re-included.

chris · April 14, 2017, 1:46pm

I’m not really sure it’s that simple. We are (I believe) excluding devices properly in OH, but despite there being a certification scheme by the Alliance, I see a number of devices that are non-compliant (and that’s without looking hard!). The Alliance has confirmed this non-compliance on a number of occasions (even though they have certified the devices as compliant!). We have to work around these bugs in the binding, and this can be problematic with so many devices out there…

I have good contacts and regular communication with Sigma Designs and they are actually keen to help with OH (stay tuned on that one) and also have good contacts with a number of manufacturers.

There are still some uncertainties though and the Serial API will likely “never” be released, so we have to live with that (although there are different ways to live with it ;)).

Anyway…

Yes - in theory this should work, and I have tested this.

No - it’s in any case needed in the event that the XML file gets removed since then we don’t know if the device was securely included in the first case (note that there’s nothing secure in the XML - just some flags, but they allow me to know the startup condition).

whwkins · April 14, 2017, 1:51pm

Hi @Chris,

I see this new alarm_number channel and tried it out. I’ve removed my local hack to get door lock reporting to work and tried the alarm_number. I have also added the alarm_number to my lock’s thing definition and re-added it in paper UI to get it to show up. I think the alarm_number doesn’t report “unknown” alarm types. I have a rule that send a notification whenever the alarm_number channel receives an update. I only get type 0 updates (my lock seems to send that every 2 hours). But nothing for unlock for example. I see the following in the logs:

2017-04-14 08:30:17.458 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 20: ALARM report - 22 = 1
2017-04-14 08:30:17.459 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 20: Unknown Alarm Type = 22, ignoring report.

I had added the following to the kwikset_914trl_0_0.xml file:

      <channel id="alarm_number" typeId="alarm_number">
        <label>Alarm Number</label>
        <properties>
          <property name="binding:*:DecimalType">COMMAND_CLASS_ALARM</property>
        </properties>
      </channel>

Let me know if I’m doing something wrong or if something else needs changed locally for this to work.

Thanks.

chris · April 14, 2017, 1:56pm

Yes - it looks like you’re probably right. I’ll try and fix this today.

shawnmix · April 14, 2017, 2:00pm

Good to know. I figured it would make life easier, but didn’t realize there were that many devices that were just non-compliant, and known by the alliance! Thanks for trucking through it and continuing to fight the good fight!

Ok this is good to hear. I have a few CHIP devices that would be a perfect candidate to simply run a bare bones install on top of the usual CHIP OS that ships which is linux based. I may have to fight through some dependencies, but my alternative may be to just throw Docker on it so I can install the same container I have on my server. It may be the easier way for ANY various devices to do the same. I’ll report the findings back if they work properly for me, and put together a basic doc to go into the documentation on creating a portable device as I’m sure many other folks will be happy to have this possibility. I remember this was one of the main benefits to my old Vera Lite, portable battery powered secure inclusion.

chris · April 14, 2017, 2:03pm

Hmmm - maybe my comment was misinterpreted. I don’t think it’s “known” by the Alliance. However, when you ask them about a specific respond to a command that isn’t how I believe it should be from the docs, then they confirm that the device is responding incorrectly (non-compliantly). It kind of tells me their current compliance testing isn’t all it could be

shawnmix · April 14, 2017, 2:09pm

Ahhh ok, I get it now. Well either way, that’s hilarious and annoying at the same time. I can only imagine how many reports you make, with responses of the same nature. You probably already know when it’s coming before they respond, but you have to push it through to validate anyway. You sir, have a level of patience I likely won’t ever foster in my lifetime!

CodingHarry · April 14, 2017, 2:42pm

I just wanted to mention, great job on this binding chris.

THX

chris · April 14, 2017, 3:17pm

@whwkins can you provide me a couple of log entries showing received frames for the alarms that you want supported - I’ll just use this for my tests so I can (hopefully) be sure it does what you want .

whwkins · April 14, 2017, 3:33pm

Sure can. I have lock, unlock, outside lock and outside unlock logs, that good? There are two more lock/unlock alarms and some others I’d prolly make use of, if you’d want them to, let me know. How should I provide the log file?

chris · April 14, 2017, 3:45pm

Up to you - Just 2 or 3 different ones is probably fine. You can paste the lines here if you like - I just need the lines that looks like this -:

 14:23:06.808 [DEBUG] [rialHandler$ZWaveReceiveThread:314  ] - Receive Message = 01 04 01 13 01 E8

Edit: If you prefer to send me a longer log I’m happy to pull out the bits I need. You can either email it to me or add it to a ticket using the ticket system on my website.

whwkins · April 14, 2017, 3:57pm

I think these are the 4 correct lines:

Manual unlock

2017-04-14 11:26:40.664 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=20, callback=0, payload=00 14 18 98 81 8B 8A 7A 6B C6 E7 D3 0C 86 48 50 F2 62 3C 14 A9 01 5F 9F 6B AB ED
2017-04-14 11:26:40.679 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 20: ALARM report - 21 = 1

Manual Lock

2017-04-14 11:26:43.974 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=20, callback=0, payload=00 14 18 98 81 88 A4 F4 6F 9D 7B 6A 8E 1A F4 27 8F 0A 4C B2 E3 5D 40 05 06 64 55
2017-04-14 11:26:43.985 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 20: ALARM report - 22 = 1

Outside Lock

2017-04-14 11:26:49.212 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=20, callback=0, payload=00 14 18 98 81 18 C9 F6 1C 7F C7 92 6F 00 C7 B5 F1 9F 9C 25 1B 3F 5D CA 34 82 F4
2017-04-14 11:26:49.220 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 20: ALARM report - 18 = 0

Outside Unlock

2017-04-14 11:26:54.347 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=20, callback=0, payload=00 14 18 98 81 B0 8B C1 D1 24 37 1F 63 19 D4 27 DC 7B C7 8A 3D E2 F3 F3 9B 88 2A
2017-04-14 11:26:54.354 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 20: ALARM report - 19 = 1

whwkins · April 14, 2017, 4:04pm

Here again with the ZWaveReceiveThread log lines too.

I think these are the 4 correct lines:

Manual unlock

2017-04-14 11:26:40.624 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 1E 00 04 00 14 18 98 81 8B 8A 7A 6B C6 E7 D3 0C 86 48 50 F2 62 3C 14 A9 01 5F 9F 6B AB ED 7D
2017-04-14 11:26:40.664 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=20, callback=0, payload=00 14 18 98 81 8B 8A 7A 6B C6 E7 D3 0C 86 48 50 F2 62 3C 14 A9 01 5F 9F 6B AB ED
2017-04-14 11:26:40.679 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 20: ALARM report - 21 = 1

Manual Lock

2017-04-14 11:26:43.936 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 1E 00 04 00 14 18 98 81 88 A4 F4 6F 9D 7B 6A 8E 1A F4 27 8F 0A 4C B2 E3 5D 40 05 06 64 55 3B
2017-04-14 11:26:43.974 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=20, callback=0, payload=00 14 18 98 81 88 A4 F4 6F 9D 7B 6A 8E 1A F4 27 8F 0A 4C B2 E3 5D 40 05 06 64 55
2017-04-14 11:26:43.985 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 20: ALARM report - 22 = 1

Outside Lock

2017-04-14 11:26:49.188 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 1E 00 04 00 14 18 98 81 18 C9 F6 1C 7F C7 92 6F 00 C7 B5 F1 9F 9C 25 1B 3F 5D CA 34 82 F4 DA
2017-04-14 11:26:49.212 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=20, callback=0, payload=00 14 18 98 81 18 C9 F6 1C 7F C7 92 6F 00 C7 B5 F1 9F 9C 25 1B 3F 5D CA 34 82 F4
2017-04-14 11:26:49.220 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 20: ALARM report - 18 = 0

Outside Unlock

2017-04-14 11:26:54.328 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 1E 00 04 00 14 18 98 81 B0 8B C1 D1 24 37 1F 63 19 D4 27 DC 7B C7 8A 3D E2 F3 F3 9B 88 2A 52
2017-04-14 11:26:54.347 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=20, callback=0, payload=00 14 18 98 81 B0 8B C1 D1 24 37 1F 63 19 D4 27 DC 7B C7 8A 3D E2 F3 F3 9B 88 2A
2017-04-14 11:26:54.354 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 20: ALARM report - 19 = 1

chris · April 14, 2017, 4:15pm

Ooops - my bad. I forgot these are secured .

Instead I need the unencrypted versions which should show up in the log a few lines further down starting with the text…

NODE 20: SECURITY_RXD .....

Sorry about the misguidance…

whwkins · April 14, 2017, 4:42pm

Hehe, no problem. I submitted the log as a ticket on your site.

Thanks!

chris · April 14, 2017, 4:53pm

Thanks.

chris · April 15, 2017, 10:57am

I’ve just updated the JAR - this version has a number of changes -:

A fix in the database exporter that properly exports command class properties. This only affects a small number of devices but means that where there are device bugs that we use a database configuration property to work around it, these weren’t exported correctly.
A fix to the “Unknown Device” problem - hopefully now devices will show up correctly in the inbox once the manufacturer information is known.
Updates to the way multi-channel and multi-instance data is handled. This might impact some devices that use multiple endpoints - the main change is only during the device initialisation so it shouldn’t impact the actual use of a device.
Updates to the alarm_number channel to support a readback of the alarm code.

Let me know if there are any issues

01av · April 15, 2017, 11:59am

Great!
I tried the last version, and I’m getting just ‘1’ (or ON) returned from alarm_number…
NODE 31: Updating channel state zwave:device:15a000f2f47:node31:alarm_number to ON [OnOffType]

Something with my setup or the binding?

chris · April 15, 2017, 12:17pm

Plea provide the log so I can see what’s happening and what alarm you’re actually receiving.