Aktualizacja 5.210 Latest Topicshttps://forum.fibaro.com/forum/1736-aktualizacja-5210/Aktualizacja 5.210 Latest TopicsenPodlewanie ogroduhttps://forum.fibaro.com/topic/80137-podlewanie-ogrodu/ W najnowszej wersji Przy próbie rozwinięcia planu podlewania, dezaktywuje się cały harmońogram. Trzeba ponownie aktywować ręcznie 

]]>80137Sun, 24 May 2026 18:48:33 +0000Niestandardowe komendy KNXhttps://forum.fibaro.com/topic/80131-niestandardowe-komendy-knx/ Aby rozszerzyć funkcjonalność integracji KNX, dodaliśmy możliwość wysyłania niestandardowych komend do sieci KNX oraz rejestrowania własnych nasłuchiwaczy do obsługi raportów z urządzeń. Pozwala to sterować urządzeniami, które mogą nie być w pełni obsługiwane przez domyślną integrację KNX, lub wdrażać specyficzne zachowania unikalne dla Twojej instalacji. Najłatwiejszym sposobem obsługi tego mechanizmu jest użycie QuickApp. Pamiętaj, że ta funkcjonalność znajduje się na etapie testowym. Może nie być jeszcze w pełni stabilna, a API może ulec zmianie w przyszłości.

 

Wysyłanie niestandardowych komend

Możesz wysyłać niestandardowe komendy do sieci KNX, wywołując akcję sendCommand na urządzeniu integracji KNX (ID 9). Akcja ta przyjmuje trzy parametry:

  • Adres grupowy, do którego chcesz wysłać komendę (np. „0/2/0”).

  • DPT wartości, którą chcesz wysłać (np. „5.001” dla DPT_Scaling).

  • Wartość, którą chcesz wysłać. Kodowanie zależy od używanego DPT.

 

Poniżej kilka prostych przykładów wysyłania różnych DPT:

 

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

Ponieważ używamy akcji urządzenia do wysyłania komend KNX, możesz wysyłać je w dowolny sposób. Możesz korzystać z QuickApps, ale także ze scen lub bezpośrednich wywołań REST API  
(POST /api/devices/9/action/sendCommand).

Listener registration

Możesz odbierać aktualizacje z adresów grupowych i obsługiwać je w swoim QuickApp. Jest to przydatne do monitorowania stanów urządzeń lub reagowania na konkretne zdarzenia.

Na ten moment nie ma możliwości rejestracji dla konkretnego adresu grupowego, więc będziesz otrzymywać wszystkie aktualizacje z sieci KNX.
Możesz je następnie filtrować w swoim kodzie, aby reagować tylko na te istotne.

 

Callback rejestruje się poprzez wywołanie akcji registerListener na urządzeniu integracji KNX (ID 9). Akcja ta przyjmuje jeden argument:

  • URL callbacku (akcja w Twoim QuickApp), który zostanie wywołany przy każdej aktualizacji z sieci KNX. URL powinien mieć format:/api/devices/<quick app id>/action/{callback name} e.g. /api/devices/123/action/myCallback.

Przekazany callback zostanie wywołany z adresem grupowym oraz wartością aktualizacji za każdym razem, gdy pojawi się nowy komunikat w sieci KNX.

Poniżej przykład obsługi tego w 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

Możesz zmienić poziom logowania integracji KNX na „debug” lub „trace”, aby zobaczyć więcej informacji dotyczących samej komunikacji KNX oraz komunikacji wymienianej między integracją KNX a Twoim QuickApp. Aby to zrobić, przejdź do ustawień KNX w interfejsie webowym i zmień poziom logów systemowych w sekcji dotyczącej komunikacji sieciowej.

]]>80131Wed, 20 May 2026 14:20:50 +0000Migracja silnika Z-Wave wersja 2.0 do 3.0. Zmiany w APIhttps://forum.fibaro.com/topic/80119-migracja-silnika-z-wave-wersja-20-do-30-zmiany-w-api/
 
# API Migration: Z-Wave 2 -> Z-Wave 3 
 
Planned release window:
- beta: `5.203`
- 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](#appendix-a-supported-legacy-device-actions) 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:
 
```json
{
  "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:**
1. The service periodically checks for available firmware — or on demand via `POST /api/update-service/updates`.
2. Devices with available updates are listed via `GET /api/update-service/devices/`.
3. To start an update, create a process via `POST /api/update-service/processes` (with `{"deviceId": ...}`).
4. Poll the process status via `GET /api/update-service/processes/{deviceId}` — statuses include `Downloading`, `Queued`, `WaitingForWakeUp`, `InProgress` (with progress stages), `Completed`, `Failed`, `Stopped`.
5. 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:**
1. Query supported firmware targets via `GET /api/zwave/fw_update/{addr}` — returns the list of updatable firmware targets and their IDs.
2. Upload a firmware file via `POST /api/zwave/fw_update/{addr}/{target}/request` (multipart/form-data with `manufacturerId`, `firmwareId`, and the firmware binary).
3. Monitor the process via `GET /api/zwave/fw_update_processes` or `GET /api/zwave/fw_update_processes/{id}`.
4. 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:**
1. Send a command to a sleeping device (e.g. `POST /api/zwave/configuration_parameters/7.0/2/value`).
2. Instead of the usual `200 OK`, the API responds with **`202 Accepted`** and a JSON body containing the `actionId`:
   ```json
   {"actionId": 1}
   ```
3. The pending action is now queued. You can inspect it via the mailbox endpoints.
4. When the device wakes up, all queued actions are executed automatically.
5. 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:
```http
POST /api/devices/{deviceID}/action/startAddingDevices
```
 
ZW3:
```http
POST /api/zwave/nm/inclusions
Content-Type: application/json
 
{"networkWide": true, "allowS0": false, "allowS2": true}
```
 
### B) Set user code
 
ZW2:
```http
POST /api/devices/{deviceID}/action/setUserCode
Content-Type: application/json
 
{"args": [1, "1234"]}
```
 
ZW3:
```http
PUT /api/zwave/user_codes/15.0/codes/1
Content-Type: application/json
 
{"userCode": "1234", "userIdStatus": "AVAILABLE"}
```
 
### C) Set configuration parameter
 
ZW2:
```http
POST /api/devices/{deviceID}/action/setConfiguration
Content-Type: application/json
 
{"args": [2, 1, 0]}
```
 
ZW3:
```http
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:
```http
POST /api/devices/{deviceID}/action/associationSet
Content-Type: application/json
 
{"args": [{"groupingId": 2, "singleChannel": [1]}]}
```
 
ZW3:
```http
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`
 
 

 

]]>80119Mon, 18 May 2026 12:25:56 +0000FIBARO System Aktualizacja 5.210 dla Home Center 3/Yubii Home Prohttps://forum.fibaro.com/topic/80111-fibaro-system-aktualizacja-5210-dla-home-center-3yubii-home-pro/ Dziękujemy za korzystanie z naszej centrali! Zaktualizuj oprogramowanie do najnowszej wersji, aby cieszyć się nowymi funkcjonalnościami i usprawnieniami.

 

Najważniejsze funkcjonalności:

 

Integracja KNX

Od teraz Twój system KNX może działać jeszcze inteligentniej dzięki integracji z naszymi centralami Yubii Home Pro oraz Home Center 3. Zyskaj pełną kontrolę nad oświetleniem, przełącznikami, kontrolerami RGBW, roletami i czujnikami w jednym spójnym ekosystemie.

 

Migracja silnika Z-Wave z wersji 2.0 do 3.0 (BETA)

W tej wersji oprogramowania możliwe jest przeprowadzenie migracji silnika Z-Wave do wersji 3.0. Migracja pozwoli Ci skorzystać ze wszystkich nowych funkcji silnika Z-Wave, w tym korzystanie ze Smart Start, lepszej generycznej obsługi urządzeń Z-Wave Plus i dostępności Security S2, który można uznać za pierwszą w pełni bezpieczną metodę komunikacji dla Inteligentnego Domu.

 

Smart Start

Od teraz można korzystać w funkcji Smart Start wykorzystującej Skaner QR w aplikacji Yubii. Funkcja ta umożliwi jeszcze szybsze dodanie urządzeń do systemu przy użyciu procesu parowania w aplikacji mobilnej.***

 

Co nowego:    

 

Elero

    Integracja z odbiornikami oświetleniowymi ELERO: TTDTW-E (Combio-868 LI W), TTDRGBW-E (Combio-868 LI RGBW),  TTDW-E (Combio-868 LI PW).

 

Łączenie central

    Gdy centrala podrzędna zostaje wyłączona lub nie ma z nią połączenia, dodane do niej urządzenia są widoczne jako nieaktywne (martwe) w centrali nadrzędnej.
    Włączenie Dostępu dla Supportu i Dostępu Zdalnego na centrali Master powoduje włączenie dostępu również na centralach podrzędnych.

 

Nice*

    Zaktualizowano oprogramowanie chipa NICE do najnowszej wersji.
    Dodano możliwość wyłączenia wpływu słońca (ustawienie wartości 0 lux w parametrze 10) dla urządzenia Domi WSC wersji 3.9.0.
    Zmieniono domyślne wartości parametrów 1, 3 i 10 dla wszystkich wersji urządzeń DOMI WSC.

 

Panel energii

     Integracja z monitorem Tibber w celu umożliwienia automatycznej aktualizacji stawek w Panelu Energii (dostępne tylko dla adresów w Niemczech, Norwegii, Szwecji lub Holandii).

 

Pozostałe

    Dodano informacje o strefie, w której wystąpił alarm.
    Weryfikacja sumy kontrolnej przy pobraniu pliku aktualizacji na początku procesu zamiast na końcu.
    Usunięto z systemu plugin PKO Ubezpieczenia w związku z oficjalnym zakończeniem współpracy.

 

Sceny

    Dodano nowy bloczek aktywacji / dezaktywacji sceny jako akcja w scenach blokowych.
    Dodano możliwość włączania/wyłączania lokalnej i zdalnej ochrony urządzeń za pomocą scen i profili.

 

Urządzenia

    Ulepszono wyświetlanie rodzin urządzeń na liście urządzeń, tak aby urządzenia podrzędne zawsze znajdowały się pod urządzeniami nadrzędnymi.
    Dodano wskaźnik stanu działania dla połączonych termostatów.
    Dodano bezpośredni dostęp do komunikacji KNX (zarówno wysyłanie, jak i odbieranie pakietów) z poziomu API.

 

Z-Wave

    Dostosowano szablony parametrów czujników w celu zmniejszenia liczby raportów dla różnych urządzeń.
    Poprawiono ustawianie wartości parametru 5 dla urządzenia MCO Home MH7H-EH.
    Ulepszono procedurę resetowania sieci Z-Wave.
    Możliwość dodawania ręcznie parametrów na każdym endpoincie.
    Zwiększona odporność silnika Z-Wave3 na problemy z komunikacją w Security S0.**
    Wsparcie dla silnika Z-wave 3.0 w aplikacji Instalator.**

 

Poprawione błędy:

 

Aktualizacja

    Przeniesiono ustawienie dotyczące informacji o wersji systemu z końcowego etapu uruchamiania na najwcześniejszy możliwy moment w celu zredukowania błędnych danych o wersji w trybie recovery.
    Zmieniono kolejność uruchamiania serwisów w czasie inicjalizacji w celu uniknięcia problemów przy aktualizacji.
    Poprawiono zachowanie paska postępu przy anulowaniu akcji pobrania aktualizacji, pasek postępu zostaje ukryty.

 

Backup

    Naprawiono problem, w wyniku którego przyciski „Aktualizuj i przywróć” dla kopii zapasowych z wyższymi wersjami oprogramowania były nieaktywne.

 

Elero

    Poprawiono wartości komponentów kolorów dla urządzenia Elero Lighting RGBW.
    Poprawiono wygląd i zachowanie ikony urządzenia Elero Lighting RGBW w interfejsie użytkownika.
    Poprawiono nieprawidłowe ustawienia temperatury barwowej w profilach dla urządzenia Elero Lighting RGBW.
    Nie można sterować oświetleniem Elero Lighting RGBW po sparowaniu z systemem, jeśli wyjście LED jest wyłączone w trakcie kończenia procesu parowania.

 

Klimat

    Naprawiono problem, w wyniku którego harmonogram nie był usuwany z kontrolera ogrzewania Heat-Control/Fibaro Heat Controller po usunięciu go ze strefy klimatu.
    Poprawiono problem, w którym dodany czujnik temperatury był usuwany z panelu klimatu przy edycji innych ustawień tego panelu.
    Poprawiono błąd występujący po usunięciu urządzenia z harmonogramu klimatu.
    Poprawiono problem z zapisywaniem stref klimatycznych, który występował w niektórych przypadkach.
    Głowice termostatyczne FGT nie są zsynchronizowane z harmonogramem.

 

KNX

    Poprawiono błąd połączenia KNX po ponownym nawiązaniu połączenia po dłuższym czasie.
    Poprawiono problem z ponownym połączeniem KNX Bridge po wykonaniu operacji „wyczyść konfigurację”.

 

Łączenie central

    Poprawiono błędy oraz nieprawidłowe wyświetlanie opcji w ustawieniach asocjacji.
    Poprawiono walidację adresu IP w zakładce Łączenia Central.
    Nieprawidłowy typ kopii zapasowej podczas aktualizacji oprogramowania central podrzędnych.
    Urządzenia z różnych sieci fizycznych są wymienione jako miejsca docelowe w asocjacjach.

 

Nice*

    Naprawiono ustawienie ulubionej pozycji dla rolet, które nie obsługują tej funkcji natywnie.
    Poprawiono obsługę keep-alive dla urządzenia Domi WSR/WS, co powodowało pokazywanie urządzenia jako odłączone w systemie.
    Poprawiono problemy związane z silnikami Nice PLN2+ sterowanymi jako grupa za pomocą funkcji Połączone urządzenia.
    Poprawiono działanie akcji grupowych powodujące m.in. błędne działanie w scenach.
    Poprawiono problem z usuwaniem urządzenia Domi WSR w przypadku gdy urządzenie jest nieaktywne.

 

Pozostałe

    Usunięto niedziałającą opcję (checkbox) wysyłania powiadomień na liście urządzeń mobilnych.
    Poprawiono widoczność nazwy urządzenia przy dodawaniu urządzeń Z-wave w aplikacji mobilnej.
    Poprawiono pozycjonowanie tooltipów w interfejsie.
    Poprawiono ekran komunikatów wyświetlających się po użyciu opcji przywrócenia ustawień fabrycznych w trybie Recovery.
    Poprawiono obsługę zdarzeń z pluginu kamera NICE, gdy urządzenia są dodane przez NVR.
    Poprawiono ikony dla pluginów Sonos i XBMC.
    Poprawiono błędy wyświetlające się w zakładce Z-wave centrali Master przy korzystaniu z interfejsu przez Dostęp Zdalny."
    Poprawiono walidator pola wpisywanych danych dla zmiennych.
    Poprawiono niedziałające akcje grupowe w profilach.
    Dodano odświeżanie na bieżąco wpisów w historii dla zdarzeń Z-Wave central scene oraz zdarzeń dotyczących scen.
    Poprawiono błąd, przez który ponowne uruchomienie systemu czasami nie działało poprawnie.
    Drobne poprawki UI/UX.
 

Profile

    Poprawiono problem z wyzwalaniem zmian za pomocą profili.

 

Quick Apps

    Zezwolono na dodatkowe parametry do funkcji hub.alert w QuickApp, aby zachować kompatybilność wsteczną ze starym kodem.
    Limit znaków w polu edycji zmiennej został zwiększony z 1024 do 2048.
    Dodano obsługę funkcji kontroli stref klimatu w QuickApps.
    Poprawiono restart procesu Quick App przy jego edycji.
    Poprawiono Heat Activator, który przestawał działać w rzadkich przypadkach.
    Poprawiono problem z zapisywaniem widoku Quick Apps do pliku przy użyciu szyfrowania (dotyczy QA eksportowanych od wersji 5.191).
    Poprawiono błąd, w wyniku którego odpowiedzi HTTP inne niż 2xx (300 i wyższe) nie zwracały treści odpowiedzi.
    Poprawiono błąd w walidacji nazw zmiennych uniemożliwiający ich późniejszą edycję.
    Poprawiono błąd związany z wyświetlaniem ikon użytkownika dla pilotów w Quick Apps.
 

Sceny

    Poprawiono problem nie wyświetlających się ikon innych niż domyślne przy wyborze profili w scenariuszach.
    Poprawiono odświeżanie przełącznika aktywności sceny w interfejsie przy wywołaniu akcji aktywacji / dezaktywacji z poziomu sceny.
    Poprawiono nieaktywny suwak temperatury barwowej urządzenia Elero Lighting TW w scenariuszach tworzonych w aplikacji mobilnej.
    Poprawiono błąd, w wyniku którego net.HTTPClient usuwał parametry z ciągu zapytania dla scen LUA.
    Poprawiono działanie suwaków w scenach blokowych dla akcji setColor, suwaki działają teraz indywidualnie.
    Poprawiono błąd, który powodował, że sceny blokowe nie działały dla ustawienia trybu ręcznego na „Do odwołania” w centralach HC3L/YH.
    Optymalizacja uruchamiania scen.
    Poprawiono problem z zapisem predefiniowanego scenariusza w przypadku wyboru niektórych urządzeń.

 

Urządzenia

    Poprawiono problem z nieprawidłową aktualizacją widoku składowej koloru dla urządzeń RGB/RGBW.
    Poprawiono problem ze zmianą ikony dla kamer Dahua.
    Poprawiono wydajność Wizarda dodawania urządzenia DoubleDimmer-Control.
    Poprawiono błąd przy konfiguracji urządzeń KNX spowodowany brakiem obsługi znaków diaktrycznych w nazwach urządzeń.
    Poprawiono problem z ustawieniami funkcji dla urządzeń Z-Wave z pustym szablonem w procesie dodawania w aplikacji mobilnej.
    Poprawiono nieprawidłowy status połączenia Bridge KNX po zmianie IP.
    Przywrócono brakujące wykresy temperatury w urządzeniu FGT w wersji 4.10.
    Poprawiono wygląd okna dialogowego w interfejsie użytkownika dla urządzenia BiDi-Awning i AV Controller.
    Poprawiono wyświetlanie ikon svg w aplikacji mobilnej dla Zraszacza i Syren NICE.
    Poprawiono problem z pluginem CoolAutomation, dzięki czemu aplikacja mobilna otrzymuje teraz prawidłowe informacje zwrotne/status.
    Poprawiono interfejs użytkownika w ustawieniach zaawansowanych dotyczących sekwencji blokowania i odblokowywania urządzenia FGKF601 (Keyfob).
    Urządzenie RGBW nie obsługuje prawidłowo ustawień kolorów w określonej sekwencji czynności przy użyciu selektora.

 

Z-Wave

    Naprawiono problem nadmiernego zatrzymywania się silnika Z-Wave3.**
    Poprawiono widoczność aktualizacji dla urządzeń Z-wave na obu wersjach silnika.

 

 

* - nie dotyczy HC3L (Home Center 3 Lite)
** - dotyczy tylko silnika Z-Wave 3.0
*** - w pełni wsparty w nadchodzącej aplikacji Yubii wersji 2.5.3

 

Bezpieczeństwo:

    Wykonano aktualizację dotyczącą luk w zabezpieczeniach Angular.
    Zaktualizowano wersję Rust toolchain.

]]>80111Wed, 13 May 2026 11:03:58 +0000