[velux] New OpenHAB2 binding - feedback welcome!

Tags: #<Tag:0x00007faed6f42928> #<Tag:0x00007faed6f427c0>

Hello Fabian,

this sounds very funny… a position of 108%. Do you have a pointer to a Somfy manual where we could get some more information about this behaviour?

Perhaps this feature can be handled by a special somfy-dedicated positioning but I’d like to check the circumstances before allowing such an approach.

Very helpful could be a debugging output of the values returned by the Somfy device (i.e. with level TRACE on org.openhab.binding.velux.things) . Thx.

Now the following changes are incorporated into the openHAB release (PR#5833):


  • Handle empty list of items properly.
  • HTTP/JSON communication.
  • Aborting connection after sending error.
  • Firmware revision properly returned.
  • Close connections during binding shutdown/removal.
  • String representation and handling of ip addresses.
  • Invalid use of myJsonBridge eliminated in case of LAN/WLAN config.
  • Initial refresh of data for item added, handling of BRIDGE_REFRESH_MSECS fixed.
  • Refresh only readable items.


  • Adapted logging (more infos, less warnings).
  • More detailed configuration in README added.
  • More information during actuator state modification for debugging.
  • Intensive logging for recognition of Somfy devices.
  • Optional handling for inversed actuators.
  • Eliminating usage of org.apache.commons.lang.StringUtils.isNotBlank.
  • Proper handling of unknown config items.
  • More infos about debug settings in README.
  • More infos in loglevel trace.
  • Provide infos about WLAN config.
  • Better error handling for unknown scenes (virtual rollershutters).
  • handling bad serial numbers (Somfy).
  • New channel timestamp for retrieving the last successful communication time.
  • New channel: reload action for retrieving all infos from bridge.

Final note: The comments for activation with OH2 are removed as there is a good documentation available at distribution doc.

Thanks to everyone for your support with questions, trace files and a lot of patience :wink: .

Thank you even more for your hard work Guenther… Without, we would have nothing to complaint about :smiley:

1 Like

Hi @gs4711,

sorry for my late reply. With the actual version of the jar, everything works like a charme!

Thank you very much!

best regrads


1 Like

I just installed the plugin. Everything works fine, except one thing:

My rollershutter is not showing the correct %. When I set the rollershutter to 100%, he is going down. Short after the percent is corrected to 99%. The same accounts for other numbers: 40%->39%, 20% -> 19%.
The rollershuter is a velux rollershutter:
Product “Rollladen” / ROLLER_SHUTTER (bridgeIndex=0,serial=::::..::**,position=C7D0) .

best regards


Hi Florian,

thanks for this information. In fact, you have already provided the explanation within your description:

Using a down command, a target position of 100% (0xc800 as Velux position) is send to the rollershutter. But, the shutter itself stops at an appropriate position - in your case at 0xC7D0 which is a position of 0,999 on a scale from 0 to 1.

The same behaviour should be noticable on Velux remote controls with feedback (i.e. KLR100 or KLR 200): There, the incorrect position will be displayed as well.

Personally I had to recalibrate one shutter in such a case by doing a factory reset with afterwards a relearning of the remote controls.

Regards, Guenther

Hi Günther, did you already receive a response from the velux engineer?


I just installed a new update of the IHC binding, which required me to install Apache http client as well. After that, I start getting warning from the Velux binding.

2019-08-13 19:06:34.051 [WARN ] [.velux.bridge.slip.SCgetDeviceStatus] - Gateway response GW_SESSION_FINISHED_NTF (772) cannot be handled at this point of interaction.
2019-08-13 19:06:34.054 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.

Is this related to the IHC binding?

EDIT - It does seem to operate fine anyway. And the warning seems to be gone as well…


the installation should not interfere with the IHC binding. But the bindings are sharing the httpclient library. Please let me know whether this will occur again.

Regards, Guenther

The warning stopped after a few minutes, and the windows operates fine from my rule. So I guess something just had to settle. But I´ll keep an eye on it, specially next time I reboot.
Which library did Velux binding use, before I installed the Apache http client?

i am not a programmer but just a man of 69 years and trying to get openhab working for me, with the prev ios binding all worked for me, but i installed the new binding and have some problems.
i am running the *org.openhab.binding.velux-
but i am getting problems with actuators like below i also uploaded some msg

handleCommandOnChannel(): cannot work on unknown actuator: 53:2A:5D:5A:12:10:3A.

Does anyone know this and how to solve ?
pls read the logfile for more messages and startup of the binding.

actuator-log.log (9.4 KB)

Helllo John, @Johnny-b,
most parts of the logfile looks fine to me. Let’s summarize:

  • you have defined 16 scenes on the KLF, which are well recognized,
  • you have registered four rollershutters on the KLF which are recognized (with one exception):
    ** there is one non-Velux shutter (“Keuken”)? It reports a strange serial-number (00:00:00:00:00:00:00:00),
  • the bridge is in fully operational mode and in good contact with the binding (status GW_S_GWM/GW_SS_IDLE).
    But there is an issue with the relationship of the devices and the appropriate things. Could you please share one of the definition lines for the four different shutters (assuming that you have them manually entered into an items file)?

Regards, Guenther

Hallo @Johnny-b again,
rereading parts of your 1st sentence:

I’m doubting whether I’ve got it right: Did the unchanged setup have worked before?

Hi Guenther,

no your right, i ment to say that it worked with the previos version and i installed the new binding but also started to create more scenes on the klf200 and tried to get them in the in the things, items and sitemap.

And then the messages came about unknown actuators.

And in the posts i saw a message from Kim Anderson who had the same msg but i could not find the solution there.

Regards Johnny

Hi John,
is it possible for you to increase the log level of the binding?
Thx in advance, Guenther

Hi Guenther,
i found the problem, it was my fault !
In the items file there where the last two digits missing in the serialnumber and that is the reason why the actuators where not found.
But thanks for the help anyway !

Hi John, thanks for your feedback.

Hello there! I’m using this binding to talk to my io-homecontrol (somfy) shutters via a KLF200, but the setup seems to be … flaky.

It sometimes works when everything is just fine (mostly after powercycling the KLF200 and then restating openhab), but it often gets stuck in some state where no commands are correctly transmitted.

The one consistent symptom that happens is log lines like this appearing in my log:

2019-08-19 12:41:48.881 [WARN ] [nding.velux.bridge.slip.SCgetProduct] - Gateway response GW_GET_ALL_NODES_INFORMATION_NTF (516) cannot be handled at this point of interaction.

I’ll try to provide more useful reproduction information when I can get it and will also try to find the “beginning” of the error state (which I’ve not yet isolated), but are there any suggestion in the meantime that might help with finding the root cause?

It looks like the problems starts when the KLF200 indicates an ended session during a command:

019-08-20 09:49:34.661 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = 52cc370d-1471-4d28-ae93-fd6d4c57a0cd, base URL = http://localhost:8080)
2019-08-20 09:49:36.259 [INFO ] [ab.binding.velux.bridge.slip.SClogin] - velux bridge connection successfully established (login succeeded).
2019-08-20 09:49:38.306 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - Found velux scenes:
2019-08-20 09:49:39.554 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - Found velux actuators:
        Product "Schlafzimmer" / UNDEFTYPE (bridgeIndex=1,serial=Schlafzimmer,position=C800)
        Product "Kinderzimmer Nord" / UNDEFTYPE (bridgeIndex=6,serial=Kinderzimmer Nord,position=C800)
        Product "Bad" / UNDEFTYPE (bridgeIndex=5,serial=Bad,position=C800)
        Product "Buero" / UNDEFTYPE (bridgeIndex=8,serial=Buero,position=C800)
        Product "Wohnzimmer Fix Sued" / UNDEFTYPE (bridgeIndex=2,serial=Wohnzimmer Fix Sued,position=00EB)
        Product "Wohnzimmer Schiebetür" / UNDEFTYPE (bridgeIndex=4,serial=Wohnzimmer Schiebetür,position=0000)
        Product "Kinderzimmer West" / UNDEFTYPE (bridgeIndex=7,serial=Kinderzimmer West,position=C800)
        Product "Wohnzimmer Fix West" / UNDEFTYPE (bridgeIndex=0,serial=Wohnzimmer Fix West,position=00EB)
        Product "Kueche" / UNDEFTYPE (bridgeIndex=3,serial=Kueche,position=0000)        .
2019-08-20 09:49:40.563 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - velux Bridge is online with 0 scenes and 9 actuators, now.
2019-08-20 09:50:04.283 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - Result: check ok. All scenes are used within Items.
2019-08-20 09:52:41.823 [INFO ] [ding.velux.bridge.slip.SCsendCommand] - setResponse(): returned ntfRunStatus: EXECUTION_FAILED.
2019-08-20 09:52:42.832 [WARN ] [ding.velux.bridge.slip.SCgetProducts] - Gateway response GW_SESSION_FINISHED_NTF (772) cannot be handled at this point of interaction.
2019-08-20 09:52:48.805 [WARN ] [.velux.bridge.slip.SCgetDeviceStatus] - Gateway response GW_ACTIVATION_LOG_UPDATED_NTF (1286) cannot be handled at this point of interaction.
2019-08-20 09:52:48.810 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.
2019-08-20 09:53:04.819 [WARN ] [.velux.bridge.slip.SCgetDeviceStatus] - Gateway response GW_GET_ALL_NODES_INFORMATION_CFM (515) cannot be handled at this point of interaction.
2019-08-20 09:53:04.823 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - handleCommandOnChannel(): updating of item V_STATUS (type BRIDGE_STATUS) failed.

Log messages like that seem to preface every time the controls end up not working. For example, this one happened shortly after restarting OpenHAB (and the velux binding correctly reporting the shutters from the KLF including their position, indicating that the KLF200 can indeed communicate with the shutters).

Just for the record I found out that at least one of the reasons why controlling the shutters doesn’t work is that they are “priority locked” (presumably by my handheld remote controls, because I’m not aware by any other systems controlling them).

Since this binding sends its commands at the priority level 5 (comfort / automation) the blinds refuse to override the presumably “more important” user setting.

While that is a good default level, it would be ideal if direct user-interacted settings (via the app or web app) were sent as user input (and thus override the priority lock). I don’t know if there is a way to distinguish “user initiated” and “automated” events in OpenHab though …

Also as a side note, it would be nice if the binding printed the details of the refusal at the INFO level, I had to switch to debug to find the “ntfStatusReply=6” value that indicates priority lock