Detecting RF Jamming

Cheap RF Transmitter

All wireless protocols can be jammed often using an inexpensive battery powered transmitter. The protocol doesn’t even have to be radio frequency (RF) based as Infra-Red (IR) and any other communication medium that travels thru the air can be jammed by blasting out noise in the same spectrum as the protocol. Think of a busy street corner where you and a friend are having a conversation and a firetruck with their sirens blareing go by. Your conversation stops because your friend simply can’t hear you above all the noise. The same thing can happen in Z-Wave where a “bad actor” brings a small battery powered transmitter and blasts out RF in the same frequency bands that Z-Wave uses. In this post I’ll explain how to jam Z-Wave and also how to detect and inform the user that jamming has occurred.

Security System Requirements

Jamming applies primarily to security systems. After all, if someone wants to jam your house from turning on the kitchen lights at night, what’s the point other than to get a laugh when you bang your knee into the table? Z-Wave has enjoyed a great deal of success in the security system market. Z-Wave is interoperable, easy to use, low-power and the mesh networking protocol means users or installers don’t have to be concerned with getting everything to talk to everything else as the protocol automatically handles (mostly) everything. Security systems however are very concerned about jamming to the point that Underwriters Laboratory has a specification for it. UL1023 is the US standard for Safety Household Burglar-Alarm Systems.

The reality of the situation for a security system is that it is unlikely a burglar will try to bypass your security system by jamming it. Burglars are simply not that tech savvy. The FBI doesn’t even track the numbers of burglaries via jamming – one would assume because the number is essentially zero. A burglar will simply bash in a window or door or more often simply walk in an unlocked door. However, if it’s easy enough and cheap enough, a burglar might just try! CNET demonstrated just how easy it is to use a $3 transmitter to bypass a popular security system using a cheap RF transmitter. Regardless of the reality of the situation, the bad press of having an easy to jam security system can crater a company.

Anti-Jamming Techniques in Z-Wave

Z-Wave was designed from day one to be robust and reliable. The very first requirement for robustness is to acknowledge that the device receiving the message did in fact receive it. Every Z-Wave message is acknowledged (ACK) otherwise the sender will try again using different mesh routes or other RF frequencies. After several retries, the protocol will give up and the application can then decide if it wants to try even more ways to deliver the message. If the message is not very important (like a battery level report), the application can just drop it. If a sensor detects smoke! Then the application will continue trying to get this life-safety message thru in every way possible for as long as possible.

Z-Wave requires two-way communication – all messages are acknowledged

Here’s a list of the techniques Z-Wave uses for robustly delivering messages:

  • Z-Wave
    • All frames are Acknowledged
    • Multiple mesh routes
    • Frequency Hopping – Two frequencies – 3 different baud rates (in US)
    • RSSI Measurements indicating jamming
    • Supervision CC confirms decryption & data integrity
  • Z-Wave Long Range
    • All frames are Acknowledged
    • Dynamic TX Power
    • Frequency hopping to alternate channel
    • RSSI Measurements indicating jamming
    • Supervision CC confirms decryption & data integrity

Even with all these different measures in place, it is still possible to jam Z-Wave. But it’s not cheap nor is it easy. But let’s give it a try for fun!

Jamming Z-Wave

Jamming Z-Wave starts with a Silicon Labs Z-Wave Developers Kit and Simplicity Studio. However, these kits are not cheap costing at least $150 for just one. It may be possible to find a cheap 900MHz transmitter but you will need two of them and they must have the ability to tune them to the specific Z-Wave frequencies of 908.4MHz and 916MHz in the US. These are not going to be $3 battery powered transmitters and they require a significant amount of technical knowledge. Neither cheap nor easy so I think we’re pretty safe from your typical burglar.

Z-Wave uses two channels (frequencies) in the US: 908.4MH for 9.6 and 40Kbps and 916MHz for 100Kbps. Z-Wave Long Range (ZWLR) also has two channels but uses spread-spectrum encoding which spreads the signal out across a band of frequencies centered at 912MHz and 920MHz. By using two channels Z-Wave is frequency agile which makes it harder to jam since you need two transmitters instead of just one. The spectrum analyzer plot below shows four DevKits blasting all 4 channels at once.

Z-Wave jamming all four frequencies – 912 & 920 are Z-Wave Long Range

Creating the jammer firmware utilizes the RailTest utility in Simplicity Studio V5. Select the DevKit in the Debug Adapters window, click on the Example Projects & Demos tab then check the Proprietary button. The only example project should be the “Flex (RAIL) – RAILtest application”. Click on Create and use the defaults. The default frequency will state it is 868 but ignore that as the Z-Wave modes are all built into RailTest and do not need to be configured. Once the project is created, click on Build and then download to a devkit. Right click on the devkit in the Debug Adapters window and click on Launch Console. Click on the Serial 1 tab then click in the command box at the bottom and press ENTER. You should get a RailTest prompt of >.

Once you're at the RailTest prompt, enter the following commands:

rx 0                 -- disables the radio which must be done before changing the configuration
setzwavemode 1 3     -- Puts the radio into Z-Wave mode
setpower 24 raw      -- 24=0dbm radio transmit power - valid range is 1 to 155 but is non-linear
setchannel 0         -- ch0=916 ch1=908.4 ch2=908.42 - ZWLR ch0=912 ch1=920
setzwaveregion 1     -- EU=0, 1=US, 13=US Long Range
Do one of the following 2 commands:
SetTxTone 1          -- narrow band Carrier Wave - unmodulated
SetTxStream 1        -- Pseudo-Random data - modulated and in ZWLR uses Spread Spectrum (DSSS) 
Use the same command with a 0 to turn the radio off
Remember to "rx 0" before changing any other configuration values

RAILtest is a powerful utility and can do all sorts of things beyond just Z-Wave. The radio in the Silicon Labs chips are Software Defined Radios, they can be customized to many common frequency bands. It is easy to create customized versions of RAILtest that will transmit a carrier wave (CW) or a modulated signal at just about any frequency band, not just Z-Wave. But that’s more complex than I have time to discuss here.

Now that we know how to jam, how do we detect it and inform the user that jamming is taking place? Detecting jamming takes place at both ends of the Z-Wave network, the Controller and the End Device. Let’s first look into the End Device which in a security system is typically a motion sensor or a door/window sensor.

End Device Jamming Detection

Most end devices are battery powered so they spend most of their time sleeping and are completely unaware of any RF jamming that might be taking place. Only when motion is detected or a door is opened will the sensor wake up and find the radio waves being jammed. The best way to check for RF jamming is to first try to send a message. When the message fails to be acknowledged, then start looking to see if jamming is occurring.

The Z-Wave Application Framework (ZAF) handles sending the message and eventually calls a callback to report status. The callback comes through EventHandlerZwCommandStatus() which will be called several seconds after sending the message. The protocol tries various mesh routes, power levels and baud rates which takes time so be sure to stay awake long enough to receive the callback. The callback returns the TxStatus variable which is typically TRANSMIT_COMPLETE_OK (0x00) which means the message was delivered. But if jamming is taking place and the radio was unable to go through it, you’ll get a TRANSMIT_COMPLETE_FAIL (0x02). This status is different than the TRANSMIT_COMPLETE_NO_ACK (0x01) which means the message was not acknowledged which is usually because the destination is offline but could also be due to jamming.

The next step is to verify that jamming is taking place by getting the current Received Signal Strength Indicator (RSSI) level by queuing the EZWAVECOMMANDTYPE_GET_BACKGROUND_RSSI event . The RSSI is a simple value in dB of the strength of signal at the radio receiver when its not actively receiving a frame. In normal operation, this value should be around -100dB. Every environment is different so the threshold for the radio being jammed needs to be a value that is significantly higher than the average value. This is particularly tough in dense housing like apartments where perhaps every unit has a Z-Wave network. This results in a relatively high RSSI average. The key here is you can’t use a simple hard-coded threshold for jamming detection based on RSSI. Instead you must average the RSSI values across a long time-span (typically hours).

Z-Wave Notification of Jamming

The next step after detecting jamming has occurred is to notify the hub. But if the jamming is still in progress, how can the notification get thru? Naturally you can’t get thru while the jamming is still happening. The trick is to keep trying and hope that the jamming is short term. The problem is that a battery powered sensor can’t keep trying constantly as it will run out of battery power perhaps in just a few minutes. You must manage battery power and at the same time keep trying with a longer and longer timeout between attempts. At some point the jamming should end, perhaps hours after the initial break-in but the jammer will eventually run out of battery power.

The Z-Wave Notification Command Class has a pre-defined value for RF Jamming – Notification Type of Home Security (0x07) with an Event of RF Jamming (0x0C) and the current average RSSI level. This notification is a critical notification so it should be wrapped in Supervision Command Class to guarantee it has been delivered and understood by the controller.

Sample Code

The code below first checks the TxStatus, if is not OK, then the RSSI level is checked by queuing the GET_BACKGROUND_RSSI event. Once the RSSI is sampled, the function will be called again with the switch going thru the GET_BACKGROUND_RSSI case below. This section of code then compares the current RSSI level with a background RSSI level and if the current level is above it then the SendRFJamNotificationPending global variable is set. When a frame is able to get thru then the pending RF Jam notification is sent since it appears the jamming has ended. This ensures the Hub is informed that there was jamming so the Hub can then decide if it needs to inform the user. The basics of the algorithm are coded here:

... 
static void EventHandlerZwCommandStatus(void)
...
switch (Status.eStatusType)    
...
    case EZWAVECOMMANDSTATUS_TX:  // callback from attempted message delivery
...
            
        if (pTxStatus->TxStatus != TRANSMIT_COMPLETE_OK) { // failed to deliver - check RSSI
            EZwaveCommandType event = EZWAVECOMMANDTYPE_GET_BACKGROUND_RSSI;
            QueueNotifyingSendToBack(g_pAppHandles->pZwCommandQueue, &event, 0); // Queue GET_RSSI
        } else { // message delivered OK
            // more cleanup happens here...
            if (SendRfJamNotificationPending) { // Is there a pending Jam Notification?
               SendRfJamNotificationPending=false;   // Send it!
               void * pData = PrepareNotifyJamReport(&zaf_tse_local_actuation);
               ZAF_TSE_Trigger((void *)CC_NotifyJam_report_stx, pData, true);
            }
        }
...
    case EZWAVECOMMANDSTATUS_GET_BACKGROUND_RSSI:  // only called if failed to deliver a message
        if (Status.Content.GetBackgroundRssiStatus.rssi > BackgroundRSSIThreshold) {    
            // Set a global to send an RF Jamming Notification which will be sent when jamming ends
            SendRfJamNotificationPending=true;
            SendRfJamNotifRSSI= Status.Content.GetBackgroundRssiStatus.rssi;
        }
... // Not shown are application level retries and various other checking

Now that we have jamming detection enabled on the end-device side, let’s look at the controller end of the communication.

Controller Jamming Detection

Obviously the main thing the controller needs to do is react to a jamming notification from an End Device. The ultimate action the controller performs is left to the controller developer but clearly the end user should be notified that jamming has been detected. But that notification needs to be qualified with enough information about the average RSSI noise level to avoid false jamming detection notifications.

If the jammer is way out at 200+ meters, the RSSI level may not jump up significantly as measured by the controller. Thus, it is important to react to the End Device notification of jamming. However, the controller must poll the RSSI level at regular intervals to determine if jamming is taking place nearby. The question is how often should it poll and when to react to a sudden change in the RSSI level? There is no definite answer to this question other than “it depends” and it depends on a lot of different factors. Typically, the RSSI should be sampled a few times per minute – perhaps every 30 seconds. If a value seems unusually high, perhaps sample several more times at a much faster rate to confirm that the RSSI has jumped and its not glitch. Like the End Device case, the average RSSI value needs to be calculated across a fairly long time frame (minutes to perhaps an hour) and when there is a change from the average value then the user should be notified.

ZW_GetBackgroundRSSI

The SerialAPI function ZW_GetBackgroundRSSI() (0x3B) will return three or four bytes of RSSI values for the various channels supported by the controller. This function can be sent to the Z-Wave controller frequently as it does not cause any delays in the radio. It does use UART bandwidth so it can’t be called too frequently or it may interfere with normal Z-Wave traffic. The polling function should coded with a low priority so it is only sent when the UART has been idle for a few seconds to avoid collisions with Z-Wave radio traffic. The one-byte RSSI values are coded as shown in the table below.

RSSI values returned by the ZW_GetBackgroundRSSI():

HexDecimal (2s Comp)Description
0x80-0xFF-128 – -1Measured RSSI in dBm
0x00-0x7C0 – 124Measured RSSI in dBm
0x7D125RSSI is below sensitivity and cannot be measured
0x7E126Radio saturated and could not be measured as it is too high
0x7F127RSSI is not available

Typically a 700 series Z-Wave controller will measure about -100dBm when the airwaves are fairly quiet. During a transmission the RSSI is often about -30dBm when the node is within a few meters of the controller.

TxStatusReport

The TxStatusReport is returned after a frame was transmitted which includes several fields with a variety of RSSI measurements. There is a Noise Floor of the sender as well as a NoiseFloor of the receiver. The RSSI values can be monitored during normal Z-Wave traffic without polling. It is best to use these values while Z-Wave traffic is taking place and to temporarily pause the polling while the Z-Wave UART is busy. Once the UART is idle, resume RSSI polling.

Missing Heartbeats

Another aspect of jamming is that battery powered devices typically send a “heartbeat” message every hour so the controller knows for sure the device is online and working (mostly that the battery isn’t dead). The controller should be keeping track of how long it has been since the last time a battery powered node has checked in and if it has missed two or at most three heartbeats, the controller should inform the user (or the installer) that the device is offline and unable to communicate. If the battery was already low, then the battery is probably dead. If the battery was fine, then there is a possibility that the device is being jammed.

Z-Wave Works With Amazon, Google, Samsung, Apple, Comcast Virtual Conference

Silicon Labs is hosting what was intended to be an in-person conference in Austin Texas but is now a virtual online conference on IoT ecosystems – the Works With Smart Home Developer Event September 9-10. The best part is it is now FREE to attend any of the in-depth technical sessions and you don’t have to wear a mask. The downside is that we don’t get to experience all that great music down in Austin – well, there’s always next year!

Virtual IoT Works With EcoSystems from Google, Amazon, Apple for Z-Wave development engineers
https://workswith.silabs.com/

I am hosting the Z-Wave track and will be making several presentations including a detailed look at Silicon Labs latest release of Simplicity Studio V5 which just came out yesterday. We’ll also have presentations on developing Z-Wave Smart Hubs and Z-Wave Certification. I’ll also be describing some IoT failures – you learn more from your failures than your successes. We have speakers and engineers from all of the ecosystem partners, not just Silicon Labs folks. Learn from the experts from across the industry!

What is Works With 2020? The smart home developer’s virtual event where you will have the opportunity to interact with our ecosystem partners from Amazon, Google, Samsung, and Z-Wave to connect devices, platforms and protocols and be able to immerse yourself in keynotes, a panel discussion on Project CHIP, hands-on, and technical sessions led by smart home engineers who are building the latest advanced IoT devices. The Works With event is live, all-online, free of charge, and you can join from anywhere around the world.

Works With Z-Wave Apple, Google, Amazon, Samsung IoT SmartHome conference 2020

Click here to Register Today and feel free to forward to the rest of your team.

Here’s an overview of what you won’t want to miss:

Specialized Engineer-Led Tracks – Educational sessions and technical training designed for engineers, executives, developers, business development and product managers.

Hands-On Workshops More than 12 workshops and hands-on sessions to give you experience, knowledge and confidence to develop and accelerate smart home development.  

One-on-One Developer Meetings – Schedule a meeting with Silicon Labs or an ecosystem partner to get 1:1 technical guidance.

Join me in September and learn how to smoothly get your IoT device plugged into any and all of the ecosystem partners. Register today, it’s totally free and you can join from anywhere in the world. See you September!

Z-Wave for the Smart Home Presentation

I’m giving a presentation on Z-Wave where you can ask questions and get answers about the opening of the Z-Wave specification among other topics. There are more Tech Talks scheduled and several recent topics were recorded. Follow the links below.

      Logo     Hero       Good news! We have added new Tech Talks. Join us on Tuesdays and Thursdays for live virtual, technical discussions hosted by a lead engineer with time allocated for your questions. We’ll cover topics like battery optimization with BG22, using Z-Wave for your Smart Home Solutions and more. You don’t want to miss these next talks.

Register by clicking here: Tech Talks:
Z-Wave Smart Home Solutions by Doctor Z-Wave
Tomorrow April 23 at 4 p.m ET

Battery Optimization with BG22
Tues, April 28 at 3 p.m. CT
Max Performance on BLE – Simultaneous Connections, Beacons and Scanning
Thurs, April 30 at 3 p.m. CT
SubGHz Proprietary and Connect Software Stack
Tues, May 5 at 3 p.m. CT
How to Measure and Debug Network Performance – Using Silicon Labs Network Analyzer
Thurs, May 7 at 3 p.m. CT

Z-Wave 700 Series Announcement

The long awaited 32-bit ARM based Z-Wave transceiver chip has finally been officially announced. The 700 series announcement is on the home page of the Silicon Labs web site so this is a big deal for SiLabs and Z-Wave. The companies joined forces just eight months ago and we already have a major advance in Z-Wave technology.

Z-Wave 700 Press Image

What’s New?

The 700 series is a major improvement to Z-Wave for both consumers and developers. For consumers, the lower power and longer radio range means more reliable communication and longer battery life. For developers the main advantage is we’ve finally moved beyond the 1980s 8051 8-bit CPU with very limited debug capability into a modern 32-bit ARM CPU with full serial wire debugging capabilities. We can FINALLY single step thru code instead of having to use PRINTF!

700 Series Features:

  • Longer RF range
    • 150% in the US and 200% in the EU due to improved RF sensitivity and increased transmit power in the EU
  • Lower Power = Longer Battery Life
    • Improved semiconductor technology and a faster CPU yields significant battery life improvement and 10 year coin cell operation
  • Lower Cost – Worldwide Support
    • Improved RF blocking means the country specific SAW filter is not needed saving cost and making a single SKU for worldwide operation
    • No external serial memory is required and OTA firmware update is now mandatory
  • Easier Product Development
    • Integrated Debug Environment (IDE) with full ARM debug, single step, trace, and energy profiler speeds product development
  • 100% Interoperable and Backwards Compatible
    • The 700 series is fully interoperable with all mesh-networked Z-Wave devices all the way back to the pre-100 series Z-Wave devices

When Can I Get One?

If you already signed up for a free Beta devkit, then one should be on its way in the next few weeks. Devkits have begun shipping but quantities are limited and will take until the end of January before all the Beta samples are shipped. The Beta signup closed back on October 1st so if you missed the deadline you’ll have to wait until later in Q1 to request one from your Silicon Labs salesperson. The official “general availability” (GA) release is the end of Q1 at which time the datasheets, chips, devkits and software will be released at the 7.xx full release version. Datasheets require an NDA until the GA release.

You can get started today using the Simplicity Studio IDE and begin developing code and explore the SDK. The software is free and can be downloaded from here.

My Initial Thoughts

I’ve had a 700 series Beta DevKit for a few weeks now working with our Alpha release partners to get some early feedback. We’ve had some hiccups and the firmware needs more work but the silicon is solid. I have joined my 700 series devkit to my home and it communicates fine with my very early pre-100 series Z-Wave light switches attesting to the ongoing commitment Z-Wave has to be fully interoperable and backwards compatible.

Z-Wave Saved My Fathers Life

My father is a cantankerous curmudgeon but at 89 years old he deserves to be a little crusty. In his infinite wisdom at the age of 79 he decided to move away from his family here in New England and purchased a home in warm sunny Florida. He was happy he no longer had to freeze in the cold of winter but I was unhappy because now he was 2,000 miles away and I worried something might happen to him. If someone broke in or if he fell no one would know potentially for weeks. To ease my worries I applied my technical expertise and deployed an inexpensive Z-Wave based system to keep an eye on him.

HomeSeer to the Rescue

HomeseerZeeS2

HomeSeer sells a Raspberry Pi based Home Automation system with a built-in Z-Wave interface called the Zee S2. This small box needs only 6 Watts of power but contains a complete Linux computer that can serve web pages and runs the HomeSeer HS3 application. My initial system was just the HomesSeer Zee S2 ($199) and two Express Controls EZMultiPli Multi-sensors ($99) for a total cost of $300 for my peace of mind.  No monthly charges, no “monitoring fees” or any other costs so this is indeed a low-cost solution. All of the Z-Wave devices just plug in with no wiring, no batteries and everything pretty much plug-and-play. In less than an hour the system went from the box to fully installed and the web interface up and running via my phone or computer.

The HomeSeer system is accessible 24x7x365 via their portal at myhs.homeseer.com. No complex router tunneling or anything like that – just plug the Zee S2 Ethernet cord into HS3the router and then login to it from anywhere in the world. The system is secure and password protected. The HS3 application serves web pages with a status of every Z-Wave device. The HS3 application runs on the Raspberry Pi so all processing is local which means temporary Internet connectivity outages are no problem.

The HS3 user interface shown here is utilitarian which is fine for this application. HomeSeer has an easy to use IF-THEN “events” page which is quite powerful. The HS3 system constantly monitors the motion sensors and depending on the time of day sends me a text anytime there hasn’t been motion detected in the house for more than 5 hours. I placed a motion sensor next to his bed and another in the kitchen. Since he typically would get up several times each night, my 5 hour time limit rarely false-triggered. The trigger was extended longer during the day since he would be up and around the house and not in the bedroom for more than 8 hours at a time.

Nothing is Perfect

When I first put the system together, it seemed to work reliably. However the Zee S2 unit was installed at the far end of the house near the cable box. The kitchen motion

ezmultipli200
Express Controls EZmultiPli Motion Sensor

sensor was about 25′ away and the bedroom one was another 20′ away and had to pass thru several walls, the HVAC system and a bathroom. With only 3 nodes in the Z-Wave network I violated one of the key rules of a mesh network – always have more than two routes to every device. In this case I had exactly one route to each device so I didn’t have a mesh and the result was a number of false triggers because the bedroom motion sensor occasionally couldn’t reach all the way back to the Zee S2.

I was frustrated because I left what I thought was a working system but soon turned out to be unreliable. Now I was 2000 miles away and had to suffer with this system for nearly a year before my next visit to Florida. The solution was to add a few lamp modules and another multi-sensor so now I had 7 nodes with several routes to all nodes. Now the system was reliable and did not false trigger. I added an event that automatically turned on a lamp in the family room whenever motion was detected. My father really liked this feature as he always had light as soon as he entered and it would automatically turn off when he had left the room.

I thought things were pretty robust at this point but my next Achilles heel turned up rather quickly. Something caused the Raspberry Pi to crash. I couldn’t log into it and it was no longer sending me the daily emails telling me what time my father had gotten up in the morning. After nearly 2 months the system just suddenly started sending me the daily emails again. Apparently a power outage had in effect rebooted the HomeSeer system. On my next visit I put the entire system on a power strip that my father could reach so he could reset the system. I still want a power strip that has a watchdog timer function and if it doesn’t get some sort of “ping” every hour or so, it reboots everything downstream.

He Takes a Fall

At 2:39am one morning in mid-November 2017, my father fell in his bedroom. He was unable to get up. He was unable to call for help. My HomeSeer system sent me a text at 7:39am stating he had not gotten up. That seemed like an odd time for him to not get up so I tried to call him. After several calls with no answer and checking the HomeSeer system to see that there has been no changes since 2:39am I became concerned. I had the Sheriff stop by and check on him and it turns out he was on the floor, awake but unable to move. The EMTs were called and he was taken to the hospital. In just 5 hours he was already dehydrated and would have slowly died a painful death in a day or so if my system had not been in place. The Z-Wave system saved my fathers life.

Looking back on it now, I had noticed that his morning schedule had started to vary significantly from day to day. For years he had been getting up at a pretty predictable time of around 10am. But in the months prior to his fall, his schedule had started to vary from 8am to as late as 1pm in the afternoon. When we talked on the phone he said he was fine but clearly he was struggling. He enjoyed being warm in Florida and he was happy and I was confident that my Z-Wave system would alert me to any major problems which it did.

CES 2018

The Consumer Electronics Show in Las Vegas is THE trade show for smart home technology and all things cool and new and geeky. It’s a massive show and I only spent one day there and never made it out of the Sands convention center which is one of the smaller venues. If you’ve never been to CES it is something to see. The crowds are enormous and the tech is brand new. So new, some of it will never actually make it to market as there is plenty of smoke and mirrors.

Eric Ryherd wireless IoT consultant expert

My purpose is obviously to seek out the latest news about Z-Wave and chat with my clients. The Z-Wave Alliance invited me to man the “Ask the Expert” desk at the show for a few hours which I was happy to do. My expert knowledge of Z-Wave answered simple questions like “what’s Z-Wave?” (It’s like wifi but low power) to complex questions about the rules around Security S2 and SmartStart.

The most common question is always what’s the difference between Z-Wave and Zigbee? My short answer is that Zigbee is like silos. If you can develop an app, gateway and all the devices you need, then Zigbee will work OK. Z-Wave however was a mesh network from day one and every Z-Wave device can talk to every other Z-Wave device regardless of the manufacturer. Z-Wave is built around standardized command classes so every hub knows precisely what format a temperature sensor is sending the data. Is it in celcius or Fahrenheit? Tenths of a degree or hundredths? With Z-Wave, the format is fully specified. The other protocols let you decide the format which is fine if you have the huge budget to do it all. But if your investors have you on a shoestring budget then Z-Wave is the way to go. I have much longer answers to the Z-Wave vs. Zigbee question but much too long to keep your interest in a quick blog post.

The big announcement for Sigma (other than the acquisition by Silicon Labs) is the announcement of the 700 series. Unfortunately details remain shrouded in secrecy but Sigma has put a stake in the ground of having developers kits by summer 2018. Finally having a real 32 bit ARM processor will be a huge productivity improvement for us IoT developers.

I had limited time to walk the floor but it does seem that smart home has finally taken off. There are so many companies making cool gizmos it’s overwhelming. From sun tracking solar powered umbrellas to cameras of every size and resolution to lots of new hubs there is no way one person can take it all in. You’ll just have to see for yourself.

The Z-Wave Alliance booth is even bigger this year filled with companies hawking the latest IoT thingamagiggy using Z-Wave. Every one of them able to talk to all the other Z-Wave doodads. The booth was busy all day long. I did wander past the tiny Zigbee booth buried in the back of the hotel with a few people in it but nothing like Z-Wave.

SiLabs acquires Z-Wave – Good or Bad?

On Friday of last week Silicon Labs signed an agreement to purchase Sigma Designs for $282M.

The question is: is this good for Z-Wave or bad? 

logoSilicon Labs is a well respected semiconductor manufacturer with an array of microcontroller products  from 8-bit 8051s thru modern low-power ARM CPUs. Silicon Labs has been chasing the IoT market since before IoT was a “thing”. Their low power micros have industry leading features often integrating the latest connectivity solutions like USB, Zigbee and now Z-Wave.  With a market cap of nearly $4B, Silicon Labs (SLAB) has a lot more financial muscle than Sigmas (SIGM) mere $265M could provide. All Z-Wave licensees should rejoice that a much larger company is now  supporting Z-Wave with the accompanying increase (we hope) of resources.

sigma-logoIn my opinion, the most interesting part of the announcement is that SiLabs is buying Z-Wave and not Sigmas primary business of Set-Top-Box processors. The announcement states: “Sigma Designs is in active discussions with prospective buyers to divest its Media Connectivity business”.  The announcement goes on to say that if Sigma can’t unload its “Media Connectivity business” then SiLabs will buy just the Z-Wave portfolio for $240M thus making the rest of Sigma worth only $42M assuming someone is willing to pay that much for it.

The Past

logo_zensyszwaveZ-Wave was originally invented by Zensys based in Copenhagen Denmark in 1999. Originally the Z-Wave protocol used Chipcon radios (acquired by TI) and Atmel processors (acquired by Microchip). In 2003 Zensys announced its own custom designed “100 series” Z-Wave transceiver which was a complete Z-Wave capable IoT System-On-Chip. In 2008 Zensys was struggling financially.  Fortunately Sigma stepped in an purchased Zensys for an “undisclosed amount”. Nine years later, Sigma has sold Z-Wave for a very nice ROI of perhaps 100X. Mergers and acquisitions in the semiconductor industry are frequent as technology and markets shift in unforeseen ways.

The Present

Z-Wave is growing like crazy as the number of 100% inter-operable mesh networked Z-Wave devices on the market continues to increase. There are now over 600 Z-Wave licensees with over 2100 products already on the market. With the recent addition of the AES-128 encrypted Security S2 communication and SmartStart to simplify the building of the Z-Wave network, Z-Wave shows it is continuing to evolve while still being completely backwards compatible with all the existing devices all the way back to the 100 series.

The Future

The future is nearly impossible to predict. I certainly don’t claim to have a clearer crystal ball than the next guy. But this acquisition bodes well for the future of Z-Wave. The additional resources should accelerate the introduction of the ARM Z-Wave microcontrollers which in turn will bring more Z-Wave products to market faster and cheaper. The soon to be announced next generation transceivers are expected to utilize modern ARM processors and make a significant leap forward in debug capabilities that are not present in the current 8051 8-bit CPUs. Z-Wave developers will finally be able to single step through their code instead of relying on printf to output a few cryptic characters giving you meager clues where your code has gone wonky.

Conclusion

The acquisition of the Z-Wave portfolio by a financially strong IoT silicon manufacturer is a “good thing” for the future of Z-Wave.

Eric Ryherd Presenting “IoT Device Testing Best Practices” at Z-Wave Summit in Oklahoma City September 26-28, 2017

Z-Wave Developers and Marketers will come together at the Z-Wave Summit at the Jasco facility in Oklahoma City September 26-28, 2017. You have to be a member of the Z-Wave Alliance to attend. I highly recommend attending if you are developing Z-Wave devices . Networking with other Z-Wave developers and having intimate access to the Sigma Design and Alliance engineers and marketing folks is invaluable. To attend, register via the Alliance member-only web site. The Alliance always has some fun in the evenings too so it’s not all work!

Eric Ryherd Presenting

Express Controls founder and Z-Wave expert Eric Ryherd (aka DrZWave) will be presenting at the summit for the 4th consecutive year. Last years presentation was “Seven Things you probably don’t know about Z-Wave” and was well received. I was surprised how many engineers were completely unaware of the many new features and command classes that have been added to Z-Wave in the past couple of years. This year’s topic is “IoT Device Testing Best Practices“. I’ll go over some of the failures I’ve found over the last several years in both my products and other products I’ve tested.

Abstract

Z-Wave wireless Internet of Things (IoT) devices are hard to test! There are countless devices already in customers hands with bugs in them that make Z-Wave seem unreliable when in fact many of the issues are bugs in the device firmware.  Eric Ryherd, Z-Wave expert and consultant, describes some of the  failures that are still shipping today and best practices when testing your IoT device to reduce the chance your device fails in your customers hands. Simple command sequences sent one at a time by a test engineer is not representative of the real world packet storms that occur in an apartment building with complex RF reflections and multiple interfering RF networks. Your device has to work in the real world and to do that you need to simulate those terrible conditions that do not happen on the engineers desk.

Author Bio

Eric Ryherd licensed Z-Wave in 2003 to develop IoT devices before the term IoT even existed. Light switches, motion & temperature sensors, water valves and meters, hubs, window shades, remote controls are just a sample of the Z-Wave IoT devices developed and tested by Express Controls. Eric applies his Z-Wave expertise in consulting, training and assisting with Z-Wave Certification to companies of all sizes. Read more by Eric at his blog – DrZWave.blog.

Z-Wave Challenges in MDUs and How to Resolve Them

Deploying a robust Z-Wave network in MDUs (like apartment buildings or hotels) can be challenging unless you follow a few basic rules.
The most common problem in MDU deployment is that many installers fail to take advantage of Z-Wave’s number one technical advantage – the mesh network. Every always-on (wall powered) Z-Wave device adds a node to the mesh. But battery powered devices like door locks, sensors and many thermostats do NOT add nodes to the mesh – they merely benefit from other devices on the mesh network. A system where there is one Z-Wave hub and a door lock in each dwelling unit will result in a poorly performing system because there is no mesh! To build a reliable mesh, every device in the network needs at least two routes between the hub and every device on the network. This means you need at least one Z-Wave repeater or lamp module in every network.
An MDU can easily have dozens or even hundreds of units all within Z-Wave range of each other. If each unit has just a single Z-Wave hub and a door lock, then each unit causes interference with every other unit resulting in a cacophony of Z-Wave traffic. A better solution is to have one hub serve 5 or even 10 units with each unit having at least one always-on device within it to provide a good “mesh” node to access the battery powered devices. Always-on devices in adjacent units help provide routing pathways to improve the robustness of the network. The installer needs the proper tools to evaluate the best location for these always-on devices to ensure a high-quality mesh network with plenty of alternate routes.
Another challenge in MDUs is that things are always changing. An owner might install a mirror (which is a metal plate on glass) or a metal appliance that significantly alters the Z-Wave quality within the unit. Even though the mirror or appliance is not in between the hub and the door lock does not mean that it won’t cause connectivity problems. The solution to this issue lies again with the mesh network and having alternate routes. Since things are always changing, the hub needs to have a policy to “heal” the network occasionally to adjust to the changes in the environment.
If some door locks seem to have short battery life then you might be suffering from limitations in older, pre-500 series Z-Wave devices. Early generations of Z-Wave would wake up battery powered devices like door locks using only their NodeID to request which node to wake up. This works fine in single family homes since every node on the network has a different NodeID, but in an MDU with multiple adjacent Z-Wave networks, if the door lock in each unit is NodeID=2, then every hub will wake up every door lock in the building any time a unit needs to check on the battery level of any door lock. The solution is to ensure each adjacent installation has a different NodeID for door locks or battery powered nodes. Thus, apartment 101 will have the door lock as NodeID=02, apartment 102 will have the door lock as NodeID=03, and so on. The latest generation of Z-Wave solves this problem so as these newer locks come on the market this issue will disappear.

A few quick rules for deploying Z-Wave in MDUs:

  1. Always build a Z-Wave mesh
  2. Install fewer hubs
  3. Use tools like IMA to validate mesh networks
  4. Don’t build the same network in every unit
  5. Network must be flexible due to changing environments

Seven Habits of Highly Effective Z-Wave Networks for Consumers

You have a Smart Home using Z-Wave as a wireless technology for all these Internet of Things (IoT) devices to communicate with each other. But maybe things are not working quite as well as you expect. You press a button on your phone and 1… 2… 3… and then finally a light comes on or maybe it doesn’t come on at all! Another common problem is when a battery powered sensor was updating the temperature last week and this week it just doesn’t seem to be sending updates anymore or at best sporadically. As a Z-Wave expert I’ve built and rebuilt hundreds of Z-Wave networks and have come up with a few habits to make Z-Wave networks more reliable.

1. Minimize Polling

This is probably THE number one mistake new users of Z-Wave make. They figure Z-Wave is a high speed network so they can just poll a light switch every 3 seconds and then react to any change in the switch. Z-Wave and most other wireless networks work best when the network is highly available. If the network is busy, every device that needs to send a message has to wait its turn and then compete (and often collide) with all that polling traffic. Collisions slow everything down just like rubber-necking on the highway.

Polling used to be the only way to get around a patent that fortunately expired in February 2016. The patent forced many light switch manufacturers to not send a message when you flipped the switch. Several manufacturers found ways to get around this or they licensed the patent. But now that the patent has expired, you can get light switches that do send a report immediately when their state has changed.

So the primary way to minimize polling is to replace the few devices in your Smart Home that trigger an event  (or SmartApp or Magic or whatever your hub calls it) with one that will instantly send an update. If you have some older switches but they’re not that important to instantly know their state has changed, you can still poll them but no more than once every few minutes. Remember that if you have 60 Z-Wave devices and you poll each one once/min then you are polling once/second and the network is hammered! So only poll a couple of nodes!

2. Have enough devices to create a mesh

I can’t tell you how many people I’ve worked with that had a door lock and a hub and nothing else, maybe a battery powered thermostat. And they wondered why the connection to the lock was unreliable when the hub was at the far end of the building! Z-Wave relies on Always-On (110VAC powered) nodes to build a “mesh” network. The mesh is the key to Z-Wave reliability. Every Always-On node acts as a repeater in the mesh and is able to forward a message from one node to another in the mesh. But only the Always-On nodes can forward a message. Battery powered devices like door locks and battery powered thermostats cannot forward messages. Only the Always-On nodes can.

Solution: If some devices are not reliable, add more Always-On devices. Add a Z-Wave repeater or any device like a lamp dimmer. Even if you don’t use the lamp dimmer it will act as a repeater and improve the network. I have a few lamp switches I use for my Christmas lights which I leave plugged in year round because they help the Z-Wave network since these nodes are at the periphery of my home.

Distance between nodes is not always the criteria for adding more nodes in a network. The Z-Wave radio signals may bounce off metal objects like mirrors or appliances and cause two nodes that are only a few feet apart be completely unable to talk to each other due to reflections of the radio signals. Adding more nodes in the mesh provide alternate routes to nodes that otherwise might be in a dead zone due to these reflections cancelling out the radio signals.

3. Place the hub in a central location

Putting the hub in a corner of the basement might be convenient, but its a terrible idea for Z-Wave. The hub is the most important node in the network and should have the best location possible. While Z-Wave is a mesh network and can route or hop thru other nodes in the mesh, each hop is a significant delay and chokes up the network with more traffic. Ideally the hub should reach 90% of the nodes in your Smart Home without relying on routing. If the hub has Wifi then putting it in a central location is easy, you just need a wall outlet to plug it in. I have my hub hung off the back of a TV cabinet in roughly the middle of the first floor of my home.

4. Heal the Network

Once a Z-Wave network is built, it has to be “healed” so every node can use all the other nodes in the network to route messages. This healing process can take many minutes to even hours depending on the size of the network. When you first build a Z-Wave network, the first node added only knows that the hub is in the network. When you add a second node, the hub knows that both the nodes are in the network but the first node you added has no idea that node 2 is there – unless you heal the network. So any time you add a node, you need to heal at least a few nodes in the network if not the entire network. Be cautious with the healing process – it uses 100% of the Z-Wave bandwidth during the process and every node will wake up every FliR node (door locks) at least once which will drain the batteries of the FLiR node. Generally only heal when nodes have been added or removed or if there seems to be a problem in the network.

Z-Wave is able to self-heal automatically. Z-Wave nodes will try various routes to get their message thru if at first it doesn’t succeed.  The node will remember the Last Working Route and try that one first for the next message. But if the nodes have no idea there are other nodes in the network they have no way of knowing what routes to try so at least one full heal of the network is required.

HomeSeer

homeseerhealHomeSeer has several platforms so the precise method might be slightly different than shown here. From the web interface home page select the menu Plug-Ins->Z-Wave->Controller Management then select the Action “Fully Optimize a Network”. The network wide heal will take some time depending on the size of the network.

SmartThings

SmartThings Expert Z-Wave Eric Ryherd DrZwaveSmartThings  user interface is thru their app which makes finding the network heal a bit of a challenge. Start from the dashboard and click on the three lines in the upper left corner. Your Hub should be the first choice in the menu that slides out, click on your hub. A new menu comes up, click on the last choice “Z-Wave Utilities”. The last choice on the next menu that slides in is “Repair Z-Wave Network” so click on it and then click on “Start Z-Wave Network Repair”. The repair will take from minutes to over an hour depending on the size of your network.

Vera

verahealVera has several versions of their UI but each of them has a similar menu structure so these instructions should work on any version. The Vera version shown here is UI7. Use a PC to log into GetVera.com and select your hub. From the Dashboard, select Settings->Z-Wave Settings and then click on the advanced tab. At the bottom of the advanced tab is the GO button to run the “Update Node Neighbors”. Depending on the size of the Z-Wave network this process will take several minutes to over an hour.

5. If a device doesn’t pair, first exclude it, then include it

You’ve taken the brand new Z-Wave IoT widget out of the box and you’ve tried to pair it (the Z-Wave term is “inclusion”) but it just won’t include! Arrrghhh! The first thing to try is to exclude the node first and then try including it. Any hub can “reset” or exclude a Z-Wave device even if that device was previously connected to another network. Some manufacturers occasionally fail to exclude the device during testing so the device may already be connected to their test network. Z-Wave Expert IoT WirelessOr you may have inadvertently included the device but the inclusion process failed somehow and the hub is confused. Excluding the node should reset it to the factory fresh state. Newer Z-Wave Plus devices (which have this logo on them) are required to have a way to reset them to factory defaults using just the device itself. Every device is different so you’ll have to refer to the device manual to perform a factory reset but if all else fails this should make the device ready to pair. Naturally having the hub physically close to the device being paired will also help though most devices can be paired from a distance.

Secure devices like door locks are particularly challenging to pair. First the secure device has to join the Z-Wave network, then the AES-128 encryption keys have to be exchanged and if that process fails (which it does on occasion), then you have to exclude and try the inclusion process all over again. Secure devices definitely want to be within a few feet of the hub during inclusion to ensure reliable and speedy Z-Wave communication.

6. Battery life and how to maximize it

When a battery powered Z-Wave device wakes up and turns on its radio, it uses 10,000 times more battery power than when it’s asleep. So the entire trick to making batteries last is to minimize the amount of time the device is awake. Some devices naturally have other battery draining activities mostly involving motors to throw a deadbolt or raise a window shade. Obviously any motor will use a lot more battery power than the Z-Wave radio but the radio will play a significant role in battery life.

When a battery powered device is added to a Z-Wave network the hub should do two things:

  1. Assign the Association Group 1 NodeID to the hub
    1. Association Group 1 is the “LifeLine” in Z-Wave and devices use this lifeline to send all sensor data and alerts to this node
    2. All hubs are required to assign Group 1 but double check this assignment
  2. Set the Wake Up Interval to no more than once per hour and ideally only a few times per day
    1. Every hub assigns the WakeUpInterval differently and largely handles it behind the scenes so this may be difficult to verify or change
    2. If the device is waking up every few minutes and sends a sensor reading then its battery life isn’t going to be more than a few weeks
    3. The battery level of the device is usually reported at the WakeUpInterval  rate

Many sensors have other Association Groups or Configuration Parameters that will let you specify the frequency of sensor readings. Realize that the more often the sensors report in, the shorter the battery life.

7.  Dead nodes in your controller

One of the big problems in Z-Wave network maintenance is eliminating “dead” nodes. When a device fails or for whatever reason is no longer in use, then it needs to be removed from the controller. If it remains in the controller then the controller will try to route thru this dead node on occasion resulting in delays in delivering messages. Eventually the self-healing aspects of Z-Wave will make this less likely but various devices will on occasion attempt to route thru it. Since the node is dead, that wastes valuable Z-Wave bandwidth and potentially battery power of sleeping devices. Occasionally running a Heal on the network will remove the node from the routing tables but it will remain in the controllers routing tables. It is best to completely remove this dead node. Each hub has a different method for removing dead nodes and usually requires going into an advanced Z-Wave menu.

Following these guidelines will help your Z-Wave experience be more robust. If you have more questions please feel feel to reach out via email to drzwave at expresscontrols.com.