Search the Community

To extend the functionality of KNX integration, we added the ability to send custom commands to KNX network, and to register your own listener to handle reports from the devices. This allows you to control devices that may not be fully supported by the default KNX integration, or to implement specific behaviors that are unique to your setup. The easiest way to handle this is to do it with a QuickApp. Be aware that this functionality is at a testing stage. It may not be fully stable yet, and also the API may change in the future. Sending Custom Commands You can send custom commands to the KNX network by calling the sendCommand action on the KNX integration device (ID 9). This action takes three parameters: The group address to which you want to send the command (e.g. "0/2/0"). DPT of the value you want to send (e.g. "5.001" for DPT_Scaling). The value you want to send. The encoding depends on the DPT you are using. A few simple examples of how to send different DPTs: -- DPT 1.001 (DPT_Switch): function QuickApp:turnOn() hub.call(9, "sendCommand", "0/2/0", "\"1.001\"", true) self:debug("binary switch turned on") self:updateProperty("value", true) end function QuickApp:turnOff() hub.call(9, "sendCommand", "0/2/0", "\"1.001\"", false) self:debug("binary switch turned off") self:updateProperty("value", false) end -- DPT 5.001 (DPT_Scaling): -- Representation of open/close mapping to percentage may differ based on the device you're integrating. function QuickApp:open() hub.call(9, "sendCommand", "0/2/0", "\"5.001\"", 0) self:debug("roller shutter opened") self:updateProperty("value", 99) end function QuickApp:close() hub.call(9, "sendCommand", "0/2/0", "\"5.001\"", 100) self:debug("roller shutter closed") self:updateProperty("value", 0) end -- 232.600 (Colour_RGB) function QuickApp:setPresetColor() local r = 0 local g = 74 local b = 147 local payload = {r, g, b} hub.call(9, "sendCommand", "2/0/16", "232.600", payload) self:updateProperty("colorComponents", {red=r, green=g, blue=b}) end Since we're using device actions to send KNX commands, you can send them in whatever way you want. You can use QuickApps, but you can also use scenes, or direct REST API calls (POST /api/devices/9/action/sendCommand). Listener registration By registering a listener, you can receive updates from the group address and handle them in your QuickApp. This is useful for monitoring device states or reacting to specific events. For now there is no way to register to a specific group address, so you will receive all updates from the KNX network. You can then filter them in your code to react only to the relevant ones. A callback can be registered by calling the registerListener action on the KNX integration device (ID 9). This action takes one argument: The callback URL (an action in your QuickApp) that will be called when there is an update from the KNX network. The URL should be in the format /api/devices/<quick app id>/action/{callback name} e.g. /api/devices/123/action/myCallback. The provided callback will be called with the group address and the value of the update whenever there is an update from the KNX network. Here is an example of how to handle this in a QuickApp: function QuickApp:onInit() -- Register a listener for KNX updates. -- ID 9 is a device that represents the KNX integration. Don't change it. -- "registerListener" is the action to register a listener. Don't change it. -- 3rd parameter is the callback URL (an action), that will be called when there is an update from the KNX network. You can choose any action you want, just make sure to handle it in your QuickApp. In this example we will call "myCallback" action. local callbackURL= "/api/devices/" .. tostring(self.id) .. "/action/myCallback" self:debug("Register KNX callback:", callbackURL) hub.call(9, "registerListener", callbackURL) self:debug("KNX QA started") end -- Callback function to handle KNX updates. The address and value parameters will contain the group address and the value of the update. function QuickApp:myCallback(address, value) self:debug("address:", address, "value:", json.encode(value)) end Debugging You can change the log level of the KNX integration to "debug" or "trace" in order to see more information about the KNX communication itself and about the communication exchanged between the KNX integration and your QuickApp. To do so, just go to the KNX settings in the web interface, and change the system log level in the network communication section.

API Migration: Z-Wave 2 -> Z-Wave 3 Planned release window: beta: 5.202 GA: 5.210 The Z-Wave 2 -> Z-Wave 3 migration is available in the system. This document is intended primarily for integrators and explains how the API changes and how to safely update integrations. 1. What changes the most This document focuses on API differences that matter for external integrations (partner systems, middleware, custom applications). Most device actions retain backward compatibility — the majority of actions previously available through /api/devices/{deviceID}/action/{actionName} remain fully functional in ZW3. Integrations that rely on device actions for switching, dimming, thermostat control, color control, door locks, etc. will continue to work without changes. See Appendix A for the full list of supported actions. In ZW3, Z-Wave infrastructure and management operations are exposed as dedicated REST resources under /api/zwave/.... This includes: configuration parameters, associations, wake-up settings, user codes, firmware update, network management (inclusion/exclusion), and node diagnostics. - The full OpenAPI specification for the new REST API is available via the built-in Swagger UI at /swagger/ — select the "ZwaveEngine Api" section, or navigate directly to /swagger/?urls.primaryName=ZwaveEngine+Api. - New integrations should use the /api/zwave/... REST API wherever possible, as it provides richer functionality, structured responses, and better async operation support. In ZW3, asynchronous operations are explicit: process endpoints (/api/zwave/nm/..., /api/zwave/fw_update_processes/...) and mailbox endpoints (/api/zwave/mailbox/...). Device firmware update is available via two mechanisms in ZW3: - /api/update-service/... — monitors the Fibaro/Nice update server for available official firmware updates. - /api/zwave/fw_update/... — new in ZW3, allows uploading a firmware file directly to a device (CC Firmware Update Meta Data). 2. How to detect the active engine Use the endpoint: GET /api/service/getZwaveEngine Example response: { "version": "3.0", "status": "set" } Recommendation: if the engine is ZW2 -> use legacy paths, if the engine is ZW3 -> use /api/zwave/.... 3. Key functional differences 3.1 Network management (adding/removing devices) ZW2 Most commonly handled through device actions, for example: startAddingDevices, stopAddingDevices, startRemovingDevices, stopRemovingDevices. ZW3 Inclusion: - POST /api/zwave/nm/inclusions - GET /api/zwave/nm/inclusions/{id} - POST /api/zwave/nm/inclusions/{id}/cancel - POST /api/zwave/nm/inclusions/{id}/grant_keys - POST /api/zwave/nm/inclusions/{id}/accept_dsk Exclusion: - POST /api/zwave/nm/exclusions - GET /api/zwave/nm/exclusions/{id} - POST /api/zwave/nm/exclusions/{id}/cancel Important: in ZW3 this is a process model (start -> poll status -> completion). 3.2 Node operations (diagnostics, topology, interview) ZW2 Commonly action-based, for example: requestNodeNeighborUpdate, sendNodeInfo, wakeUpDeadDevice. ZW3 Nodes and details: - GET /api/zwave/nodes - GET /api/zwave/nodes/{node_id} Interview: - GET /api/zwave/nodes/{node_id}/interview - POST /api/zwave/nodes/{node_id}/interview - POST /api/zwave/nodes/{node_id}/interview/cancellation Topology and connectivity: - POST /api/zwave/nodes/{node_id}/ping - GET /api/zwave/nodes/{node_id}/neighbors - POST /api/zwave/nodes/{node_id}/neighbors/update - GET /api/zwave/nodes/{node_id}/last_working_route - POST /api/zwave/nodes/{node_id}/reachability Diagnostics: - GET /api/zwave/nodes/diagnostics/transmissions - DELETE /api/zwave/nodes/diagnostics - DELETE /api/zwave/nodes/diagnostics/{node_id} 3.3 Configuration parameters ZW2 Parameter read/write is usually handled through device actions and device properties. ZW3 GET /api/zwave/configuration_parameters/{addr} GET /api/zwave/configuration_parameters/{addr}/{number} POST /api/zwave/configuration_parameters/{addr}/{number}/value POST /api/zwave/configuration_parameters/{addr}/{number}/default POST /api/zwave/configuration_parameters/{addr}/default POST /api/zwave/polling/configuration_parameters/{addr}/{number} 3.4 Associations ZW2 Associations are managed through legacy plugin endpoints under /api/apps/com.fibaro.zwave/..., for example: - GET /api/apps/com.fibaro.zwave/nodes/{nodeId}/associationGroupInfo - GET /api/apps/com.fibaro.zwave/nodes/{nodeId}/endpoints/{endpointId}/associationGroupInfo - GET /api/apps/com.fibaro.zwave/nodes/{nodeId}/associations - GET /api/apps/com.fibaro.zwave/nodes/{nodeId}/endpoints/{endpointId}/associations - POST /api/apps/com.fibaro.zwave/nodes/{nodeId}/actions (set/add/remove/clear association operations) - GET /api/apps/com.fibaro.zwave/nodes/{nodeId}/actions - GET /api/apps/com.fibaro.zwave/nodes/{nodeId}/actions/{actionId} - DELETE /api/apps/com.fibaro.zwave/nodes/{nodeId}/actions/{actionId} ZW3 GET /api/zwave/associations DELETE /api/zwave/associations/{id} GET /api/zwave/association_groups/{node_id} GET /api/zwave/association_groups/{addr} GET /api/zwave/association_groups/{addr}/{group_id} POST /api/zwave/association_groups/{addr}/{group_id}/associations 3.5 Wake-up (battery devices) ZW2 Most commonly handled through device actions. ZW3 GET /api/zwave/wake_ups/{node_id} PUT /api/zwave/wake_ups/{node_id}/configuration POST /api/zwave/polling/wake_ups/{node_id} mailbox: - GET /api/zwave/mailbox/{node_id}/wake_ups - POST /api/zwave/mailbox/{node_id}/wake_ups/clear 3.6 User codes (door locks) ZW2 Handled through actions such as setUserCode, setUserName, synchronizeUserCodes. ZW3 POST /api/zwave/user_codes/{addr}/synchronize GET /api/zwave/user_codes/{addr} GET /api/zwave/user_codes/{addr}/codes GET /api/zwave/user_codes/{addr}/codes/{user_identifier} PUT /api/zwave/user_codes/{addr}/codes/{user_identifier} POST /api/zwave/user_codes/{addr}/codes/{user_identifier}/clear POST /api/zwave/user_codes/{addr}/clear_all_codes PUT /api/zwave/user_codes/{addr}/master_code POST /api/zwave/user_codes/{addr}/keypad_mode 3.7 Device firmware update In ZW3 there are two independent mechanisms for updating device firmware: 3.7.1 Update Service (/api/update-service/...) The Update Service is a background process that monitors the Fibaro/Nice update server for available firmware updates for supported devices. How it works: The service periodically checks for available firmware — or on demand via POST /api/update-service/updates. Devices with available updates are listed via GET /api/update-service/devices/. To start an update, create a process via POST /api/update-service/processes (with {"deviceId": ...}). Poll the process status via GET /api/update-service/processes/{deviceId} — statuses include Downloading, Queued, WaitingForWakeUp, InProgress (with progress stages), Completed, Failed, Stopped. To stop an update, call POST /api/update-service/processes/{deviceId}/stop. Endpoints: GET /api/update-service/devices/ — list devices with available firmware updates GET /api/update-service/devices/{deviceId} — get update info for a specific device GET /api/update-service/devices_count — number of devices ready to update POST /api/update-service/updates — force check for available updates from server GET /api/update-service/processes — list all update processes POST /api/update-service/processes — start new update process GET /api/update-service/processes/{deviceId} — get update process status POST /api/update-service/processes/{deviceId}/stop — stop update process 3.7.2 Firmware Update from file (/api/zwave/fw_update/...) — new in ZW3 ZW3 introduces the ability to upload a firmware file directly and apply it to a device. This is an implementation of the Z-Wave CC Firmware Update Meta Data command class. How it works: Query supported firmware targets via GET /api/zwave/fw_update/{addr} — returns the list of updatable firmware targets and their IDs. Upload a firmware file via POST /api/zwave/fw_update/{addr}/{target}/request (multipart/form-data with manufacturerId, firmwareId, and the firmware binary). Monitor the process via GET /api/zwave/fw_update_processes or GET /api/zwave/fw_update_processes/{id}. If activation is required, trigger it via POST /api/zwave/fw_update_processes/{id}/activate. Endpoints: GET /api/zwave/fw_update/{addr} — get firmware update info (targets, hardware version, activation support) POST /api/zwave/fw_update/{addr}/{target}/request — upload firmware file and start update GET /api/zwave/fw_update_processes — list all firmware update processes GET /api/zwave/fw_update_processes/{id} — get process status POST /api/zwave/fw_update_processes/{id}/cancel — cancel firmware update POST /api/zwave/fw_update_processes/{id}/activate — activate new firmware GET /api/zwave/fw_update_processes/{id}/activate — get activation status 3.8 Mailbox (pending actions for battery devices) Battery-powered Z-Wave devices spend most of their time asleep and cannot receive commands. When a command is sent to a sleeping device, ZW3 stores it in a mailbox — a queue of pending actions that will be executed automatically when the device next wakes up. How it works: Send a command to a sleeping device (e.g. POST /api/zwave/configuration_parameters/7.0/2/value). Instead of the usual 200 OK, the API responds with 202 Accepted and a JSON body containing the actionId: json {"actionId": 1} The pending action is now queued. You can inspect it via the mailbox endpoints. When the device wakes up, all queued actions are executed automatically. After execution, the actions are removed from the mailbox. Mailbox endpoints per resource type: GET /api/zwave/mailbox/{node_id}/configuration_parameters — pending configuration changes POST /api/zwave/mailbox/{node_id}/configuration_parameters/clear — clear pending configuration changes GET /api/zwave/mailbox/{node_id}/associations — pending association changes POST /api/zwave/mailbox/{node_id}/associations/clear — clear pending association changes GET /api/zwave/mailbox/{node_id}/wake_ups — pending wake-up configuration changes POST /api/zwave/mailbox/{node_id}/wake_ups/clear — clear pending wake-up changes GET /api/zwave/mailbox/{node_id}/user_codes — pending user code changes POST /api/zwave/mailbox/{node_id}/user_codes/clear — clear pending user code changes DELETE /api/zwave/pending_actions/{action_id} — remove a specific pending action by ID The mailbox has a configurable capacity. If the mailbox is full, the API returns an error. 3.9 Polling (on-demand device state refresh) Polling endpoints allow forcing an immediate state refresh from a device. This is useful when you need to ensure the locally cached state is up-to-date with the physical device. All polling endpoints follow the pattern POST /api/zwave/polling/{resource_type}/{addr}/... and return: 200 OK (empty body) for mains-powered devices — the device was polled immediately. 202 Accepted with {"actionId": ...} for sleeping devices — poll request added to the mailbox. Available polling endpoints (selected): POST /api/zwave/polling/configuration_parameters/{addr}/{number} — poll a configuration parameter POST /api/zwave/polling/binary_switches/{addr} — poll binary switch state POST /api/zwave/polling/multilevel_sensors/{addr}/{sensor_type} — poll sensor reading POST /api/zwave/polling/door_locks/{addr} — poll door lock state POST /api/zwave/polling/alarm_sensors/{addr}/{sensor_type} — poll alarm sensor POST /api/zwave/polling/binary_sensors/{addr}/{sensor_type} — poll binary sensor POST /api/zwave/polling/color_switches/{addr}/{component_id} — poll color component POST /api/zwave/polling/user_codes/{addr}/codes/{user_identifier} — poll user code POST /api/zwave/polling/wake_ups/{node_id} — poll wake-up configuration POST /api/zwave/polling/association_groups/{addr}/{group_id} — poll association group POST /api/zwave/polling/protection/{addr} — poll protection state POST /api/zwave/polling/sound_switches/{addr} — poll sound switch state POST /api/zwave/polling/window_covering/{addr}/parameters/{parameter_id} — poll window covering POST /api/zwave/polling/central_scenes/{addr} — poll central scene configuration POST /api/zwave/polling/schedule/{addr}/{block_id}/{schedule_id} — poll schedule entry POST /api/zwave/polling/basic/{addr} — poll basic value POST /api/zwave/polling/failed_nodes — poll failed nodes list 4. ZW3 asynchronous model (what this means for integrations) In ZW3, some operations do not return final state immediately. Integrations should: store the process identifier, poll the status endpoint, handle mailbox queue responses (especially for battery-powered devices), treat the operation as complete only after final status is returned. 5. Before/after examples A) Start inclusion ZW2: POST /api/devices/{deviceID}/action/startAddingDevices ZW3: POST /api/zwave/nm/inclusions Content-Type: application/json {"networkWide": true, "allowS0": false, "allowS2": true} B) Set user code ZW2: POST /api/devices/{deviceID}/action/setUserCode Content-Type: application/json {"args": [1, "1234"]} ZW3: PUT /api/zwave/user_codes/15.0/codes/1 Content-Type: application/json {"userCode": "1234", "userIdStatus": "AVAILABLE"} C) Set configuration parameter ZW2: POST /api/devices/{deviceID}/action/setConfiguration Content-Type: application/json {"args": [2, 1, 0]} ZW3: POST /api/zwave/configuration_parameters/15.0/2/value Content-Type: application/json {"value": 0} For a sleeping (battery) device the response is 202 Accepted with {"actionId": 1} — the action is queued in the mailbox and will be applied on the next wake-up. D) Add association ZW2: POST /api/devices/{deviceID}/action/associationSet Content-Type: application/json {"args": [{"groupingId": 2, "singleChannel": [1]}]} ZW3: POST /api/zwave/association_groups/15.0/2/associations Content-Type: application/json {"destinationNode": 1, "destinationEndpoint": 0} Appendix A: Supported legacy device actions The following 101 device actions remain available in ZW3 via /api/devices/{deviceID}/action/{actionName} for backward compatibility. Switching & level control turnOn, turnOff, open, close, startLevelIncrease, startLevelDecrease, stopLevelChange, stop, step, pause Brightness & values setValue, setValue2, setBrightness, setVolume, poll Color control setColor, setColorComponents, setR, setG, setB, setW, startColorEnhancement, startColorFade, stopColorChange Thermostat setThermostatMode, setThermostatFanMode, setHeatingThermostatSetpoint, setCoolingThermostatSetpoint, setFurnaceThermostatSetpoint, setDryAirThermostatSetpoint, setMoistAirThermostatSetpoint, setAutoChangeoverThermostatSetpoint, setEnergySaveHeatingThermostatSetpoint, setEnergySaveCoolingThermostatSetpoint, setAwayHeatingThermostatSetpoint, setAwayCoolingThermostatSetpoint, setFullPowerThermostatSetpoint Door lock secure, unsecure, unsecureWithTimeout, unsecureInside, unsecureInsideWithTimeout, unsecureOutside, unsecureOutsideWithTimeout, setDoorLockMode User codes setUserCode, setUserCodeDec, setUserName, deleteUserCode, getUserCode, getMaxUsers, synchronizeUserCodes Scheduling setSchedule, setAllSchedules, removeSchedule, setOverrideSchedule, removeOverrideSchedule, setScheduleState Node management removeFailedNode, requestNodeNeighborUpdate, getNeighborList, getLastWorkingRoute, markDead, wakeUpDeadDevice Protection setProtection, setExclusiveControl, setTimeout All Switch mode switchAllOn, switchAllOff, switchAllGet, switchAllSetMode Indicator identify, indicatorGet, setIndicatorValue Metering reset, resetMeter, clearEnergyData Configuration setConfiguration, readWholeConfiguration AV control getSupportedCommands, sendAVControl Window covering setSlatsAngle, setFavoritePosition, configureFavoritePositions, startCalibration Barrier operator setAllSubsystems Black box getRecords, removeRecords Sound switch setTone, setDefaultTone, setArmed, setSequence, removeSequence Device-specific setDefaultPartyTime, startProgram, setRingsLightMode, setTamperMode, setAutoFanMode, setUnlockSequence, setLockKey, setIdleTimeout, configure

API Migration: Z-Wave 2 -> Z-Wave 3 Planned release window: beta: 5.202 GA: 5.210 The Z-Wave 2 -> Z-Wave 3 migration is available in the system. This document is intended primarily for integrators and explains how the API changes and how to safely update integrations. 1. What changes the most This document focuses on API differences that matter for external integrations (partner systems, middleware, custom applications). Most device actions retain backward compatibility — the majority of actions previously available through /api/devices/{deviceID}/action/{actionName} remain fully functional in ZW3. Integrations that rely on device actions for switching, dimming, thermostat control, color control, door locks, etc. will continue to work without changes. See Appendix A for the full list of supported actions. In ZW3, Z-Wave infrastructure and management operations are exposed as dedicated REST resources under /api/zwave/.... This includes: configuration parameters, associations, wake-up settings, user codes, firmware update, network management (inclusion/exclusion), and node diagnostics. - The full OpenAPI specification for the new REST API is available via the built-in Swagger UI at /swagger/ — select the "ZwaveEngine Api" section, or navigate directly to /swagger/?urls.primaryName=ZwaveEngine+Api. - New integrations should use the /api/zwave/... REST API wherever possible, as it provides richer functionality, structured responses, and better async operation support. In ZW3, asynchronous operations are explicit: process endpoints (/api/zwave/nm/..., /api/zwave/fw_update_processes/...) and mailbox endpoints (/api/zwave/mailbox/...). Device firmware update is available via two mechanisms in ZW3: - /api/update-service/... — monitors the Fibaro/Nice update server for available official firmware updates. - /api/zwave/fw_update/... — new in ZW3, allows uploading a firmware file directly to a device (CC Firmware Update Meta Data). 2. How to detect the active engine Use the endpoint: GET /api/service/getZwaveEngine Example response: { "version": "3.0", "status": "set" } Recommendation: if the engine is ZW2 -> use legacy paths, if the engine is ZW3 -> use /api/zwave/.... 3. Key functional differences 3.1 Network management (adding/removing devices) ZW2 Most commonly handled through device actions, for example: startAddingDevices, stopAddingDevices, startRemovingDevices, stopRemovingDevices. ZW3 Inclusion: - POST /api/zwave/nm/inclusions - GET /api/zwave/nm/inclusions/{id} - POST /api/zwave/nm/inclusions/{id}/cancel - POST /api/zwave/nm/inclusions/{id}/grant_keys - POST /api/zwave/nm/inclusions/{id}/accept_dsk Exclusion: - POST /api/zwave/nm/exclusions - GET /api/zwave/nm/exclusions/{id} - POST /api/zwave/nm/exclusions/{id}/cancel Important: in ZW3 this is a process model (start -> poll status -> completion). 3.2 Node operations (diagnostics, topology, interview) ZW2 Commonly action-based, for example: requestNodeNeighborUpdate, sendNodeInfo, wakeUpDeadDevice. ZW3 Nodes and details: - GET /api/zwave/nodes - GET /api/zwave/nodes/{node_id} Interview: - GET /api/zwave/nodes/{node_id}/interview - POST /api/zwave/nodes/{node_id}/interview - POST /api/zwave/nodes/{node_id}/interview/cancellation Topology and connectivity: - POST /api/zwave/nodes/{node_id}/ping - GET /api/zwave/nodes/{node_id}/neighbors - POST /api/zwave/nodes/{node_id}/neighbors/update - GET /api/zwave/nodes/{node_id}/last_working_route - POST /api/zwave/nodes/{node_id}/reachability Diagnostics: - GET /api/zwave/nodes/diagnostics/transmissions - DELETE /api/zwave/nodes/diagnostics - DELETE /api/zwave/nodes/diagnostics/{node_id} 3.3 Configuration parameters ZW2 Parameter read/write is usually handled through device actions and device properties. ZW3 GET /api/zwave/configuration_parameters/{addr} GET /api/zwave/configuration_parameters/{addr}/{number} POST /api/zwave/configuration_parameters/{addr}/{number}/value POST /api/zwave/configuration_parameters/{addr}/{number}/default POST /api/zwave/configuration_parameters/{addr}/default POST /api/zwave/polling/configuration_parameters/{addr}/{number} 3.4 Associations ZW2 Associations are managed through legacy plugin endpoints under /api/apps/com.fibaro.zwave/..., for example: - GET /api/apps/com.fibaro.zwave/nodes/{nodeId}/associationGroupInfo - GET /api/apps/com.fibaro.zwave/nodes/{nodeId}/endpoints/{endpointId}/associationGroupInfo - GET /api/apps/com.fibaro.zwave/nodes/{nodeId}/associations - GET /api/apps/com.fibaro.zwave/nodes/{nodeId}/endpoints/{endpointId}/associations - POST /api/apps/com.fibaro.zwave/nodes/{nodeId}/actions (set/add/remove/clear association operations) - GET /api/apps/com.fibaro.zwave/nodes/{nodeId}/actions - GET /api/apps/com.fibaro.zwave/nodes/{nodeId}/actions/{actionId} - DELETE /api/apps/com.fibaro.zwave/nodes/{nodeId}/actions/{actionId} ZW3 GET /api/zwave/associations DELETE /api/zwave/associations/{id} GET /api/zwave/association_groups/{node_id} GET /api/zwave/association_groups/{addr} GET /api/zwave/association_groups/{addr}/{group_id} POST /api/zwave/association_groups/{addr}/{group_id}/associations 3.5 Wake-up (battery devices) ZW2 Most commonly handled through device actions. ZW3 GET /api/zwave/wake_ups/{node_id} PUT /api/zwave/wake_ups/{node_id}/configuration POST /api/zwave/polling/wake_ups/{node_id} mailbox: - GET /api/zwave/mailbox/{node_id}/wake_ups - POST /api/zwave/mailbox/{node_id}/wake_ups/clear 3.6 User codes (door locks) ZW2 Handled through actions such as setUserCode, setUserName, synchronizeUserCodes. ZW3 POST /api/zwave/user_codes/{addr}/synchronize GET /api/zwave/user_codes/{addr} GET /api/zwave/user_codes/{addr}/codes GET /api/zwave/user_codes/{addr}/codes/{user_identifier} PUT /api/zwave/user_codes/{addr}/codes/{user_identifier} POST /api/zwave/user_codes/{addr}/codes/{user_identifier}/clear POST /api/zwave/user_codes/{addr}/clear_all_codes PUT /api/zwave/user_codes/{addr}/master_code POST /api/zwave/user_codes/{addr}/keypad_mode 3.7 Device firmware update In ZW3 there are two independent mechanisms for updating device firmware: 3.7.1 Update Service (/api/update-service/...) The Update Service is a background process that monitors the Fibaro/Nice update server for available firmware updates for supported devices. How it works: The service periodically checks for available firmware — or on demand via POST /api/update-service/updates. Devices with available updates are listed via GET /api/update-service/devices/. To start an update, create a process via POST /api/update-service/processes (with {"deviceId": ...}). Poll the process status via GET /api/update-service/processes/{deviceId} — statuses include Downloading, Queued, WaitingForWakeUp, InProgress (with progress stages), Completed, Failed, Stopped. To stop an update, call POST /api/update-service/processes/{deviceId}/stop. Endpoints: GET /api/update-service/devices/ — list devices with available firmware updates GET /api/update-service/devices/{deviceId} — get update info for a specific device GET /api/update-service/devices_count — number of devices ready to update POST /api/update-service/updates — force check for available updates from server GET /api/update-service/processes — list all update processes POST /api/update-service/processes — start new update process GET /api/update-service/processes/{deviceId} — get update process status POST /api/update-service/processes/{deviceId}/stop — stop update process 3.7.2 Firmware Update from file (/api/zwave/fw_update/...) — new in ZW3 ZW3 introduces the ability to upload a firmware file directly and apply it to a device. This is an implementation of the Z-Wave CC Firmware Update Meta Data command class. How it works: Query supported firmware targets via GET /api/zwave/fw_update/{addr} — returns the list of updatable firmware targets and their IDs. Upload a firmware file via POST /api/zwave/fw_update/{addr}/{target}/request (multipart/form-data with manufacturerId, firmwareId, and the firmware binary). Monitor the process via GET /api/zwave/fw_update_processes or GET /api/zwave/fw_update_processes/{id}. If activation is required, trigger it via POST /api/zwave/fw_update_processes/{id}/activate. Endpoints: GET /api/zwave/fw_update/{addr} — get firmware update info (targets, hardware version, activation support) POST /api/zwave/fw_update/{addr}/{target}/request — upload firmware file and start update GET /api/zwave/fw_update_processes — list all firmware update processes GET /api/zwave/fw_update_processes/{id} — get process status POST /api/zwave/fw_update_processes/{id}/cancel — cancel firmware update POST /api/zwave/fw_update_processes/{id}/activate — activate new firmware GET /api/zwave/fw_update_processes/{id}/activate — get activation status 3.8 Mailbox (pending actions for battery devices) Battery-powered Z-Wave devices spend most of their time asleep and cannot receive commands. When a command is sent to a sleeping device, ZW3 stores it in a mailbox — a queue of pending actions that will be executed automatically when the device next wakes up. How it works: Send a command to a sleeping device (e.g. POST /api/zwave/configuration_parameters/7.0/2/value). Instead of the usual 200 OK, the API responds with 202 Accepted and a JSON body containing the actionId: json {"actionId": 1} The pending action is now queued. You can inspect it via the mailbox endpoints. When the device wakes up, all queued actions are executed automatically. After execution, the actions are removed from the mailbox. Mailbox endpoints per resource type: GET /api/zwave/mailbox/{node_id}/configuration_parameters — pending configuration changes POST /api/zwave/mailbox/{node_id}/configuration_parameters/clear — clear pending configuration changes GET /api/zwave/mailbox/{node_id}/associations — pending association changes POST /api/zwave/mailbox/{node_id}/associations/clear — clear pending association changes GET /api/zwave/mailbox/{node_id}/wake_ups — pending wake-up configuration changes POST /api/zwave/mailbox/{node_id}/wake_ups/clear — clear pending wake-up changes GET /api/zwave/mailbox/{node_id}/user_codes — pending user code changes POST /api/zwave/mailbox/{node_id}/user_codes/clear — clear pending user code changes DELETE /api/zwave/pending_actions/{action_id} — remove a specific pending action by ID The mailbox has a configurable capacity. If the mailbox is full, the API returns an error. 3.9 Polling (on-demand device state refresh) Polling endpoints allow forcing an immediate state refresh from a device. This is useful when you need to ensure the locally cached state is up-to-date with the physical device. All polling endpoints follow the pattern POST /api/zwave/polling/{resource_type}/{addr}/... and return: 200 OK (empty body) for mains-powered devices — the device was polled immediately. 202 Accepted with {"actionId": ...} for sleeping devices — poll request added to the mailbox. Available polling endpoints (selected): POST /api/zwave/polling/configuration_parameters/{addr}/{number} — poll a configuration parameter POST /api/zwave/polling/binary_switches/{addr} — poll binary switch state POST /api/zwave/polling/multilevel_sensors/{addr}/{sensor_type} — poll sensor reading POST /api/zwave/polling/door_locks/{addr} — poll door lock state POST /api/zwave/polling/alarm_sensors/{addr}/{sensor_type} — poll alarm sensor POST /api/zwave/polling/binary_sensors/{addr}/{sensor_type} — poll binary sensor POST /api/zwave/polling/color_switches/{addr}/{component_id} — poll color component POST /api/zwave/polling/user_codes/{addr}/codes/{user_identifier} — poll user code POST /api/zwave/polling/wake_ups/{node_id} — poll wake-up configuration POST /api/zwave/polling/association_groups/{addr}/{group_id} — poll association group POST /api/zwave/polling/protection/{addr} — poll protection state POST /api/zwave/polling/sound_switches/{addr} — poll sound switch state POST /api/zwave/polling/window_covering/{addr}/parameters/{parameter_id} — poll window covering POST /api/zwave/polling/central_scenes/{addr} — poll central scene configuration POST /api/zwave/polling/schedule/{addr}/{block_id}/{schedule_id} — poll schedule entry POST /api/zwave/polling/basic/{addr} — poll basic value POST /api/zwave/polling/failed_nodes — poll failed nodes list 4. ZW3 asynchronous model (what this means for integrations) In ZW3, some operations do not return final state immediately. Integrations should: store the process identifier, poll the status endpoint, handle mailbox queue responses (especially for battery-powered devices), treat the operation as complete only after final status is returned. 5. Before/after examples A) Start inclusion ZW2: POST /api/devices/{deviceID}/action/startAddingDevices ZW3: POST /api/zwave/nm/inclusions Content-Type: application/json {"networkWide": true, "allowS0": false, "allowS2": true} B) Set user code ZW2: POST /api/devices/{deviceID}/action/setUserCode Content-Type: application/json {"args": [1, "1234"]} ZW3: PUT /api/zwave/user_codes/15.0/codes/1 Content-Type: application/json {"userCode": "1234", "userIdStatus": "AVAILABLE"} C) Set configuration parameter ZW2: POST /api/devices/{deviceID}/action/setConfiguration Content-Type: application/json {"args": [2, 1, 0]} ZW3: POST /api/zwave/configuration_parameters/15.0/2/value Content-Type: application/json {"value": 0} For a sleeping (battery) device the response is 202 Accepted with {"actionId": 1} — the action is queued in the mailbox and will be applied on the next wake-up. D) Add association ZW2: POST /api/devices/{deviceID}/action/associationSet Content-Type: application/json {"args": [{"groupingId": 2, "singleChannel": [1]}]} ZW3: POST /api/zwave/association_groups/15.0/2/associations Content-Type: application/json {"destinationNode": 1, "destinationEndpoint": 0} Appendix A: Supported legacy device actions The following 101 device actions remain available in ZW3 via /api/devices/{deviceID}/action/{actionName} for backward compatibility. Switching & level control turnOn, turnOff, open, close, startLevelIncrease, startLevelDecrease, stopLevelChange, stop, step, pause Brightness & values setValue, setValue2, setBrightness, setVolume, poll Color control setColor, setColorComponents, setR, setG, setB, setW, startColorEnhancement, startColorFade, stopColorChange Thermostat setThermostatMode, setThermostatFanMode, setHeatingThermostatSetpoint, setCoolingThermostatSetpoint, setFurnaceThermostatSetpoint, setDryAirThermostatSetpoint, setMoistAirThermostatSetpoint, setAutoChangeoverThermostatSetpoint, setEnergySaveHeatingThermostatSetpoint, setEnergySaveCoolingThermostatSetpoint, setAwayHeatingThermostatSetpoint, setAwayCoolingThermostatSetpoint, setFullPowerThermostatSetpoint Door lock secure, unsecure, unsecureWithTimeout, unsecureInside, unsecureInsideWithTimeout, unsecureOutside, unsecureOutsideWithTimeout, setDoorLockMode User codes setUserCode, setUserCodeDec, setUserName, deleteUserCode, getUserCode, getMaxUsers, synchronizeUserCodes Scheduling setSchedule, setAllSchedules, removeSchedule, setOverrideSchedule, removeOverrideSchedule, setScheduleState Node management removeFailedNode, requestNodeNeighborUpdate, getNeighborList, getLastWorkingRoute, markDead, wakeUpDeadDevice Protection setProtection, setExclusiveControl, setTimeout All Switch mode switchAllOn, switchAllOff, switchAllGet, switchAllSetMode Indicator identify, indicatorGet, setIndicatorValue Metering reset, resetMeter, clearEnergyData Configuration setConfiguration, readWholeConfiguration AV control getSupportedCommands, sendAVControl Window covering setSlatsAngle, setFavoritePosition, configureFavoritePositions, startCalibration Barrier operator setAllSubsystems Black box getRecords, removeRecords Sound switch setTone, setDefaultTone, setArmed, setSequence, removeSequence Device-specific setDefaultPartyTime, startProgram, setRingsLightMode, setTamperMode, setAutoFanMode, setUnlockSequence, setLockKey, setIdleTimeout, configure

Thank you for using our gateway! Be sure to update to the latest version to enjoy new features and improvements. Main features: KNX integration From now on, your KNX system can work even smarter thanks to integration with our Yubii Home Pro and Home Center 3 hubs. Gain full control over lighting, switches, RGBW controllers, blinds, shutters and sensors within one unified ecosystem. Migration of Z-Wave engine from 2.0 to 3.0 version (BETA) In this version of the software, it is possible to migrate the Z-Wave engine to version 3.0. Migration will allow you to take advantage of all the features of the new Z-Wave engine, including using Smart Start, better generic support for Z-Wave Plus devices and the availability of Security S2, which can be considered the first fully secure communication method for the Smart Home. Smart Start From now on, you can use the Smart Start function using QR Scanner in Yubii App. This function will allow you to add devices to the system even faster using binding process.*** What's new: Devices Improved display of device families on the device list so that child devices are always located under their parent device. Added Operating State indicator for Linked thermostats. Added direct access to KNX communication (both sending and recieving packets) from the API. Elero Integration with ELERO Lighting Receivers: TTDTW-E (Combio-868 LI W), TTDRGBW-E (Combio-868 LI RGBW), TTDW-E (Combio-868 LI PW). Energy Panel Integration with Tibber monitor to allow automatic rates update for Energy Panel (Available only for addresses located in Germany, Norway, Sweden or the Netherlands). Gateway connection When the Slave hub is turned off or there is no connection, the devices added to it are visible as inactive (dead) in the Master hub. Enabling Support Access and Remote Access on the Master hub also enables access on slave hubs. Nice* Upgraded NICE chip firmware version to the newest one. Added the option to disable the sun impact (setting the value to 0 lux in parameter 10) for the Domi WSC device v3.9.0. The default values of parameters 1, 3, and 10 have been changed for all versions of DOMI WSC devices. Other Added the information about the zone where the alarm occurred. Verification of the checksum when downloading the update file at the beginning of the process instead of at the end. Removed PKO Assistance plugin from the system due to official termination of cooperation. Scenes Added a new scene activation/deactivation block as an action in block scenes. Added possibility to enable/disable local and remote device protection via scenes and profiles. Z-Wave Adjusted parameters templates for sensors to reduce number of reports for various devices. Fixed setting of parameter 5 for the MCO Home MH7H-EH device. Improved clearing Z-Wave network reset procedure. The ability to manually add parameters at each endpoint. Improved Z-wave3 engine resilience to communication issues in Security S0.** Support for Z-Wave 3.0 in Installer App.** Bug Fixes: Backups Fixed an issue where the “Update and restore” buttons for backups with higher software versions were inactive. Climate Fixed an issue where the schedule was not cleared from the Heat-Control/Fibaro Heat Controller when it was removed from the climate zone. Fixed an issue where an added temperature sensor was removed from the climate panel when editing other settings in that panel. Fixes an error occurs after deleting a device in the climate schedule. Fixed issue with saving climate zones in some cases. The FGT thermostatic heads are not synchronised with the schedule. Devices Fixed an issue where the Color component view was not updating correctly. Fixed an issue with changing icon for Dahua cameras. Improved performance for the DoubleDimmer-Control binding Wizard. Fixed a problem with KNX device configuration caused by the lack of support for diacritical marks in device names. Fixed an issue with function settings for Z-Wave devices with an empty template during the binding process in the mobile application. Fixed incorrect KNX Bridge connection status after IP change. Restored missing temperature graphs on FGT device version 4.10. Fixed the appearance of the dialog in the user interface for BiDi-Awning and AV Controller. Fixed the display of svg icons in the mobile app for Sprinkler and NICE Siren devices. Fixed problem with CoolAutomation plugin to receive correct feedback/status in mobile application. Fixed UI for Advanced Configuration for the Keyfob lock button and unlock sequence. RGBW device doesn't control properly the color setting in specific actions sequence using the picker. Elero Fixed color component values for the Elero Lighting RGBW device. Fixed the appearance and behavior of the Elero Lighting RGBW device icon in the user interface. Fixed invalid settings for temperature color in profiles for the Elero Lighting RGBW device. It is not possible to control Elero Lighting RGBW after pairing it with the system if the LED output is turned off during finishing binding procedure. Gateway connection Fixed errors and incorrect display of options in association settings. Fixed IP address validation in the Gateway Connection tab. Wrong backup type while software update for slave hubs. Devices from different phisical networks are listed as a target destinations in associations. KNX Fixed a KNX connection error that occurred when reconnecting after a long period of time. Fixed problem with reconnecting the KNX bridge after performing a 'clear configuration' action. Nice* Fixed setting favorite position for the screen devices which does not support this natively. Fixed keep-alive support for Domi WSR/WS device, which caused the device to be shown as disconnected in the system. Fixed issues with Nice PLN2+ motors controlled as a group using Linked Device. Fixed the operation of some group actions causing i.a. malfunctions in scenes. Fixed an issue with removing device Domi WSR when the device is inactive. Other Removed a non-functional option (checkbox) for sending notifications on the list of mobile devices. Fixed visibility of device name when adding Z-wave devices in the mobile application. Fixed tooltips positioning in the interface. Fixed the message screen displayed after using the factory reset option in Recovery mode. Fixed handling of events from the NICE camera plugin when devices are added via NVR. Fixed icons for Sonos and XBMC plugins. Fixed errors displayed in the Z-wave tab of the Master hub when using the interface via Remote Access. Fixed the input validator for variables. Fixed non-functioning group actions in profiles. Added real-time refreshing of history entries for Z-Wave Central Scene events and scene-related events. Fixed an issue where the reboot sometimes didn't work properly. Minor UI/UX fixes. Profiles Fixed problem with triggering changes via profiles. Quick Apps Allowed additional parameters to hub.alert function in QuickApp to keep backward compatibility with old code. Variable edit box character limit has been increased from 1024 to 2048. Added support for climate zone control functions in QuickApps. Fixed restarting the Quick App process when editing it. Fixed Heat Activator which stopped working in rare cases. Fixed an issue with saving the Quick Apps view to a file when encrypting (applies to QA exported from version 5.191 or later). Fixed problem that HTTP responses other than 2xx (300 and higer) don't return response body. Corrected validation of variable names to allow editing of existing variable values. Fixed an issue with the display of custom icons for remote controllers in Quick Apps. Scenes Fixed an issue that icons other than the default ones are not displayed when selecting profiles in scenarios. Fixed refreshing of the scene activity switch in the interface when calling activation/deactivation action from the scene level. Fixed inactive color temperature slider for device Elero Lighting TW in scenarios created in the mobile app. Fixed problem that net.HTTPClient strips query string parameters in LUA scenes. Fixed the behavior of sliders in block scenes for the setColor action, sliders now function independently. Fixed an error that block scene with setting Manual mode to "Hold" does not work on HC3L/YH hubs. Optimization of scene running. Fixed an issue with saving a predefined scenario when some devices are selected. Update Moved the setting related to system version information from the final stage of startup to the earliest possible point in order to reduce incorrect version data in recovery mode. Changed the order in which services start during initialization to avoid issues during updates. Fixed the behavior of the progress bar when canceling an update download; the progress bar is now hidden. Z-Wave Fixed redundant stopping of Z-Wave3 engine.** Fixed the visibility of updates for Z-Wave devices on both engine versions. * - Does not apply to HC3L (Home Center 3 Lite). ** - Applies only to Z-Wave 3.0 engine. *** - Fully supported in the upcoming Yubii v2.5.3 application Security: Angular vulnerabilities update. Updated Rust toolchain version.