Z-Wave SDK Version 8.0.0 - Release Notes (Jan 22, 2026)#

Simplicity SDK Version 2025.12.0

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

Key Features#

• Addressing the increasing demands for low power in battery-operated devices, the Z-Wave stack is now implemented independently from the platform power state (e.g., energy modes: EM0, EM1, EM1P, EM2, EM3/EM4). This architectural improvement reduces overall stack power consumption during radio events by leveraging the EM1P power state during radio operations instead of EM1. Additionally, using sl_power_manager APIs from application code will no longer interfere with Z-Wave stack radio logic. For more details, refer to the Important Changes section.

• The Z-Wave Long Range TX output power algorithm is refactored. It now tracks independently all the Z-Wave Long Range end devices. It is backward-compatible with the previous algorithm.

• The 9.6 kbps PHY is used only if an end device in the network is not able to operate at a higher modulation rate (40 kbps or 100 kbps).

API Changes#

• The zpal_power_manager module is removed from the Z-Wave Silicon Labs PAL. It is replaced by two entities:

  • A new zw_shutdown_manager component. This module is responsible for sending a never listening end device to the EM4 power state. Requirements can be added by the application to prevent that transition, similarly to the sl_power_manager component.

  • In the zpal_radio PAL layer, new APIs zpal_radio_request_stay_awake and zpal_radio_revoke_stay_awake handle requests to maintain an RX radio state in the stack.

• The Packet Trace Interface (PTI) enablement relies on the standard sl_rail_util_pti component instead of specific Z-Wave stack APIs.

Bug Fixes#

Below are important bugs fixed in this release. For a complete list, refer to this section.

• The previous Z-Wave Long Range TX output power algorithm had an issue in the low output power range. It would revert to transmitting at the maximum output power. The issue is addressed in the newer implementation.

• The FLiRS end device radio behavior was impacted negatively by the use of the zpal_pm_stay_awake() API. It would prevent the Z-Wave stack from properly behaving and acknowledging beam events. With the power management refactoring, this is no longer a concern. The Z-Wave stack behaves independently from application power management decisions.

• NLS Support won't be enabled by default anymore. Added optional component (zw_s2_nls_support) to enable Network Level Security (NLS) support advertisement in the KEX Report during S2 inclusion. This allows alpha testing of NLS while avoiding certification issues when the feature is not certified.

Chip Enablement#

None.

Key Features#

New Features | Enhancements | Removed Features | Deprecated Features

New Features#

The Z-Wave stack is now independent from the power state of the platform, meaning that using sl_power_manager APIs will not interfere with Z-Wave stack logic. It improves the stack power consumption during radio events, leveraging the EM1P power state. Refer to Important Changes for additional information.

Note: This improvement has implications on the application. It is now responsible to keep the EFR32 host awake if required. The Z-Wave stack only handles the radio state.

Enhancements#

• The Z-Wave Long Range TX output power algorithm is refactored. It now tracks independently of all Z-Wave Long Range end devices. It is backward-compatible with the previous algorithm.

• The 9.6 kbps PHY is used only if an end device in the network is not able to operate at a higher modulation rate (40 kbps or 100 kbps).

• The function CC_Configuration_SetValue(), previously only declared without an implementation, has been implemented.

Removed Features#

None.

Deprecated Features#

None.

API Changes#

New APIs | Modified APIs | Removed APIs | Deprecated APIs

New APIs#

New API Signature

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

CC_UserCredential_send_association_report

CC_UserCredential_AssociationReport_tx

ZW_DCDC_CONFIG¹

ZW_EM4_PIN_RETENTION_MODE

SL_DEVICE_INIT_EMU_EM4_PIN_RETENTION_MODE

ZW_EM4_INITIAL_STATE

SL_DEVICE_INIT_EMU_EM4_STATE

ZW_EM23_VOLTAGE_SCALE

ZW_EM4_RETAIN_LFXO

SL_DEVICE_INIT_EMU_EM4_RETAIN_LFXO

ZW_EM4_RETAIN_LFRCO

SL_DEVICE_INIT_EMU_EM4_RETAIN_LFRCO

ZW_EM4_RETAIN_ULFRCO

SL_DEVICE_INIT_EMU_EM4_RETAIN_ULFRCO

zw_shutdown_manager_add_lock

• zw_power_manager_lock²

• zpal_pm_lock²

zw_shutdown_manager_take_temporary_lock

• zw_power_manager_relock²

• zpal_pm_relock²

zw_shutdown_manager_release_lock

• zw_power_manager_lock_cancel²

• zpal_pm_lock_cancel²

zw_shutdown_manager_init

• zw_power_manager_init²

• zpal_pm_init²

</tbody>

¹ The value of ZW_DCDC_CONFIG is currently not applied by the Z-Wave stack.

² The exact replacements for these Power Manager APIs depend on your use case:

• For controlling the power state (i.e. EM state) of the ARM core, use the sl_power_manager API.

• To maintain the Z-Wave radio in an active listening state during periods when the application itself is not transmitting, use the zpal_radio API.

• To prevent the device from entering deep sleep mode, use the zw_shutdown_manager API.

Note that the new lock behavior is significantly different from the previous Power Manager APIs.

For more details, refer to Important Changes and Migration Guide.

Modified APIs#

Old API

Modified API </thead> <tbody>

zpal_tx_power_t

zpal_tx_power_decidbm_t

ZW_TX_POWER_10DBM

ZW_TX_POWER_100_DDBM

ZW_TX_POWER_14DBM

ZW_TX_POWER_140_DDBM

ZW_TX_POWER_20DBM

ZW_TX_POWER_200_DDBM

EZWAVECOMMANDSTATUS_GET_ROUTING_TABLE_LINE

EZWAVECOMMANDSTATUS_GET_NEIGHBOR_TABLE_LINE

EZWAVECOMMANDTYPE_GET_ROUTING_TABLE_LINE

EZWAVECOMMANDTYPE_GET_NEIGHBOR_TABLE_LINE

SUPPORT_GET_ROUTING_TABLE_LINE

SUPPORT_GET_NEIGHBOR_TABLE_LINE </tbody>

Removed APIs#

Deprecated APIs#

Bug Fixes#

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

1542556

Fixed an issue that prevented the modification of credential data via the CLI. All-zero PIN Code credentials (e.g. 0000) are now rejected by default.

None

ZAF / User Credential Command Class

1525543

Fixed lower limit of configuration ranges in CC Binary Switch duration, User Credential CC max credential slots, and minimum and maximum credential data length to allow values of 0.

None

ZAF / User Credential Command Class, Binary Switch Command Class

1516742

Fixed User Credential Association Reports not being advertised in the list of Lifeline notifications and not being sent to the required Lifeline destinations.

None

ZAF / User Credential Command Class

1489288

Fixed applications supporting the User Credential Command Class not reporting support for name encodings ASCII, Extended ASCII, and UTF-16. This applies changes from the 2025A specification.

None

ZAF / User Credential Command Class

1488041

A Credential Report with the status "Credential Unchanged" is now returned if no credentials are deleted after a bulk credential deletion request is received over the air. This applies changes from the 2025A specification.

None

ZAF / User Credential Command Class

1480294

Fixed the s_colorComponent structure to be compatible with the zaf_config_t.

None

ZAF / Color Switch Command Class

1473325

Slow refresh has been enabled by default in Central Scene V3 according to the specification.

None

• Central Scene Command Class

• zwave_soc_wall_controller

1432659

Fixed an issue when too many reports are sent when multiple buttons are pressed at once.

None

All examples

1556171

Multilevel Sensor Command Class support has been extended to include all sensor types and scales defined by the specification. If auto-generating sources from .cc_config files fails, no error message is displayed. It is recommended to run the CC Configurator manually (see DevTools/cc_configurator/README).

None

Multilevel Sensor Command Class

1490329

User-defined configurations in SLC project files related to the Energy Management Unit had not been applied due to the Z-Wave stack initialization process overriding them with hard-coded values. These configurations are now configurable via the Z-Wave Core Component and applied correctly except for the DC/DC Converter Mode (ZW_DCDC_CONFIG), which is still hard-coded.

None

All examples

1356409

Fixed an issue where the Serial API controller would not acknowledge the "Initiate Shutdown" command.

SF case 00320844

Serial API controller

1298116

The Serial API controller could mistake an Explorer Autoinclusion frame as an Application Frame, notifying the host with "junk" data. The packet is now properly handled.

SF case 00315326

Serial API controller

1390101

Fixed an issue preventing the configuration of a TX output power above +14 dBm in the Serial API controller application.

None

ZPAL

1516616

Fixed an issue where the Z-Wave Long Range TX output power algorithm would transmit at maximum power while it was supposed to transmit at a negative TX power.

None

ZPAL radio

1358615

Addressed a behavior where a FLiRS device would not be able to acknowledge a beam when the zpal_pm_stay_awake() API was used.

SF case 00320854

ZPAL

378359

Previously, KEX Fail messages were sent without being secure. They are now sent encrypted with the same level of encryption as the frame at that point of inclusion. The fix aligns with the behavior to the Z-Wave specification.

None

Z-Wave stack

1325755

Removed an unnecessary duplicate message during the S2 bootstrapping process when S2 Authenticated mode is used.

None

Z-Wave stack

1600768

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.

S2V2, end nodes

1603657

Restore the fragmented LR beam length to 3s (it was set to 2s from SDK version 7.20 onwards). The change had introduced a regression where FLiRS devices (configured for 900ms wakeup period) would miss about 10% of the beams.

None

Z-Wave stack

1605311

Fixed an issue that prevented controllers from handling beam ACK when only 1 fragment was remaining.

None

Z-Wave stack

1604659

Fixed an issue where the FLiRS device did not wait for the end of the fragment to send the beam ACK.

None

ZPAL radio </tbody>

Chip Enablement#

None.

Application Example Changes#

New Examples | Modified Examples | Removed Examples | Deprecated Examples

New Examples#

None.

Modified Examples#

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

Example Name

Changes

Supported Software Variants if applicable

Supported Modes

Supported OPNs / Boards / OPN Combinations

Supported Host Interfaces </thead> <tbody>

zwave_soc_sensor_pir

Removed unused device init config: SL_DEVICE_INIT_LFXO_TIMEOUT

N/A

• OPN: All Z-Wave supported 800 series OPNs

• All Z-Wave supported 800 series boards

N/A

All examples

The Energy Management Unit related configurations, previously set in the SLC project files, had been overridden by system_startup_core during the stack init phase. To maintain their visibility, they were moved to the configuration of the zw_core component in a new, hardware-specific header file.

N/A

• OPN: All Z-Wave supported 800 series OPNs

• All Z-Wave supported 800 series boards

N/A

zwave_soc_sensor_pir, zwave_soc_multilevel_sensor

The Sensor PIR and Multilevel Sensor applications now support the S0 security scheme (Security Command Class V1). See Note below this table.

N/A

• OPN: All Z-Wave supported 800 series OPNs

• All Z-Wave supported 800 series boards

N/A </tbody>

Note: The S0 security scheme enablement is introduced regressions on the S0_InvalidNetworkKeySet_Rev01 and S0_SettingNewNetworkKey_Rev01 CTT tests. Currently, these are identified as test-related errors. Clarification is in progress with the Z-Wave Alliance and test house.

Removed Examples#

None.

Deprecated Examples#

None.

Known Issues and Limitations#

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

1556587

Endpoints are handled incorrectly in the Multilevel Sensor Command Class implementations: the sensor types and scales configured for the first endpoint are mirrored to subsequent endpoints, overriding their configuration.

Currently not available.

ZAF / Multilevel Sensor Command Class

1568087

The configuration value for DC/DC Converter Mode (ZW_DCDC_CONFIG) is not applied.

Currently not available.

All Z-Wave applications

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

1556296

The never listening device type activity profile is modified during SmartStart inclusion. It results in improved power consumption when the device is not transmitting smart start frames but additional power consumption during the SmartStart communications (typically from 1.22 µA to 1.89 µA).

Never listening device type.

1568316

In regions that leverage fragmented beams (Japan, Korea, and Long Range), the acknowledgement from the Frequently Listening device can be sent at the end of the fragmented beam instead of when the first fragment is received. This results in an added delay for the end device to notify the beaming device.

Frequently Listening device type. </tbody>

Impact of Release Changes#

Impact Statements | Migration Guide

Impact Statements#

None.

Migration Guide#

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

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#

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