Zwave experiments

[vc1234]

So, while trying to figure out thermostat unreliability, I finally put together an inexpensive (about $15) zwave sniffer. Also, tapping into the serial connection between elk zwave board and vrc0p.
 
I found out that my zwave uses two data rates: 9.6K with older wallplates and 40K with the newer thermostats and the coffee machine 20A wallplate. Lock communication is in fact encrypted and the locks react pretty quickly to beaming packets.
 
I also confirmed general Zwave implementation awfulness. 
 
E.g. almost immediately upon using the sniffer, I discovered that my two thermostats tried to communicate through a non-existent node ID which I moved to a new location in December of the last year thus getting a new node id.  Of course, I "rebuilt" routes using the Leviton stick in Dec, but apparently the "healing" did not cure anything. Now, that I knew about a wrongheaded routing attempts, I could remove the routes to a non-existent id from both thermostats (using the Leviton poor excuse for software).
 
Typical trace:
 
1458526080039 Preamble found Device ID : 13 Dest ID : 17
1458526080099 Preamble found Device ID : 13 Dest ID : 17
1458526080161 Preamble found Device ID : 17 Dest ID : 13
1458526080226 Preamble found Device ID : 13 Dest ID : 4
1458526080295 Preamble found Device ID : 4 Dest ID : 17
1458526080301 Preamble found Device ID : 13 Dest ID : 4
 
VRC0P (id 13) sends two identical packets to node 17 (a wallplate) 60ms apart, maybe due to a timeout.  Node 17 replies directly, but then node 13 send a packet via node 4 (a thermostat) which is located farther from node 17) than the controller itself.
 
Interestingly, despite the incorrect routing tables on two thermostats,  the only message loss  caught was  between elk's zwave serial board  and vrc0p so far. No messages were lost  over the air as yet.
 
It is amazing that zensys does not offer a tool like that to diagnose various zwave related issues considering how cheap it is to build.

 

[Dean Roddey]

One of the things that most folks really don't get about Z-Wave is that it seems like a simple product. But, if you actually want to set it up to do anything non-trivial, hardly anyone really understands all of the ifs, ands and buts involved in keeping it stable and not messing anything up. No average user is going to do any serious spelunking; and, even if they did, most would be very hard pressed to make good use of the information they gained from doing so. 
 
Of course one big reason such software isn't available is that so much of what is required to set it up is in setting up configuration bytes in the modules to make them do what you want. But those are not standardized and half of the time are barely even documented. No software is going to know how to tell you that module 15 has byte 20 set to the wrong thing, which is causing it to send out it's opinion of your breath instead of it's current off/on state. 
 
And the id based inter-module messaging scheme means that any changes to the modules that can change the ids, such as removing a module and re-adding it, can completely hose up any any associations you so carefully set up and it suddenly seems not to be working.
 
It's the price they paid to get the product out to market quickly. It's not really a fully baked, robust technology, And a lot of functionality was added excrementally over time, such that there are often many ways to skin any given cat, and that makes it even harder for any software to automatically understand what is 'correct operation' of all of the modules.

 

[linuxha]

It's also a security issue. I saw a nice Youtube video of a gentleman hijacking the door lock and opening it. Cost him about $75 US for the Ti dongle, free software, a bit of investigation using info gleened from the Open Z-Wave project. Not sure if this will happen with ZWave+ and I'm pretty sure that other wireless protocols have similar issues.
 
I have Z-Wave (and other wireless) devices and I won't be giving them up anytime soon. ;-)

 

[pete_c]

Goofing around with the Leviton RF+ remote I have been able to reset my switches from across the house when turning them on.  
 
If you have one give it a try.

 

[BobS0327]

Here's a really interesting article written by a couple of computer scientists from SensePost.  SensePost is essentially an organization recruited to identify security flaws in your hardware/software.  They have identified a vulnerability in the Zwave key exchange protocol which has since been addressed and resolved by Sigma Designs.  But the article does provide a lot of good information about the internal "plumbing" of Zwave.  It might be helpful in your Zwave experimentation.
 
 
Article link   https://www.sensepost.com/cms/resources/conferences/2013/bh_zwave/Security%20Evaluation%20of%20Z-Wave_WP.pdf

 

[ano]

Remember, Z-Wave is a proprietary standard created and licensed by one company. It has undergone very little pier review, and likely has many security problems. That is just the nature of the beast. This is VERY different than Zigbee or Bluetooth or WiFi.  This is why you rarely if ever see Z-Wave used in commercial applications. Just realize this when you use Z-Wave.

 

[vc1234]

Here's a really interesting article written by a couple of computer scientists from SensePost.  SensePost is essentially an organization recruited to identify security flaws in your hardware/software.  They have identified a vulnerability in the Zwave key exchange protocol which has since been addressed and resolved by Sigma Designs.  But the article does provide a lot of good information about the internal "plumbing" of Zwave.  It might be helpful in your Zwave experimentation.
 
 
Article link   https://www.sensepost.com/cms/resources/conferences/2013/bh_zwave/Security%20Evaluation%20of%20Z-Wave_WP.pdf

Interesting,  thanks !  They used a much better  radio (the CC1110 chip) than I am using.  I may be tempted to try theirs It would be  still about an order of magnitude less expensive than the sigma sniffer.
 
Right now I am losing probably 10% of packets which is a progress compared to the situation when I could receive only 10%.  But you can go only so far with the cheap SDR hardware.
 
Looking at Zwave packets, one could see that it's trivial to spoof lights and thermostats since home id/node ids/payload are in clear text. My Yale locks presumably have the firmware which fixes the vulnerability described in the article.  Not sure why thermo/lights traffic is not encrypted too.
 
The more I look at Zwave traffic the less sense leviton's/sigma routing decisions make sense.  E.g. some packets are routed via more distant nodes to get to the controller although the direct path would have stronger signal.

 

[vc1234]

Another small discovery:
 
Thanks to the home made sniffer, I've noticed packets with the destination node id that I knew I never had. 
 
Turns out that at some point about 5 years ago  I installed a couple of X10 wireless motion sensors using the upper part of the elk lighting address space as someone else on the forum described. The sensors despite being X10 worked surprisingly well watching for wild life at night (I use optex motion sensors for more serious tasks). So now when an X10 motion is triggered, the status is transmitted by elk, for some strange  reason, from one serial board to the zwave serial board and then to vrc0p and radioed to a node id that does not exist. The on/off commands to the never-existed-node id were also registered by my serial tap. Perhaps, that's why elk people do not recommend mixing different kinds of lighting.
 
A more irritating problem is that my locks are still trying to access a relocated node former node id. While I was able to exclude the non-existent node id from thermostat routing tables, I cannot do the same with locks which are not routing slaves as opposed to the thermostats  and refuse to purge their routing table, therefore.  The problem appears to be harmless though because after trying to transmit their status to the controller via a non-existent node 10 times, they give up and eventually connect directly (which they should have done from the very beginning). It does cause an about half a second delay: 10x60ms = .6s.