Qolsys Security Panel as Secondary Z-Wave Controller

[jay (support)]

When would the Manufacture ID for HS3 software get used then? https://products.z-wavealliance.org/products/1310

Never - as I said, software that uses the Z-Wave Serial API (which is how everyone talks to the various USB dongles) never needs to reply with it's own manufacturer ID. They probably just put their ID there because they have one for their hardware.

Also, if the SmartStick+ is used with HS3 software, it would have a different feature set than if used on Indigo or some other software-based controller. How would a device or secondary controller know this if the Manufacture ID of the software isn't used? Is there some other provision in the specification for this?

If HomeSeer implements some custom classes in their controller (I'm not even sure that's possible) and doesn't publish that information then they would have access to those functions but nobody else would. I don't know of any functionality that the SmartStick has that's unique to HomeSeer or, for that matter, is different from any other USB Z-Wave interface that uses the same version of the Serial API.

Interesting enough, I found 2 other certified software controllers, ThinkEssentials and PyZW, and neither appear to have a Manufacture ID assigned to it. This supports Jay's comment that Software doesn't get a Manufacture ID.

Yep.

I'm using a HomeSeer SmartStick+

According to the product data XML file from https://products.z-wavealliance.org/products/1363:

<ManufacturerId>0x014F</ManufacturerId>
<ProductTypeId>0x</ProductTypeId>
<ProductId>0x</ProductId>

The Manufacture ID of 0x014F is actually for Nortek Security & Control LLC, who I am guessing manufactures the product since the Manufacture ID of HomeSeer is Ox000C.

So therefore, I believe our response should use a Manufacture ID of 0x014F and a Product Type ID of 0x0001 (Controller). However, I'm not sure what the Product ID should be. Would 0x0000 be appropriate? Or 0x0001?

Turn on Zwave debugging, then restart Zwave interface.

In the millennia of logs, you'll see:

Code: Select all

Z-Wave Debug                    SENT getInterfaceApiCapabilities: 01 03 00 07 FB
...
Z-Wave Debug                    . .  getInterfaceApiCapabilities: serialApi 3.07, manufactureId 0086, productType 0002, productId 0001

That's the values we need to use, so let me know those.

Peter

Code: Select all

Z-Wave Debug                    . .  getInterfaceApiCapabilities: serialApi 4.32, manufactureId 0000, productType 0001, productId 0001


Interesting that the Manufacture ID of 0x0000 is Sigma Designs. However, the very next line in the log is:

Code: Select all

 Z-Wave                          connected to Generic Controller interface on /dev/cu.usbmodem141111 (firmware 4.32)


This makes me think that Indigo had not yet communicated with the SmartStick+ when it logged the "getInterfaceApiCapabilities".

Here's the startup sequence in the log file:

Code: Select all

   Z-Wave                          connection reset requested
   Z-Wave Debug                    starting serial connection loop
   Z-Wave Debug                    starting zwave packet parser thread
   Z-Wave Debug                    SENT getVersion: 01 03 00 15 E9
   Z-Wave Debug                    RCVD getVersion: 01 10 01 15 5A 2D 57 61 76 65 20 34 2E 30 35 00 01 97
   Z-Wave Debug                    . .  getVersion: Z-Wave 4.05 static controller
   Z-Wave Debug                    SENT getHomeID: 01 03 00 20 DC
   Z-Wave Debug                    RCVD getHomeID: 01 08 01 20 C2 10 38 C6 01 FB
   Z-Wave Debug                    . .  getHomeID: C21038C6, nodeID: 001
   Z-Wave Debug                    SENT getInterfaceFeatures: 01 03 00 05 F9
   Z-Wave Debug                    RCVD getInterfaceFeatures: 01 04 01 05 18 E7
   Z-Wave Debug                    . .  getInterfaceFeatures: 18
   Z-Wave Debug                    SENT getInterfaceApiCapabilities: 01 03 00 07 FB
   Z-Wave Debug                    RCVD getInterfaceApiCapabilities: 01 2B 01 07 04 20 00 00 00 01 00 01 FE 81 FF 88 CF 1F 00 00 FB 9F 7D A0 67 00 80 80 00 80 86 00 00 00 E8 73 00 00 0E 00 00 60 00 00 03
   Z-Wave Debug                    . .  getInterfaceApiCapabilities: supportedFuncIDs: 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 1C 20 21 22 23 24 27 28 29 2A 2B 2C 2D 41 42 44 45 46 47 48 49 4A 4B 4C 4D 50 51 53 54 55 56 57 5E 60 61 62 63 66 67 78 80 90 92 93 98 B4 B6 B7 B8 B9 BA BD BE BF D2 D3 D4 EE EF
   Z-Wave Debug                    . .  getInterfaceApiCapabilities: serialApi 4.32, manufactureId 0000, productType 0001, productId 0001
   Z-Wave                          connected to Generic Controller interface on /dev/cu.usbmodem141111 (firmware 4.32)
   Z-Wave Debug                    SENT forceSUC: 01 05 00 54 01 01 AE
   Z-Wave Debug                    RCVD forceSUC: 01 04 01 54 01 AF
   Z-Wave Debug                    SENT getInitialNodeData: 01 03 00 02 FE
   Z-Wave Debug                    RCVD getInitialNodeData: 01 25 01 02 05 08 1D 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 00 CB
   Z-Wave Debug                    . .  getInitialNodeData: is static update controller
   Z-Wave Debug                    . .  getInitialNodeData: [1, 2, 3]
   <clip>


Do any of these responses sound appropriate?

Manufacture ID: 0x014F (Nortek Security & Control LLC)
01 09 72 05 01 4F 00 01 00 01 CE

Manufacture ID: 0x0000 (Sigma Designs)
01 09 72 05 00 00 00 01 00 01 80

Manufacture ID: 0x000C (HomeSeer Technologies)
01 09 72 05 00 0C 00 01 00 01 8C

I calculated the checksums manually, so hopefully I got it right.

You’re enjoying this aren’t you?

Very close, if not correct, however you don’t need to worry about 01 09 or the checksum.

Just create the Send Raw Zwave action/trigger and put the 72 05 ... bit without the checksum. Indigo will handle the rest of the command.

Peter


Sent from my iPhone using Tapatalk Pro

You’re enjoying this aren’t you?

Yes! I retired last year after a career of tech jobs, the last of which was almost 23 years at a very large tech company. I've been looking for something "technical" to dive into and this might be it.

Very close, if not correct, however you don’t need to worry about 01 09 or the checksum.

Just create the Send Raw Zwave action/trigger and put the 72 05 ... bit without the checksum. Indigo will handle the rest of the command.

That makes it much easier. Thanks!

Going back to the version response...

Can you create an trigger on "ZWave Command Received": From: Node 2/Qolsys: Match Raw Packet: * 0x02 0x02 0x86 0x11 *

For the action, set it to ZWave > "Send Raw ZWave": To: Node 2/Qolsys: Payload: 0x86 0x12 0x02 0x02 0x4E 0x02 0x00

This is how I'm interpreting the response:

Code: Select all

86      COMMAND_CLASS_VERSION
12      VERSION_REPORT
02      Z-Wave Library Type (Controller)
02 4E   Z-Wave Protocol Version and Sub Version (SDK Version 2.78)
02 00   Application Version and Sub Version (Indigo Version 2.0 )

Is this correct? If so, why would we report Indigo's version at 2.0? Maybe "Application" refers to something different?

Ok, I'm back home and ready to try the responses, but there's an issue with the logic right from the start.

Can you create an trigger on "ZWave Command Received": From: Node 2/Qolsys: Match Raw Packet: * 0x02 0x02 0x86 0x11 *

For the action, set it to ZWave > "Send Raw ZWave": To: Node 2/Qolsys: Payload: 0x86 0x12 0x02 0x02 0x4E 0x02 0x00

Node 2/Qolsys doesn't yet exist since these queries are sent during the inclusion process, so it's not possible to select the Qolsys panel in the "from" and "to" popups.

Really what we need to do is respond to any device asking these questions. It's been a while since I've written scripts, but I think a script knows which device caused a trigger to trip. If so, we can just respond to that device.

Right, we're gonna need a plugin for that.

Let me add it to one of my others for now, probably ZWave Scene Controller as it has the logic to do triggers already.

I'll post ASAP.


Sent from my iPad using Tapatalk Pro

Try https://www.dropbox.com/s/i3c5ktozgu4ef ... n.zip?dl=1

You don't need a Watcher device like the regular plugin, it's listening to node 2 for 86 11 or 72 04 queries all the time., and ready for more as we progress.

The indigo log will tell you when it sees and responds to those queries.

Peter

Thanks! Before I saw your post...

The good news: I was able to get the trigger working (without the plugin) by setting the "from" to be any Z-Wave device. Then for the action, I created a script that sent the raw command to a specific node. I could predict the node that the Qolsys controller would get during inclusion so I just used that node. Not ideal, but it worked for testing. I'm sure the plugin will work much better.

The bad news: After some tweaking of the responses, and adding another response for the Basic Get query, the Qolsys panel appeared to accept them. However, the end result was the same. From the Qolsys panel:

Added Devices from Primary
Pass non-secure node paired process, but fail during secure node paired process – Status code: 518

I don't have access to the Qolsys logs, but according to the security company, the (previous) logs indicate that the point of failure is passing of security keys. This leads me to believe that the problem actually occurred BEFORE any of the queries we've been discussing. Any thoughts here?

That makes sense.

Indigo supports encrypted inclusion, but only between itself and an included node.

It has no support for responding to a controller trying to include Indigo as a secondary device, so won’t even begin to support encryption.

We’ll have to do some reading around encryption, with Matt’s help, to see if it’s something we have any hope of achieving.

Peter


Sent from my iPhone using Tapatalk Pro

I stumbled across a solution completely by accident. Just by including the Qolsys panel a second time, everything works as expected, even the locks. Both Indigo and the Qolsys panel can control all of the Z-Wave devices (assuming they are compatible with the Qolsys panel). The query responses we created speed up the process, but otherwise, they are not necessary. Here's the sequence that appears to work:

1. Include devices on the Indigo server. This includes devices that do not use encryption and those that do (such as locks).
2. To add the Qolsys controller: Interfaces -> Z-Wave -> Start Controller Inclusion Mode with Encryption
3. Press "Add/Remove Controller" on the Qolsys panel.

After the process finishes, the error message displays on the Qolsys panel so include it again:

1. To add the Qolsys controller: Interfaces -> Z-Wave -> Start Controller Inclusion Mode with Encryption
2. Press "Add/Remove Controller" on the Qolsys panel.

This time the process succeeds. ??? Create a new device and sync:

1. File -> New Device
2. Select Z-Wave in the "Type" pop-up
3. The Node number for the controller automatically populates the "Sync using node" pop-up
4. Press the Sync button
5. Name the device "Qolsys Security Panel" or whatever you want

As an interesting side affect, you can include the Qolsys panel again to update the panel when new devices are added or removed from Indigo. At any point, just start the controller in inclusion mode with encryption and press the Add/Remove Controller on the Qolsys panel. Not sure if syncing is necessary again, but it works.

A remaining issue is that neither controller updates the other with device status. So for example, if a light is turned on from Indigo, the Qolsys panel doesn't know that the light is on until it eventually polls that light for status. The same is true for Indigo if the Qolsys panel turns on a light. I may start a new thread to better understand this issue.

I found the following in the Indigo 7 v7.0.0 Released posting:

Support for Z-Wave encryption communication. Note encryption security keys are negotiated during device network inclusion, so to enable you must exclude and then re-include the module using the New with Encryption Enabled button inside the define/sync dialog.

Matt or Jay (or anybody): It appears this re-inclusion is the key to getting the Qolsys controller included with encryption. Why is the 2nd inclusion necessary?

Here's a more complete list of what is working and not working.

• Indigo (primary controller) and the Qolsys IQ2 (secondary controller) can both control all of the Z-Wave devices.
• Device status is not communicated between the two controllers. This means the actual status of a device may be displayed incorrectly on one of the controllers until a polled update occurs. The exception though is that Indigo does get lock status when the IQ2 locks/unlocks a lock.
• After the successful re-inclusion, custom device names are not displayed in the IQ2. For example, if Z-Wave Node 5 is named "Kitchen Light" in Indigo, it will be named "Light5" on the IQ2. It can then be assigned a name in the IQ2.
• Changes to Indigo are not automatically propagated to the IQ2. For example, if a device is added or deleted in Indigo, that change is not automatically propagated to the IQ2. However, the list can be rebuilt with another re-inclusion. (see next bullet)
• When the IQ2 is re-included, the device list is NOT updated. Instead, all devices are deleted from the IQ2 and a new list is created. This means the list will now be updated with any devices added or deleted from Indigo, but it also means:
  
  • Custom names will have to be retyped for all devices.
  • Scenes still work, but are based on Z-Wave node numbers. So as long as the node numbers don't change (ex. Kitchen Light is still node 5), scenes still work. (Note that with my system, scenes are setup at alarm.com, not on the IQ2 panel itself.)

Here are some additional notes:

• In order to get the locks working properly with Indigo and the IQ2, all of the devices had to be very close to each other when the IQ2 was included (with encryption) into the network. I had all 4 devices (Indigo, IQ2 and 2 locks) all on the same table during the inclusion/re-inclusion.
• After starting from scratch 2 different times by excluding, including then re-including the IQ2, the locks eventually quit working both times from the IQ2 panel. They still worked fine from Indigo. I wasn't running a controlled test, but instead, actually configuring the network and devices. The point being that I don't know if this was some sort of issue with the locks or the IQ2 panel, or if it was something that I inadvertently broke during configuration. Either way, this setup does appear to be fragile in some way and it's possible that it does not work long term.

[jay (support)]

Support for Z-Wave encryption communication. Note encryption security keys are negotiated during device network inclusion, so to enable you must exclude and then re-include the module using the New with Encryption Enabled button inside the define/sync dialog.

Matt or Jay (or anybody): It appears this re-inclusion is the key to getting the Qolsys controller included with encryption. Why is the 2nd inclusion necessary?

In context, this means that if you have a device that you included without encryption, to enable encryption you have to exclude then include with encryption. There is no requirement for a 2nd inclusion if you included the device with encryption in the first place.

We don't support secondary controllers at the moment for a reason - we haven't worked through all the necessary requirements. You are running across just some of those requirements.

Hanns, it won’t be straight away but I’ll look at a plugin to help here somewhere.

Not sure if it will be a Qolsys or 2nd Controller plugin yet.


Sent from my iPhone using Tapatalk Pro