Z-Wave Frustration

[MWareman]

Hi Michel

 

 

 

Thanks for the response. The problem is that I can do dozens of Heal Network operations and all the devices seem respond just fine. Watching the event viewer doesn't indicate any failures during the Heal, though there can be some retries.

 

And everything looks good until I try to query a lock either programmatically or from the ISY Admin Console. Then I get the message "Cannot Communicate With ZW Lock (ZW000X_X). Please check connections." As long as the ISY doesn't do a Zwave query and only issues Lock/Unlock commands life is good. Of course the ISY does a query every night and that breaks everything, but I also want to do programatic queries at other times and they also break the Zwave connections to the locks.

 

 

 

 

I wasn't able to right mouse click "Z-Wave" in the menu and see the option to "Show Z-Wave Information in Event Viewer" (FYI I'm running 4.5.1). I assume that it is the "Zwave" in the menu bar, or is it a different object? Either way, I think the ISY is Z-Wave node #1 because I can see all the others devices have number 2 through 9, which leads me to believe that the ISY is #1.

 

Any other suggestions? If I have to exclude every lock and then include them again I will, but because the locks are all mounted now, dragging the ISY close enough to them for a secure enroll will be a challenge. Or can the ISY be further away and enroll remotely the second time?

 

Thanks

Eric

I had *exactly* this problem using repeater devices that claimed to do security and beaming when in reality they couldn't do secure beaming... (Except in my case the lock and unlock commands also failed most of the time)

 

As soon as I added some Aeon 'Sirens' to replace the junk Aeon 'Repeaters' my locks started working properly.

[vjk]

 

Hi Michel

 

Ummm... That makes sense as the problem doing queries seems to only affect the locks, but it does affect them all regardless of location or neighbors. 

 

Is there any way to wake battery powered devices up without sending a lock or unlock command? The whole reason I installed Zwave locks was to be able to monitor their status remotely. Basically I'm trying to determine which locks are unlocked prior to someone leaving an area on the property or arming the area the locks are part of. I also want to poll the locks battery status regularly and trigger a service alert if the batteries are low. I tried to use something like a 'Synchronize Clock' command just before the Query. Unfortunately the 'Synchronize Clock' command seems to execute without any errors in Event Viewer, but any Query following immediately errors out about 90% of the time (I have attached a copy of a typical Event Viewer log showing first a Sync Clock followed immediately by a Query that fails). Why the query seems to work 10% of the time is also a mystery to me.

 

Does the setting "Automatically put battery devices back to sleep" have any impact on this? I currently have that set to 'No' as an attempt to find a solution, but I wasn't sure how much impact that would have on the batteries. 

 

Finally, I currently have the default ISY program 'Query All' running at 3:00 am. However I think it is playing havoc with the locks. Is that likely? 

 

Thanks

Eric

 

I do not know much about how ISY handles locks, but I can say this:  a lock always sleeps and wakes up periodically, I believe once a second, to listen for so called beaming command which is nothing more but a string of hex 0x55 lasting slightly longer than a second. So, any command directed at a lock has to wake it up first . E.g.

 

Controller 13 to lock 11:

 

  7 2016-08-19T15:01:50.640571 01037408 13 11 (10) 0301 8f  -43  6

  8 2016-08-19T15:01:50.667501 55 11  -43  0

  9 2016-08-19T15:01:50.671546 55 11  -43  4

 10 2016-08-19T15:01:50.676515 55 11  -43  0

 11 2016-08-19T15:01:50.680562 55 11  -43  1

 12 2016-08-19T15:01:50.685848 55 11  -43  2

...

  2 2016-08-19T15:01:51.817551 55 11  -44  0

  3 2016-08-19T15:01:51.825529 01037408 13 11 (20) 4106 9880f747ac7f6f9a842ff1  -43  2

  4 2016-08-19T15:01:51.830563 01037408 11 13 (10) 0306 88  -78 12

 

The controller here "beams" at the lock for about 1.1 sec and then sends a secure command.  So, any interaction with a lock assumes that the lock is asleep even when in fact it is awake.  You cannot force a battery device to stay constantly awake unless you bombard it with some command once a second.  Maybe less frequently,  I do not know how soon a battery device goes to sleep.  I'd imagine immediately in order to conserve the battery.

[vjk]

The controller here "beams" at the lock for about 1.1 sec and then sends a secure command.  So, any interaction with a lock assumes that the lock is asleep even when in fact it is awake.  You cannot force a battery device to stay constantly awake unless you bombard it with some command once a second.  Maybe less frequently,  I do not know how soon a battery device goes to sleep.  I'd imagine immediately in order to conserve the battery.

"any interaction" means *any* exchange with a lock is preceded by "beaming" including query status commands, not only lock/unlock.  So, to diagnose what is wrong with your locks, you'd need a sniffer to see where the problem lies.  Perhaps, the lock simply ignores the status commands, who knows.  Btw, you do not need to query a lock for its status -- it should be transmitted by the lock upon the software/manual status change to the controller with which the lock is associated.  The status can sometimes be lost if the communication path is not good enough.  I saw that happening with my zwave thermostats, but it may as well happen with locks.

[Michel Kohanim]

PLCGuy,

 

The main question is: why do you have to keep querying them? ISY does retry the query for devices that are asleep but is this really a hard requirement? You are simply going to drain their batteries. i.e. can you ALWAYS and reliably do the following?

1. Lock

2. Unlock

3. Have the correct status in the Admin Console when someone locks/unlocks the door at the door

 

 

With kind regards,

Michel

[PLCGuy]

Hi Michel

 

Fair question... Actually I don't want to keep querying the locks, I just want the status in the ISY (and by extension, the ELK alarm system) to be accurate when someone or the system looks at the status of the home. And using this, some of the tasks I want to achieve are:

 

1) Automatically lock doors that are secure (i.e. not violated according to the ELK alarm system), not jammed and have no nearby motion when the area alarm is being set. Use Case: It is night, someone forgot to lock the shop, no one is in it and the homeowner wants to set the alarm to Stay from their bedside without going out in the rain.

2) Disarm the alarm for an area when someone unlocks the corresponding lock using the keypad (i.e. using the same code as the alarm disarm code). Use Case: If someone knows the lock code then there is little point forcing them to take the extra step to also disarm using the same code.

3) Have the nearest camera send the homeowner an email with a photo of the person near the door if a door is unlocked. Use Case: Advising the  homeowner who has entered the home (usually a tradesperson). 

4) Provide a remote whole house status view showing lock and door status for every zone, motion and cameras on one screen.

5) Send a warning to the alarm keypad if a lock is jammed or is locked with the door open.

6) Send a warning to the alarm keypad if a lock has a low battery

 

Interestingly #2 works reliably, but was harder to do than expected (there doesn't seem to be a way to tell if someone has unlocked a lock externally using the keypad or internally with the manual deadbolt). All the others tasks seem to be hit and miss. For example, the whole house view is accurate about 75% of the time. And it doesn't seem to matter which lock is being "queried" - all fail at some point to be accurate - even the one with a Aeon Siren only a few feet away.

 

What has me puzzled is what I should do to determine if the problem is really is the comms path and if so, improve the network. Since I have the Aeon 'Sirens' I can move them around to experiment. And I have the Leviton Vizia RF+ Tool to help with troubleshooting, but I really am feeling like I am lacking a good plan of action so I can be efficient in my troubleshooting. Right now everything seems like a shot in the dark. For example, maybe one of the powered nodes is unreliable and thus is causing the other nodes to occasionally lose comms links. I just don't know how to tell.

 

So troubleshooting suggestions are greatly appreciated. And I'll be happy to send a lock if that would help.

 

Thanks

Eric

 

[vjk]

 

Right now everything seems like a shot in the dark. For example, maybe one of the powered nodes is unreliable and thus is causing the other nodes to occasionally lose comms links. I just don't know how to tell.

 

You have to know the actual path a zwave frame takes to travel from point A to point B and the signal strength at each re-transmitter/zwave node point to figure out what may be broken if your queries go unanswered.

 

Unfortunately, Sigma offers no troubleshooting tools to the end user at a reasonable price.  One could get an RF sniffer from sigma by signing an NDA and paying $1,000 fee. Neither is there any diagnostic information provided by the zwave protocol itself. So, yes, with zwave, the end user  is doomed to groping in the darkness, more or less.

[Michel Kohanim]

Hi PLCGuy,

 

Thank you. Did you always have the same 75% hit/miss or did it start happening after you introduced queries? Please note that some locks (specifically Schlage) have a 10-15 second timeout from one command to the other (they call it a security feature alas it's beyond my comprehension). So, if these problems started happening after the introduction of queries, then it's the queries that are causing the issue.

 

With kind regards,

Michel

[PLCGuy]

Please note that some locks (specifically Schlage) have a 10-15 second timeout from one command to the other (they call it a security feature alas it's beyond my comprehension). So, if these problems started happening after the introduction of queries, then it's the queries that are causing the issue.

That is interesting. That might be the case because for some of those use cases I am current doing multiple actions as fast as the ISY will execute them. I'll set up a test this week with variable times between the query and next action and see if there is a correlation. I'll let you know what I find.

 

Regards

Eric