Kwikset 910 Z-Wave Lock Issue

Good morning,

I have a Qolsys IQ Panel 2 and just signed up for your service. I have a Kwikset 910 smart lock that I am trying to install on the Qolsys IQ Panel 2 using your system.

I ran all the tests, watched your videos, cleared all Z-Wave devices on the Qolsys panel (SETTINGS à ADVANCED SETTINGSà à INSTALLATION àDEVICESà Z-WAVE DEVICESà CLEAR DEVICES (and pressed learn on the lock)). The Qolsys panel confirmed all was cleared. I then added the device under the same Z-Wave sub-menu (à ADD DEVICE à PAIR (and pressed learn on the lock)). All worked great and the lock was added. I ran a Z-Wave test on that specific lock and it said it “PASS” as well as other diagnostics to say the internal card is fine.

Nonetheless, on the main menu the battery has a “!” in it (the batteries are fine) and I get a notification that the lock is off-line. When I go to control it, I get a spinning circle and it comes after a while, yet nothing happens at the lock.

If I repeat the test, the lock yields a “PASS”. I looked at the detailed menu on Z-Wave devices and it shows the signal strength to that specific lock is excellent (green).

Can you please help me?
Many thanks!

Welcome to the forum, we are always happy to assist!

Records indicate that the Z-Wave Lock in question has not completed Secure Enrollment.

The lock will typically be found by the panel, populate status, etc., but secure enrollment issues will cause problems with remote control.

This issue is commonly caused by learning in the lock too far away from the primary controller. The locks are not NWI (network wide inclusion) devices, and must be paired to your system while within about 6 feet of the panel. As a battery powered device, the lock can be brought to the panel for this, or the panel can be moved to the lock. This is easier with some panels than others.

Did you learn in the lock within 6 feet of the panel? If not, I would recommend using the remove/clear device function with the lock, wait 5 minutes, then relearn the lock close by the panel. After pairing close-by, move the devices to their permanent locations and run a Network Rediscovery. (Settings -> Advanced Settings -> System Tests -> Z-Wave Tests -> Rediscover Network)

Hello!

I’m having a similar issue, but with a twist. My Qolsys IQ Panel 2 is a secondary controller in the Z-Wave network. I have 2 Kwikset 916 locks that are working perfectly with the primary controller (Indigo Domotics). Similar to Dexter’s issue though, the locks are showing up in the panel and pass the Z-Wave tests, but won’t lock/unlock or return a status. Here are a few questions:

When I learn the IQ2 panel as a secondary controller, it takes quite a while to complete the process, maybe 10-15 minutes. What exactly is it doing behind the scenes?

In Tyler’s previous post, as well as other posts I’ve found, the symptoms could indicate that there was a problem with secure enrollment. Do the locks get “re-enrolled” when the IQ2 panel is learned into the network? If so, do the locks need to be near the panel during this process?

Thanks for any assistance.

When I learn the IQ2 panel as a secondary controller, it takes quite a while to complete the process, maybe 10-15 minutes. What exactly is it doing behind the scenes?

When setting one controller as a secondary, the primary controller must pass node info to the primary. The controllers should be within a few feet of one another for this entire process.

Time will depend on the type and number of devices you have.

In Tyler’s previous post, as well as other posts I’ve found, the symptoms could indicate that there was a problem with secure enrollment. Do the locks get “re-enrolled” when the IQ2 panel is learned into the network? If so, do the locks need to be near the panel during this process?

The locks shouldn’t need to be, but the controllers do. Did you have those in close proximity?

The locks shouldn’t need to be, but the controllers do. Did you have those in close proximity?

Yes, the controllers were about 3 feet from each other.

Time will depend on the type and number of devices you have.

Currently there are 10 GE light switches (3 dimmer switches and 7 relay switches). These were all added into the network with encryption disabled. The 2 locks were added into the network with encryption enabled. The Qolsys controller was added with encryption enabled. Not sure if encryption was necessary for the Qolsys.

You cannot alter whether a device uses encryption or not with Z-wave during the learn process or by settings on the IQ Panel. Locks use encryption and share security keys for communication when learned in.

One thing you might try is learning the locks into the Qolsys Panel directly. Do you have an issue when this is done or do they function through ADC as expected? If they still show an issue, this may have more to do with the model of lock, although the 916 is listed as compatible.

You cannot alter whether a device uses encryption or not with Z-wave during the learn process or by settings on the IQ Panel.

Interesting. Since the IQ Panel is secondary, I haven’t learned anything directly using the panel. The Indigo server allows learning devices with or without encryption. I figured lights did not need encryption, but locks did. That seems like the correct decision since the IQ panel requires encryption for locks. I’ll experiment some with learning devices directly using the IQ panel and see if the locks function properly that way (as you suggested).

The process I’m using to make the IQ panel secondary is as follows:

  1. On the IQ panel, Z-Wave Settings -> Primary Controller is disabled
  2. Put the Indigo server in Inclusion Mode with encryption enabled.
  3. On the IQ panel, Adv Settings -> Installation -> Devices -> Z-Wave Devices -> Add/Remove Controller
  4. Once complete, press the Sync button on the Indigo server. This causes the exchange of neighbor node and other information between the two controllers (according to Indigo logs).

This process seems to work, but as I mentioned before, it takes quite a bit of time to complete. The other annoying thing is that I have to rename all of the devices both on the panel and then through alarm.com. The names assigned on the Indigo server do not transfer to the IQ panel.

Does this sound like the correct process for making the IQ panel secondary?

I’ve not used an Indigo Controller and could not cay with certainty the proper steps for it with regard to its settings, but overall the process you describe sounds fine.

If Indigo shares the device list (which will typically take a little while) that would indicate a success.

I would try defaulting the IQ Panel Z-wave network and just learn in the locks with nothing else. This is just to verify the locks alone will function with the panel.

I would try defaulting the IQ Panel Z-wave network and just learn in the locks with nothing else. This is just to verify the locks alone will function with the panel.

I did some experimenting yesterday and this morning. First, yes, the locks work fine when the IQ Panel is the primary controller for the Z-Wave network. Unfortunately, Indigo cannot be configured as a secondary controller so that’s not a permanent option, but it does prove that the locks are compatible with the IQ Panel.

From what I’ve been reading in other forums, Indigo doesn’t officially support secondary controllers, even though it seems to work. Here’s a pretty simple test that may shed some light. I excluded all Z-Wave devices from the network, then reset the Indigo controller all together, essentially starting from scratch. With no devices defined, I tried to learn the IQ Panel as a secondary controller with encryption enabled. Indigo and the IQ Panel were about 1 foot away from each other. Here are the results:

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

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

The Indigo logs show the IQ Panel sending a query of some sort approximately every 55 seconds that Indigo does not respond to. After 4 attempts, the following message displays on the IQ Panel:

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

The Indigo controller shows up as “Other Devices” type on the IQ Panel and the IQ Panel shows up as a “Static Controller” on the Indigo Server. Syncing appears to work, but not sure if the correct information is being synced. I’ve uploaded the Indigo log file with debug enabled. Is there someplace where I can see logs from the IQ Panel?

The next test will be to learn 1 or 2 devices (lights) with Indigo before learning the IQ Panel with Indigo. Lights work properly between the two controllers, except that the status does not immediately update. After that, I’ll add a lock and see what’s different.

What I’m trying to accomplish from a Z-Wave perspective is really two things:

  1. Control all Z-Wave devices using the Indigo server
  2. Control a few of the same lights and the same locks using the IQ Panel

Any thoughts on another way to accomplish this?

Thanks!

Lern-Controller-Log-File.txt (7.49 KB)

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

The Indigo logs show the IQ Panel sending a query of some sort approximately every 55 seconds that Indigo does not respond to. After 4 attempts, the following message displays on the IQ Panel:

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

I think the issue is explained here pretty succinctly. The Indigo is not responding to the IQ request for lock security keys.

Unencrypted devices will likely work, locks will not.

If Indigo does not support secondary controllers there would not be a work-around.

I think the issue is explained here pretty succinctly. The Indigo is not responding to the IQ request for lock security keys.

I’m a little confused at what’s going on. In this test, there were no locks. In fact, there were no devices defined at all, except for the controller itself (Indigo). According to the Indigo logs, the security keys (between the two controllers) were exchanged properly during the learn.

The IQ Panel displayed that it was “Adding Devices from Primary” right before it sent the queries. I assume the device it was adding is the Indigo controller itself since it was the only device defined. Do you know what specifically the query was for? Why would it be sending an additional query if the security keys were already exchanged?

I agree that the problem is likely with the Indigo server in that it doesn’t fully support secondary controllers. However, it’s very flexible in that it supports scripting and/or plug-ins. I’m just trying to fully understand the details of what is missing to see if it would be worth pursuing a workaround with code.

Thanks.

The IQ Panel displayed that it was “Adding Devices from Primary” right before it sent the queries. I assume the device it was adding is the Indigo controller itself since it was the only device defined. Do you know what specifically the query was for? Why would it be sending an additional query if the security keys were already exchanged?

The Qolsys panel was getting the device list from the Indigo. Whether or not the devices are there, it will still attempt this as it is a standard part of the process.

There is limited troubleshooting which can be done with the IQ. Logs on Z-wave specifically are not available on the panel, but one thing it does pass to the back-end is whether or not secure enrollment of the locks has been completed (passing security keys)

I cannot provide technical support for the Indigo, but I can say based on what has been tested and reported so far that the point of failure is absolutely passing of security keys. This is common if the controller manufacturer does not support multiple controller interaction.

You could learn in all of the appropriate devices into Indigo and watch the logs again during another pairing with the IQ Panel to check for lock specific activity. But I don’t think it is a matter of the Indigo not having nodes previously, and I would expect to see the same result where secure node enrollment fails. For some reason Indigo is not responding to the request.

According to the Indigo logs, the security keys (between the two controllers) were exchanged properly during the learn.

I’m not 100% on this, but I believe what you are seeing here is simply successful pairing specifically between the two controllers. They can speak to one another with encryption. This does not extend to the locks, which are shared with the controller after the initial connection.

Can you try to learn in all locks to the Indigo, connect to the IQ again, then leave them in the panel and let us know?

We can double check on the status on the back end and send a command in an attempt to poll the security keys. This works in some cases in a single controller environment. I am curious if it will prompt another request from the IQ and whether it may assist. Unlikely, but worth a shot.

Done. I learned 2 locks and 1 light, then learned the IQ Panel. Confirmed that the light works, but the locks do not at this point.

Alright, thank you. I can confirm that the issue reported on ADC is a failure of secure enrollment for the locks. I’ve sent commands to try to complete secure enrollment, but so far those have not succeeded. You might be able to see in Indigo logs if the Qolsys panel actually attempted again.

Oh well. I do see 2 queries in the logs, but not sure if they are relevant or not. I’m going to troubleshoot this from the Indigo side for a while and see if a workaround is possible. I’ll report back if/when I have something to report.

Thanks for all of your help!

Starting to troubleshoot this from the Indigo side using debug logs from the simple test environment described earlier. In this environment, there are no devices (no lights, not locks, etc.), just the Indigo server and the Qolsys IQ2. The debug logs are from learning the IQ2 as a secondary controller into the network with encryption enabled.

The IQ2 is sending a query that Indigo is not responding to. The specific query is:

01 08 00 04 00 02 02 72 04 85 (hex)

This appears to be a manufacture specific question.

Later there’s another query:

01 08 00 04 00 02 02 86 11 64 (hex)

This appears to be a version question that Indigo should be able to answer. Looking at how to create a workaround for this.

Then there’s a final query before failing:

01 08 00 04 00 02 02 20 02 D1 (hex)

This is asking if Indigo is on or off, probably because there were no responses to the other queries.

Is there any Qolsys documentation to research these queries? If not, is this the correct place to ask these questions or should I work with Qolsys directly? I’m initially interested in the first query, to find out what the IQ2 is asking.

Thanks.

Qolsys is not yet open today, (pacific time) but we are happy to forward the question. I have to say that the answer may not be what you’re looking for though, I’m not 100% sure how specific they’ll be able to be on this, but we’re happy to try.

As far as manufacturer goes, this would likely either be referencing devices being sent by the Primary controller, or the controller itself. The panel will request the manufacturer of each device to distinguish on the back-end.

The panel is seeking a Version of the controller, and yes, this should be something the controller can provide. I think this is likely the failure point. I don’t think the manufacturer question would cause the process to fail. The version question probably would.

We will forward any info Qolsys can provide.

Thanks, Warren. The first query is probably the IQ2 asking for the manufacture information of the Indigo “controller” and not about any devices (I don’t think) since none were learned in the Indigo server for this test.

I obtained a potential workaround for the version query from the Indigo forum, but unfortunately I’m out of town for a week. I’ll try the workaround when I’m back home. In the mean time I’d like to continue to gather any information I can.

It sure would be great if Qolsys would provide some technical documentation, even if it were unofficial, on the process of adding the IQ2 as a secondary controller. That would give us the best chance of creating a workaround, or a more permanent plugin.

Thanks again for your help and any information you can get from Qolsys.

Pretty quick response, here’s the info Qolsys has available on the manufacturer related query:

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