The Z-Wave Summit & UnPlugFest took place last week in Austin TX. If you missed it, here is a quick Recap. I organized the UnPlugFest on Tuesday which included an RF Range test down the Colorado River right in downtown Austin. The Z-Wave Alliance Reference Application Design (ZRAD) won the maximum range with a distance of 1.1miles (1.7km) which wasn’t quite line-of-sight (LOS). I produced a video of the event which you have to be a member of the Alliance to gain access. Virtually all of the other Z-Wave Long Range Devices tied in a close second place at 0.7mi (1.1km) however we had limited LOS points to test at bridges across the river. We proved that PCB antennas and shipping Z-Wave devices in a noisy RF environment can easily achieve over a kilometer of range. Note that we measured the range where we are getting 100% corruption free, fully encrypted packets at 100kbps. Obviously we could go much farther if we are just trying to get a NOP to ACK but that’s not useful even though other protocols use that as their yardstick.
The Open Source Work Group met in-person in the afternoon to work on finalizing User Code Command Class. Additional Range testing was measured inside the hotel (with concrete floors) where most devices were able to pass thru several floors. Late in the afternoon was the Fireside Chat where we aired our hope, desires and disappointments for Z-Wave. Watch for a survey coming out soon!
Tuesday evening is the network event which was hosted by Silicon Labs where all the Z-Wave personalities meet and renew friendships and business relationships.
My presentation on the Z-Wave Alliance (ZWA) Reference Application Design (ZRAD) is a preview of the soon to be released github project. There were lots of presentations on all sorts of IoT related topics. You can find the presentation on the ZWA members web site.
FUN! Electric Shuffle
After the UnPlugFest and a full day of presentations it was time to relax and join the competition at Electric Shuffle.
Summit Takeaways
This is my personal set of takeaways. Please add yours in the comments below!
- Z-Wave is very much alive!
- Lots of new products have been certified and more are in the pipeline
- Most are Z-Wave Long Range
- Z-Wave spec and Open Source Code continues to improve
- Z-Wave Long Range is indeed Long Range!
- Over 1mi LOS in downtown Austin – over 2mi proven in NH
- Certification for an SDK Update is Review ONLY!
- No need to redo the entire certification process to update the Z-Wave SDK
- Previously a full re-cert was required ($$$!)
- Now you can get the latest bug fixes/security patches and just file paperwork for cheap
- Can add Z-Wave Long Range (ZWLR) to a device and keep the same FCCID
- Can OTA devices already in the field to add ZWLR!
- Requires working with the “right” FCC test house and FCC must be redone with the new frequencies
- Talk to Trident for more details
- Why is the RF range so short in the EU for many devices?
- 500 series devices can only transmit at -1dBm (hardware limitation)
- 700/800 can transmit at +14! More than twice the range!
- Update those EU devices!
- USB Zniffer firmware can capture BOTH ZWLR frequencies
- Select US_LR_END_DEVICE for the region to get ONLY the 2 ZWLR channels (no mesh channels)
- Select US_LR_BACKUP to get the ZWLR B channel and mesh channels
- Select US_LR to get ZWLR A channel and mesh channels
- Z/IP Gateway has a maintenance release expected in June but there will probably only be 1 more maintenance release before it EOLs
- Switch to Unify or Z-Wave JS soon!
DrZWave 
Really great and useful summary! Thank You!
LikeLike
Looking forward to meeting everyone at the EMEA Z-Wave Unplugfest and Summit in Barcelona Spain on 7/8 February 2025. See more details and register here: https://z-wavealliance.org/eve/z-wave-alliance-emea-summit-unplug-fest-2025/
LikeLike
“Switch to Unify or Z-Wave JS soon!”… That’s an advice many will not follow. Not speaking of buying some ready to use home automation solution but DIY: Z-Wave JS is really cumbersome due to it’s language choice (JS for a driver! What a strange idea…) and heavy dependencies (+ will be increasing maintenance nightmare over time). So this needs another pile of isolation (docker) to manage dependencies the dirty (or the microsoft) way, a MQTT server even if everything is co-hosted. Just to drive a serial-usb interface! Ok, typical modern devops work, to sum it up.
=>A nightmare many refuse to get into compared to previous Open-Zwave situation that was much easier from user POV being integrated natively in home management solutions. So legacy zwave <= 500 remains and they go zigbee when more hardware is needed.
Some zwave devices (Qubino Smart-Meter being one, unfortunately at the head of whole home electric power management) are also known for not being supported by ZwaveJS (even if with OZW, there was some glitches on relay control side due to long ACK responses but at least this buggy HW could be handled with a few quirks).
Your advice was shared by some DIY home management that exists since long compared to HA (that is more recent… but here that’s everything that is designed the zwavejs way), but FYI they finally maintained OZW integration (natively or plugin) because users faced many issues (installation nightmare, at least ; unsupported/problematic legacy HW, at worst).
Having no easy way out drive many old zwave addicts to avoid adding new HW using this protocol and build a side-zigbee network to handle anything new. As newest controllers are now unsupported and old 500 ones no more available, after a failure I see many 2nd hand zwave devices just sold on home management forums because their owner don’t want to hear about zwave anymore after the OZW debacle and the labyrinthine thing that followed.
LikeLike
I agree that Silicon Labs has done a huge disservice to the Z-Wave community with the long delays in fixing SerialAPI bugs for the 700/800 series. But those have now been resolved. In this era of super cheap computing (aka Raspberry Pi) having a layered solution to talk Z-Wave works OK and isn’t a performance penalty. But may make long term support more burdensome due to the complexity.
What I want is to replace the SerialAPI is a more complete solution that completely handles all the complex timing of SmartStart, inclusion/exclusion, all security keys and encryption, guaranteed delivery in less than 2s (not spend 60+ seconds trying various routes that don’t work) and better response times in general. The 800 series chips have plenty of CPU power and hardware assist for encryption – why not make use of it! The resulting, much simpler SerialAPI could then be interfaced by anyone easily. Security S2 is really hard to get working, I’ve tried a couple of times without success.
LikeLike