Update 5.210 Latest Topics

HC3 Z-Wave Engine 3 migration issue with ID Lock 150

Wed, 03 Jun 2026 05:07:40 +0000

Environment

Home Center 3
Firmware: 5.210.12
Previously running Z-Wave Engine 2
Migrated to Z-Wave Engine 3
Approximately 40 Z-Wave devices in the network
All other Z-Wave devices continue to work normally after migration

Problem

An ID Lock 150 that was previously fully functional stopped working immediately after the migration from Z-Wave Engine 2 to Z-Wave Engine 3.

The lock can no longer be controlled from HC3 and HC3 is unable to properly identify the device.

Current behavior

After inclusion, HC3 creates the lock device, but:

Lock / Unlock commands do not work
Device shows:
- Z-Wave SDK version: 0.0
- Version: 0.0
- Security level: None
- Parameters template: No
Advanced / Parameters page generates API errors
HC3 Diagnostics reports:
- "No template"
Browser console shows:
- GET /api/zwave/hc/configuration/ returns HTTP 404

Example:

GET /api/zwave/hc/configuration/70 -> 404

Troubleshooting already performed

Excluded lock from HC3
Factory reset of ID Lock 150
Factory reset of Z-Wave module
Re-included multiple times
Reconfigure device
Read configuration
Included using S2
Included using S0
Included without security
Included using Network Wide Inclusion
Included without Network Wide Inclusion
Firmware updated on ID Lock 150

None of the above changes the behavior.

Important observation

The issue appeared immediately after migration from Z-Wave Engine 2 to Z-Wave Engine 3.

The lock worked correctly before the migration.

All other Z-Wave devices in the network continue to operate normally, including secure devices.

Because the lock shows SDK version 0.0, Version 0.0, Security None and No Template regardless of inclusion method, it appears HC3 is unable to fully interview or identify the device after the Engine 3 migration.

Could you please verify whether there are any known compatibility issues between HC3 Z-Wave Engine 3 and ID Lock 150, or if additional diagnostics can be collected to determine why the device interview fails?

Update to ZW 3 gives Walli Switch Rings Upper / Bottom issues

Mon, 01 Jun 2026 18:22:40 +0000

Hello,

After update to ZW 3 the Walli Switch led rings don't work anymore.

Have 2 walli switches but switching on the ring that worked before the update, stopped after update.

hub.call(DevId, 'setRingsLightMode', "on", "upper", 0)

Update went oke, had only 1 older Fibaro Eye, to reconfigure, stopt communicating. After reconfiguration it worked as it should

is this a known issue??

HC3 QuickApp dropdown/select UI shows stale selections after updateView

Mon, 01 Jun 2026 19:21:39 +0000

Hi Fibaro R&D team,

I am seeing a consistent issue with QuickApp select/dropdown elements in the HC3 Device Preview UI.

This is not a Lua state problem. The QuickApp state is correct, the debug logs show the correct values, and the save/action logic receives the correct data. The problem is that the rendered Device Preview UI can keep showing stale selected values after the QuickApp updates the dropdown programmatically.

Context:

I am building a configuration QuickApp where the user maps Logic Group Matrix buttons to different target systems such as Hue, Velux/Tahoma, and Sonos.

The UI contains dynamic dropdowns/selects for:

Destination type
Target device
Matrix device
Button mapping profile

Typical flow:

Select Hue
Select a Hue device
Select a Matrix device
Select button mappings
Save mapping
Switch destination type to Velux/Tahoma
Lua state is cleared correctly
Device Preview UI may still show old Hue/button selections, or otherwise stale dropdown state

The internal state is correct. The visual UI is not always correct.

We tested multiple approaches:

self:updateView("selectName", "selectedItems", {})
self:updateView("selectName", "values", {})

For single-select elements we also tested:

self:updateView("selectName", "selectedItem", "")
self:updateView("selectName", "value", "")

We also tested clearing and republishing options:

self:updateView("selectName", "options", {})
self:updateView("selectName", "selectedItems", {})
self:updateView("selectName", "values", {})

fibaro.setTimeout(80, function()
self:updateView("selectName", "options", options)
self:updateView("selectName", "selectedItems", values)
self:updateView("selectName", "values", values)
end)

For multi-select we also tested clearing with:

self:updateView("selectName", "selectedItems", { "" })

The behavior remains unreliable. Sometimes the UI updates correctly, sometimes it keeps showing an old selection. If the user switches away from the Preview tab, for example to Variables, and then back to Preview, the UI often corrects itself. That strongly suggests a Device Preview render/cache issue rather than a QuickApp logic issue.

This is problematic for configuration QuickApps because the visible UI can no longer be trusted. The user may see a selected item that is no longer selected in the QuickApp state.

Questions for Fibaro R&D:

What is the officially supported way to clear a QuickApp dropdown/select from Lua?

Is there a difference between clearing single-select and multi-select elements?

Which properties are officially supported and recommended: selectedItem, selectedItems, value, values, or a combination?

Is the Device Preview cached in a way that can prevent immediate visual updates after updateView?

Is there a supported way to force the Device Preview UI to re-render a select element?

When options are updated dynamically, is the previous selection expected to be preserved, cleared, or validated against the new options?

Is the behavior different between legacy viewLayout and the newer UI?

Can Fibaro provide a minimal supported example showing how to:

Create a select/dropdown
Select an item
Clear the selection programmatically
Replace the options dynamically
Handle both single-select and multi-select correctly

Expected behavior:

When updateView changes or clears a select value, the visible Device Preview UI should immediately reflect the actual QuickApp state.

Actual behavior:

The QuickApp state changes correctly, but the Device Preview UI can continue to show stale selected values until the Preview tab is reloaded or reopened.

From a developer point of view, this looks like either an undocumented API detail or a Device Preview rendering/cache bug. A clear statement from Fibaro R&D on the supported API and expected behavior would be very helpful.

Fakro Window blind issue after ZW3 migration

Fri, 29 May 2026 15:49:07 +0000

I have completed the Migration from ZW2 to ZW3, which went relatively relatively smoothly, apart from having to reconfigure all the RGBW modules so they worked properly, but my main issue to getting my Fakro Window blinds to work with my scenes. They have worked flawlessly for 4 years.

I have 6 x Fakro Z Wave roof windows - These work fine after migration. (again after running reconfig)

I have 6 x Fakro Z Wave roller blinds for the said windows.

A couple of salient points first;

When the window is open there is no power to the blind

When the window is closed, power is restored to the blind and the blind should reconnect to the Z wave network to be operated.

In ZW2 I think (after 4 years) that the polling of the device was set at an interval as such that it reconnected relatively quickly even if it did not reconnect straight away. How I had my scenes set up for opening and closing etc based on outside temp, nightime bla blaa blaa this worked flawlessly.

With ZW3 the blinds simply don't reconnect to the network, unless I manually click reconnect in the app / interface. This means that no scenes work anymore when the windows close as the HC3 things they are offline. I notice that all the polling settings have been removed from ZW3.

Any thoughts on how to get around this as its a bit boring that some quite expensive window blinds don't really work with automations.

Thx

Still no update for Hue Pro Bridge!

Tue, 19 May 2026 15:05:55 +0000

I wonder what‘s keeping Fibaro from implementing the new plugin … 🤔

Experience from this release

Thu, 21 May 2026 17:34:56 +0000

Anyone who has installed this release and can share some experience?

Device serial number & zwave engine 3

Mon, 25 May 2026 16:50:32 +0000

I changed the Z-Wave engine from version 2 to version 3. The migration went smoothly, or so it seemed. The whole system worked neither faster nor slower - from a user perspective, I did not notice any difference.

However, there is another change that has concerned me: after adding a device using Engine 3, the serialNumber field is empty. I checked this with an FGPB-101 button and a Motion Sensor. Both of these devices do have a unique serial number, but its value is populated into the serialNumber field only when the device is added to the system using Engine 2. I use this field extensively in DNSfD.

In short: Engine V3 has stopped mapping the serial number value to the serialNumber field in the HC3 API.

My question to @m.roszak is - why? And will this be fixed? This is very important for me and for my customers.

Since the update and the switch to Z-Wave 3, I've been getting a lot of errors

Sat, 23 May 2026 16:52:03 +0000

After updating to Z-Wave 3, I'm seeing errors in the log for my FIBARO Smart Implant devices! I have three of them, and all of them send this error several times a day. Can I ask what to do about this? One Implant controls the boiler heating system, where it monitors overflow from the solar panel and sends it to the boiler, where the temperature is measured and the valves are switched. So it’s a pretty critical issue; I didn’t have any errors before. Thank you for your comments, advice, etc.

Please login or register to see this attachment.

KNX Custom Commands

Wed, 20 May 2026 14:17:30 +0000

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

Z-Wave engine 2.0 -3.0 Migration. Changes in API.

Mon, 18 May 2026 12:21:43 +0000

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
Please login or register to see this link.
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).

Important: After migrating from ZW2 to ZW3, all existing integrations should be reviewed for compatibility with the new API and re-tested. Refer to the comprehensive Swagger documentation (/swagger/) for the authoritative reference of all available endpoints, request/response schemas, and error codes.

2. How to detect the active engine

Use the endpoint:

GET /api/service/getZwaveEngine

Example response:

Please login or register to see this code.

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

The full specification is available via built-in Swagger UI at /swagger/ — select the "UpdateService Api" section.

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.

Key integration point: Any endpoint that modifies device state may return 202 with an actionId for sleeping devices. Integrations should handle both 200 (executed immediately) and 202 (queued for wake-up) responses.

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

Refer to Swagger UI for the complete list of polling endpoints and their parameters.

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:

Please login or register to see this code.

ZW3:

Please login or register to see this code.

B) Set user code

ZW2:

Please login or register to see this code.

ZW3:

Please login or register to see this code.

C) Set configuration parameter

ZW2:

Please login or register to see this code.

ZW3:

Please login or register to see this code.

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:

Please login or register to see this code.

ZW3:

Please login or register to see this code.

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

FIBARO System Update 5.210 for Home Center 3/Yubii Home Pro

Wed, 13 May 2026 11:01:21 +0000

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.

Update 5.210 Latest Topics

HC3 Z-Wave Engine 3 migration issue with ID Lock 150

Update to ZW 3 gives Walli Switch Rings Upper / Bottom issues

HC3 QuickApp dropdown/select UI shows stale selections after updateView

Fakro Window blind issue after ZW3 migration

Still no update for Hue Pro Bridge!

Experience from this release

Device serial number & zwave engine 3

Since the update and the switch to Z-Wave 3, I've been getting a lot of errors

KNX Custom Commands

Sending Custom Commands

Listener registration

Debugging

Z-Wave engine 2.0 -3.0 Migration. Changes in API.

API Migration: Z-Wave 2 -> Z-Wave 3

1. What changes the most

2. How to detect the active engine

3. Key functional differences

3.1 Network management (adding/removing devices)

ZW2

ZW3

3.2 Node operations (diagnostics, topology, interview)

ZW2

ZW3

3.3 Configuration parameters

ZW2

ZW3

3.4 Associations

ZW2

ZW3

3.5 Wake-up (battery devices)

ZW2

ZW3

3.6 User codes (door locks)

ZW2

ZW3

3.7 Device firmware update

3.7.1 Update Service (/api/update-service/...)

3.7.2 Firmware Update from file (/api/zwave/fw_update/...) — new in ZW3

3.8 Mailbox (pending actions for battery devices)

3.9 Polling (on-demand device state refresh)

4. ZW3 asynchronous model (what this means for integrations)

5. Before/after examples

A) Start inclusion

B) Set user code

C) Set configuration parameter

D) Add association

Appendix A: Supported legacy device actions

Switching & level control

Brightness & values

Color control

Thermostat

Door lock

User codes

Scheduling

Node management

Protection

All Switch mode

Indicator

Metering

Configuration

AV control

Window covering

Barrier operator

Black box

Sound switch

Device-specific

FIBARO System Update 5.210 for Home Center 3/Yubii Home Pro

3.7.1 Update Service (`/api/update-service/...`)

3.7.2 Firmware Update from file (`/api/zwave/fw_update/...`) — new in ZW3