ZPC Version 2.0.1 - Release Notes (Oct 15, 2026)¶
ZPC is a Linux/macOS-based Z-Wave gateway application that functions as a central static controller in Z-Wave networks. It provides the host-side functionality of the Z-Wave Controller and interacts with the Z-Wave network through the Silicon Labs Network Co-Processor (NCP) controller. As a static controller, ZPC remains continuously powered and acts as the primary hub for managing and coordinating communication among all Z-Wave devices in a smart home network. ZPC provides network management, device control, and state synchronization capabilities through an MQTT-based communication interface.
This is the first certifiable general availability (GA) version of ZPC, with self-certified quality. It follows v2.0.0, keeps the same MQTT interface, adds several new features, and fixes inclusion, interview, and network-management problems found after v2.0.0.
Release Summary¶
Key Features · API Changes · Bug Fixes · Chip Enablement · Known Issues · Impact and Migration
- GA: first certifiable GA release, with self-certified quality.
- New: on-demand interview, Time CC v3, Firmware Update Meta Data Request/Prepare Get, Indicator Set/Report MQTT and Lifeline behavior,
network_statuson node properties. - API: new
Network/Node/Interviewcommand; clearer factory-reset and remove-node MQTT behavior; DSK only when authenticated or provisioned. - Fixes: inclusion/security, interview, network management, and command-class issues found in v2.0.0 (see Bug Fixes).
- Platform: unchanged from v2.0.0 (see Chip Enablement).
Key Features¶
New Features¶
- On-demand interview. Publish
zpc/<home_id>/Network/Node/Interviewwith anode_idto run capability discovery again for a node that is already in the network. When the interview finishes, ZPC publisheszpc/<home_id>/Interview/Report. - Time Command Class, version 3. ZPC answers date and time from the host operating system. The time source is Wi-Fi or the internet. Time Offset stays at zero, and Time Set or Date Set from the network is not applied.
- Firmware Update Meta Data. ZPC now supports Firmware Update Meta Data Request Get and Prepare Get.
- Indicator. An incoming Indicator Set is published on MQTT. After ZPC applies an Indicator Set, it sends an Indicator Report to the Lifeline destinations.
- Node availability in node properties.
Network/Nodeproperties reports includenetwork_status(online,offline, orunknown), using the same values asNetwork/Status/Report.
Enhancements¶
- A Version Report follows the specification. The No Operation command class is reported as version 0.
- Version capabilities are interviewed only when the node supports Version Command Class version 3.
- ZPC no longer advertises internal protocol command classes in the Node Information Frame.
- MQTT commands for a command the node does not support are dropped.
- Incomplete or out-of-range numeric values in MQTT payloads are rejected.
- Classic transmit power above 127 is sent as a 16-bit value. Older controllers that do not accept that value fall back to the previous encoding.
- The S2 timeout used during manual inclusion is longer, so a slow user response is less likely to fail the inclusion.
- A SmartStart node that fails inclusion no longer blocks the next inclusion. The DSK stays in the provisioning list so a later inclusion request can retry.
- ZPC sends a NOP only when self-destruction has just started, or when the NOP is addressed to a failed node.
No features or APIs were removed or deprecated in this release.
API Changes¶
New APIs¶
| New API | Notes |
|---|---|
zpc/<home_id>/Network/Node/Interview |
Request a (re-)interview for one node. Completion is reported on the existing Interview/Report topic. See the Network Management MQTT API. |
Modified APIs¶
- Node properties reports include
network_status. The other fields are unchanged. - A rejected factory reset is published as a report instead of being silent.
- Retained MQTT topics for a removed node are cleared. Clients that kept reading those retained messages after removal will see them disappear.
- Add and Remove reports include a DSK only when that DSK was authenticated or came from the provisioning list. Non-secure, S0, and S2 Unauthenticated inclusions no longer publish a made-up DSK.
Bug Fixes¶
The following table lists issues fixed in this release.
| ID | Issue Description | GitHub / Salesforce Reference (if any) |
|---|---|---|
| 1841567 | After a failed SmartStart S2 inclusion, publishing SmartStart/Remove during the self-destruct NOP wait could restart NOP transmission on every Network Management event and leave ZPC stuck in an infinite NOP loop. NOP is now sent only on the intended self-destruct timeout or Remove Failed path, so cleanup can finish and the next inclusion can proceed. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/165 |
| 1841635 | MQTT requests for command classes or commands that the node does not support were still handed to the attribute resolver, which could flood never-listening nodes with retries on wake-up. Unsupported requests are now dropped without generating a Z-Wave frame. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/150 |
| 1841019, 1783541, 1687510 | A stuck or freshly started interview could stall indefinitely or be aborted immediately (unset progress time treated as a long stall), blocking SmartStart inclusion and later exclude/include sequences. Interviews now keep a valid progress timestamp, stall-detect, and fail out so Network Management returns to idle. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/153 |
| 1839956, 1736357 | Under a high rate of classic SmartStart inclusions, concurrent post-interview work could collide and leave Network Management busy or locked resulting in further inclusions stopped. Post-interview work for SmartStart nodes is serialized and Network Management returns to idle so subsequent inclusions can proceed. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/139 |
| 1837451 | When the self-destruct NOP after a failed SmartStart inclusion did not complete, Network Management could remain locked and block further SmartStart inclusions. Failed self-destruct cleanup now returns Network Management to idle so the next inclusion can start. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/154 |
| 1831951 | ZPC could send Wake Up No More Information repeatedly to a node that was already sleeping, which under stress made ZPC unresponsive and delayed application traffic. The Wake Up resolution listener is registered only after the interview asks for the value, so WUNMI is not repeated incorrectly. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/137 |
| 1831378 | Building with Clang 21 and -Werror failed because discarded [[nodiscard]] results from std::stoul and similar APIs became hard errors. These call sites have been fixed so the project builds cleanly with Clang 21. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/102 |
| 1830226 | Reinclusion stress tests could crash ZPC with a segmentation fault caused by a race condition in attribute timeout handling. Timeout operations are synchronized so the race no longer occurs. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/128 |
| 1829957 | A Network/NLS/State request for a node ID that is not in the network still returned a successful-looking report. The request now returns "fail" when the node is not present. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/159 |
| 1827442 | Certification test CCM_VersionCmdClassCCVersions_Rev01 failed because Version Report did not advertise No Operation command class version 0. ZPC now reports version 0 for No Operation, matching the specification. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/75 |
| 1826880 | When Network Management was busy, Network/FactoryReset was ignored with no MQTT report, so clients could not tell the command was rejected. A rejected factory reset now publishes Network/FactoryReset/Report with "status": "fail". |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/73 |
| 1825100 | Certification test DD_VersionCCData_Rev01 failed because Version Report did not advertise the host application as Firmware 1. ZPC now reports the host app as Firmware 1 and keeps Firmware Update Meta Data target counts in sync. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/66 |
| 1820249 | Certification test CSR_CommandClassIsSupported_Rev02 failed because No Operation was missing from the non-secure Node Information Frame. ZPC now advertises No Operation in the non-secure Application NIF. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/62 |
| 1819914 | Certification test CR_NodeCommissionInterviewOnRequest_Rev01 required on-demand capability discovery. ZPC adds Network/Node/Interview so a node already in the network can be interviewed again, with completion on Interview/Report. Basic is not advertised in the NIF, so re-interview still sends Basic Get even when a Version Report has already stored version 0. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/60 |
| 1818606 | ZPC kept sending Version Command Class version 3 capability queries to nodes that only support version 2. Version capabilities are interviewed only when the node supports Version Command Class version 3. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/141 |
| 1818401 | The Python helper that dumps network keys failed because cryptography was missing from ci/dependencies/requirements.txt. The module is now listed as a dependency. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/163 |
| 1816195 | Certification test TimeCmdClassV3_Rev01 failed because Time Command Class version 3 commands were not answered correctly. ZPC serves date and time from the host OS, keeps Time Offset at zero, and does not apply Time Set or Date Set from the network when the time source is Wi-Fi or the internet. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/11 |
| 1812384 | Certification test CCR_MultilevelSwitchCC_Rev02 failed because Multilevel Switch Set duration was encoded incorrectly (minutes became an unexpected value) and due to incorrect command ordering during interview with Multilevel Switch Supported Get. Duration encoding and interview command order now follow the specification. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/38 |
| 1810873 | While ZPC waited on an S2 send-data timeout, an incoming S2 SOS Nonce Report could be dropped, leaving secure traffic stuck. A valid Nonce Report is now handled so S2 can resynchronize. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/35 |
| 1780533 | If the serial or IP link to the NCP dropped or the NCP was power-cycled, ZPC kept running. ZPC now logs that the Z-Wave API connection was lost and exits so it can be restarted. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/28 |
| 1778916 | During S0 encapsulation, a Transport Service fragment could be treated as a full application message and accidentally trigger NETWORK_KEY_SET. The security key is taken from the whole application message, not from each fragment. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/156 |
| 1773180, 1692694 | After inclusion or exclusion failures, Network Management could remain unready; Network/Node/Add/Abort also had no effect in NM_WAIT_FOR_PROTOCOL. Abort is now accepted while waiting for the protocol and returns Network Management to idle. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/83 |
| 1765317 | Add and Remove reports published a made-up DSK for non-secure, S0, and S2 Unauthenticated inclusions. A DSK is now included only when it was authenticated or came from the provisioning list. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/68 |
| 1751397 | After an OTA update, reinterview could stall forever waiting for an S2 Command Supported Report that never arrived. S0 and S2 Supported Get are retried through the attribute resolver so the interview can complete. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/111 |
| 1739209 | After a node was removed, retained MQTT messages for that node remained on the broker. Retained topics for a removed node are now cleared. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/81 |
| 1738724 | Publishing DSK/Accept while ZPC was still waiting for a key grant was treated as granting all requested keys. Inclusion now tracks whether it is waiting for a key grant or a DSK accept, so DSK/Accept no longer grants keys. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/93 |
| 1738717, 1738713, 1682691 | If the user did not send DSK/Accept or Grant Keys, or responded slowly during manual S2 inclusion, inclusion aborted after a short timeout without a clear Add report. The S2 timeout for manual inclusion is longer, and the secure-add watchdog waits for the S2 user-input timeout, then publishes Network/Node/Add/Report with "status": "fail" and skips interview. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/9 |
| 1687398, 1682677 | Certification tests for SIS Lifeline configuration and sleeping devices failed because Wake Up interview order and Basic Get timing were wrong. Wake Up interview follows the specification step order, and Basic Get is sent only after the Version Report is known. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/6 |
| 1687014 | After an end device restarted, a valid Nonce Report could be dropped by duplicate detection, blocking S2 recovery. A valid Nonce Report from a power-cycled node is accepted so secure traffic can resume. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/84 |
| 1684057 | Certification test RT_CSCIsFirstNodeInNetwork_Rev02 failed because ZPC did not report a failed node correctly. Failed-node reporting for that SIS case now matches the expected behavior. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/21 |
| 1684033 | When a secondary controller included an end device, ZPC node properties were not updated. Node properties now reflect nodes included by a secondary controller. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/18 |
| 1683187 | Thermostat Setpoint version 3 interview failed because capabilities were not queried for each supported setpoint type, and a Get was not sent after a Set. Each supported type is interviewed, and a Get follows a Set. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/23 |
| 1682828 | Multi Command Encapsulation frames were not answered. ZPC accepts MULTI_CMD_ENCAP, handles each enclosed command, rejects truncated or invalid lengths, and continues with remaining commands if one fails. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/46 |
| 1682825 | After applying an Indicator Set, ZPC did not send an Indicator Report to Lifeline destinations. An Indicator Report is now sent to the Lifeline after the Set is applied. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/49 |
| 1682815 | Identify (Indicator) behavior required for certification did not work. Indicator Identify handling now satisfies the Z-Wave Plus v2 Indicator requirements. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/27 |
| 1682705 | Multi Channel interview failed when endpoint IDs were not contiguous. Multi Channel Capability Get and Report handling works for non-contiguous endpoint IDs. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/48 |
| 1682703 | A non-secure Z-Wave Plus Info Get from an S0-only node was rejected. The Get is accepted at the allowed security level for that case. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/25 |
| 1682666 | Multi Channel Association certification failed because Association Set destination rules and S0 interview endpoint handling were wrong. Multi Channel Association Set follows the specification, and an S0 interview continues when the device answers from the root endpoint. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/16 |
| 1682660 | Power Level Test Node Report used an incorrect status field. The report frame now matches the specification. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/3 |
| 1682391, 1674996 | Remove Failed for a node ID that was already gone returned inconsistent results (success for classic/mesh, a different failure for Long Range) and could send a classic/mesh NOP to a truncated Long Range node ID. Remove Failed is rejected consistently when the node is not in the network, and ZPC no longer pings such a node. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/94 |
| 1661837 | With accepted_transmit_failure set to 1, a node was marked failing only on the second transmission failure. The first failed transmission now counts, so the node is marked offline when the configured threshold is reached. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/86 |
| 1660520 | Network/NLS/Enable/Report returned "status": "ok" even when the node does not support Network Layer Security. The enable path reports failure when NLS is not supported. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/88 |
| 1659858 | After the controller was power-cycled, MQTT Switch Binary Get did not drive the radio, while Switch Binary Set and Basic Get still did. MQTT Switch Binary Get now refreshes state like the other command classes. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/28 |
| 1655606 | Classic transmit power values above 127 were reduced before they were sent, so measured RSSI was much lower than with PC Controller. Values above 127 are sent as a 16-bit value, with a fallback for older controllers that do not accept that encoding. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/71 |
| 1650037 | Incomplete or out-of-range numeric values in MQTT payloads (for example Basic Set) were truncated or accepted instead of rejected. Invalid numeric payloads are now rejected by validation. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/87 |
| 1649893 | S2 inclusion could fail when concurrent encrypted traffic from another node occurred during key exchange. Application traffic is held back during S2 key exchange so inclusion can complete. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/132 |
| 1618037 | On a fresh start with an empty database, ZPC reused network keys from the Serial API controller instead of generating new ones. ZPC now generates new network keys on a fresh start. |
Chip Enablement¶
Hardware and software used in verification and certification tests. The platform is unchanged from v2.0.0.
| Component | Hardware | Firmware version |
|---|---|---|
| ZPC | Raspberry Pi 4 Model B | v2.0.1 |
| NCP Controller | BRD4001A WSTK + BRD4205B radio board | Simplicity SDK 2025.12.3 |
| End Device | BRD4001A WSTK + BRD4205B radio board | Simplicity SDK 2025.12.3 |
Known Issues and Limitations¶
For resolved issues, see Bug Fixes.
| ID | Issue or Limitation Description | GitHub / Salesforce Reference (if any) |
|---|---|---|
| 1846920 | When nodes are included one by one with SmartStart on Z-Wave Long Range, the first Long Range SmartStart Prime does not start inclusion, even if the DSK is already on the provisioning list. ZPC logs the Prime and stays idle. Inclusion starts only when a later Long Range Prime arrives. A Prime on classic Z-Wave is ignored when Long Range is the preferred protocol. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/197 |
| 1841591 | After an OTA update, ZPC starts the post-OTA interview as soon as the wait time in the Firmware Update Meta Data Status Report has elapsed. Some devices are not ready yet. They acknowledge S2 Commands Supported Get, then send neither the Report nor an SOS Nonce Report, so the interview stalls until it times out. ZPC does not add extra wait time before that interview. This issue applies only when using a Serial API Controller NCP running Z-Wave SDK 8.1.0 or later. The post-OTA flow works correctly with NCP versions based on Z-Wave SDK 8.0.x. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/195 |
| 1682679 | The certification test LR_ControllerRequestsNoAckFromWOEEN_Rev01 is a known failure caused by incorrect behavior in CTT. A fix is expected in the next CTT version. |
https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/78 |
| 1673178 | If inclusion or interview stops before it finishes, the node can stay in the attribute database. The attribute resolver keeps sending Get commands for the missing attributes and does not time out. That traffic competes with a later inclusion, including S2 bootstrapping, and can delay or fail the new node's security handshake and interview. The leftover node remains until it is removed. | https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/issues/198 |
Impact and Migration¶
v2.0.1 is compatible with a network created by v2.0.0. Existing MQTT clients keep working. No configuration migration is required.
Behavior changes that may affect clients (details under API Changes and Bug Fixes):
- Add and Remove reports no longer contain a DSK unless it was authenticated or provisioned. If an application treated that field as a real device DSK for non-secure, S0, or S2 Unauthenticated inclusions, stop using it unless the inclusion authenticated the DSK or the node was provisioned.
- Retained MQTT messages for a removed node are deleted. If an application depended on retained command-class state remaining after removal, subscribe to the removal report and drop local state there.
Network/Node/Add/Abortcan stop an inclusion that is waiting on the protocol.- Transmit power values above 127 are no longer reduced before they are sent.
- If the serial (or IP) link to the NCP drops, ZPC logs that the Z-Wave API connection was lost and exits. Start ZPC again after the controller is back.
Documentation Changes¶
network_statusis documented on the node properties report in the Network Management MQTT API.- The command class generator input
zwave.xmlwas updated from version 2.16.1 to 2.18.3. - The v2.0.0 known-failing CTT test list is no longer in the repository. Remaining issues are listed under Known Issues.
Using This Release¶
To build and run ZPC, see the Getting Started guide.
For the full documentation set, see the docs README.
Help and Feedback¶
- Contact Silicon Labs Support.
- Get help from our developer community.
- See how to contribute to the project.