Z-Wave

Z-Wave Long Range Zniffer

DrZWave1 Comment

Packet sniffing is critical for debugging any wireless IoT product and Z-Wave Long Range (ZWLR) is no exception. The challenge with ZWLR at the moment is that you must use a WSTK Pro Developers Kit and connect it via Ethernet AND USB. See my Unboxing the 800 Series video for a demonstration and more details on how to set up a WSTK so it is both a SerialAPI controller and a Zniffer at the same time. The challenge with this setup is that since the WSTK requires an Ethernet interface, you need a router and perhaps a switch and specifically a DHCP server to connect the Zniffer via Ethernet. This is easily done when at the office or even working from home, but I’ve been doing some Long Range testing at a remote site with no power or Ethernet let alone the Internet and a router/switch. But in this post I’ll show you how to wire up Ethernet point-to-point without a router. I expect needing both Ethernet and USB for the Zniffer will be solved in a future SDK release but to get things done today I offer this solution.

I have a Windows 10 laptop so that’s the help I can provide but Mac or Linux users I assume can find similar solutions. I don’t normally use the Ethernet jack on my PC so I can alter the Windows settings and leave them this way as I use either WiFi or a USB-C port expander when I am in my office. If you use the Ethernet jack on your PC, you may want to buy a USB to Ethernet adaptor for this specific purpose to avoid having to constantly change the settings.

On the Windows10 PC – go to Control Panel\Network and Internet\Network Connections and Select the desired LAN interface. In my case it’s the Ethernet interface on the motherboard. If you connect the WSTK to the interface you’ll see it show up as “no Internet” but connected.

Double click the desired “interface”, then select Properties and scroll down to TCP/IPv4 and click on it and enter the IP address 192.168.1.1 as shown here:

click OK in both windows. This changes the PC Ethernet interface to a fixed IP address and apparently also provide IP addresses to connected devices.

Open Simplicity Studio (SSv5) and then Commander (Tools->Simplicity Commander)

Plug the devkit and the PC together using both USB and Ethernet.

In Commander select the USB kit number in the Select Kit drop down. Then edit the Network Information and enter as shown here:

The devkit should then get assigned an IP address of 192.168.1.2 in several seconds and then show up in SSv5 as connected via both USB and Ethernet.

Open the Zniffer application and click on Capture -> Detect Zniffer Modules if the IP device doesn’t already come up in the drop down menu. Select the IP address then click on Start and trigger some Z-Wave traffic to make sure the Zniffer is working.

When you later return to the office and want to connect the WSTK to a real network with a DHCP server, use Commander and the USB interface to go into the Network Information and select Use DHCP. The WSTK should then properly negotiate for an IP address on the network and automatically show up in the Zniffer.

Hopefully this solution is only needed for another quarter or two as we’ve had many requests to make a much easier to use ZWLR Zniffer solution. Someday I hope we would eventually switch to a Wireshark based solution but for now we have the Zniffer as-is.

One last Zniffer recommendation is to also click on View then enable All Frames to be sure you can see the wakeup beams and CRC errors.

Make Your Own Z-Wave Device

DrZWave1 Comment

Have you always wanted your very own Z-Wave widget-thing-a-ma-bob-doohickey? Silicon Labs recently released the Thunderboard Z-Wave (TBZ) which is an ideal platform for building your own Z-Wave device. Officially known as the ZGM230-DK2603A, the TBZ has sensors galore, expansion headers to connect even more stuff, comes with a built-in debugger via USB-C and can be powered with a single coin cell. Totally cool! I am working on a github repo for the TBZ but right now there are three simple sample apps in Simplicity Studio to get started.

ThunderBoard Z-Wave

Thunderboard Z-Wave

Features

  1. ZGM230 Z-Wave Long Range Module – +14dBm radio – 1mi LOS RF range
    1. ARM Cortex-M33, 512/64K FLASH/RAM, UARTs, I2C, SPI, Timers, DAC/ADC and more
  2. Built-in Segger J-Link debugger
  3. USB-C connectivity for SerialAPI and/or debugging
  4. RGB LED, 2 yellow LEDs, 2 pushbuttons
  5. Temperature/Humidity sensor
  6. Hall Effect sensor
  7. Ambient Light sensor
  8. 6-Axis Inertial sensor
  9. Metal sensor
  10. 1Mbyte SPI FLASH
  11. Qwiic I2C connector
  12. Break-out holes
  13. SMA connector for antenna
  14. Coin cell, USB or external power
  15. Firmware development support via Simplicity Studio

Sample Applications

There are three sample applications in Simplicity Studio at the time of this writing (Aug 2022 – SDK 7.18.1);

  1. SerialAPI,
  2. SwitchOnOff
  3. SensorMultilevel

The TBZ ships with the SerialAPI pre-programmed into it so you can use it as a Z-Wave controller right out of the box. Connect the TBZ to a Raspberry Pi or other computer to build a Z-Wave network. Use the Unify SDK to get a host controller up and running quickly or use the PC-Controller tool within Simplicity Studio for development and testing. The SwitchOnOff sample app as the name implies simply turns an LED on/off on the board via Z-Wave. This is the best application to get started as the ZGM230 chip is always awake and is easy to debug and try out. The SensorMultilevel sounds like a great app as it returns a temperature and humidity but at the moment it does not use the sensor on the TBZ and simply always returns a fixed value. SensorMultilevel shows how to develop a coin-cell powered device. Additional sample apps are expected to be available in future SDK releases but I am working on a github repo with a lot of sensor support.

Naturally a single Z-Wave Node doesn’t do much without a network. You’ll need some sort of a hub to connect to. Most of the common hubs (SmartThings, Hubitat, Home Assistant, etc) will at least let you join your widget to the network and do some basic control or status reporting. You need either a pair of TBZs or perhaps purchase the even cheaper UZB7 for the controller side and then the TBZ for the end-device. Then you have a network and can build your doohickey and talk to it over the Z-Wave radio.

Getting Started

Plug in the TBZ to your computer and open Simplicity Studio which will give you a list of applicable documents including the TBZ User Guide. Writing code for the TBZ definitely requires strong C programming skills. This is not a kit for an average Z-Wave user without strong programming skills. There is a steep learning curve to learn how to use the Z-Wave Application Firmware (ZAF) so only experienced programmers should take this on. I would recommend watching the Unboxing the 800 series video on the silabs web site to get started using Simplicity Studio. I hope to make a new video on the TBZ and publish the github repo so stay tuned.

Have you created a Thing-a-ma-bob using the TBZ? Let me know in the comments below!

Z-Wave 800 GPIO Decoder Ring

DrZWaveLeave a comment

The two Z-Wave 800 series chips from Silicon Labs have flexible GPIOs but figuring out which one is the best for which function can be challenging. There are a number of restrictions based on the function and the energy (sleep) mode you need the GPIO to operate in. Similar to my posting on the 700 series, this post will guide you to make wise decisions on which pin to use for which function.

The tables below are a compilation of several reference documents but all of the data here was manually copied out of the documents and I could have made a mistake or two. Please post a comment if you see something wrong and I’ll fix it right away.

Reference Documents

  • EFR32xG23 Z-Wave 800 SoC Family Datasheet
  • ZGM230 Z-Wave 800 Module Datasheet
  • EFR32xG23 Reference Manual
  • WSTK2 Schematic (available via Simplicity Studio)
  • BRD4210 EFR32ZG23 Radio Board +20dBm Schematic
  • Thunderboard Z-Wave UG532 and Schematic

Pin Definitions

The table below lists the pins from the most flexible to the most fixed function. There are more alternate functions than the ones listed in this table. The most commonly used alternate functions are listed here to keep the table readable. Refer to the schematics and datasheets for more details.

Port A and B are operational down to EM2, other GPIOs will retain their state but will not switch or pass inputs. Thus, use port A and B for anything special and use C and D for simple things not needed when sleeping (LEDs, enables, etc).

WSTK GPIO Probe Points

Only the ZG23 QFN48 pin numbers are listed in the table. The QFN48 is expected to be pin compatible with future version of the ZG23 with additional Flash/RAM so I recommend using it over the QFN40. The WSTK2 is the Pro DevKit board with the LCD on it which comes as part of the PK800 kit. There are two sets of holes labeled with Pxx numbers on them which are handy to probe with an oscilloscope. The Thunderboard Z-Wave (TBZ) also has 2 rows of holes which are ideal for probing or connecting to external devices for rapid prototyping.

NameZG23ZGM230WSTK2TBZALT
FUNC		Comments
PB2229P19EXP5
BTN1		Use the pins at the top of this list first as they are the most flexible
PB6NA5EXP15
I2CSDA		TBZ Qwiic I2C_SDA
PB5NA6EXP16
I2CSCL		TBZ Qwiic I2C_SCL
PB4NA7
PA10NA23
PC1235P1EXP4PC and PD are static in EM2/3
PC2336P3EXP6
PC3437P5EXP8
PC4538P35BLUE
PC6740P33EXP9
PC8942P31LED0
PC91043P37LED1
PD34530P26IMUEN
PB02411P15VDAC0CH0
PA02512P2GREENIDACVREF
PB12310P17REDEM4WU3
VDAC0CH1		EM4WUx pins can wake up from EM4 sleep mode on a transition of the GPIO
PB3218P21EXP3
BTN0		EM4WU4
PC0134P7EXP10EM4WU6
PC5639P12EXP7EM4WU7
PC7841P13SNSENEM4WU8
PD24631P6EXP11EM4WU9
PD0_LFXTAL_O4833XC32XC32BRD4210 and TBZ have 32KHz crystal mounted
PD1_LFXTAL_I4732XC32XC32Accurate timing while sleeping – Time CC
PA73220P10TraceD3Trace pins for debug & code coverage
PA63119P8TraceD2Trace is configurable for 4, 2 or 1 data pin
PA53017P4IMUINTEM4WU0
TraceD1
PA4_TDI2916P41EXP13JTAG_TDI
TraceCLK		JTAG data in
Trace Clock out
Pins below here should be used primarily for debug
PD4_PTIDATA4429P25Packet Trace Interface (PTI) data
PD5_PTISYNC4328P24EM4WU10PTI Sync
PA9_URX3422P11EXP14VCOM UART
PA8_UTX3321P9EXP12VCOM UART
PA3_SWO2815P16JTAG_TDO
TraceD0		RTT UART printf and Trace D0
PA2_SWDIO2714P18JTAG_TMSThese two SWD pins should ONLY be used for debug and programming
PA1_SWCLK2613P20JTAG_TCKSWD debug clock
Pins below here are fixed function only
SUBG_O118NANot used by Z-Wave
SUBG_I116NANot used by Z-Wave
SUBG_O0193RFIO on ZGM230
SUBG_I017NAMatching network to SMA
RESET_N131F4Push buttons on DevKit boards
HFXTAL_O12NA39MHz crystal
HFXTAL_I11NA39MHz crystal
DECOUPLE36181.0uF X8L cap (unconnected on ZGM230)
VREGSW37NAInductor to DVDD for DCDC – 3.3V
VREGVDD38253.3V In/Out based on mode
DVDD4024VDCDC on ZGM230
AVDD41NAHighest voltage – typically battery voltage
IOVDD42261.8-3.8V
PAVDD20NA3.3V for +20, 1.8V for +14dBm
RFVDD14NA1.8V or 3.3V but less than PAVDD
VREGVSS3927, 44GND
RFVSS152, 4GND

Power Supply Pins

Obviously the power supply pins are fixed function pins. The only really configurable parts to this set of pins is the voltage to apply to the IOVDD, AVDD and whether to use the on-chip DC to DC converter or not. If your device is battery powered, AVDD should be the battery voltage assuming the battery is nominally 3V (coin cells or CR123A). AVDD can be measured by the IADC in a divide by 4 mode to give an accurate voltage reading of the battery. This avoids using GPIOs and resistor dividers to measure the battery level thereby freeing up GPIOs and reducing battery drain. IOVDD should be set to whatever voltage needed by other chips on the board. Typically either 1.8 or 3.3V. The DCDC should be used in most battery powered applications unless a larger DCDC is present on the board already to power other chips.

The other configurable voltage is the RFVDD and PAVDD and the choice there depends on the radio Transmit Power you wish to use. For +14dBm PA an RF VDD are typically 1.8V. For +20dBm PAVDD must be 3.3V.

Every product has unique requirements and sources of power so I can’t enumerate all possible combinations here but follow the recommendations in the datasheets carefully. Copy the radio board or Thunderboard example schematics for most typical applications.

Debug, PTI and Trace Pins

The two Serial Wire Debug (SWD) pins (SWCLK and SWDIO) are necessary to program the chip FLASH and are the minimum required to be able to debug firmware. While it is possible to use these pins for other simple purposes like LEDs, it is best if they are used exclusively for programming/debug. These should be connected to a MiniSimplicity or other debug header.

The SWO debug pin is the next most valuable pin which can be used for debug printfs in the firmware and output to a debugging terminal. Alternatively, the UART TX and RX pins can also be used for debugging with both simple printfs and able to control the firmware using the receive side of the UART to send commands.

The two Packet Trace Interface (PTI) pins provide a “sniffer” feature for the radio. These pins are read by Simplicity Studios Network Analyzer to give a detailed view of all traffic both out of and into the radio. The main advantage of these pins is that they are exactly the received data by the radio. The Z-Wave Zniffer can also be used as a standalone sniffer thereby freeing these pins for any use. The standalone Zniffer however does not show you exactly the same traffic that the PTI pins do especially in noisy or marginal RF conditions. Thus, the PTI pins on the device provide a more accurate view of the traffic to the device under test.

The Trace pins provide additional levels of debug using the Segger J-Trace tool. These pins output compressed data that the debugger can interpret to track the exact program flow of a running program in real time. This level of debug is invaluable for debugging exceptions, interrupts, multi-tasking RTOS threads as well as tracking code coverage to ensure all firmware has been tested. Often these pins are used for other purposes that would not be necessary during firmware debug and testing. Typically LEDs or push buttons can be bypassed during trace debug. There are options to use either 4, 2 or even 1 trace data pin but each reduction in pins cuts the bandwidth and make debugging less reliable.

LFXO and EM4WU Pins

The Low Frequency Crystal Oscillator (LFXO) pins are typically connected to a 32KHz crystal to enable accurate time keeping within several seconds per day. If supporting the Time Command Class, I strongly suggest adding the 32KHz crystal. While you can rely on the LFRCO for time keeping, it can drift by as much as a minute per hour. While you can constantly get updated accurate time from the Hub every now and then, that wastes Z-Wave bandwidth and battery power. Both the Thunderboard and BRD4210 include a 32KHz crystal so you can easily compare the accuracy of each method.

Reserve the EM4WU pins for functions that need to wake the EFR32 from EM4 sleep mode. These are the ONLY pins that can wake from EM4! Note that ports PC and PD are NOT able to switch or input from peripherals while in EM2. See the datasheet and reference manual for more details.

Remaining GPIOs

Many of the remaining GPIOs have alternate functions too numerous for me to mention here. Refer to the datasheet for more details. Most GPIOs can have any of the digital functions routed to them via the PRS. Thus, I2C, SPI, UARTs, Timers and Counters can generally be connected to almost any GPIO but there are some limitations. Analog functions have some flexibility via the ABUS but certain pins are reserved for special functions. Hopefully these tables help you make wise choices about which pin to use for which function on your next Z-Wave product.

Z-Wave Mesh Priority Routes Explained

DrZWave6 Comments

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.

Controlling FLiRS via Associations

DrZWave2 Comments

Frequently Listening Routing Slaves (FLiRS) are a class of Z-Wave devices that are battery powered but wake up every second to check if there is a message waiting for them. FLiRS were initially used for door locks. Door locks have fairly large batteries since they have to move a mechanical device to lock or unlock a door. Typically this is four AA batteries. With this fairly large battery storage, we still need a method to talk to the lock but can’t stay awake all the time as the batteries would only last a week or so. FLiRS to the rescue! FLiRS lets the lock remain asleep 99% of the time and wake up very briefly once per second and listen for an always-on device to be sending a “Wakeup-Beam”. The Beam is a constant transmission of the NodeID and a 1 byte hash of the HomeID telling that specific node to fully wake up and be ready to receive a message. This low-power mode allows Z-Wave devices to run for years on a battery but still be ready to lock or unlock within 1 second.

Z-Wave door locks first appeared in 2008 but since then FLiRS mode has found uses in other battery powered devices. The next most popular FLiRS device are thermostats. Older heating systems which rely on a simple mercury switch have only 2 wires and do not need power. To upgrade these simple switches to a smarthome Z-Wave thermostat means a battery powered device has to last for years on a single set of 3 or 4 AA batteries. FLiRS to the rescue again! Since a user is fine if it takes a few seconds to change thermostat settings, FLiRS is the ideal way to extend battery life and still be connected to the internet.

Recently we’ve had a number of window shades come to market based on FLiRS. Window shades have the challenge that often there is no power near the window so they need to be battery powered. Sometimes a solar cell can help keep the batteries fresh but the FLiRS mode is key to long battery life. Controlling the shades with Alexa is the favorite mode to show off your smarthome – “Alexa, set shades to 0%”. The challenge comes in if you want a battery powered wall switch or some other device to directly control the shades. This is usually done using a Z-Wave Association where the wall switch is “associated” with the shade and then controls the shades without the Hub being involved. This is faster and in some cases can be done without a Hub at all. The trick is getting the wall switch to send the Beam to wake up the shades. Setting the Association is insufficient. A Return Route has to be sent which will tell the wall switch to send a beam.

Association

The first step in directly controlling the shades from a wall switch is to assign the shade to an Association Group. Using the PC Controller application to add the association is done by selecting the destination in the left window and then choosing the Association Group to add it to in the right window. In this case I’ve added the shade NodeID=3 to the Wall Controller NodeID=4 Group 2 which will send a BASIC_SET when I press button 0.

Note the checkbox for Assign Return Routes. Initially I’ll leave this unchecked. This is what many Hubs fail to do properly – set the Return Route anytime an association is made. So what happens when I press Button 0?

The Wall Controller (nodeID=4) sends the Basic Set command 3 times but the Shade (nodeID=3) does not ACK. The Wall Controller tries two more time with Explorer Frames trying enlist anyone else in the network to deliver the frame. But they all fail. Why? Because the Shade is asleep waiting for a Wakeup Beam.

Assign Return Route

To get the Wall Controller to send a FLiRS Wakeup Beam we have to tell it to send one! That is done by assigning a Return Route. In the PC Controller the easy way to do that is to simply check the box in the Association window. The way a Hub should do it is with the SerialAPI command ZW_AssignReturnRoute( SourceNodeID, DestNodeID, callback) which is SerialAPI command 0x46 (see section 4.4.4 of INS13954). We can do this manually in the PC Controller using the Setup Route window shown here. The key is to select the Return Route radio button, then in the left pane select the Wall Controller (the Source NodeID) and in the right pane select the Shade (the Destination), then click on Assign.

When you click on assign you’ll see 4 frames sent from the Hub to the Wall Controller which includes the information to send a FLiRS Beam to the Shade.

These Assign Return Route frames are not officially documented but you can pretty quickly figure out the details of the data. Once the Return Route frames have been delivered to the Wall Controller, it will then send a Wakeup Beam to the Shade before sending the Basic Set.

Here we can see the Shade ACKing the Basic Set in line 72 so the Wakeup Beam did its job and woke up the shade so it was ready to receive the basic set and close the shade.

Z-Wave Long Range Impact

Z-Wave Long Range supports FLiRS types of devices but it doesn’t support Associations. Z-Wave Long Range is a star network so all communication has to go thru the hub. Then the hub forwards the message on to the FLiRS device after Beaming to wake it up. There is no way for a Long Range end device to send a frame to another end device, it has to go thru the controller.

Z-Wave Virtual Academy

DrZWaveLeave a comment
Z-Wave Virtual Webinar Wednesdays at Noon Eastern US time

Doctor Z-Wave will be giving a hands-on live demo of getting started using Z-Wave with Simplicity Studio on Wednesday June 17. This is a live demo with just a couple of slides so you don’t want to miss it. The session is a short roughly 30 minutes with time for Q&A afterward. I will show you some simple things on setting up Simplicity to make your life easier when getting started. If you can’t make it, it will be recorded and available via the Alliance web site.

There are lots of other topics for Webinar Wednesdays:

Webinar Wednesday Schedule*: *This schedule will be updated regularly on the Z-Wave Alliance website as the series progresses
May 27, 2020  
  Manufacturing During a Global Pandemic: Insight & Strategy from Companies Who Are Coping Hosted by: Avi Rosenthal – Bluesalve Partners  
June 3, 2020   Social Distance Sales for Uncertain Times: Tips & Insight for Integrators Hosted by: Jeremy McLerran – Qolsys
June 10, 2020   Residential Smart Lock Market: Trends, Use-Cases & Opportunities Hosted by: Colin DePree – Salto Systems
June 17, 2020 Z-Wave 700 Series: Getting Started Hosted by: Eric Ryherd – Silicon Labs
June 24, 2020  
  Feature of Leedarson Z-Wave 700 Series Security Products Hosted by: Vincent Zhu & Michael Bailey Smith – Leedarson
 

SiLabs acquires Z-Wave – Good or Bad?

DrZWave2 Comments

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.

Z-Wave Summit 2017 at Jasco in Oklahoma City

DrZWaveLeave a comment

“IoT Device Testing Best Practices” by Eric Ryherd

Summit1Click HERE to see the entire presentation including my notes. If you are a Z-Wave Alliance member a video of the presentation is usually posted on the members only section of their web site. The main takeaways from my presentation are:

  • Have a written test plan
  • Use the Compliance Test Tool (CTT) as the START of your test plan
  • Vary the environmental conditions during testing
  • Test using real world applications
  • Test using complex Z-Wave networks with routing and marginal RF links
  • Test with other hubs and devices
  • Automate testing using tools like the ZWP500
  • Code firmware with failure in mind
  • Utilize the WatchDog timer built into the Z-Wave chip

ZWaveSummit2017aThe presentation goes into detail on each of these topics so I won’t duplicate the information here. I also go thru several failures of devices I’ve been working with. You learn more from failures than you do when everything just works. Feel free to comment and let me know what topic you’d like to see for next years summit.

Z-Wave Summit Notes

One of the main purposes of the summit is to learn what’s new in Z-Wave and what Sigma is planning for the future. The most important news at this year’s summit is SmartStart. The goal for SmartStart is to simplify the user experience of installing a new device on a Z-Wave network. The concept is that a customer will open the package for a device, plug it in, the hub is already waiting for the device to be joined and the device just shows up on their phone without having to press a button or enter the 5 digit pin code. This is a “game changer” as Sigma pointed out many times during the summit. Typically a user has to put their hub into inclusion mode, read the product manual to determine the proper button press sequence to put the device into inclusion mode, wait for the inclusion to go thru, write down the NodeID number, with an S2 device they have to read the teeny-tiny 5 digit PIN code printed on the product (or scan the QR code) and then MAYBE the device is properly included. Or more often, they have to exclude and retry the process all over again a couple of times. SmartStart as you can see will make the user experience much easier to get started with Z-Wave.

SmartStart enables “pre-kitting” where a customer buys a hub and several devices as a kit. The hub and the devices in the kit are all scanned at the distribution warehouse and are all white listed on the hub web site. When the customer plugs all the devices in, they automatically join and all just magically show up ready to be used without the frustration of trying to get all the devices connected together. Unfortunately there are no devices that support SmartStart and there are no hubs that support it either – yet. We’ll get over that eventually but I suspect it’ll take a year before any significant numbers of SmartStart supported devices show up on Amazon.

SmartStart is enabled in the SDK release 6.81 which occurred during the summit. There are some other handy features in this release. The main new feature (after SmartStart) is the ability to send a multi-cast FLiR beam. One problem with FLiR devices is that they are all sleeping devices and briefly wake up once per second to see if someone wants to talk to them. Prior to 6.81 you had to wake up the devices one at a time and each one would take more than one second to wake up. If you have battery powered window shades like I do, there is a noticeable delay as the shades start moving one at a time instead of all together. Both the shades and the remote (or hub) will need to be upgraded to 6.81 before we can use this new feature. That means it’ll be again probably another year before this feature is widely available, but it’ll get there eventually.

There are rumors that Sigma will be announcing a new generation of the Z-Wave transceiver chip in early 2018. I am hoping it will will finally include the upgrade from an 8-bit 8051 CPU to a more capable 32-bit ARM CPU.  The current 500 series relies on the ancient 8051 with very limited debugging capabilities which significantly slows firmware development. With an ARM CPU developers like Express Controls will find it easier to hire engineers who can code and debug firmware and thus we’ll be able to bring more Z-Wave products to market in less time.

A new web site, Z-WavePublic.com, has been populated with the Z-Wave documentation as well as images for the Beagle Bone Black and Raspberry Pi loaded with Sigmas Z/IP and Z-Ware. With one of these boards and a USB Z-Stick anyone can start developing with Z-Wave without having to sign a license agreement. Nice way to get started with Z-Wave for you DIY nerds out there. There were many other presentations on Security S2, Certification, The CIT, Z/IP, HomeKit and many other topics on the technical track of the summit. The marketing track had a different set of presentations so I recommend sending both a technical person and a marketing person to the summit.

Summit isn’t all work, work, work

IMG_20170927_090355The Summit isn’t all work all day though the days are long and tiring. Tuesday evening was a reception at Coles Garden which is a beautiful event venue. Unfortunately it was raining so we couldn’t wander thru the gardens much but Mitch, the Alliance Chairman, kept us entertained.

Wednesday evening was the Members Night at the Cowboy museum. Oil profits made a lot of wealthy Oklahomans who were able to make sizable donations to this huge museum. There is a lot more to see than we had time to explore so I’d recommend spending more time here if anyone is visiting Oklahoma City. Lots of food and drink made for an ideal networking environment with your fellow Z-Wave developers.

 

Z-Wave Challenges in MDUs and How to Resolve Them

DrZWaveLeave a comment
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

EZMultipli How-To for Vera

DrZWave4 Comments

vera_logo_tmVera is one of the more popular home automation platforms and with the UI7 release it fully supports the EZMultipli muli-sensor. The main selling points of Vera are “no monthly subscription fee, no contracts and no hassles” which pretty much sums Vera up. Vera is an easy to use system with good support and an active user community who are often quicker to respond to questions than the Vera technical support team.  Vera has several platforms to choose from. I’m using the VeraEdge in this How-To which for only $69 is a good deal. This post will show you how to get the most out of Express Controls EZMultipli Z-Wave MultiSensor and specifically how to use it with Vera UI7. Refer to the EZMultipli User Manual for more details.

EZMultipli Multisensor

ezmultipli200The EZMultipli performs five functions:

  1. Motion Sensor
  2. Temperature Sensor
  3. Light Level Sensor
  4. Color LED indicator
  5. Z-Wave Range Extender

What sets the EZMultipli apart from the typical battery-powered motion sensors is that it is wall powered so you never need to change the batteries! Because EZMultipli is wall powered it is a Z-Wave range extender and adds another routing node in the Z-Wave mesh network. If your Z-Wave network is a little flakey and you have some nodes that are having trouble reporting in reliably, adding an EZMultipli or two will provide additional routes for every Z-Wave node to talk to every other node. The sensors are just a bonus!

Because EZMultipli is simply plugged into an outlet, there is no mounting required. No screws, no tape, no mending of the wall when you move. This makes EZMultipli ideal for apartments, offices or other short-term uses where you’ll want to take it with you when you leave. But what if you don’t have an outlet in the right spot for detecting motion? Ah… that is a problem and not every device can solve every problem. EZMultipli was specifically designed with a wide-angle lens to capture motion in any direction out to about 12 feet. So it doesn’t have to be placed in the perfect location to be able to detect motion where you need it. It is ideal for kitchens, bathrooms and garages which often have unused outlets in handy locations. You can also put it in unused outlets under a table or chair. Obviously it isn’t much good behind a couch or other solid furniture. Some locations like hallways will have to use a battery-powered motion sensor because the sensor has to be in just the right place and there are no outlets in that place.

Another placement problem involves pets. If you put the sensor down low in a typical wall outlet, virtually any pet from a cat to a small dog will trigger the motion sensor. You have to either put the sensor up on a higher outlet or in a room that pets are not allowed in when you need to detect if a burglar is in your home. In my case we always close off our home office from the pets during the day when we are not home. Only the EZMultipli in the office and the one in the garage will send us a text when the home is in Away mode.

Setup and Configuration

The first and most important step is to make sure you are running Vera Firmware Version 1.7.2406 or later. Check the firmware via Settings->Firmware and the screen will show you which version you currently have and if there is an upgrade available. You can include the EZMultipli into Vera but previous firmware versions didn’t understand the Z-Wave Notification command class used by EZMultipli so it isn’t very usable without at least this version.

Include EZMultipli into Vera in the normal way: Devices->Add Device->Generic Z-Wave Device->Next->Next then press the button on the side of EZMultipli. You should get a device called “EZM” which is the default name. Pick a room. Then click on FINISH.

You’ll then have three new devices:

  1. vera3sensorsEZM which is the motion sensor
  2. _Temperature Sensor which is obviously the temperature sensor
  3. _Light Sensor which is the light level in the room

Initially the temperature and light level sensors don’t have a value but in a few minutes the sensors will send readings the values will update. Rename the devices to more meaningful names  by clicking on the > and entering a new name. These three sensors are the main sensors – but where is the color LED? Currently you have to load a Plug-in to use the color LED. Hopefully in a future release Vera will add support for the Z-Wave Color Command Class and we won’t need the plugin anymore. To add the plugin click on Apps->Install Apps and then enter “EZM” into the search bar and the EZMultipli Color Utility will come up. Click on DETAILS and then install the app. While you’re at it, search for DataMine2 graphing plug in and install that too.

vera4sensorsWith the plugin installed there are three more devices but the only one that is interesting is the EZM Light 2 which has the 8 LED color buttons as shown here. Assign that device to the same room as the other EZMultipli sensors. I create a virtual room called ZZZVirtual to put all the extra stuff I don’t normally want to see so it’s at the bottom of the screen.

If you wave your hand in front of the motion sensor, the EZM device will go red indicating the sensor has detected motion. If there is no motion for 10 minutes it will go back to being grey which means no-motion. NOTE! The motion sensor sends a MOTION command when motion is initially detected. Then, only after the OnTime number of minutes of there being a complete lack of motion will the No-MOTION command be sent. The sensor does NOT send a motion command every time it detects motion (though you can enable it to do that).

Vera Scenes

The most common thing you want to do with a motion sensor is to turn on a light when motion is detected and turn it back off again when no one is in the room. With Vera, we do this with Scenes. Click on Scenes->Add Scene. This will open up a wizard that will guide you thru the process. Step 1 picks the device which in this case is EZM and we’ll choose “Whenever EZM detects motion whether is armed or disarmed”. Step 2 is to pick a light to control. In this case we’ll chose the EZM Color and chose the green color. Click on Next step, scroll down and name the scene then click Finish. Next click on the RUN button just to be sure the scene works. There are tons of other options you can choose as part of the scene so try them out and experiment. You can set the scene to only run at certain times of the day or certain days of the week. This is handy for example to set the brightness of a dimmer to be only 20% late at night when all you really want is a night lite to get down a hallway without stepping on the toys your kids left in the hallway.

Configuration Parameters

EZMultipli has five configuration parameters that change how the device responds to various events.

  1. OnTime – Number of minutes the light will stay on when motion is not detected
  2. OnLevel – Dim level sent to Association Group 2 nodes
  3. LiteMin – Number of minutes between luminance reports
  4. TempMin – Number of minutes between temperature reports
  5. TempAdj – Temperature adjustment

The most important parameter is the OnTime parameter. As the name implies, OnTime is the number of minutes the lights will be ON after motion stops being detected. When you walk within range of the motion sensor, Vera receives a Motion event immediately. Vera can then turn lights on or if you configure association group 2 EZMultipli can control the lights directly. Let’s say you then walk around the room for 5 minutes and then walk out of the room. Then 10 minutes later, Vera will be sent a No-Motion event. Why 10 minutes and not 5? Because OnTime is set to 10 minutes which starts counting down when you left the room, not when you entered. Here are some recommended values for the OnTime parameter:

  • OnTime=0 disables sending OFF commands. Only ON commands are sent. This setting is not recommended.
  • OnTime=1 is the minimum setting. For example, late at night you could set the timeout to be only the 1 minute since you’re probably just passing thru. But at dinner time you want a much longer timeout of 30 minutes to prevent Vera from turning the lights off at the dinner table while you are eating dinner. Having to wave your arms in the air in the middle of dinner to turn the lights back on will lower your Wife-Acceptance-Factor (WAF).
  • OnTime=5 minutes is generally a good setting for hallways or other places that you are actively moving thru and only need the lights on while moving thru the space
  • OnTime=10 default setting which is OK for most use cases.
  • OnTime=30 minutes is recommended for rooms where people might be sitting for some time such as in an office or watching TV.
  • OnTime=60 minutes or more might be necessary for a room where someone might be sitting for a long time perhaps reading.

Remember that EZMultipli detects MOTION, not people. So the people have to be moving within range of the sensor otherwise the lights will turn off while they are still in the room!

veraconfigTo change parameters, click on the > on the EZM device and then the Device Options to get the screen shown here. If there are no configuration settings shown, click on the Add Configuration Settings button and one will be created. Select “1 byte dec” in the Data Size field then enter the desired value for the OnTime parameter in the Desired Value field. Then click on Save Changes.

Refer to the EZMultipli User Manual for details on the other parameters. The challenge with the Vera parameter user interface is that it only uses unsigned integers whereas many parameters are signed values. For example, parameter 5 is the TempAdj parameter which is in 1/10ths of a degree Fahrenheit and is a signed number. So if you want to adjust the temperature readings of EZMultipli up by 1.2 degrees you enter 12. But if you want to lower the readings by 1.2 degrees you have to enter the number of 256-12=244. The other parameters are unsigned 1 byte integers so they don’t require this crazy math.

Z-Wave Association Direct Control of Lights

EZMultipli also supports the Z-Wave Association Command class. Associations are used to tell EZMultipli to send ON/OFF commands directly to other Z-Wave devices with out requiring a scene or even talking to Vera. The advantage of Associations is that it results in very fast response times and even if Vera isn’t running the lights will come on and off automatically. Note that if EZMultipli controls a device via Associations, the Vera UI won’t show the new state of the controlled device until it gets around to polling it which can be several minutes later.

Setting associations in Vera involves first clicking on the EZM device and then Device Options. Associations are just below the configuration parameters. Enter a 2 in the Group ID field and then Click on Add Group. Refresh the screen and there should now be Group ID 2. Click on SET and choose the device you want to directly control using EZMultipli. Finally click on Apply Changes. Once this is set, the device that is now associated will automatically turn on when motion is detected and turn off after OnTime minutes when motion is no longer detected.

 

Well that should get you started using EZMultipli with Vera. Future posts will include more advanced usage of the color LED and how to use the other sensors. If you have an interesting use case for the EZmultipli please add a comment or send an email to DrZwave at ExpressControls.com.