Z-Wave SDK Version 8.1.1 - Release Notes (MM DD, YYYY)#

Simplicity SDK Version 2026.6.1

Z-Wave and Z-Wave Long Range SDK are designed to meet the demands of the future smart home and beyond, where increasing needs for more sensors and battery-operated devices require both long range and low power. Context-aware environments are the next evolution in the smart home market, and they require technologies that have been optimized specifically for these applications.

Click here for earlier releases.

Release Summary#

Key Features | API Changes | Bug Fixes | Chip Enablement

Production Use Warning: Due to known issue 1661022, this release cannot be certified on ZG28 devices.

[#TODO remove warning if appropriate]: #

Key Features#

Added in 8.1.1#

None.

Added in 8.1.0#

  • The Silicon Labs Bootloader now supports switching multiprotocol solutions. See the Creating Z-Wave-BLE SMP solution instruction for an example how to build a switched multiprotocol (SMP) firmware which combines a Z-Wave Switch On/Off application and a Bluetooth OTA DFU application that can upgrade the Z-Wave app.

API Changes#

Changed in 8.1.1#

None.

Changed in 8.1.0#

  • (Breaking change) On Series 2, SL_SLEEPTIMER_PERIPHERAL must be SL_SLEEPTIMER_PERIPHERAL_DEFAULT (typically SYSRTC), not BURTC. The platform sleeptimer and Z-Wave deep sleep (zw_shutdown_manager) must not use the same peripheral: BURTC is reserved for EM4 wake-up and compare programming. Project generation fails if BURTC is selected. When you migrate a project from an older SDK, SL_SLEEPTIMER_PERIPHERAL is updated to DEFAULT automatically (Simplicity SDK project migration / upgrade.slcu and sleeptimer_peripheral_upgrade.lua).

Bug Fixes#

Fixed in 8.1.1#

None.

Fixed in 8.1.0#

The following table lists the key issues fixed in this release. For a complete list, see this section.

  • The Multilevel Sensor Command Class now correctly reports its multi-channel capabilities.

  • Network Level Security (NLS) support is no longer enabled by default. Added the optional zw_s2_nls_support component to advertise NLS support in the KEX Report during S2 inclusion. This allows alpha testing of NLS while avoiding certification issues when the feature is not certified.

  • Adjusted the dynamic Tx power algorithm margin to 6 dBm to provide additional headroom and reduce the probability of first-attempt transmission failures.

  • The ZW_DCDC_CONFIG setting (Project Configurator / zw_hardware_config.h) is now applied at startup. Previously, the device always operated in AUTO mode regardless of the configured setting. See the migration guide for information about the available modes. If sleep current remains high after transmission at very low battery voltages (approximately 2.1–2.5 V), consider using BYPASS mode.

  • NLS enabled nodes would accept protocol encrypted commands with a lower security level. This issue is now fixed and NLS enabled nodes will accept only the highest security level for encrypted protocol commands.

  • Use of SerialAPI command Set RF Receive Mode with a FL configured SerialAPI end device would result in an unresponsive device. This issue is now fixed and the node will restart on Set RF Receive Mode ON to ensure correct configuration of the radio.

  • In some cases, the first LR frame after startup was sent with an invalid noise level. Now it waits until a valid noise level is available before sending the first LR frame.

  • Fixed Transport Service handling for Long Range controllers with node IDs above 255 so fragmented responses use the correct destination node ID.

  • Fixed an issue where Serial API Controller could re-enable Long Range auto channel after reset even when Channel A or Channel B had been selected explicitly.

  • Fixed end-of-beam fragment detection so Frequently Listening nodes can acknowledge fragmented beams correctly, improving response latency.

  • Fixed transmission locking so the lock starts only after a successful transmission, avoiding incorrect lockouts after failed attempts.

  • Fixed a CCA/CSMA regression where transmissions could start while the channel was still busy, causing collisions.

  • Corrected LBT/CCA threshold handling for 2-channel and Long Range regions in zpal_radio.

  • Refactored and fixed app_session_id handling through the transmit stack: session IDs are carried from the Serial API into the transport and security layers (S0/S2) and returned in extended TX status, with separate unicast/multicast tracking to avoid overwrites during concurrent sends.

Chip Enablement#

None.

Key Features#

New Features | Enhancements | Removed Features | Deprecated Features

New Features#

Added in 8.1.1#

None.

Added in 8.1.0#

  • The Silicon Labs Bootloader now supports switching multiprotocol solutions. See the Creating Z-Wave-BLE SMP solution instruction for an example how to build a switched multiprotocol (SMP) firmware which combines a Z-Wave Switch On/Off application and a Bluetooth OTA DFU application that can upgrade the Z-Wave app.

  • Added an API to customize the DTPA noise margin from the application.\ Note: The noise margin is not stored in NVM. Applications must set the customized value after each initialization.

  • Added component zw_host_hibernation to support hibernating host controller.

  • Added component zw_cc_wakeoncriticalmessage to support alpha command class Wake On Critical Message.

  • Supported new variant of Pro Kit Mainboard: BRD4002B. The new SHT40 sensor and the previous sensor are supported by a unidriver component for dynamic run-time selection in the sample applications. Note that it causes a RAM usage increase. To avoid increased RAM usage in production, use a dedicated driver for the sensors.

Enhancements#

Added in 8.1.1#

None.

Added in 8.1.0#

  • BURTC is now initialized only in Z-Wave application code (zw_shutdown_manager) for never-listening EM4 entry and wake-up. The platform sl_sleeptimer uses the default peripheral (SYSRTC on Series 2). Remaining sleeptimer ticks are converted to BURTC ticks when programming the EM4 compare register. For internal measurement results from the Sensor PIR sample application, see Smart Start pre-inclusion power.

  • Smart Start pre-inclusion power: For never-listening battery end devices, Smart Start pre-inclusion power consumption is significantly lower. On the Z-Wave Sensor PIR reference application, average supply current measured 4 minutes after startup (device not yet included, Smart Start idle) decreased from about 0.75 mA to about 0.21 mA (~**72%** lower) in internal measurements. Previously, Smart Start kept the radio in a stay-awake state (EM1) between activity instead of allowing deep shutdown, to avoid a dependency on application code. Smart Start now uses an internal state machine that preserves its state in retention across EM4, so pre-inclusion idle periods can use deep sleep instead of holding the radio awake.

  • Increased SPAN decryption capacity on end devices to 5 values per CC:009F.01.00.12.003, reducing network congestion by recovering from lost messages without S2 re-synchronization.

  • Improved S2 SPAN synchronization handling to mitigate conflicts when the sender and the receiver transmit simultaneously.

  • Multilevel Sensor Command Class: Endpoint-aware sensor and scale querying functions are now available.

  • CLI components now only use the iostream component. The app_log component is no longer used by the CLI. This allows logs to be accessed via an interface different from the CLI (e.g., logging through RTT and CLI through UART). Note that a migration script will restore app_log in old projects for backward compatibility.

  • Improved channel lock management in the 3ch region. A channel is now locked only after a successful transmission. Previously, the channel could remain locked even if the transmission failed, especially in case of LBT failure.

  • Improved SmartStart performance when multiple devices are started at the same time, reducing contention during inclusion.

  • Refined SmartStart backoff timing so inclusion activity is spread more evenly across devices.

Removed Features#

None.

Deprecated Features#

None.

API Changes#

New APIs | Modified APIs | Removed APIs | Deprecated APIs

New APIs#

Added in 8.1.1#

None.

Added in 8.1.0#

New API Signature

Deprecated API replaced by this (if any) </thead> <tbody>

cc_multilevel_sensor_get_supported_scale_by_endpoint

None

cc_multilevel_sensor_get_supported_sensors_by_endpoint

None

ZW_dtpa_set_noise_margin

None

ZW_dtpa_get_noise_margin

None </tbody>

For more details, refer to the Migration Guide.

Modified APIs#

Changed in 8.1.1#

None.

Changed in 8.1.0#

Old API

Modified API </thead> <tbody>

SL_SLEEPTIMER_PERIPHERAL default was BURTC

SL_SLEEPTIMER_PERIPHERAL default is now SYSRTC (SL_SLEEPTIMER_PERIPHERAL_DEFAULT). Project configuration (slcp) must use the new default; build validation fails if left as BURTC. Project migration from an older SDK automatically sets non-DEFAULT values to SL_SLEEPTIMER_PERIPHERAL_DEFAULT via upgrade.slcu and sleeptimer_peripheral_upgrade.lua.

zpal_radio_get_background_rssi used to unconditionally return ZPAL_STATUS_OK

zpal_radio_get_background_rssi now returns ZPAL_STATUS_BUSY when the radio is busy or if the underlying RSSI measurement is not available. In this case, rssi is set to SL_RAIL_RSSI_INVALID_DBM. </tbody>

Removed APIs#

Removed in 8.1.1#

None.

Removed in 8.1.0#

Removed API

Was Deprecated?

Explanation

cc_configuration_set_interface

No

Unimplemented function declaration. The behavior can be changed by overriding the weakly defined default implementation.

cc_configuration_set_default_configuration

No

Default configuration parameter values can be defined via the cc_config file.

Deprecated APIs#

None.

Bug Fixes#

Fixed in 8.1.1#

<col width="10%"> <col width="45%"> <col width="20%"> <col width="25%"> </colgroup> <thead>

ID

Issue Description

GitHub / Salesforce Reference (if any)

Affected Software Variants, Hardware, Modes, Host Interfaces </thead> <tbody>

</tbody>

Fixed in 8.1.0#

<col width="10%"> <col width="45%"> <col width="20%"> <col width="25%"> </colgroup> <thead>

ID

Issue Description

GitHub / Salesforce Reference (if any)

Affected Software Variants, Hardware, Modes, Host Interfaces </thead> <tbody>

1556587

Regardless of the endpoint specified in the query, every sensor type supported by the device was reported for every multi channel endpoint and only the supported scales of the first endpoint were reported for any single sensor type.

None

Multilevel Sensor Command Class

1596754

NLS Support was advertised in KEX Report for all end node firmwares since version 7.23.0 even when the feature was not certified, which could cause certification issues. Added optional component (zw_s2_nls_support) to allow users to choose whether to enable NLS support for alpha testing.

None

S2V2, end nodes

1568087

The ZW_DCDC_CONFIG setting had no effect: startup always forced AUTO. The chosen mode (AUTO, BYPASS, or DCDC low-noise) is now applied from zw_hardware_config.h / Project Configurator.

None

Devices using on-chip DC/DC

1506054

With the default AUTO mode, some products on a weak supply (about 2.1–2.5 V) saw higher sleep current after transmitting. You can now change ZW_DCDC_CONFIG (for example BYPASS) instead of being stuck on AUTO.

00332759

Battery / low-voltage supplies, DC/DC-capable parts

1570179

Use of SerialAPI command Set RF Receive Mode with a FL configured SerialAPI end device would result in an unresponsive device. This issue is now fixed and the node will restart on Set RF Receive Mode ON to ensure correct configuration of the radio.

None

SerialAPI End Device in Frequently Listening device type mode

1619678

NLS enabled nodes would accept protocol encrypted commands with a lower security level. This issue is now fixed and NLS enabled nodes will accept only the highest security level for encrypted protocol commands.

None

S2V2, end nodes with NLS support enabled (alpha feature)

1630119

In some cases, the first LR frame after startup was sent with an invalid noise level. Now wait until a valid noise level is available before sending the first LR frame.

None

LR & Dynamic Tx Power Algorithm

1629596

Fixed Transport Service handling for Long Range controllers with node IDs above 255 so fragmented responses use the correct destination node ID.

None

Long Range devices

1625699

Fixed an issue where Serial API Controller could re-enable Long Range auto channel after reset even when Channel A or Channel B had been selected explicitly.

None

NCP Serial API Controller

1568316

Fixed end-of-beam fragment detection so Frequently Listening nodes can acknowledge fragmented beams correctly, improving response latency.

None

Frequently Listening device type

1557297

Reduced never-listening SmartStart awake time so devices no longer stay awake significantly longer than expected during SmartStart activity.

None

Never listening device type

1639024

Fixed transmission locking so the lock starts only after a successful transmission, avoiding incorrect lockouts after failed attempts.

None

3ch region, especially after LBT failure

1620305

Updated background RSSI handling to return zpal_status_busy when the sampled RSSI value is invalid.

None

Z-Wave Platform Abstraction Layer

1594583

Fixed a CCA/CSMA regression where transmissions could start while the channel was still busy, causing collisions.

None

LBT / CCA-CSMA transmit path

1590900

Corrected LBT/CCA threshold handling for 2-channel and Long Range regions in zpal_radio.

None

2-channel regions and Long Range regions

1586442

Refactored and fixed app_session_id handling through the transmit stack: session IDs are carried from the Serial API into the transport and security layers (S0/S2) and returned in extended TX status, with separate unicast/multicast tracking to avoid overwrites during concurrent sends.

None

Serial API command handling

1568859

Frequently Listening device type applications originally created with an SDK version lower than 8.0.0 could become unresponsive when upgraded to a higher SDK version due to a misaligned power-management configuration. Upgrades now apply the required configuration automatically.

None

Frequently Listening device type applications

1562754

Fixed an out-of-bounds access in NOP frame handling.

None

Never Listening and Frequently Listening device type applications before inclusion

1574930

Corrected retry statistics tracking to use proper channel indexing for the LR dynamic channel switch

None

Long Range devices </tbody>

Chip Enablement#

None.

Application Example Changes#

New Examples | Modified Examples | Removed Examples | Deprecated Examples

New Examples#

None.

Modified Examples#

None.

Removed Examples#

None.

Deprecated Examples#

None.

Known Issues and Limitations#

Workarounds

<col width="10%"> <col width="40%"> <col width="15%"> <col width="20%"> <col width="15%"> </colgroup> <thead>

ID

Issue or Limitation Description

GitHub / Salesforce Reference (if any)

Workaround (if any)

Affected Software Variants, Hardware, Modes, Host Interfaces </thead> <tbody>

1399709

Reported S2 command class version remains 1 until certification covers S2v2.

Currently not available.

All Z-Wave applications

369430

All S2 multicast frames are sent using verified delivery S2_TXOPTION_VERIFY_DELIVERY whether or not a response is expected.

Change source code depending on the frame sent.

ZAF

1067228

Zniffer on BRD4204D does not detect LR wakeup beams.

Use different board for sniffing LR wakeup beams.

zwave_ncp_zniffer

1574455

S2v2 alpha implementation allows for disabling NLS via NLS State Set command for experimenting with the alpha implementation. This is not allowed according to the Z-Wave specification and will be removed in the future GA implementation.

S2v2 alpha feature

1619029

When a fragmented beam is transmitted in a 3ch region, the channel hopping is not frequent enough to comply with local regulation.

Currently not available.

Frequently Listening device type

1661022

Radio is not correctly calibrated at startup. Because of this bad calibration, RSSI measurements are affected by close frequencies. In addition to bad noise measurements, this can also affect CCA, so a channel may look busy because of activity on a close frequency. This issue impacts ZG28 and makes this release not certifiable for ZG28. (ZG23 is not affected)

Currently not available.

ZG28

1666189

Frequently Listening (FLiRS) battery applications, such as the door lock example, may experience watchdog resets when the IDLE task does not run often enough to feed the watchdog. The hardware watchdog counts only during EM0 (active) execution. In FLiRS mode, the device wakes briefly for beam reception and other interrupt-driven work; if application changes prevent the IDLE task from feeding the watchdog, EM0 active time from many short wakeups can accumulate until the watchdog timeout is exceeded. Unmodified SDK sample applications are not expected to hit this issue, but customized firmware has no guarantee.

Use FreeRTOS YIELD regularly if no task are scheduled to properly enter IDLE Hook in order to feed properly the watchdog and prevent watchdog resets.

Frequently Listening (FLiRS) end devices: zwave_soc_door_lock_keypad battery-powered end nodes with watchdog enabled

1641161

Zniffer truncates destination node IDs to 8 bits in WakeUp Beam Start frames when connected via USB.

https://github.com/Z-Wave-Alliance/z-wave-tools-core/issues/76

Connect to the Zniffer device via Ethernet.

zwave_ncp_zniffer, </tbody>

Workarounds#

None.

Impact of Release Changes#

Impact Statements | Migration Guide

Impact Statements#

  • Due to known issue 1661022, this release cannot be certified on ZG28 devices.

Migration Guide#

Click here for the migration guide for deprecated, removed, and modified items.

Documentation Changes#

The 'Important Changes' document is now removed. All information relevant to the current release is provided in both the Release Notes and the Migration Guide.

Using This Release#

Installation and Use | Help and Feedback

Installation and Use#

To upgrade your existing software with this release, see instructions in the Migration Guide.

To run your first demo, see our Z-Wave Getting Started for End Devices.

To learn more about the software in this release, dive into our Z-Wave online documentation.

For information about Secure Vault Integration, see Secure Vault.

To review Security and Software Advisory notifications and manage your notification preferences:

  1. Go to https://community.silabs.com/.

  2. Log in with your account credentials.

  3. Click your profile icon in the upper-right corner of the page.

  4. Select Notifications from the dropdown menu.

  5. In the Notifications section, go to the My Product Notifications tab to review historical Security and Software Advisory notifications

  6. To manage your preferences, use the Manage Notifications tab to customize which product updates and advisories you receive.

Help and Feedback#

Note:Ask AI is experimental.

SDK Release and Maintenance Policy#

See our SDK Release and Maintenance Policy.