Z-Wave Mesh Priority Routes Explained

Z-Wave is a wireless mesh protocol with over two decades of real-world learning built into the latest version. While the other new wireless protocols are still writing the specification for their mesh network, Z-Wave has learned a thing or two over the past twenty years. Z-Wave is a Source Routing protocol where the Primary Controller of the network keeps track of the best paths thru the network to/from any point to any other point.

Z-Wave limits the number of hops thru the mesh to four hops to bound the routing calculations to something an inexpensive microprocessor can handle. These four hops quickly explode into a huge number of routing combinations as the size of the network grows to more than a few dozen nodes. The trick is to pick the optimal set of routes to get from one node to the next. This is where the two decades of learning have proven to be the key to Z-Waves robust delivery.

Source Routing Introduction

The 500 series Appl. Prg. Guide section 3.4 describes the “routing principles” used in Z-Wave. While this is a 500 series document the 700 series uses the same algorithm with a few minor enhancements. The key to source routing is that the Primary Controller (PC) calculates the route from Node A to Node B. Each node along the way does not need to know anything about the routing, it just follows the route in the packet header determined by the PC. When an end node needs to talk to the PC or any other node, the PC will send the end node four routes to get from Node A to Node B. As a final backup route, Node A can send out an Explorer Frame asking all nodes within radio range if they can help get the message to Node B. If a node is able to help and the message is delivered, this route becomes what is known as the Last Working Route (LWR). Node A will then use the LWR route whenever it needs to talk to Node B.

There are a total of five routes stored in any node to get to any other node. Note that routes are calculated and stored only if a node is Associated with another node. Since most nodes usually only talk to the PC (Associated via the Lifeline – Association Group 1), that is the only set of routes it stores. The primary controller has the full network topology but still follows the same basic algorithm when sending a message to a node. The five routes are held in a list for each destination. If a message is delivered successfully, that route is moved to the top of list and is called the Last Working Route (LWR). The LWR will be used from now on until it fails for some reason. RF communication is fraught with failures and they will happen occasionally so the LWR often changes over time. When the LWR route fails, the list is pushed down and once a working route is found, it is placed at the top of the list as the new LWR.

Application Priority Routes

Application Priority Routes (APR) are special routes the Application can assign to a node to get messages from Node A to Node B. They are called “Application” Priority Routes because the protocol never assigns APRs, only the APPLICATION can assign APRs. Typically the application is the software that is talking directly to the PC – a Hub application like SmartThings or Hubitat or one of the many other Hub applications. The protocol assumes that someone smarter than it (meaning an expensive powerful CPU with tons of memory) can figure out a better route from A to B than it can. The protocol places the APR at the top of the 5 routes in the list and always keeps it there. Even ahead of the LWR. While this gives the application a great deal of power, it also means the application can make a mess of routing and inadvertently cause a lot of latency. Large Z-Wave networks tend to have dynamic routing which is why the LWR has been the key to the routing algorithm – Once you find a working route, keep using it!

PCC Icon for APR

I generally don’t recommend using APRs since the routing tends to be dynamic and it is often best to let the protocol find the best route. However, adding Direct Route APRs where the node will talk back to the Hub directly rather than routing thru other nodes can reduce latency. This sometimes solves the problem where the LWR gets stuck with a multi-hop route when the Hub could reach it directly. A direct route is the fastest way to deliver messages and multi-hop messages often can have noticeable delay to them. When a motion sensor detects motion in a dark room, speed and low-latency are central to maintaining a high WAF factor and quickly turn on a light.

Using the PC Controller to Assign APRs

The PC Controller has a section called “Setup Route” which has a number of ways of setting up various routes.

There are 5 different types of Routes that the PCC can setup:

# RouteDescriptionSerialAPI Command
1Return RouteAssigns 4 controller computed routes between 2 nodesZW_AssignReturnRoute() (0x46)
2Priority Return RouteAssigns an Application Priority Route between 2 nodesZW_AssignPriorityRoute() (0x4F)
3Set Priority RouteAssigns an Application Priority Route from the controller to a nodeZW_SetPriorityRoute() (0x93)
4SUC Return RouteAssigns 4 controller computed routes from the end node to the controllerZW_AssignSUCReturnRoute() (0x51)
5Priority SUC Return RouteAssigns an Application Priority Route from the controller to an end nodeZW_AssignPrioritySUCReturnRoute() (0x58)

1. Return Route

Return Route assigns four routes to the source node (left) to reach the destination node (right). Anytime an Association is made from one node to another, a Return Route MUST be assigned so the source knows how to reach the destination. The most common application is a motion sensor turning on a light without going thru the hub. For example; a motion sensor (Node 10) is associated with the light (Node 20) and then a call to ZW_AssignReturnRoute(10,20,SessionID) will send four messages to node 10 with four different routes to get to node 20. In this case the Application does NOT specify the route to be used but lets the Primary Controller calculate the best 4 routes. The source node can still use Explorer Frames to find a route if all four fail. During inclusion a controller should always assign return routes to the end node back to the PC so the end node has routes for any unsolicited messages (or use the SUC Return Route below). If the network topology changes significantly (nodes added or removed), then all the return routes of every node in the network should be reassigned to ensure the optimal route is used.

2. Priority Return Route

Priority Return Route is used to assign an Application Priority Route between two nodes. The only time I recommend using this command is to assign a priority route back to the controller to use no routing assuming the node is within direct range of the controller. It is too easy to mess up the routing with this command so in general I do not recommend using it.

3. Get/Set Priority Route

Get or Set the Application Priority Route (APR) the primary controller uses to reach a node. Since the node will use the same route to return the ACK this will become the LWR for the end node so both sides will use this route first. Note that this route is not set at the end node, only the controller will use this route. If the end node needs to send a message to the controller it will use this route if it is the LWR otherwise it will use one of its own assigned routes. Note that you can set the speed in this command. Be careful not to blindly set the speed to 100kbps. If the nodes in the path are older or the destination is a FLiRS device then they may only support 40kbps. Old 100 series nodes can only do 9.6kbps but they can still be part of the mesh. Note that you can GET the priority route (0x92) with this command if one has been assigned. If a Priority Route has not been assigned then the current LWR is returned.

The only application of Set Priority Route I recommend is to force nodes close to the controller to always try direct communication first. In this case, you would Set Priority Route with all zeroes in the route. This tends to make scenes that turn on a lot of lights run quickly so there is less popcorn effect. If a scene with a lot of lighting nodes fails to deliver to one of the nodes, the PC then searches thru routes to find a new route, the routed route becomes the LWR and the controller will continue to use the LWR until that route fails for some reason. By assigning a Priority direct route the controller will always try the direct route first. Since 700 series devices usually have excellent RF, if the controller is in the same room or at least on the same floor as the lights it is controlling, then the direct routes will minimize the popcorn delay. However, if the lights are not in direct range, it will just delay everything making the popcorn worse! So be careful in assigning APRs! Don’t make things worse.

Set the Application Priority Route to Node 2 to direct (no hops) at 100kbps

The example above shows how to assign an APR direct route to Node 2. The function call for this would be: ZW_SetPriorityRoute(2, 0, 0, 0, 0, 3); Every time the PC sends a message to node 2 it will always try this direct route first, if that fails to ACK, then it will use the LWR then the other return routes it has calculated.

APR to Node 6 thru 5->4->3->2 at 100kbps

The example above shows an extreme example where we force routing to be the maximum number of hops of four. This is a handy way to test your product with a lot of routing! A zniffer trace of a message looks like:

Node 1 sending Basic Set to Node 6 via 1->5->4->3->2->6

The function call for this would be: ZW_SetPriorityRoute(6, 5, 4, 3, 2, 3); The PC will always use the route to send a message to node 6, if it fails, it will try the LWR and then the other return routes and finally an Explorer Frame.

4. SUC Return Route

The SUC Return Route is a shorter version of the Assign Return Route (1. above) which simply sets the Destination NodeID to be the SUC which in most cases is the Primary Controller.

5. Priority SUC Return Route

The Priority SUC Return route is again a short version of the Assign Priority Return Route (2. above) which automatically sets the Destination NodeID to be the SUC. It is generally easier to simply use the normal Return Route commands (1. aan 2. above) and fill in the Destination NodeID as the PC (which is usually the SUC) than to use these two commands.

Conclusion

The techniques explained here are not intended for general Z-Wave users but instead for the Hub developers and end-device developers. Since these are low-level commands and not something a user typically has access to, you’ll have to pressure your Hub developer to follow these recommendations.

Hub developers MUST assign return routes ANY time an Association is made between two nodes especially back to the Hub immediately after inclusion and assignment of the Lifeline. If the network topology changes such as when a node is added or removed, it may be necessary to reassign ALL of the routes to all nodes to take advantage of the new routes or eliminate nodes that no longer exist. Be careful assigning Priority routes especially if a node in a Priority Route is removed from the network. If a now non-existent NodeID is in an APR, the node will try really hard using the APR with the missing node before finally giving up using the LWR. This will result in annoying delays in delivering commands or status updates. Z-Wave will still deliver the message, but only after you’ve banged your shin into the coffee table in the dark because the motion sensor is still trying to send thru the missing NodeID in the Application Priority Route.

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