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_PERIPHERALmust beSL_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_PERIPHERALis updated to DEFAULT automatically (Simplicity SDK project migration /upgrade.slcuandsleeptimer_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_supportcomponent 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_CONFIGsetting (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_hibernationto support hibernating host controller.Added component
zw_cc_wakeoncriticalmessageto 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 platformsl_sleeptimeruses 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
iostreamcomponent. Theapp_logcomponent 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 restoreapp_login 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:
Log in with your account credentials.
Click your profile icon in the upper-right corner of the page.
Select Notifications from the dropdown menu.
In the Notifications section, go to the My Product Notifications tab to review historical Security and Software Advisory notifications
To manage your preferences, use the Manage Notifications tab to customize which product updates and advisories you receive.
Help and Feedback#
Contact Silicon Labs Support.
To use our Ask AI tool to get answers, see the search field at the top of this page.
Note:Ask AI is experimental.
Get help from our developer community.
SDK Release and Maintenance Policy#
See our SDK Release and Maintenance Policy.