Qolsys Security Panel as Secondary Z-Wave Controller

I've been reading through the forums and it appears that Indigo does not currently support secondary controllers in a Z-Wave network. Being new to Z-Wave, but a long time user of Indigo, I had no idea this would be an issue. Now I'm stuck with a large investment in equipment that doesn't work together. So the purpose of this post is twofold:

1) Confirm that Indigo does not support secondary Z-Wave controllers in the network (for what I'm trying to do)
2) Figure out a fix or workaround for my scenario, even if I have to write a script or plug-in

My wife and I recently moved to a new home and so I am starting over with home automation here. I began with X10 many (many!) years ago and most recently had over 100 Insteon devices in our previous home, all controlled with Indigo. I decided to move to Z-Wave for this home and have purchased about 15 modules so far, most of which are light switches (dimmers and on/off relays). I also purchased 2 Kwikset 916 deadbolts. These all work great with Indigo so far. For security, I went with a Qolsys IQ Panel 2, partly because it also supports Z-Wave automation.

My goal is pretty straight forward. I'd like the bulk of the home automation controlled with Indigo. I've acquired many ideas and scripts over the years and would like to continue to use them. I'd also like to control a few of the same lights and the same locks from the Qolsys Panel. The panel provides a secondary connection out of the home via cellular so if the Internet goes offline for some reason, I could still be notified of events such as the back door being unlocked, etc. It also provides a backup inbound connection for checking status and controlling devices. For example, when we come home at night, I'd like to press a single button on my iPhone that will activate a scene to disarm the security system, unlock 2 locks, turn on a few lights if it's night time, etc. The home is pretty remote and I'm told the Internet goes out pretty often in the area.

So here's the problem. In order to make all this work, the Qolsys controller must be learned into the network as a secondary controller, with Indigo as the primary controller. This somewhat works for lights that do not use encryption, but does not work for the locks that have been learned using encryption. This is consistent with information in a previous post from Matt.

After learning the Qolsys panel into the network, the lights can then be controlled via Indigo and/or via the Qolsys panel. However, as Matt stated, status and triggers are not handled properly between the controllers. I can probably find a workaround for these issues. The larger problem though is that the locks do not work at all. When learning the Quolsys panel into the network, it responds with: "Pass non-secure node paired process, but fail during secure node paired process – Status code: 518". I have confirmed with the security company that the issue is a failure of secure enrollment for the locks.

I can post more technical details, logs, etc., but before going down that road, I wanted to know if anybody thinks a workaround can be created. Or is this lack of support for secondary controllers something that can't be worked around?

Thanks!

I’m replying just to follow the topic.

I’m the most experienced Zwave plugin developer here, beyond Matt and Jay themselves, so interested in thinking about this over a period of time.

Waiting for Matt/Jays responses.

Oeter


Sent from my iPhone using Tapatalk Pro

[matt (support)]

What steps did you perform when including the Qolsys as a secondary controller? Have you tried using Indigo's option to include with encryption?

Yes, I tried both with encryption enabled and without. Also, the Indigo server and Qolsys Panel were about 1 foot apart from each other. After lots of experimentation and working with the security company, I setup a very simple test to isolate the issue. I started from scratch with a new Z-Wave network created using Indigo (excluded all devices and reset the Z-Wave interface). The only node on the network was Indigo, no other modules. I then tried to add the Qolsys Panel with encryption enable (Interfaces -> Z-Wave -> Start Controller Inclusion Mode with Encryption). I then started the Add Controller process on the Qolsys Panel. Here is exactly what happens:

Qolsys Panel:
Controller Add/Remove
Processing Controller Add/Remove please wait…

The Indigo logs (with debug enabled) show what appears to be a successful inclusion with encryption key exchange. This was a quick process:

Code: Select all

May 10, 2018 at 11:26:44 AM
   Z-Wave Debug                    SENT enterInclusionMode: 01 04 00 4A C1 70
   Z-Wave Debug                    RCVD enterInclusionMode: 06 (ACK)
   Z-Wave                          started controller inclusion mode with encryption
   Z-Wave Debug                    RCVD inclusionMode ready: 01 07 00 4A 01 01 00 00 B2

May 10, 2018 at 11:27:01 AM
   Z-Wave Debug                    RCVD inclusionMode node found: 01 07 00 4A 01 02 00 00 B1
   Z-Wave Debug                    RCVD inclusionMode adding controller: 01 16 00 4A 01 04 02 0F 02 02 00 5E 72 98 21 86 85 59 22 73 5A 56 EF D6
   Z-Wave Debug                    RCVD inclusionMode node added: 01 07 00 4A 01 05 02 00 B4
   Z-Wave Debug                    SENT exitInclusionMode: 01 04 00 4A 05 B4
   Z-Wave Debug                    RCVD exitInclusionMode: 06 (ACK)
   Z-Wave Debug                    RCVD inclusionMode finished: 01 07 00 4A 01 06 02 00 B7
   Z-Wave Debug                    SENT getNodeProtocolInfo: 01 04 00 41 02 B8
   Z-Wave Debug                    RCVD getNodeProtocolInfo: 01 09 01 41 D3 96 01 02 02 00 F2
   Z-Wave Debug                    . .  getNodeProtocolInfo:       node 002, class name: Static Controller
   Z-Wave Debug                    . .  getNodeProtocolInfo:            class hierarchy: Static Controller : Static Controller : -- (02 : 02 : 00)
   Z-Wave Debug                    . .  getNodeProtocolInfo:         base class command: 00
   Z-Wave Debug                    . .  getNodeProtocolInfo:   supported class commands: 20
   Z-Wave Debug                    . .  getNodeProtocolInfo:     encrypt class commands:
   Z-Wave Debug                    . .  getNodeProtocolInfo:                   features: beaming
   Z-Wave                          controller included module: 002 - Static Controller
   Z-Wave                          querying module for encryption support
   Z-Wave Debug                    SENT requestSecuritySchemes: 01 0A 00 13 02 03 98 04 00 25 F5 AB
   Z-Wave Debug                    RCVD requestSecuritySchemes: 01 09 00 04 00 02 03 98 05 00 6E
   Z-Wave Debug                    . .  requestSecuritySchemes: node 002, schemeIndex 0
   Z-Wave                          starting encryption key exchange with module
   Z-Wave Debug                    SENT nonceRequest: 01 09 00 13 02 02 98 40 25 F6 EE
   Z-Wave Debug                    RCVD nonceReport: node 002, nonce 62 88 80 FE 64 4D 02 52
   Z-Wave Debug                    SENT setNetworkSecurityKey: ** ** ** ** (encrypted)
   Z-Wave Debug                    RCVD nonceFetch: node 002
   Z-Wave Debug                    SENT nonceReport: 01 11 00 13 02 0A 98 80 5E 74 A9 A2 10 1D A7 1C 25 F8 A7
   Z-Wave Debug                    RCVD encryptedPacket: 00 98 07 (decrypted)
   Z-Wave Debug                    RCVD keyVerify: 01 08 00 04 00 02 02 98 07 FF
   Z-Wave                          completed encryption key exchange with module
   Z-Wave                          stopped controller inclusion mode


Qolsys Panel:
Adding Devices from Primary
Please Wait while adding new devices…

The Indigo logs show the Qolsys Panel sending a query of some sort 3 times approximately every 55 seconds that Indigo does not respond to:

Code: Select all

May 10, 2018 at 11:27:19 AM
   Z-Wave Debug                    RCVD requestReply1: 01 08 00 04 00 02 02 72 04 85 (hex)

May 10, 2018 at 11:28:13 AM
   Z-Wave Debug                    RCVD requestReply1: 01 08 00 04 00 02 02 72 04 85 (hex)

May 10, 2018 at 11:29:10 AM
   Z-Wave Debug                    RCVD requestReply1: 01 08 00 04 00 02 02 86 11 64 (hex)


Then there's a 4th query that Indigo does not respond to:

Code: Select all

May 10, 2018 at 11:30:04 AM
   Z-Wave Debug                    RCVD basicGetState: 01 08 00 04 00 02 02 20 02 D1
   Z-Wave Debug                    . .  basicGetState: node 002, endpoint None


After this, the following message displays on the Qolsys Panel:

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

After completing this process, I then sync from Indigo:

Code: Select all

May 10, 2018 at 11:35:51 AM
   Z-Wave Debug                    intiatingSyncUI (timeout in 1500 seconds)
   Z-Wave                          Syncing - started for "002 - Static Controller"
   Z-Wave Debug                    SENT getNodeNeighbors: 01 06 00 80 02 01 01 7B
   Z-Wave Debug                    RCVD getNodeNeighbors: 01 20 01 80 01 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 5F
   Z-Wave Debug                    . .  getNodeNeighbors: nodeId 002, neighbors: 1
   Z-Wave                          Syncing - retrieved module neighbors list: 1
   Z-Wave Debug                    SENT requestNodeInfo: 01 06 00 60 02 24 F9 46
   Z-Wave Debug                    RCVD nodeInfoFrame: 01 15 00 49 84 02 0F 02 02 00 5E 72 98 21 86 85 59 22 73 5A 56 EF 57
   Z-Wave Debug                    . .  nodeInfoFrame: node 002, combined class list: 20v1 21v1 22v1 85v1 86v1 72v1 73v1 56v1 98v1 59v1 5Av1 5Ev1
   Z-Wave Debug                    SENT nonceRequest: 01 09 00 13 02 02 98 40 25 FA E2
   Z-Wave Debug                    RCVD nonceReport: node 002, nonce 76 2D 28 40 51 B3 AD 8B
   Z-Wave Debug                    SENT requestEncryptedCmdClasses: 98 02 (encrypted)
   Z-Wave Debug                    RCVD nonceReport: node 002, nonce 6B 17 6F 09 74 B9 90 9F (saving)
   Z-Wave Debug                    timeout waiting for reply from module (non-fatal, skipping request)
   Z-Wave Debug                    SENT requestManufactureInfo: 01 09 00 13 02 02 72 04 25 FC 4A
   Z-Wave Debug                    RCVD requestManufactureInfo: 01 0E 00 04 00 02 08 72 05 01 2A 00 01 00 02 A0
   Z-Wave Debug                    . .  requestManufactureInfo: node 002, manufacturerId 012A, productId 00010002
   Z-Wave Debug                    . .  requestManufactureInfo: Unknown, Static Controller
   Z-Wave                          Syncing - retrieved manufacture and model names: Unknown - 012A, Static Controller - 00010002
   Z-Wave Debug                    SENT requestVersInfoGen: 01 09 00 13 02 02 86 11 25 FD AA
   Z-Wave Debug                    RCVD requestVersInfoGen: 01 11 00 04 00 02 0B 86 12 01 04 18 04 18 01 01 02 00 74
   Z-Wave Debug                    . .  requestVersInfoGen: node 002, protoVers 4.24, appVers 4.24
   Z-Wave                          Syncing - retrieved protocol version 4.24, app version 4.24
   Z-Wave                          Syncing - retrieved class hierarchy: Static Controller : Static Controller : -- (02 : 02 : 00, base 00)
   Z-Wave                          Syncing - retrieved command classes: 20v1 21v1 22v1 85v1 86v1 72v1 73v1 56v1 98v1 59v1 5Av1 5Ev1
   Z-Wave                          Syncing - retrieved encrypt commands: - none -
   Z-Wave                          Syncing - retrieved capabilities: beaming, security
   Z-Wave Debug                    SENT requestAssociationGroupCount: 01 09 00 13 02 02 85 05 25 FE BE
   Z-Wave Debug                    RCVD requestAssociationGroupCount: 01 09 00 04 00 02 03 85 06 01 71
   Z-Wave Debug                    . .  requestAssociationGroupCount: node 002, group count: 1
   Z-Wave Debug                    SENT requestAssociations: 01 0A 00 13 02 03 85 02 01 25 FF BB
   Z-Wave Debug                    RCVD requestAssociations: 01 0B 00 04 00 02 05 85 03 01 05 00 75
   Z-Wave Debug                    . .  requestAssociations: node 002, group: 1, num associations: 0, max associations: 5, replies left: 0
   Z-Wave Debug                    . .  requestAssociations: node 002, group: 1, associations: []
   Z-Wave                          Syncing - retrieved group 1 associations: []
   Z-Wave Debug                    SENT addInterfaceAssociation: 01 0B 00 13 02 04 85 01 01 01 25 01 41
   Z-Wave                          Syncing - added group 1 association to interface
   Z-Wave Debug                    . .  addInterfaceAssociation: node 002, group: 1, associations: [1]
   Z-Wave                          Syncing - created device "002 - Static Controller"
   Z-Wave                          Syncing - complete
   Z-Wave Debug                    terminatingSyncUI


At this point, each controller has the other listed as a device. In this test though, there were no other devices included other than the two controllers. In prior tests, other devices added in Indigo would show up in the Qolsys Panel as well. Light switches (unencrypted) defined in Indigo would show up in the Qolsys Panel and could be controlled as expected. However, if a light switch was turned on or off via Indigo, the Qolsys Panel would not get that trigger. Conversely, if a light switch was turned on or off via the Qolsys Panel, Indigo would not get that trigger either. Locks (encrypted) defined in Indigo would also show up in the Qolsys Panel, but could not be controlled at all, nor could the panel obtain status. Any devices later added in Indigo would not automatically propagate to the Qolsys Panel.

Any thoughts? Does anybody know what the queries are that Indigo is not responding to?

The Indigo logs show the Qolsys Panel sending a query of some sort 3 times approximately every 55 seconds that Indigo does not respond to:

May 10, 2018 at 11:27:19 AM
Z-Wave Debug RCVD requestReply1: 01 08 00 04 00 02 02 72 04 85 (hex) Node 2 (Qolsys) asking Indigo a Manufacturer_Specific Question

May 10, 2018 at 11:28:13 AM
Z-Wave Debug RCVD requestReply1: 01 08 00 04 00 02 02 72 04 85 (hex) Node 2 (Qolsys) asking Indigo a Manufacturer_Specific Question

May 10, 2018 at 11:29:10 AM
Z-Wave Debug RCVD requestReply1: 01 08 00 04 00 02 02 86 11 64 (hex) Node 2 (Qolsys) asking Indigo what Version it is

Then there's a 4th query that Indigo does not respond to:

May 10, 2018 at 11:30:04 AM
Z-Wave Debug RCVD basicGetState: 01 08 00 04 00 02 02 20 02 D1 Node 2 (Qolsys) asking Indigo if it is turned On or Off
Z-Wave Debug . . basicGetState: node 002, endpoint None

We could feasibly respond to the Version question - we know the correct response for that.

We've no way of knowing what Manufacturer_Specific question Qolsys is asking unless it's own docs explain this.

I suspect the reason it is asking the 4th question is because it hasn't received a Version response which tells it that Indigo is a Controller - so it's therefore presuming you're including a ZWave module, not controller, and is thus seeking it's on/off state.

Matt, are you happy for me to advise a 72 05 response to the Version Get, to see if Qolsys responds further? (We can temporarily do this as a Zwave received Trigger with Zwave Raw action if you agree?)

Peter

Ok, I've spoken with Matt offline.

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

Report back with logs on that.

Thanks for the followup, howartp. Unfortunately though, I'm out of town for a week. As soon as I get back home I'll try the trigger and report back with the results and logs.

That’s fine.

I’m busy as well so replies will be sporadic.


Sent from my iPhone using Tapatalk Pro

Concerning the first query, this is Qolsys' explanation:

The IQ2 is sending a MANUFACTURER_SPECIFIC_GET. The device should respond with MANUFACTURER_SPECIFIC_REPORT according to Z-Wave specifications.

Manufacturer Specific Report Command
COMMAND_CLASS_MANUFACTURER_SPECIFIC 0x72
MANUFACTURER_SPECIFIC_REPORT 0x05
7 6 5 4 3 2 1 0
Command Class = COMMAND_CLASS_MANUFACTURER_SPECIFIC
Command = MANUFACTURER_SPECIFIC_REPORT
Manufacturer ID 1
Manufacturer ID 2
Product Type ID 1
Product Type ID 2
Product ID 1
Product ID 2

Manufacturer ID (16 bits)
display as: HEX
Product Type ID (16 bits)
display as: HEX
Product ID (16 bits)
display as: HEX

Would it be worth trying to come up with a response for that query?

Concerning the first query, this is Qolsys' explanation:

The IQ2 is sending a MANUFACTURER_SPECIFIC_GET. The device should respond with MANUFACTURER_SPECIFIC_REPORT according to Z-Wave specifications.

Would it be worth trying to come up with a response for that query?

Ah, I presumed Manufacturer_Specific was "Specific to the manufacturer to do what they like". Not, "what Manufacturer ID and product is it?"

I need to know what ZWave USB stick you have; I've got the relevant IDs for some manufacturers and sticks, and also better ideas of the raw zwave response I gave you last night now I've found similar documents.

Peter

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.

HomeSeer HS3 Home Automation Software is Z-Wave+ certified even though it is software. The product data XML file shows:

<ManufacturerId>0x000C</ManufacturerId>
<ProductTypeId>0x0001</ProductTypeId>
<ProductId>0x0003</ProductId>

So when using HS3 with the SmartStick+, the Manufacture ID of 0x000C (HomeSeer) would be used. This would be true even if the software was used with another brand of hardware USB stick. I can't find where Indigo has an assigned Manufacture ID.

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?

Keep in mind that while I've learned a lot in the last couple of months, I'm a total newbie when it comes to Z-Wave. I've been experimenting, reading protocol specification documentation and header files, but the information above should not be considered completely reliable.

[jay (support)]

This would be true even if the software was used with another brand of hardware USB stick. I can't find where Indigo has an assigned Manufacture ID.

Nope. Only Z-Wave hardware is assigned/uses a Manufacturer ID. HomeSeer's ID is assigned because they OEM hardware from another manufacturer but sell it under the HomeSeer brand (so their manufacturer ID is used). Also, their HomeSeer controller hardware will use it's Z-Wave Manufacturer ID because it's hardware (and has the Z-Wave interface built-in).

Software doesn't get a Z-Wave Manufacturer ID because it uses someone else's hardware. Well, I suppose if the software gets certified they may get a Manufacturer ID from Sigma, but it's not used for anything because only hardware needs to report those IDs.

At least, that's my understanding.

Correct, Jay.

I’ll create those responses tonight.


Sent from my iPhone using Tapatalk Pro

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

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?

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.