Z-Wave sniffer?

[simonmason]

I am trying to find a bad module in my house that is causing other lights to go on and off.  I have been spending weeks disabling modules and waiting to see what happens, etc. but this is starting to get really annoying.  It occurs to me that there has to be a way to install a sniffing device that can tell me where the command is coming from so I can start to zero in on the bad module?  Does anyone have any experience with this?  Thanks.

 

[macromark]

such a thing does exist but it's part of the development kit and involves running a modified controller with licensed software (Zniffer).  Looks something like this: https://www.youtube.com/watch?v=zwPCj_ab6CA

 

[simonmason]

So how does one get their hands on this?  I have heard that it is expensive.  However what is the cost of going through my house and shutting off over 50 z-wave modules and waiting to see if anything goes wrong?

 

[macromark]

http://z-wave.sigmadesigns.com/dev_kits

 

[drvnbysound]

What is your setup?
 
I've yet to need to use it, but I think the Leviton RFIT (when used with their VRUSB-1US) provides some tools to help troubleshoot network issues...

 

[simonmason]

I downloaded it and took a look around.  It certainly looks interesting but can't get it working without their USB stick.  I also couldn't find much in the way of documentation.  Has anyone had any experience with it?

 

[vc1234]

The lack of basic troubleshooting tools for zwave, similar to ping, traceroute, tcpdump, at this time and age is scandalous.
 
I made a huge mistake of going with zwave about 5-7 years ago. Now, I have about a dozen switches and three zwave thermostats that are performing acceptably being controlled from elk m1. However, I had to resort to rather silly hacks to make it all work, more or less.  For example, originally, my thrermostats lost commands about once every two-three days per each unit, as in you send a setpoint and it's silently ignored. Based on this forum recommendations, I created a rule to send a command twice, and reliability improved dramatically (the command is lost "only" once or twice a year, the last loss occured today.  That's not a solution though, but a terrible and unreliable hack for something as important as controlling a heating system. Moreover, it's simply impossible to know for sure where the data loss occurred due to the total lack of troubleshooting tools mentioned above and not help at all by the equally mediocre elk zwave controller.  You can try and play with placing multiple intermediary routing nodes, for example, but there is simply no objective way to know if your fumbling with multiple zwave gizmo is helping or harming your "mesh' network.
 
 
There are numerous problems with light contol, such as delaying zwave commands by about 2 secs in a sequence, or lack of instant feedback due to the crazy Lutron patent.
 
 
I hope zwave will die a horrible death very soon so that it would save tons of aggravation to potential unsuspecting users.
 
Today, I'd probably go with UPB or maybe RR2 for lighting. Not sure about thremostats and locks though.

 

[simonmason]

I tend to agree with you.  Like many I started with a large X-10 network.  I still have a few switches left over in non-important locations (using an XTB which is rock solid).  Then I began the switch to UPB - which worked nicely and I still run some devices.  But the cost was eye-popping and the industrial design of the devices left a lot to be desired - after all, don't you want your automated house to look sharp!  Then I was lured into z-wave with the promise of lower cost and a much broader selection of devices.  And now I find myself back in the X-10 days - one device has gone rogue and is wreaking havoc on my network - and there is no way to find it!  I am a man on a mission now - I will find a way to diagnose this issue and share it with the community.

 

[drvnbysound]

I currently have ~25 devices on my Zwave network including dimmers, receptacles, switches, a deadbolt and a thermostat and haven't had any issues. I've also setup 2 other networks, neither of which has as many devices; one has 4 devices (2 receptacles, a thermostat, and a deadbolt) and the other also has 4 devices currently (2 receptacles, 1 dimmer, and 1 switch). None of these networks have any any issues. I believe I started purchasing and setting up my network in 2012 and have obviously expanded it quite a bit since then.

 

[vc1234]

I currently have ~25 devices on my Zwave network including dimmers, receptacles, switches, a deadbolt and a thermostat and haven't had any issues. I've also setup 2 other networks, neither of which has as many devices; one has 4 devices (2 receptacles, a thermostat, and a deadbolt) and the other also has 4 devices currently (2 receptacles, 1 dimmer, and 1 switch). None of these networks have any any issues. I believe I started purchasing and setting up my network in 2012 and have obviously expanded it quite a bit since then.

Well, you must be in a lucky minority then since at least three more people reported the same problem with the thermostat losing a setpoint command: http://cocoontech.com/forums/topic/25616-tz45-ignoring-setpoints-from-elk/
 
Another irritating example is, as I mentioned earlier, an unexplainable delay in a sequence of two zwave commands:
 
whenever motion1 and dark outside
  then turn flood lights
  then turn garage lights
 
The second command is apparently executed about 2 seconds after the first one judging by when actual lights turn on.  If I swap the lines in the rule, the picture is also reversed.  Having some sort of sniffer, would at least show immediately what is the culprit in this sort of behavior.

 

[drvnbysound]

Well, you must be in a lucky minority then since at least three more people reported the same problem with the thermostat losing a setpoint command: http://cocoontech.com/forums/topic/25616-tz45-ignoring-setpoints-from-elk/
 
Another irritating example is, as I mentioned earlier, an unexplainable delay in a sequence of two zwave commands:
 
whenever motion1 and dark outside
  then turn flood lights
  then turn garage lights
 
The second command is apparently executed about 2 seconds after the first one judging by when actual lights turn on.  If I swap the lines in the rule, the picture is also reversed.  Having some sort of sniffer, would at least show immediately what is the culprit in this sort of behavior.

 
I'll admit that I have not issued any setpoint commands via Elk to date, but rather primarily use it for standard temperature monitoring for now and just have Elk send me emails in over/under conditions (ie my HVAC unit has an issue). I have used the connectivity (via eKeypad) to alter the current setting to trigger the system to turn on, which I know worked but I never monitored how long that setting remained, as I do utilize the thermostat's internal programming.
 
I too have a few rules that are setup to turn on multiple lights (e.g. each of my front yard flood lights) at sunset. I've honestly never been outside to monitor if there is any delay in them turning on... but I know they are both on when I get home and it's after sunset  Honestly, I would understand if there is a small delay because the messages to take some time to propagate through the network; for instance when I issue the command to lock/unlock my deadbolt it does take a second or two before the lock responds. Similarly, I have a rule set that when the deadbolt is locked it will turn off my foyer light; again there is a small delay between when I manually lock the deadbolt and when that light is turned off. I don't have any issue with the small delays, as long as I'm not actually missing commands and devices aren't responding at all. Sure if it took 3-5 minutes for a light to come on... yeah, I'd have some issues with that and call it unusable, but for what the power of automation can provide me... I'll give it a 2-3s delay as opposed to me having to manually control all of those lights. Quite simply, I'd forget to turn some of them on/off fairly often, which is why I automated them in the first place.

 

[Dean Roddey]

Another irritating example is, as I mentioned earlier, an unexplainable delay in a sequence of two zwave commands:

 
whenever motion1 and dark outside
  then turn flood lights
  then turn garage lights
 
The second command is apparently executed about 2 seconds after the first one judging by when actual lights turn on.  If I swap the lines in the rule, the picture is also reversed.  Having some sort of sniffer, would at least show immediately what is the culprit in this sort of behavior.

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

 

[pete_c]

Here I have a few garage UPB controlled lights going on before I go in to the garage. 
 
That said  I make it daylight and I expect it to be that way before I go into the garage. One or two or three seconds delay would have me driving in to a dark garage.
 
I don't really pay much attention these days. 

 

[drvnbysound]

Here I have a few garage UPB controlled lights going on before I go in to the garage. 
 
That said  I make it daylight and I expect it to be that way before I go into the garage. One or two or three seconds delay would have me driving in to a dark garage.
 
I don't really pay much attention these days. 

 
I have my garage light to turn on automatically if either entry door into the garage (from the home) are opened, if it's dark out... or anytime the garage door is closed. 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. Basically, as I'm opening the door to go out, I see the light turn on.  The light will also turn on if motion in the garage is detected and it's dark out, or if the GD is close (same as above). I don't see any latency there, but it's also a single rule firing off a door contact or motion which provide reliable triggers...

 

[simonmason]

I don't see much latency in my system - except when the pesky bad module acts up.  The only latency I generally see is when my server is under load and it takes a second or two to process the commands.  Unrelated to the bad module I do see random disconnects with z-wave devices around the house.  They will suddenly show up as unknown status in Homeseer.  It doesn't happen very often - and it doesn't really impact much as this state will clear out when they transmit the next time, or Homeseer sends them a command.  The only downside to this is that I use MainLobby on my touchscreens and the way I have these modules displayed results in an ON status when it is unknown.  Unfortunately I have not figured out how to get MainLobby to recognize three states - ON, OFF and UNKNOWN.  I am toying with writing a script to check module status every so often and re-polling any module that reports UNKNOWN.