Yes, this yet another post about lock reliability.
I have 6 of them. There's a beaming GE dimmer near each one with a couple of more positioned to provide good communication to the locks that are farthest from the PC (Z-Stick). Everything looks good in Z-Seer and all of the locks pass the send and receive test.
The problem is not just that sometimes a command never gets to a lock, but that even if it does, the status information may not make it back to HS. So, the lock may get locked but the lock status value of 'On' and the alarm status of 'Locked by Z-Wave' never make it back. This is seldom a problem when I manually lock or unlock a lock. The status almost always updates immediately.
Also, I recently created an HS-Touch screen to control the locks. There are lock and unlock buttons for each lock as well as alarm status and battery status. And, there are 'Lock All' and 'Unlock All' buttons. If I press the lock all, most of the locks may lock but the alarm status rarely makes it back to HS. I even tried inserting a delay between the lock commands in the Action Editor window. I tried different amounts of delay from 1-5 seconds. It helped a little bit but it was still generally unreliable.
It sounds like a traffic problem to me. So, I have the following questions:
1) How can I manually route the Z-Wave communications? I suspect that some of the communication is being routed through locks to get to other locks. I would like to eliminate this and route all communications through the dimmers. Hopefully this would speed things up (sometimes locking occurs after a noticeable delay) as well as improve the reliability and the ability of the status values to make it back. I'm guessing that this is especially a problem when 'Lock All' is pressed and a lock is busy doing it's thing while some of the dimmers are polling it wanting to route traffic from another lock through it.
2) Are there any Z-Stick parameters that could be changed that might help with the throughput?
3) Does HS que incoming status responses sent from devices? HS spends a lot of time updating the log and telling me that a lock command didn't go through (sometimes even if it did go through) or that there was a delay. Could some of the device status responses be getting lost because HS is busy with other things when they come in?
I have 6 of them. There's a beaming GE dimmer near each one with a couple of more positioned to provide good communication to the locks that are farthest from the PC (Z-Stick). Everything looks good in Z-Seer and all of the locks pass the send and receive test.
The problem is not just that sometimes a command never gets to a lock, but that even if it does, the status information may not make it back to HS. So, the lock may get locked but the lock status value of 'On' and the alarm status of 'Locked by Z-Wave' never make it back. This is seldom a problem when I manually lock or unlock a lock. The status almost always updates immediately.
Also, I recently created an HS-Touch screen to control the locks. There are lock and unlock buttons for each lock as well as alarm status and battery status. And, there are 'Lock All' and 'Unlock All' buttons. If I press the lock all, most of the locks may lock but the alarm status rarely makes it back to HS. I even tried inserting a delay between the lock commands in the Action Editor window. I tried different amounts of delay from 1-5 seconds. It helped a little bit but it was still generally unreliable.
It sounds like a traffic problem to me. So, I have the following questions:
1) How can I manually route the Z-Wave communications? I suspect that some of the communication is being routed through locks to get to other locks. I would like to eliminate this and route all communications through the dimmers. Hopefully this would speed things up (sometimes locking occurs after a noticeable delay) as well as improve the reliability and the ability of the status values to make it back. I'm guessing that this is especially a problem when 'Lock All' is pressed and a lock is busy doing it's thing while some of the dimmers are polling it wanting to route traffic from another lock through it.
2) Are there any Z-Stick parameters that could be changed that might help with the throughput?
3) Does HS que incoming status responses sent from devices? HS spends a lot of time updating the log and telling me that a lock command didn't go through (sometimes even if it did go through) or that there was a delay. Could some of the device status responses be getting lost because HS is busy with other things when they come in?
Comment