Controlling FLiRS via Associations

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 Summit 2017 at Jasco in Oklahoma City

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

 

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.