Z-Wave sniffer?

[pete_c]

The only latency I generally see is when my server is under load and it takes a second or two to process the commands

 
I see this too with Homeseer but not with the OPII panel (but the events / triggers are less and simpler on the OPII). 
 
This is why I mention analog / wire sensors a bunch.  I mean every piece between the topology of the "controller" and the "automated" device is just another thing that can get disconnected or cause latency.  
 
I do a multievent / trigger weather picture which is comprised of Homeseer weather station variables, NOAA maps, HTML captures and CCTV captures which can be dependant on the state of the internet concurrent with other events.  I try to space them such that they do not run in sync; but it does happen and it does slow things down.

 

[vc1234]

I'm not sure how you are sending the commands. But, if it's something that's not just blindly sending commands, i.e. it's waiting for acknowledgements of the commands to complete (which is the safe thing to do), and your Z-Wave communications is iffy, either to those particular modules or in general, the sender may be trying it a few times until gets a positive response before sending the next one (or perhaps before giving up if it took longer still.)

Well, it's sort of obvious how I send the commands from the elk rule above, no ? 
 
Assuming the communication with Light1 is bad and with Light 2 is good, the delay would always occur with Light1 only, but it shifts depending on the order in which the commands are sent to the lights.
 
Someone mentioned locks.  The delays with locks are expected due to the beast nature.  But not with lights, though.  Again, there is no way to figure out where exactly the delay occurs because Sigma in int infinite proprietary wisdom did not provide even very rudimentary tools to troubleshoot zwave installation.

 

[vc1234]

One or two or three seconds delay would have me driving in to a dark garage.

Quite.

 

[vc1234]

As soon as I open either door the light turns on (almost) immediately - provided a small amount of latency between the control recognizing the door opened (mag. gap), running the rules, and sending the signal to turn the light on.

Likewise with *one* light.  But when I execute the second command from the same rule, it's delayed by 2 secs.

 

[Dean Roddey]

Well, it's sort of obvious how I send the commands from the elk rule above, no ? 

 
I'm not getting paid so I didn't read the whole thread.
 

Assuming the communication with Light1 is bad and with Light 2 is good, the delay would always occur with Light1 only, but it shifts depending on the order in which the commands are sent to the lights.

 
That assumes that the issue is only with a given module. That's not always the case. Z-Wave is a mesh network and messages flow around via other modules. But it's not unusual for there to be random delays on occasion, or for the network quality to vary over time as well, for who knows what reasons. If you are also trying to poll modules for status, then any of them being iffy will increase latency for all other polled modules. Or if it happens to be the one through which other modules' messages are being routed.

 

[pete_c]

@Simon
 
Have you considered a Leviton  / Elk combo panel?
 
Here utilize both Homeseer and the Leviton HAI panel. 
 
Recently have upgraded my UPB switches to dual load / multipaddle to reduce of the footprint on the numbers of switches.

 

[vc1234]

Just experimented with three different (from the original 2) zwave lights:
 
whenever Task
  then turn on L1
  then turn on L2
  then turn on L3
 
The pattern remains the same: L1 no pause, L2 about 2 sec delay, L3 about another 2 sec delay. Actually, it's slighly less than 2, maybe 1.6 sec.  In any case, the pause is cumulative: the more lights you have to turn on the longer you will wait for the last light.
 
I am aware of "scenes", but for two lights it's an overkill.
 
I have an ancient HA07 that does *not* exhibit that sort of behavior: I pressed two buttons in a rapid succession and there was no delay betwee L1 and L2. So, apparently some Elk module introduces the odd delay, but you never know since you do not have any tool to confirm or disprove that theory !

 

[sda]

As another experiment, try:
 
whenever task
  then turn on L1
 
whenever task
  then turn on L2
 
It shouldn't make a difference, but you never know.

 

[vc1234]

As another experiment, try:
 
whenever task
  then turn on L1
 
whenever task
  then turn on L2
 
It shouldn't make a difference, but you never know.

It does not -- I already tried it, it's fully equivalent in its behavior to multiple 'then's.

 

[Dean Roddey]

I have an ancient HA07 that does *not* exhibit that sort of behavior: I pressed two buttons in a rapid succession and there was no delay betwee L1 and L2. So, apparently some Elk module introduces the odd delay, but you never know since you do not have any tool to confirm or disprove that theory !

 
Those types of devices are very simplistic. Probably all they do is send and pray a few times without making any attempt to verify the success of the operation.

 

[drvnbysound]

Those types of devices are very simplistic. Probably all they do is send and pray a few times without making any attempt to verify the success of the operation.

 
I don't know.... I have recently observed the serial communication out of the M1XSLZW (Elk to Zwave translator board)... and the [ASCII] message it sends to Lock/Unlock a deadbolt is only provided once to the VRC0P. I didn't bother checking to see what it sends for lighting commands, but I would suspect that it would be the same.

 

[vc1234]

Those types of devices are very simplistic. Probably all they do is send and pray a few times without making any attempt to verify the success of the operation.

Not really.
 
My device shows "Success" or "Failure" upon each button press which indicates it probably gets an acknowledgement packet in the first  case and a timeout in the second (when trying to access a node that does not exist any more).

 

[vc1234]

I don't know.... I have recently observed the serial communication out of the M1XSLZW (Elk to Zwave translator board)... and the [ASCII] message it sends to Lock/Unlock a deadbolt is only provided once to the VRC0P. I didn't bother checking to see what it sends for lighting commands, but I would suspect that it would be the same.

It is possible that vrc0p+3 does wait for an acknowledgement zwave packet and subsequently sends <E000/<X000 back  to M1XSLZW. The latter may chose to ignore the status feedback which would make the zwave ack rather pointless.
 
Did you see <E000/<X000 strings from vrc0p when you captured serial port exchaange ?

 

[drvnbysound]

It is possible that vrc0p+3 does wait for an acknowledgement zwave packet and subsequently sends <E000/<X000 back  to M1XSLZW. The latter may chose to ignore the status feedback which would make the zwave ack rather pointless.
 
Did you see <E000/<X000 strings from vrc0p when you captured serial port exchaange ?

 
I don't recall specifically because I wasn't looking for that, but I believe I did...
 
All I did was connect a laptop to the M1XSLZW (opened a serial connection via Putty) and issued commands via Elk rules to ensure that ASCII commands were being sent by the XSLZW. Then I connected to the VRC0P and sent messages to it from the laptop... I was trying to troubleshoot a lock issue, which I still haven't resolved, then again I haven't spent a lot of time on it either. Ive got a single lock working without issues but haven't been able to get multiple working yet. Not a huge deal for me, but something that I will need to address sometime in the future.

 

[ddennerline]

OP: What kind of controller software did you use to install network? What Z-Wave devices (mfg and model) are being used. RFIT can diagnose flakey network nodes, but it only works with VRUSB.
 
VC: The delay between lighting commands is not specific to Z-Wave, but rather Elk limitation. Elk inserts a small timer between each light action. As you suggested, the only workaround is to create an area for two lights and name it "Outside Night." I have about the same size network as drvnbysound with only one major complaint relating to RFIT/VRC0P and area over-the-air synchronization. Z-Wave works fine for me.