That was quick, thanks! In case anybody is interested, here’s the thread on the Indigo forum:
I may have found a workaround. After initially including the IQ2 with encryption (failed attempt), simply re-include it a second time (don’t exclude first, just include a second time). This seems to work and allows the control of Z-Wave locks (and lights of course) from the IQ2 and the Indigo server. Additionally, with help I was able to create appropriate responses to the queries the IQ2 was sending to the Indigo server. It doesn’t appear these responses are necessary, but it does speed up the inclusion process.
There are still issues which I’m going to try to track down. Specifically, after some time, the locks quit working from the IQ2 panel, but continue to work fine from the Indigo server. This might be because of something I did when configuring the network overall, or it could be some other technical issue.
The one thing that makes me suspicious of the IQ2 is that even when I was previously controlling all of the Z-Wave devices from the IQ2 as the primary (only) controller, the locks would randomly stop working. I didn’t perform a controlled test so I can’t say for sure what the issue was.
Now that I better understand the issue and Z-Wave in general, I’m going to troubleshoot one variable at a time. To get started, I’m going to remove the Indigo server alltogether and control the Z-Wave devices solely from the IQ2. If any problems with the locks show up, it will be much easier to troubleshoot.
The one thing that makes me suspicious of the IQ2 is that even when I was previously controlling all of the Z-Wave devices from the IQ2 as the primary (only) controller, the locks would randomly stop working. I didn’t perform a controlled test so I can’t say for sure what the issue was.
Did you perform a network rediscovery after including all devices?
A network rediscovery will map routes for communication and is necessary for all non-NWI (network wide inclusion) devices like locks.
It is also extremely important to follow the proximity rule for locks. They must be learned into their primary controller within a few feet.
Did you perform a network rediscovery after including all devices?
Yes. After having issues, I tried multiple things including another rediscovery and even moving the panel to within a few feet of the problematic lock. What is strange is that things would work great for a day or so, then all of a sudden one of the locks would not unlock. Then from that point forward, it would have issues. Again though, it wasn’t a controlled test and I wasn’t really troubleshooting the setup since I considered it to be temporary.
It is also extremely important to follow the proximity rule for locks. They must be learned into their primary controller within a few feet.
Yes, did that as well. I learned early on that the panel needed to be close to the locks during inclusion.
Quick update. I excluded all of the Z-Wave devices from Indigo and started a new network from scratch using the IQ2. Indigo is no longer being used at all at this point so the IQ2 is the primary (only) controller. After including all devices and rediscovering the network a few times, the lights and locks all appeared to be working properly. (I was only about 1-2 feet away from each of the two locks during inclusion.)
Throughout the day yesterday, I occasionally locked or unlocked a door using alarm.com or the panel, to make sure things were working, and they were. So then my wife and I made a quick trip to the grocery store and when we returned, one of the 2 locks failed to unlock as part of a scene on alarm.com. Note that this lock (on the side door) is about 6’ away from the panel, but around a corner. The lock that unlocked successfully is further outside of the side door by about 10’ on an unattached garage door.
So then my wife and I made a quick trip to the grocery store and when we returned, one of the 2 locks failed to unlock as part of a scene on alarm.com. Note that this lock (on the side door) is about 6′ away from the panel, but around a corner. The lock that unlocked successfully is further outside of the side door by about 10′ on an unattached garage door.
This is not indicative of the same issue as before. The locks do not show any malfunction and have completed secure enrollment so this is indicative of a missed command.
On the IQ Panel 2 there are some advanced diagnostics available under System Tests - Z-wave Tests. Under Counters do you see any in the Failed categories?
Failed Commands no ACK = 3.
Agreed that this is not indicative of the original issue. However, after getting past the original issue, this same thing started to happen which is why I moved all devices to the IQ2 and removed Indigo altogether. I’m going to run it this way for a few weeks to establish a baseline so when I them move the IQ2 back to being a secondary controller, it will be easier to troubleshoot failures.
In hindsight, I wish I would have thought to ask you to verify in the ADC logs that the security keys for the locks were installed properly after including the IQ2 as a secondary controller. If the logs are still available, could you check this? I successfully included the IQ2 as a secondary controller on Tuesday later in the morning (I think) central time. I was then able to control the locks both from the primary controller (Indigo) and from the IQ2. Thanks!
In hindsight, I wish I would have thought to ask you to verify in the ADC logs that the security keys for the locks were installed properly after including the IQ2 as a secondary controller. If the logs are still available, could you check this? I successfully included the IQ2 as a secondary controller on Tuesday later in the morning (I think) central time. I was then able to control the locks both from the primary controller (Indigo) and from the IQ2. Thanks!
We can only verify this in real-time with the current status. We cannot look to see the secure enrollment status of a different instance of a device after deletion.
Failed Commands no ACK = 3.
This means the panel sent commands to the device but the device did not acknowledge them. It may be influenced by power levels, so replacing the batteries may be a good test.
This is more of a normal Z-wave network error, in that it is going to typically happen here and there in most networks for one reason or another (moved devices, repeaters powered off, low power, etc.)