public/openhab-addons
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[velux] fix concurrency bugs, other minor issues, update readme.md (replaces #8493) (#8520)

Browse Source 
Signed-off-by: Andrew Fiddian-Green <software@whitebear.ch>
This commit is contained in:
Andrew Fiddian-Green
2020-09-28 17:27:46 +01:00
committed by GitHub
parent d5f6bd326c
commit 64a713e74a
23 changed files with 588 additions and 486 deletions
Download Patch File Download Diff File Expand all files Collapse all files

376
bundles/org.openhab.binding.velux/README.md
View File

@@ -5,6 +5,8 @@ This binding integrates the <B>Velux</B> devices with help of a gateway, the <B>
The Velux Binding interacts via the Velux Bridge with any [io-homecontrol](http://www.io-homecontrol.com/)-based
devices like window openers, shutters and others.
![Velux](doc/veluxlogo.jpg)
Based on the VELUX API this binding integrates <B>Velux</B> and other io-homecontrol devices directly into the openHAB, avoiding the necessity of any cloud-based mediation infrastructures. The complete home-automation will work even without any Internet connectivity.
For details about the features, see the following websites:
@@ -12,263 +14,259 @@ For details about the features, see the following websites:
- [Velux](http://www.velux.com)
- [Velux API](http://www.velux.com/api/klf200)
## Overview
## Supported Things
As the API is widely open, there are several use cases which are supported by the Bridge:
From the complete configuration of a set of io-homecontrol devices including registration, naming, grouping, crypto key setup and exchange, the definition of intended settings, so called scenes, up to the control of single devices, i.e. ```open window of bathroom up to 45%```.
The binding supports the following types of Thing.
The following areas are covered:
| Thing Type | Description | Note |
|---------------|-----------------------------------------------------------------------------------|------|
| bridge | A Velux KLF200 which acts as a gateway to all Velux / IO-home controlled devices. | |
| window | A Velux / IO-home control window. | 1. |
| rollershutter | A Velux / IO-home control roller shutter. | 1. |
| actuator | Generic Velux / IO-home device. | 1. |
| scene | A Velux Scene which commands Velux / IO-home devices to specific positions. | |
| vshutter | A Velux virtual shutter. | 2. |
| information | A Thing that provides overall information about the binding itself. | |
| Topic | Details |
|-------------------------|------------------------------------------------------------------------------------------------------------|
| General bridge commands | SW version(\*), Gateway state(\*), Learn state, Clock, Reboot, FactoryReset, Network Setup(+) |
| Configuration Services | Node Discovery, Node Removal, Controller Copy, Crypto Key Generation, Crypto Key Exchange, Actuator config |
| Information Services | House Monitoring Service(\*), Node information(+), Group information |
| Activation Logging | |
| Command Handling | Command activation(\*), Command interruption(\*), Status Request(\*), Actuator Identification(\*), Limitations |
| Scene Handling | Scene definition, Scene execution(\*), Scene deletion, Scene renaming, Scene Overview(\*) |
| Physical I/O Handling | I/O Port setup |
1. Only supported in hubs with firmware v0.2.x.x or above
2. Only needed in hubs with firmware v0.1.x.x (due to note 1. above)
Items marked with (\*) are fully implemented. Items marked with (+) have only partial support.
## Discovery
## Binding Configuration
To simplify the initial provisioning, the binding provides one thing which can be found by autodiscovery.
Unfortunately there is no way to discover Velux bridges themselves within the local network.
But after configuring a Velux Bridge, it is possible to discover all scenes and actuators like windows and rollershutters in that hub.
To simplify the initial provisioning, the binding provides one thing which can be found by autodiscovery:
This thing named <B>Velux Binding Information</B> establishes one channel named <B>information</B> describing
the current binding state in a (hopefully) human understandable fashion. Additionally it will give three
properties with the version number of the bundle, the number of registered bridges and number of overall
things attached to the bridge(s).
## Thing Configuration
The <B>Velux KLF200</B> bridge has to be configured with some parameters, at least with the IP address of the bridge.
### Thing Configuration for "bridge"
| Property | Default | Required | Description |
|------------------------|------------------|:--------:|--------------------------------------------------------------|
| ipAddress | | Yes | Hostname or address for accessing the Velux Bridge. |
| protocol | slip | No | Underlying communication protocol (http/https/slip). |
| tcpPort | 51200 | No | TCP port (80 or 51200) for accessing the Velux Bridge. |
| password | velux123 | No | Password for authentication against the Velux Bridge.(\*\*) |
| timeoutMsecs | 1000 | No | Initial Connection timeout in milliseconds. |
| retries | 5 | No | Number of retries during I/O. |
| refreshMsecs | 10000 | No | Refresh interval in milliseconds. |
| isBulkRetrievalEnabled | yes | No | Load all scenes and actuators in one step. |
| isSequentialEnforced | no | No | Enforce Sequential Actuator Control even for long operations.|
| isProtocolTraceEnabled | no | No | Show any protocol interaction (loglevel INFO). |
The bridge Thing connects to the KLF-200 hub (bridge) to communicate with any respective connected Velux or IO-home device Things.
It signs on to the hub using the supplied connection parameters, and it polls the hub at regular intervals to read and write the data for each connected device.
The KLF-200 supports two Application Programming Interfaces "API" (a SLIP based one, and a JSON based one), and this binding can use either of them to communicate with it.
Before the binding can communicate with the hub, the Configuration Parameters `ipAddress` and `password` must be entered.
In addition there are some optional Configuration Parameters.
(\*\*) Note: This password is the API password that is printed on the back of the unit. Normally it differs from the password of the web frontend.
| Configuration Parameter | Default | Required | Description |
|-------------------------|------------------|:--------:|--------------------------------------------------------------|
| ipAddress | | Yes | Hostname or address for accessing the Velux Bridge. |
| password | velux123 | Yes | Password for authentication against the Velux Bridge.(\*\*) |
| timeoutMsecs | 500 | No | Communication timeout in milliseconds. |
| protocol | slip | No | Underlying communication protocol (http/https/slip). |
| tcpPort | 51200 | No | TCP port (80 or 51200) for accessing the Velux Bridge. |
| retries | 5 | No | Number of retries during I/O. |
| refreshMsecs | 10000 | No | Refresh interval in milliseconds. |
| isBulkRetrievalEnabled | yes | No | Load all scenes and actuators in one step. |
| isSequentialEnforced | no | No | Enforce Sequential Actuator Control even for long operations.|
| isProtocolTraceEnabled | no | No | Show any protocol interaction (loglevel INFO). |
Advise: if you see a significant number of messages per day like
(\*\*) Note: This password is the API password that is printed on the back of the unit.
Normally it differs from the password of the web frontend.
Advice: if you see a significant number of messages per day as follows, you should increase the parameters `retries` or/and `timeoutMsecs`...
```
communicate(): socket I/O failed continuously (x times).
```
please increase the parameters retries or/and timeoutMsecs.
For your convenience you'll see a log entry for the recognized configuration within the log file i.e.
```
2018-07-23 20:40:24.746 [INFO ] [.b.velux.internal.VeluxBinding] - veluxConfig[ipAddress=192.168.42.1,tcpPort=80,password=********,timeoutMsecs=2000,retries=10]
```
The <B>Velux</B> Things (beside the mentioned bridge) are <B>Velux Window</B>, <B>Velux Rollershutter</B>, and a generic <B>Velux Actuator</B> and <B>Velux Scene</B>. The 1st three Things have to be configured with an identification by their serial number.
### Thing Configuration for "actuator", "window", "rollershutter"
| Property | Default | Required | Description |
|----------------|------------------------|:--------:|-----------------------------------------------------------|
| serial | | Yes | Serial number of the io-homecontrol device. |
| name | | No | (Optional) name of the io-homecontrol device. |
| inverted | false | No | Inverts any device values. |
These types of Thing only supported in the Velux Bridge in API version two or higher (firmware version > 0.2.*.*).
These types of Thing are configured by means of their serial number in the hub.
In addition there are some optional Configuration Parameters.
The fourth Thing, the <B>Velux Scene</B>, has to be configured with an identification by their scenename.
| Property | Default | Required | Description |
|----------------|------------------------|:--------:|-----------------------------------------------------------|
| sceneName | | Yes | Name of the io-homecontrol configuration. |
The fifth Thing, the <B>Velux Virtual Shutter</B>, has to be configured with pairs of level combined with the appropriate scenenames.
| Property | Default | Required | Description |
|----------------|------------------------|:--------:|-----------------------------------------------------------|
| sceneLevels | | Yes | <Level1>,<Scene1>,<Level2>,<Scene2>,.... |
| currentLevel | 0 | No | Inverts any device values. |
## Discovery
Unfortunately there is no way to discover the Velux bridge itself within the local network. But after configuring the Velux Bridge, it is possible to discover all scenes and actuators like windows and rollershutters by the binding.
## Item Configuration
The Items of a Velux Bridge consists in general of a pair of mastertype and subtype definition.
In the appropriate items file, i.e. velux.items, this looks like
```
{ velux="thing=<Mastertype>;channel=<Subtype>" }
```
Optionally the subtype is enhanced with parameters like the appropriate name of the scene.
```
{ velux="thing=<Mastertype>;channel=<Subtype>#<Parameter>" }
```
| Mastertype | Description |
|---------------|----------------------------------------------------------------------------------|
| binding | Provides informations for easier configuration of this binding. |
| bridge | The Velux KLF200 represents a gateway to all Velux devices. |
| scene | Named ordered set of product states which can be activated for execution. |
| actuator | Generic IO-home controlled device which can be maintained by parameter settings. |
| window | IO-home controlled device of type window. |
| rollershutter | IO-home controlled device of type rollershutter. |
| vshutter | IO-home controlled device of type rollershutter. |
### Subtype
| Subtype | Item Type | Description | Mastertype | Parameter |
|--------------|---------------|-----------------------------------------------------------------|--------------|-----------|
| information | String | Describes the current state of the binding | binding | N/A |
| status | String | Current Bridge State (\*\*\*) | bridge | N/A |
| reload | Switch | Reload information from bridge into binding | bridge | N/A |
| timestamp | Number | Timestamp of last successful device interaction | bridge | N/A |
| doDetection | Switch | Start of the product detection mode | bridge | N/A |
| firmware | String | Software version of the Bridge | bridge | N/A |
| ipAddress | String | IP address of the Bridge | bridge | N/A |
| subnetMask | String | IP subnetmask of the Bridge | bridge | N/A |
| defaultGW | String | IP address of the Default Gateway of the Bridge | bridge | N/A |
| DHCP | Switch | Flag whether automatic IP configuration is enabled | bridge | N/A |
| WLANSSID | String | Name of the wireless network | bridge | N/A |
| WLANPassword | String | WLAN Authentication Password | bridge | N/A |
| products | String | List of all recognized products | bridge | N/A |
| scenes | String | List of all defined scenes | bridge | N/A |
| check | String | Result of the check of current item configuration | bridge | N/A |
| shutter | Rollershutter | Virtual rollershutter as combination of different scenes | bridge | required |
|--------------|---------------|-----------------------------------------------------------------|--------------|-----------|
| serial | String | IO-Homecontrol'ed device (\*\*\*\*) (\*\*\*\*\*) | actuator | required |
| position | Rollershutter | Position of the IO-Homecontrol'ed device (\*\*\*\*) | actuator | optional |
| state | Switch | State of the IO-Homecontrol'ed device | actuator | optional |
| limitMinimum | Rollershutter | Minimum position of the IO-Homecontrol'ed device (\*\*\*\*) | actuator | optional |
| limitMaximum | Rollershutter | Maximum position of the IO-Homecontrol'ed device (\*\*\*\*) | actuator | optional |
|--------------|---------------|-----------------------------------------------------------------|--------------|-----------|
| serial | String | IO-Homecontrol'ed device (\*\*\*\*) (\*\*\*\*\*) | window | required |
| position | Rollershutter | Position of the IO-Homecontrol'ed device (\*\*\*\*) | window | optional |
| limitMinimum | Rollershutter | Minimum position of the IO-Homecontrol'ed device (\*\*\*\*) | window | optional |
| limitMaximum | Rollershutter | Maximum position of the IO-Homecontrol'ed device (\*\*\*\*) | window | optional |
|--------------|---------------|-----------------------------------------------------------------|--------------|-----------|
| serial | String | IO-Homecontrol'ed device (\*\*\*\*) (\*\*\*\*\*) | rollershutter| required |
| position | Rollershutter | Position of the IO-Homecontrol'ed device (\*\*\*\*) | rollershutter| optional |
| limitMinimum | Rollershutter | Minimum position of the IO-Homecontrol'ed device (\*\*\*\*) | rollershutter| optional |
| limitMaximum | Rollershutter | Maximum position of the IO-Homecontrol'ed device (\*\*\*\*) | rollershutter| optional |
|--------------|---------------|-----------------------------------------------------------------|--------------|-----------|
| sceneName | String | Defines the scene by name according to registration in KLF200 | scene | required |
| action | Switch | Activates a set of predefined product settings | scene | optional |
| silentMode | Switch | Modification of the silent mode of the defined product settings | scene | optional |
| Configuration Parameter | Default | Required | Description |
|-------------------------|------------------------|:--------:|-------------------------------------------------------------------|
| serial | | Yes | Serial number of the io-homecontrol device in the hub. |
| name | | No | (Optional) name of the io-homecontrol device in the hub. |
| inverted | false | No | (Optional) the position is inverted (i.e. 0% translates to 100%). |
Notes:
(\*\*\*) The existence of this item triggers the continuous realtime status updates of any Velux item like shutters even if they are manually controlled by other controllers.
(\*\*\*\*) To enable a complete invertion of all parameter values (i.e. for Velux windows), use the property `inverted` or add a trailing star to the eight-byte serial number. For an example, see below at item `Velux DG Window Bathroom`.
1. To enable a complete invertion of all parameter values (i.e. for Velux windows), use the property `inverted` or add a trailing star to the eight-byte serial number. For an example, see below at item `Velux DG Window Bathroom`.
(\*\*\*\*\*) Somfy devices does not provides a valid serial number to the Velux KLF200 gateway: The bridge reports a registration of the serial number 00:00:00:00:00:00:00:00. Therefore the binding implements a fallback to allow an item specification with a actuator name instead of actuator serial number whenever such an invalid serial number occurs. For an example, see below at item `Velux OG Somfy Shutter`.
2. Somfy devices do not provide a valid serial number to the Velux KLF200 gateway. The bridge reports a registration of the serial number 00:00:00:00:00:00:00:00. Therefore the binding implements a fallback to allow an item specification with a actuator `name` instead of actuator serial number whenever such an invalid serial number occurs. For an example, see below at item `Velux OG Somfy Shutter`.
### Thing Configuration for "scene"
### Subtype Parameters
The Velux Bridge in API version one (firmware version 0.1.1.*) allows activating a set of predefined actions, so called scenes.
So besides the bridge, only one real Thing type exists, namely "scene".
This type of Thing is configured by means of its scene name in the hub.
In case of the scene-related subtypes, action and silentMode, the specification of the related scene as parameters is necessary;
| Configuration Parameter | Default | Required | Description |
|-------------------------|------------------------|:--------:|-----------------------------------------------------------|
| sceneName | | Yes | Name of the scene in the hub. |
```
{ velux="thing=scene;channel=<Subtype>#<Parameter>" }
```
### Thing Configuration for "vshutter"
The subtype shutter requires an even pair of parameters, each defining the shutter level and the related scene:
The Velux Bridge in API version one (firmware version 0.1.1.*) does not support a real rollershutter interaction.
So besides the bridge, this binding provides a virtual rollershutter Thing consisting of different scenes which set a specific shutter level.
Therefore the respective Item definition contains multiple pairs of rollershutter levels each followed by a scene name.
The virtual shutter Thing must be configured with pairs of level (0..10%) combined with the appropriate scene names (text) as follows.
```
{ velux="thing=brigde;channel=shutter#<Level1>,<Scene1>,<Level2>,<Scene2>" }
```
| Configuration Parameter | Default | Required | Description |
|-------------------------|------------------------|:--------:|-----------------------------------------------------------|
| sceneLevels | | Yes | <Level1>,<Scene1>,<Level2>,<Scene2>,.... |
| currentLevel | 0 | No | Inverts any device values. |
### Rain Sensor
## Supported Channels for Thing Types
Unfortunately Velux has decided to closely integrate the rain sensor into the window device. The rain sensor is therefore not displayed in the device list. On the other hand, the 'limitMinimum' channel of a roof window now provides information about rainy weather: if it is set internally by the Velux control unit to a value other than zero, it rains.
### Channels for "bridge" Things
### Virtual shutter
The supported Channels and their associated channel types are shown below.
As the bridge with firmware version one does not support a real rollershutter interaction, this binding provides a virtual rollershutter consisting of different scenes which set a specific shutter level. Therefore the item definition contains multiple pairs of rollershutter levels each followed by a scene name, which leads to this setting.
| Channel | Data Type | Description |
|-------------|-----------|---------------------------------------------------------------------------------|
| status | String | Description of current Bridge State. |
| reload | Switch | Command to force reload of the bridge information. |
| downtime | Number | Time interval (sec) between last successful and most recent device interaction. |
| doDetection | Switch | Command to activate bridge detection mode. |
### Channels for "window", "rollershutter" Things
### Items
The supported Channels and their associated channel types are shown below.
[Sample items file for textual configuration](doc/conf/items/velux.items)
| Channel | Data Type | Description |
|--------------|---------------|-------------------------------------------------|
| position | Rollershutter | Actual position of the window or device. |
| limitMinimum | Rollershutter | Minimum limit position of the window or device. |
| limitMaximum | Rollershutter | Maximum limit position of the window or device. |
### Sitemap
### Channels for "actuator" Things
[Sample sitemaps file for textual configuration](doc/conf/sitemaps/velux.sitemap)
The supported Channels and their associated channel types are shown below.
### Rules
| Channel | Data Type | Description |
|--------------|---------------|-------------------------------------------------|
| position | Rollershutter | Actual position of the window or device. |
| state | Switch | Device control (ON, OFF). |
| limitMinimum | Rollershutter | Minimum limit position of the window or device. |
| limitMaximum | Rollershutter | Maximum limit position of the window or device. |
[Sample rules file for textual configuration](doc/conf/rules/velux.rules)
### Channels for "scene" Things
The supported Channels and their associated channel types are shown below.
| Channel | Data Type | Description |
|------------|-----------|----------------------------------------------------------------|
| action | Switch | Activates the scene (moves devices to their preset positions). |
| silentMode | Switch | Enables silent mode. |
### Channels for "vshutter" Things
The supported Channel and its associated channel type is shown below.
| Channel | Data Type | Description |
|--------------|---------------|-----------------------------------------|
| position | Rollershutter | Position of the virtual roller shutter. |
### Channels for "information" Thing
The supported Channel and its associated channel type is shown below.
| Channel | Data Type | Description |
|-------------|-----------|--------------------------------|
| information | String | Information about the binding. |
## Rain Sensor
Unfortunately Velux has decided to closely integrate the rain sensor into the window device.
The rain sensor is therefore not displayed in the device list.
On the other hand, the 'limitMinimum' channel of a roof window provides information about rainy weather:
If it is set internally by the Velux control unit to a value other than zero, it rains. (Joke!!)
## Properties of the "bridge" Thing
The bridge Thing provides the following properties.
| Property | Description |
|-------------------|-----------------------------------------------------------------|
| check | Result of the check of current item configuration |
| connectionAttempt | Date-Time of last connection attampt |
| connectionSuccess | Date-Time of last successful connection attampt |
| defaultGW | IP address of the Default Gateway of the Bridge |
| DHCP | Flag whether automatic IP configuration is enabled |
| firmware | Software version of the Bridge |
| ipAddress | IP address of the Bridge |
| products | List of all recognized products |
| scenes | List of all defined scenes |
| subnetMask | IP subnetmask of the Bridge |
| vendor | Vendow name |
| WLANSSID | Name of the wireless network (not suported any more) |
| WLANPassword | WLAN Authentication Password (not suported any more) |
## Full Example
### Things
[Sample things file for textual configuration](doc/conf/things/velux.things)
```
Bridge velux:klf200:g24 "Velux KLF200 Hub" @ "Under Stairs" [ipAddress="192.168.1.xxx", password="secret"] {
Thing window w56-36-13-5A-11-2A-05-70 "Bathroom Roof Window" @ "Bathroom" [serial="56:36:13:5A:11:2A:05:70", inverted=true]
}
```
## More automation samples
[=> download sample things file for textual configuration](./doc/conf/things/velux.things)
At this point some interesting automation rules are included to demonstrate the power of this gateway to the io-homecontrol world.
### Items
```
Rollershutter Bathroom_Roof_Window_Position "Bathroom Roof Window Position [%.0f %%]" {channel="velux:window:g24:w56-36-13-5A-11-2A-05-70:position"}
```
### Closing windows after a period of time
[=> download sample items file for textual configuration](./doc/conf/items/velux.items)
### Sitemap
```
Frame label="Velux Windows" {
Slider item=Bathroom_Roof_Window_Position
}
```
[=> download sample sitemaps file for textual configuration](./doc/conf/sitemaps/velux.sitemap)
### Rules
**Rule for closing windows after a period of time**:
Especially in the colder months, it is advisable to close the window after adequate ventilation. Therefore, automatic closing after one minute is good to save on heating costs.
However, to allow the case of intentional prolonged opening, an automatic closure is made only with the window fully open.
```
/*
* Start of imports
*/
import org.openhab.core.library.types.*
/*
* Start of rules
*/
```java
rule "V_WINDOW_changed"
when
Item V_WINDOW changed
then
logInfo("rules.V_WINDOW", "V_WINDOW_changes() called.")
//
// Get the sensor value
//
val Number windowState = V_WINDOW.state as DecimalType
logWarn("rules.V_WINDOW", "Window state is "+windowState+".")
if (windowState < 80) {
if (windowState == 0) {
logWarn("rules.V_WINDOW", "V-WINDOW changed to fully open.")
var int interval = 1
createTimer(now.plusMinutes(interval)) [|
logWarn("rules.V_WINDOW:event", "event-V_WINDOW(): setting V-WINDOW to 100.")
sendCommand(V_WINDOW,100)
V_WINDOW.postUpdate(100)
createTimer(now.plusMinutes(interval)) [ |
logWarn("rules.V_WINDOW:event", "event-V_WINDOW(): setting V-WINDOW to 100.")
sendCommand(V_WINDOW,100)
V_WINDOW.postUpdate(100)
logWarn("rules.V_WINDOW:event", "event-V_WINDOW done.")
]
} else {
logWarn("rules.V_WINDOW", "V-WINDOW changed to partially open.")
}
}
//
// Check type of item
//
logDebug("rules.V_WINDOW", "V_WINDOW_changes finished.")
end
/*
* end-of-rules/V_WINDOW.rules
*/
```
[=> download sample rules file for textual configuration](./doc/conf/rules/velux.rules)
## Debugging
For those who are interested in more detailed insight of the processing of this binding, a deeper look can be achieved by increased loglevel.
@@ -352,46 +350,46 @@ However if you have set the configuration parameter isProtocolTraceEnabled to tr
[INFO ] [internal.bridge.slip.SlipVeluxBridge] - Received answer GW_GET_NODE_INFORMATION_CFM.
[INFO ] [internal.bridge.slip.SlipVeluxBridge] - Received answer GW_GET_NODE_INFORMATION_NTF.
[INFO ] [internal.bridge.slip.SlipVeluxBridge] - Sending command GW_GET_LIMITATION_STATUS_REQ.
...
```
## Supported/Tested Firmware Revisions
The Velux Bridge in API version one (firmware version 0.1.1.*) allows activating a set of predefined actions, so called scenes. Therefore beside the bridge, only one main thing exists, the scene element. The next-generation firmware version two is not backward compatible, and does not provide a public web frontend, but version two does provide full access to any IO-Home compatible devices not limited to Velux and includes many different features.
The Velux Bridge in API version one (firmware version 0.1.1.*) allows activating a set of predefined actions, so called scenes.
Therefore beside the bridge, only one main thing exists, the scene element.
The next-generation firmware version two is not backward compatible, and does not provide a public web frontend, but version two does provide full access to any IO-Home compatible devices not limited to Velux and includes many different features.
| Firmware revision | Release date | Description |
|:-----------------:|:------------:|-------------------------------------------------------------------------|
| 0.1.1.0.41.0 | 2016-06-01 | Default factory shipping revision. |
| 0.1.1.0.42.0 | 2017-07-01 | Public Web Frontend w/ JSON-API. |
| 0.1.1.0.44.0 | 2017-12-14 | Public Web Frontend w/ JSON-API. |
| 2.0.0.71 | 2018-09-27 | Public SLIP-API w/ private-only WLAN-based Web Frontend w/ JSON-API. |
| 0.2.0.0.71.0 | 2018-09-27 | Public SLIP-API w/ private-only WLAN-based Web Frontend w/ JSON-API. |
Notes:
- Velux bridges cannot be returned to version one of the firmware after being upgraded to version two.
- Firmware updates are currently provided at [Velux download area](https://updates2.velux.com/).
## Is it possible to run the both communication methods in parallel?
For environments with the firmware version 0.1.* on the gateway, the interaction with the bridge is limited to the HTTP/JSON based communication, of course. On the other hand, after upgrading the gateway firmware to version 2, it is possible to run the binding either using HTTP/JSON if there is a permanent connectivity towards the WLAN interface of the KLF200 or using SLIP towards the LAN interface of the gateway. For example the Raspberry PI can directly be connected via WLAN to the Velux gateway and providing the other services via the LAN interface (but not vice versa).
## Known Limitations
The communication based on HTTP/JSON is limited to one connection: If the binding is operational, you won't get access to the Web Frontend in parallel.
The SLIP communication is limited to two connections in parallel, i.e. two different openHAB bindings - or - one openHAB binding and another platform connection.
Both interfacing methods, HTTP/JSON and SLIP, can be run in parallel. Therefore, on the one hand you can use the Web Frontend for manual control and on the other hand a binding can do all automatic jobs.
Both interfacing methods, HTTP/JSON and SLIP, can be run in parallel.
Therefore, on the one hand you can use the Web Frontend for manual control and on the other hand a binding can do all automatic jobs.
## Unknown Velux devices
All known <B>Velux</B> devices can be handled by this binding. However, there might be some new ones which will be reported within the logfiles. Therefore, error messages like the one below should be reported to the maintainers so that the new Velux device type can be incorporated."
All known <B>Velux</B> devices can be handled by this binding.
However, there might be some new ones which will be reported within the logfiles.
Therefore, error messages like the one below should be reported to the maintainers so that the new Velux device type can be incorporated.
```
[ERROR] [g.velux.things.VeluxProductReference] - PLEASE REPORT THIS TO MAINTAINER: VeluxProductReference(3) has found an unregistered ProductTypeId.
```