All posts by DrZWave

Virtually all embedded systems must run 24 x 7 x 365 x many many years without ever being rebooted. Since there is no one there to “press the reset button” if the device fails, the watchdog timer is there to do just that. The 500 series Z-Wave chips from Silicon Labs have a watchdog timer and the example code provides a very minimal use of the watchdog timer. However, the minimal use in the example code is not sufficient to provide a robust watchdog for embedded Z-Wave devices. This post explains some rules and methods to code a robust watchdog timer.

Long time embedded expert Jack Ganssle has a great article on Watchdog timers. He describes the use of a watchdog timer on the Clementine spacecraft where a fault in the system caused the spacecraft to dump virtually of its fuel resulting in the loss of the mission. The lead software engineer had wanted a watchdog but the designers decided not to include it. Jacks example shows how important it is to spend at least some time coding a robust watchdog for our IoT devices. While our devices aren’t controlling multi-million dollar spacecraft, we are coding light switches that are hardwired into the wall and cannot be easily rebooted. Try telling the customer to go into the basement and toggle the power to his entire house to reboot the light switches!

What is a Watchdog?

A watchdog timer is a timer that runs constantly. Typically a complex combination of events resets (or “kicks”) the watchdog timer every now and then, usually every few milliseconds. If the combination of events ever gets stuck, the timer will continue to run. If the watchdog timer “times out”, the system is reset – basically the reset button is pushed! Your embedded system reboots and keeps on running. Generally no one even realizes it has rebooted (I’ll discuss that problem in more detail shortly).

This diagram shows the Watchdog timers value which is constantly counting up. Every time the Watchdog is “kicked”, the counter is reset to zero. Somewhere in your code the ZW_WatchDogKick() routine is called which resets the watchdog timer. Sometimes this reset condition happens on a nice regular basis, sometimes it happens at varying times as shown by the level of the timer. The key is the timeout threshold has to be longer than any normal operating condition. If a fault condition occurs, the timer keeps on counting up until the threshold is reached and then the system is reset. When the watchdog timer fires, the Z-Wave chip goes thru a full reset just as if power had been removed and reapplied. Your embedded system is back up and running as if nothing had happened.

SiLabs Sample Code = Bad Watchdog

The SiLabs sample code has the following implementation of the watchdog:

The sample code has the good implementation practice of putting the Watchdog code inside #defines so it can be easily enabled/disabled. Unfortunately it makes the very large mistake of blindly kicking the dog every ApplicationPoll without checking any other conditions. ApplicationPoll is called roughly every few hundred microseconds and a lot of fault conditions can exist and ApplicationPoll will still be called. With this implementation the only way the watchdog is going to fire is if there is a catastrophic failure and ApplicationPoll is no longer being called. While this implementation is better than nothing, it won’t reset the system in many cases where the device has become unresponsive.

Good Dog Example

Writing good watchdog code requires some significant thought and testing. The possible sources of failure need to be discussed with members of the team and with other Z-Wave developers who are fighting the same fight (thus the need for this blog). I can provide a few guidelines to include in your analysis but this is not a complete solution.

Mutex Gets Stuck

The most common failure I have seen is the fact that the SiLabs provided Application Framework (AF) code mutex can get stuck. When the mutex is stuck, it most often results in the device still able to receive Z-Wave traffic but often can’t respond. If the device is power cycled, then it returns to full operation. So often this failure goes unnoticed both in testing and in actual use.

What is the mutex you ask? The mutex is a simple flag in the AF that prevents the code from overwriting the Send Buffer while a message is currently being sent over the radio. When a GET command comes in, the AF will call a command class handler to handle the GET and build a REPORT frame in memory. When ready to send the frame, the AF will call pTxBuf=GetResponseBuffer() to get a buffer for the radio to send. There is only one buffer so if the buffer is already in use, you get a NULL pointer back and will have to wait and send the frame later. This in general works fine as long as frames don’t come in too fast. But in a large network with lots of repeated and re-routed frames you will occasionally get a bunch of GETs quickly and it is possible for the REPORTs to get cross wired and end up locking up the mutex for a frame that will never be sent. If the code then doesn’t properly release the buffer, the mutex is stuck. The Application Framework code is known to lock the mutex occasionally so you must code around this problem. The easiest solution to this rare event is to ensure the watchdog is watching the mutex and simply reboot if it gets stuck for too long.

My solution is to have a counter that counts up once per second in ApplicationPoll anytime ActiveJobs() is true (in SDK 6.81.xx its now called ZAF_mutex_isActive()). ActiveJobs is true anytime a buffer is in use and false when all the buffers are free. There are actually two buffers, one for response frames (REPORTs sent as a result of a GET) and a second buffer for request frames (unsolicited notifications).

Application Specific Reasons

Beyond the mutex you must think long and hard about application specific failure conditions. The most obvious is that the device has not received or sent a frame in 25 hours. Most hubs will poll a device at least a couple of times per day to make sure it is still alive. So if there has been no traffic in a day, maybe something is stuck and a reboot is in order. Plus if nothing has happened in a day then probably no one will notice the reboot (which only takes 1.5 seconds). You do have to be careful that some other part of the application isn’t impacted as a result of the reboot. For example, if you are a light switch and by default you turn the light off on a reboot, then people will be really annoyed if the light randomly turns off because your hub hasn’t polled it in day. There are lots of potential checks you can make here but every application will have different requirements so you will have to think hard about all the possible conditions for your specific case.

In the example code above we do have a major issue in that if the counters stop counting for some reason, the watchdog will never fire! But that’s easy to check for in ApplicationPoll and if ApplicationPoll itself isn’t running then the WatchDog is no longer being kicked so it will reset.

Doesn’t Work If Not Tested

The old coding adage (proven totally true by me many many times) goes “If the code hasn’t been tested, it doesn’t work”. Same thing applies to your Watchdog code. So how do you test the watchdog? The first thing to do is to log the number of times the watchdog has triggered. This has to be stored in NVM since RAM will be lost when you reboot. Fortunately ApplicationInitHW is called with the bWakeupReason parameter which lets you know the watchdog fired when equal to ZW_WAKEUP_WATCHDOG. Note that usually ApplicationInitHW just stores the bWakeupReason and later in ApplicationInitSW we check it as the NVM isn’t available in InitHW.

Use a Configuration Command Class parameter to read or update this value for testing purposes. I also like to put in a small block of code wrapped in #ifdef WATCHDOG_TESTING_ENABLED that upon receiving a BASIC_SET with a value of 0xDE (not a valid value) calls GetResponseBuffer() which locks up the mutex and in 30 seconds the chip should reboot. If not, then you have a bug in the watchdog code! You can test all the branches in your watchdog code with various values of a BASIC_SET.

When to Enable Watchdog

Perhaps a better question is when NOT to enable the watchdog since ALL production builds absolutely must have the watchdog enabled! My recommendation is to disable the watchdog during development. You want the chip to lock up if you have a bug. The watchdog is really good at masking major bugs since things just keep on working. If the device locks up, then you know something is wrong and you need to chase it down. If you power cycle and the device is fine again, IT IS NOT FINE! You have a bug in your code! During production testing I usually turn the watchdog back on but I also have the testing scripts check the watchdog counter and if it increments then the test fails.

Watchdog Best Practices for Z-Wave Developers

Disable Watchdog during development using #defines

Only kick the watchdog when everything is idle

Kicking every ApplicationPoll is INSUFFICIENT

Check the ActiveJobs() being stuck (aka Mutex)

Check other conditions within your product

Check that the RF has received something every X minutes or hours

Have a way to test the Watchdog during development

Store the number of Watchdog resets in NVM and retrieve them via a configuration parameter

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.

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

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.

In my new role as field applications engineer for Silicon Labs I use virtually every video conferencing app available. What irks me is that none of them can figure out which microphone to use. If the largest corporations in the world with thousands of smart engineers can’t solve this simple problem then I think it’s safe to assume that the singularity is a long way off.

Sorry for posting off the Z-Wave topic but this is truly ridiculous. My job involves supporting customers all over the US and I often call the Z-Wave home office in Denmark. Using a video conferencing app is essential, not so much for the video but to be able to share screens for presentations or demos. I normally use the app my customer prefers so I’ve used all of the popular ones in the last few weeks. Skype, WebEx, Google Hangouts, Zoom, GoToMeeting. bluejeans and the SiLabs corporate solution Lifesize.

Can you hear me?

The start of every call begins with “can you hear me?”. Then various members of the call attempt to get their microphone and speakers to work. After a couple of minutes a few members invariably call into the dial up number and then we can finally get down to business.

I acknowledge the problem isn’t trivial. My laptop has a built in mic, speakers, a line in/out, my docking port has line in/out, my monitor has speakers, I have 2 USB headsets and a Bluetooth one. So there are a lot of possible microphones and speakers.

How hard can it be?

Some apps are better than others. Most give you a menu to change the audio and quickly test the audio before the call starts. Some make reasonable guesses but still get it wrong occasionally. Skype for business is the worst as it gives a limited set of choices because Microsoft “knows” which audio to use but unfortunately is just wrong with no way to pick the correct one. ugh.

Seems to me there is a simple solution – at the start of the call, if the input currently selected has nothing on it but one of the others does, switch to the one with sound!Or at least popup a menu suggesting the user might want to switch to the input with the user yelling “can you hear me” into the mic.

If a few engineers can’t solve this simple problem then I feel we have some time before Skynet becomes self aware and decides to wipe us all out.

The Z-Wave Summit is usually held only once each year in the USA and it is not to be missed. I’ll give a brief overview of what was discussed at the summit in the short post below. But if you didn’t attend in person, you missed the most valuable aspect of the summit which is the chance to meet and talk to other Z-Wave developers. This year the summit was hosted by Bulogics in the city of brotherly love, Philadelphia PA. Bulogics is a Z-Wave certification house so they know everything about Z-Wave and how to have a good time!

Summit Notes

The 700 series was officially “revealed” at the summit with many presentations talking about the new ARM based Z-Wave transceiver. The summit has over 140 attendees from 70 companies not including all the Silicon Labs and Alliance employees. This is the largest attendance of a summit to date and reflects the rapidly growing world of Z-Wave.

Matt Johnson, IoT Sr. VP, described the roadmap for multiprotocol chips which include Z-Wave, zigbee, BLE and Wifi as well as proprietary protocols. For the immediate term though the focus is on getting the 700 series shipping. The real key for Z-Wave is the interoperability and certification ensuring every Z-Wave device can communicate with every other device.

Z-Wave product manager Johan Pedersen presented the important improvements in the 700 series over the 500 series:

ARM M4 32-bit CPU

150% RF range improvement in the US and more in EU/Asia

Lower power and faster wakeup time making coin cell operation a reality

Lower cost due to elimination of the external NVM & SAW

Single HW build for all regions due to elimination of the SAW filter

Longer battery life with 1.8-3.6V operation

Serial debugging

By far my main interest as a developer is that we finally have a real CPU with an M4 and serial debugging so I can finally single step my code and figure out where I went wrong!

The next natural question of course is when will the 700 series be a reality? The answer is “soon”. Ugh. Developers kits are supposed to be available soon and the parts will be shipping in early 2019.

Technical Track

On the second day of the summit the groups are split between marketing and technical geeks like me. More presentations on things like the new Z-Wave Plus V2 requirements which will go into effect with the 700 series release. The V2 requirements significantly ups the bar for support for various command classes with the goal of making Z-Wave devices to fully inform the hub of their capabilities. There should be little or no custom coding to support most V2 devices – the device will tell you everything it can do.

The presentation by Alex Capecelatro, founder of Josh.ai, described the future of voice control which sounds amazing. Alex described just how hard voice control really is and has a long way to go before it really works the way we all want it to. I liked his quote from the New York Times: “We overestimate what technology can do in 3 years but underestimate what can be done in 10 years”. Z-Wave has come a long way in the dozen years it’s been around.

Configuration Command Class

I gave a presentation on Configuration Command Class Version 4 and all the wonderful things it can do. The most notable point is that 2/3rds of the Z-Wave Plus certified devices have at least one Configuration Parameter. Yet many hubs have no way of modifying or displaying to the user the current value of parameters. Z-Wave Plus V2 mandates support for Configuration Command Class V4 for both hubs and devices so you need to get busy! My presentation title is: “The Chicken vs Egg is over: Moving Your Product to Configuration Version 4” which can be downloaded from this link: Z-WaveAlliance2018EricRyherd.

Interoperables Band

Once again the band The Interoperables played at the evening get together at a local brewery. These guys are really good for having only practiced a couple of times!

DrZWave joins Silicon Labs

That’s right, I have officially joined Silicon Labs as an FAE covering the Eastern US. I can be contacted at drzwave@Silabs.com.

The death of the 8-bit CPU has been prognosticated for over a decade but these old tiny workhorses keep going and going and going. Z-Wave is currently based on the venerable Intel 8051 CPU but we’re about to get an upgrade to a 32-bit ARM CPU via the 700 series which is due out later this year. In this posting I’ll give a few tips on coding in C for the 8051 to typically improve speed of execution.

I’ve been writing code for 8-bit CPUs since the 1980s and I designed a few in the 1990s. I also designed a couple of 32-bit RISC CPUs in the 1990s and early 2000s. I often had to squeeze the code just a little harder to get an operation to happen just fast enough to meet a system requirement. This meant that I either had to code in assembly or often just coding C in a slightly different way would convince the compiler to generate the most optimal assembly code for me.

8-bit CPU Architecture

I could go thru a long discussion of the block diagram of the 8051 CPU but instead I’ll just cut to the chase – the 8051 is not at all “C friendly”. The 8051 was architected back in the bad ol’ days of assembly programming – especially for embedded systems where resources were in very short supply (think 1K ROM and 64 bytes of RAM). Thus the architecture has all sorts of funny things that a C compiler can’t take advantage of efficiently. The PSR flags, the D pointer, the single accumulator, memory mapped registers and the SFR registers are all parts of the 8051 that make it special but unfortunately are just not efficient in C. The folks at Keil have worked really hard to make their compiler as efficient as possible and to make access to these non-C hardware resources available without too much effort. But at the end of the day, a C compiler really wants a nice simple block of 32-bit registers to perform integer arithmetic on and a simple flat memory – in other words, a RISC CPU.

In the Z-Wave world, the 8051 in the 500 series chips is a 32 MHz 8051 with 128K bytes of FLASH and 16K bytes of RAM. “But wait” you say, “the 8051 is an 8-bit CPU with a 16-bit Program Counter, how can it address 128K bytes?”. The answer is Bank Switching which is just plain crazy but I won’t get onto that soapbox in this posting. The Z-Wave code from Silicon Labs is delivered as pre-compiled C libraries that the application developer links into their code. The application code is written in C and the Keil compiler does a fine job of squeezing a reasonable amount of code into the tiny 8051. Fortunately in IoT, the task to be performed is usually pretty simple – turn a light on or off by activating a relay connected to a GPIO so we don’t need a multi-Gigahertz CPU with gobs of RAM.

The Silicon Labs SDK comes with a number of sample applications and a bunch of “helper” routines all written in C. Thus, a Z-Wave application can generally be written completely in C, compiled using the Keil compiler and it’ll generally squeeze into the limited code space as long as you don’t try to do too much on this little CPU. But it seems there are always some little things that I just need to do a little faster. The following tips are just a few of the simple tricks I’ve learned from decades of embedded coding.

The Fastest 8051 Loop

What is the fastest 8051 loop you can execute in C?

The most common loop is a simple FOR loop:

for (iter=0;iter<16;iter++) {
...
}

Which is easy to read and does the job just fine – if we don’t need to do it very fast. Often the innermost loop is executed a lot and squeezing just a few instructions out of the code will significantly improve the performance of the routine.

Which as you can see is quite a few instructions and even longer when you consider that each instruction is at least 4 CPU clocks. The Compare and Jump if Not Equal (CJNE) is a 3 byte instruction which requires many clock cycles to execute. If we can squeeze a few instructions out of the loop then it will run much faster. Obviously we could code in assembly but this exercise is to show that HOW you code in C can make a big difference in the performance. An alternative coding of the for loop above is:

iter=16;
do {
...
} while (--iter);

With this slight change in the coding style the while loop turns into a single byte DJNZ opcode as shown below so this is the fastest and most efficient looping structure when targeting the 8051.

The real trick to improving the performance of your code is to see what assembly instructions the code compiles into.

How to See What Your C Code Turns Into

You can’t improve the performance of your code unless you can measure what the performance is and where all the time is being spent. A classic method of measuring the performance is to set a GPIO pin high or low during specific routines. Then use an oscilloscope to observe how long the routine takes. Other options involve printing out markers out a UART or using a hardware timer to measure the duration of a routine.

A simple method to observe the instructions our C code generates for our little 8051 CPU is to use the simulator built into the Keil C compiler. By default the Keil IDE does not have a simulator when using the Silicon Labs sample projects so you have to assign one. Right click on the project then select “options” then click on the “Debug” tab. Then enter “s8051” into the CPU DLL box as shown here. You can now click on Debug->Start/Stop Debug Session or press <CTL>F5. This will enter the Keil Simulator for the 8051. One thing to understand is that this simulator does NOT understand the bank switching of the Silicon Labs version of the 8051 used in the 500 series. Unfortunately you can’t debug code much using this simulator as any bank switching doesn’t work. But it will work well enough to debug small snippets of code and of course to see what you code turns into.

Once the debugger opens in the IDE, click on the line of code you are interested in and the Disassembly window (use View->Disassembly if its not visible) will take you right to the line of code you are interested in as shown here. Note that the C source code is mixed in as comments in the assembly code. This helps guide you to match the C code to the assembly code which can be a little convoluted depending on the optimization the compiler has applied. You can see here that the Do-While has turned into our desired DJNZ single instruction loop.

Don’t rely strictly on the instruction count to guide your C coding style. One slow-down I often see in the Silicon Labs code is they call a subroutine, that calls a subroutine, that calls (several more) subroutines which finally just returns a value. While this may be structured C coding it is very slow in an 8051. Each subroutine call pushes and pops a number of registers and parameters on the stack and each of those takes several clock cycles to perform. Ideally a C macro is used to specify a value or a register which becomes just a single instruction fetch of the value from a register or memory instead of all this pushing and popping.

Unrolling Loops

Another easy speedup in C is to unroll short loops. A classic situation for unrolling loops is when emulating a serial protocol like I2C with a GPIO. Since the loop is typically only 8 passes you can often significantly improve performance by unrolling the loop – often taking the I2C bit rate from under 10Kbps to nearly 100Kbps.

Which works well for short fixed length loops but obviously won’t work in every case. The slow down with the FOR loop involves reloading the accumulator and the D pointer with various constants and the iteration value. The inline version doesn’t have any of these nor are there any delays from looping. This technique also works well on 32-bit RISC processors.

Conclusion

There are a lot more tricks when coding for small 8-bit CPUs. But I’m hoping I won’t have to bother with them for much longer and the dominance of the 32-bit CPU will finally crush the 8-bit out of existence. The price of silicon continues to drop and 32-bit CPUs are often as cheap or even cheaper than these ancient 8-bit boat anchors. The modern CPUs also come with advanced debuggers unlike the 8051 which has… wait for it… printf or worse yet simply toggling an IO. Ugh.

There is a lot of confusion between Z-Wave Plus and older non-Plus devices.

A product that is Z-Wave Plus means it has passed a rigorous certification process and thus is likely to be more reliable and have fewer issues than non-Plus devices. All Z-Wave devices are 100% interoperable and backwards compatible so a Z-Wave Plus device can communicate with any non-Plus device without issue. If you have a choice between a Z-Wave Plus device and a non-Plus device, I recommend you choose the Z-Wave Plus device because the Plus device will work better.

Z-Wave History Lesson

The timeline shows the technology trajectory that Z-Wave has traveled since its inception in 2002.The timeline shows the constant improvement and evolution of Z-Wave. Initially the data rate was only 9600 bits per second. This was fast enough to turn a light or two on or off but as things progressed and you want to slowly change the color of a dozen or more bulbs, then you need a faster data rate. Thus, the increase to 40K with the 300 series and 100K with the 500 series. There are many other enhancements along the way including longer range, better RF sensitivity, lower power, more peripherals and in particular the AES encryption engine. The amazing thing though all of these improvements is that they have all remained 100% backward compatible. Even the latest chips can talk to the early 100 series chips. Granted it is only at the slower 9600 bps but it still works! So the lamp dimmer you bought in 2004 is still able to talk to the latest SmartThings hub.

The Curse of the Even Series

Z-Wave has had some mistakes along the way, after all no one is perfect. Much like the Star Trek Movies, all of the even series chips were flawed and quickly obsoleted. The developers became so fearful of the curse of the even series they skipped the 600 series and jumped straight to 700. The 200 series chips were simply buggy. Period. They had some significant power issues making them difficult to use as a battery powered device among other problems. The flaws were quickly fixed and the series replaced with the largely firmware compatible 300 series which had a long and plentiful life. Many 300 series devices are still in the market though the chips have reached end-of-life so there are limited inventories left. A small number of 300 series chip based devices are Z-Wave Plus – but that number is quite small and there are probably none left on the shelves though you could have one installed in your home. Fortunately, as we’ve seen they are all completely interoperable so no problem there.

The 400 series suffered from a marketing mistake early on – the memory that holds the firmware is One-Time-Programmable (OTP). This means the firmware cannot be updated – EVER. You burn it once, and pray it is good. This is a nightmare for developers as they have to replace the chip every time they make a new firmware build, which they typically do hundreds of times per day. While the OTP saves a fraction of cent in the cost of the chip, the drawbacks far outweigh that tiny cost. Fortunately we developers didn’t have long to wait and the 400 series was replaced with the 500 series. The 500 series had plenty of FLASH and added the ability to update the firmware in the device even after it is installed in the field using a technique called Over-The-Air (OTA) firmware update.

Z-Wave Security – AES Encryption

One of the most important IoT devices is a door lock. Naturally, a door lock needs to be secure. Up until 2008, Z-Wave was “in the clear” meaning it wasn’t secure at all. The Security Command Class was added to encrypt all communication with banking quality AES-128 encryption which makes Z-Wave secure – or so the Z-Wave developers thought.

In 2013 it was widely published that the Z-Wave security has a weakness when a device is first joined to a network. During that process, the encryption “key” is sent to the device over the radio and it is encrypted, but the encryption key is 128 bits of 0. Since the encryption key is all zero, it is possible for someone with very sophisticated equipment to “sniff” the radio data and thus obtain the key to every secure device in the network. While this is a security hole, it requires a lot of equipment on-site at the short time when the user is adding a secure device to the network. Much easier for a burglar to throw a brick thru a window to gain access vs. hacking a Z-Wave door lock. But Z-Wave had to counter with an improvement and they did just that in 2015 – with the updated Security S2 command class.

Security S2 adds full diffe-hellman symmetric encryption to the key exchange. A number of performance improvements were also made which enables battery powered devices to be secure without spending extra time exchanging secrets back and forth. All devices certified after April 2017 are required to support Security S2.

The question of Z-Wave Plus vs. Non-Plus however is independent of Security. Since new devices have to implement Security and they are Z-Wave Plus certified, it seems like the two go together but in reality they are independent. But all new devices will have both which is good. Fortunately support for Security S2 isn’t required to be supported by Hub vendors like SmartThings, Vera, HomeSeer, etc. They will need to add support but all your older non-secure devices will remain 100% backward compatible.

The Future

Z-Wave continues to evolve and improve but continues to remain 100% backward compatible all the way back to 2002 and the initial release of the 100 series transceivers. The Z-Wave Certification program continues to be strengthened with new features and new tests that make every Z-Wave certified product better and completely interoperable with every other Z-Wave device on the market. Interoperability is the advantage Z-Wave has over the many other competing wireless protocols for IoT.

Newer devices have been tested more rigorously and use the latest chip sets for better RF range and mesh network routing algorithms. So given the choice it’s generally better to buy newer devices using the latest technology.

Conclusion

Choose a Z-Wave Plus device over a non-Plus device even if you have to pay a little more. A Z-Wave Plus device uses the 500 series chips with the latest RF technology and firmware and has been tested under the Z-Wave Alliance Certification program which is quite difficult to pass. Rest assured that the Z-Wave device you purchase today will continue to be interoperable with future versions of Z-Wave technology for the foreseeable future.

IoT Device Testing Best Practices by Eric Ryherd

Click 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

The 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. This is the same presentation that gave last fall in the US summit.

Z-Wave Summit Notes

There were nearly 200 attendees at the Summit – a significant increase over last year. One of the main purposes of the summit is to learn what’s new in Z-Wave and what Silicon Labs is planning for the future. The most important news at this year’s summit is the 700 series which was announced at CES in January. Unfortunately we will have to wait a bit longer to get our hands on the chips due to the purchase of Sigma Designs by Silicon Labs. The 700 series chip has been updated to match the other SiLabs microcontrollers so the silicon has been delayed a bit but they expect to ship parts before the end of 2018. Z-Wave will benefit tremendously from a real CPU instead of the very resource constrained 8051 in the 500 series. The feature I can’t wait for is the hardware debugger. We’ll finally be able to single step our C code and inspect variables and set breakpoints. No more PRINTF! Yeah!

Time for hubs to switch to Z/IP and ZWare

The very clear message of the summit is that Z/IP and ZWare are now mature and is THE gateway interface going forward. My initial brief trials with Z/IP were frustrating with poor documentation and the software really wasn’t quite ready. But with the recent release of 2.81 it would appear it is ready for prime time and I’ll have to give it another look. I was surprised by the number of gateway developers that were at the summit and most were already using at least Z/IP and many also using the ZWare abstraction layer. The SerialAPI is the interface most gateway developers have used in the past but this is a very low-level interface. There are many nuances of handling sleeping devices and the complexities of the encrypted security encapsulation when using such a low-level interface. This is where Z/IP comes in which handles nearly all of these lower level details for you. Z/IP is planned to be the only supported interface in the near future and certification costs will be significantly higher if it is not used. ZWare adds another layer on top of the Z/IP which provides much easier C++ objects relieving the developer from having to learn the details of each Z-Wave command class. See the Z-Wave Public web site for more details.

The internal Z-Wave Technical Site (ZTS) is now also available to everyone but you still have to click on “accept terms” to gain access. However the access is granted immediately so you don’t have to wait for “approval”. So anyone wanting to learn about the inner guts of Z-Wave can now do so without buying a DevKit.

Summit isn’t all work, work, work

The Summit isn’t all work all day even though the days are long and filled with lots of technical information. This summit had an evening at the Rosarium park. The park has room for team building games like a maze run, archery, volleyball among other games and of course lots of food and drink. It was a nice ice breaker and a good way to get to know your fellow Z-Wave developers. The networking opportunities are a very large part of the value of attending the summit in person. The evening highlight was a performance by the “Interoperables” Z-Wave Rock and Roll band lead by Alliance chairman Mitch Klein.