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.

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)
CC_UserCredential_send_association_report CC_UserCredential_AssociationReport_tx
ZW_DCDC_CONFIG1
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_lock2
  • zpal_pm_lock2
zw_shutdown_manager_take_temporary_lock
  • zw_power_manager_relock2
  • zpal_pm_relock2
zw_shutdown_manager_release_lock
  • zw_power_manager_lock_cancel2
  • zpal_pm_lock_cancel2
zw_shutdown_manager_init
  • zw_power_manager_init2
  • zpal_pm_init2

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

Removed APIs#

Removed API

Was Deprecated?

zw_power_manager_is_active

No

zw_power_manager_init

No

zw_power_manager_lock

No

zw_power_manager_relock

No

zw_power_manager_lock_cancel

No

zpal_get_max_timeout

No

zpal_pm_lock_is_active

No

zpal_pm_init

No

zpal_pm_lock

No

zpal_pm_relock

No

zpal_pm_lock_cancel

No

zpal_pm_halt

No

zpal_pm_register_domain

No

zpal_zw_pm_event_handler

No

zpal_radio_debug_configure

No

zpal_radio_is_debug_enabled

No

EZWAVECOMMANDTYPE_ZW_GET_PTI_CONFIG

No

EZWAVECOMMANDSTATUS_ZW_GET_PTI_CONFIG

No

Deprecated APIs#

Deprecated API

Planned Removal Date (if any)

Replacement API Name (if any)

CC_UserCredential_send_association_report

TBD

CC_UserCredential_AssociationReport_tx

Bug Fixes#

ID Issue Description GitHub / Salesforce Reference (if any) Affected Software Variants, Hardware, Modes, Host Interfaces
1542556Fixed 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.NoneZAF / User Credential Command Class
1525543Fixed 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.NoneZAF / User Credential Command Class, Binary Switch Command Class
1516742Fixed User Credential Association Reports not being advertised in the list of Lifeline notifications and not being sent to the required Lifeline destinations.NoneZAF / User Credential Command Class
1489288Fixed 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.NoneZAF / User Credential Command Class
1488041A 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.NoneZAF / User Credential Command Class
1480294Fixed the s_colorComponent structure to be compatible with the zaf_config_t.NoneZAF / Color Switch Command Class
1473325Slow refresh has been enabled by default in Central Scene V3 according to the specification.None
  • Central Scene Command Class
  • zwave_soc_wall_controller
1432659Fixed an issue when too many reports are sent when multiple buttons are pressed at once.NoneAll examples
1556171Multilevel 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).NoneMultilevel Sensor Command Class
1490329User-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.NoneAll examples
1356409Fixed an issue where the Serial API controller would not acknowledge the "Initiate Shutdown" command.SF case 00320844Serial API controller
1298116The 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 00315326Serial API controller
1390101Fixed an issue preventing the configuration of a TX output power above +14 dBm in the Serial API controller application.NoneZPAL
1516616Fixed 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.NoneZPAL radio
1358615Addressed 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 00320854ZPAL
378359Previously, 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.NoneZ-Wave stack
1325755Removed an unnecessary duplicate message during the S2 bootstrapping process when S2 Authenticated mode is used.NoneZ-Wave stack

Chip Enablement#

None.

Application Example Changes#

New Examples | Modified Examples | Removed Examples | Deprecated Examples

New Examples#

None.

Modified Examples#

Example Name Changes Supported Software Variants if applicable Supported Modes Supported OPNs / Boards / OPN Combinations Supported Host Interfaces

zwave_soc_sensor_pir

Removed unused device init config: SL_DEVICE_INIT_LFXO_TIMEOUTN/A
    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
    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
    N/A
  • OPN: All Z-Wave supported 800 series OPNs
  • All Z-Wave supported 800 series boards
N/A

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#

ID Issue or Limitation Description GitHub / Salesforce Reference (if any) Workaround (if any) Affected Software Variants, Hardware, Modes, Host Interfaces
1556587Endpoints 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
1568087The configuration value for DC/DC Converter Mode (ZW_DCDC_CONFIG) is not applied.Currently not available.All Z-Wave applications
1399709Reported S2 command class version remains 1 until certification covers S2v2.Currently not available.All Z-Wave applications
369430All 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
1067228Zniffer on BRD4204D does not detect LR wakeup beams.Use different board for sniffing LR wakeup beams.zwave_ncp_zniffer
1556296The 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.
1568316In 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.

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#

SDK Release and Maintenance Policy#

See our SDK Release and Maintenance Policy.