[velux] New OpenHAB2 binding - feedback welcome!

Tags: #<Tag:0x00007f74644c7040> #<Tag:0x00007f74644c6f00>

Usually I keep the old .jar around, but in this case I stupidly erased it, as at first I did not notice that something is wrong:

The binding logs in to the KLF fine, I can see it in the logs. All scenes and actuators are recognized. I can even control all actuators with OH.

In fact everything but the status updates works. OH only reports errors all 10secs that it failed to get the current state, for all of my actuators. I use standard Velux SSL rollershutters and a KSX window opener. Everything worked fine until the update (however, I newly coupled the KSX to the KLF at the same time, so this migjt also be a reason).

I had this issue as well with one of my 8 windows with the latest binding. It turned out beeing due to having this specific window added both through PaperUI and manual thing file, (I assume the binding dont like when the same serial beeing added twice). It still updated the status though.
When I removed the windows from PaperUI added thing, the problem dissapeared…

Since this is probably not your case, I have no idea why it should fail on status for all your devices. You probably need to turn on Trace logging for Guenther to see whats going on.

Never thought about this issue. Now, it works fine even for multiple identical items or things.

:smiley: Expect anything when I´m testing :laughing:

I´m really pleased with the way it runs now, Guenther… Nice peace of work…

About the silent mode… I wonder if my windows simply dont support silent mode? They are rather old, (Integra windows Velux made in 2006. 6 of them don´t even support the 24volt socket on the side for curtain support). Perhaps they are too old to support silent mode?

1 Like

Yipeee! Update seems to have fixed my problem, too. Thanks a lot!

1 Like

For keeping the community up-to-date, the changes in a nutshell:

  • a thing named binding represents the current binding providing
    – information about the state (as channel information) and
    – the runtime environment (shown as property bundleVersion).
    – This thing is discovered even with no bridge definition to inform the user about further configuration steps.

  • the thing named klf200 represents a gateway towards the io-homecontrol world providing
    – information about the bridge itself (as channels and as well as properties) and
    – discovery of any registered io-homecontrol device (resulting in things with flavors window, rollershutter or actuator) and bundle of product settings (named scene).
    – non-Velux devices are supported even if there is no name attached within the gateway,
    scene's can be optionally attached with a velocity (default/fast/silent).

Open restrictions:

  • Direct access to a rain sensor is not possible - indirect access via device limitation settings does not yet work (as the gateway returns a protocol error :roll_eyes:),
  • Handling of position MY which may be used on some remotes to store a special position.

You’re the man!
Hope these Velux-guys will make the rainsensor accesible in the near future…

How to use the binding thing? I can add it in PaperUI but it claims that an KLF200 has to be added before, which I already have.

@gs4711, thanks a lot for this Binding, great work and ongoing support! As the KLF supports other devices as well, is there a way to trace the capability of these devices? I have recently added a HeatPump Boiler to my collection and - guess what - it supports io-homecontrol. I was able to connect it to the KLF and the binding shows it as “unknown device” and shows 2 channels, that don’t seem to change. Is there a way to trace capabilities?
I know this is a bit off-Topic from the VELUX KLF, will accept a “not-supported/out of scope” answer.


If you already have the KLF200 added (and online) in PaperUI. You just need to search for things, just like usual. (click the + sign, and choose the Velux binding).


thanks for your feedback. The binding should accept all devices, even an

if the device is recognized by the KLF200.

For getting more information out of the box, I suggest to enable the property isProtocolTraceEnabled within the thing klf200. This should display any communication on byte level within the log.

Maybe I was able to replicate the issue (a bit)?

I renamed the Binding Thing and now, it has configuration pending… it was working before and it is working still, but this is confusing. @gs4711 might want to have a look (here are my most recent logs)
velux.log.9.log (1000.0 KB) velux.log.10.log (1000.0 KB)
velux.log (412.2 KB)

Ehh, how on earth did you manage to get the Velux:Binding as a thing?? That should not occure like that.
The KLF200 thing is correct.

IT happened automatically everytime. I have never seen this before, but I don’t care. I tried it on different systems as well. I thought it belongs to the solution…
It shows up first thing, auto discovered, after the binding is dropped in the Jar folder and booted for the first time. even has nice text in it :smiley:

PS: Translated:
Velux Binding Information

This element informs about the status of the Velux binding and is automatically generated by Discovery without further configuration. It serves exclusively as information to support the commissioning phase.

Status: ONLINE A coupling element has already been defined. You can now set up additional devices by means of search (or discovery) or by manually adding Things.

Weird if you ask me… But it may be on purpose (for some reason) when using PaperUI things. I did try a scan in PaperUI which found all my devices. But I dont recall ever having seen that one.

I´m using manual things file, in which I believe this will not be possible.
Interesting to know to reason though :smiley:

did I miss something? Normally changing of the preferences within the section user interface should lead to the proper messages…

Oh, I was not complaining, I use german for myself, but for the forum I added a translation.

1 Like

Hi, I just upgraded from an older OH1 version (march 2019) to the latest OH2 version and must say that I am very impressed :slight_smile:
I was having issues that any klf action was veryyyy slow, like reacting only after around 20s of triggering it.

With the latest version it is instantaneous!
Thank you!

In case this is not normal, I am getting these lines on every item update:

10:34:09.609 [INFO ] [ing.velux.handler.VeluxBridgeHandler] - handleCommand(velux:rollershutter:home:blinds_velux_xxx:limitation,REFRESH): updating of item velux:rollershutter:home:blinds_velux_xxx
:limitation (type velux:rollershutter/limitation) failed

While debugging some issues I had I also saw a lot of

2019-11-10T11:07:24+01:00 homectrl karaf[19828]: 11:07:24.356 [DEBUG] [g.velux.bridge.slip.SCgetHouseStatus] - getRequestCommand() returns GW_OPENHAB_RECEIVEONLY (0xfffffffd).
2019-11-10T11:07:24+01:00 homectrl karaf[19828]: 11:07:24.358 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_OPENHAB_RECEIVEONLY,authenticated) called.
2019-11-10T11:07:24+01:00 homectrl karaf[19828]: 11:07:24.359 [DEBUG] [ng.velux.bridge.slip.SlipVeluxBridge] - bridgeDirectCommunicate(GW_OPENHAB_RECEIVEONLY) returns failure.
2019-11-10T11:07:24+01:00 homectrl karaf[19828]: 11:07:24.361 [DEBUG] [lux.bridge.VeluxBridgeGetHouseStatus] - evaluateState() finished with failure.

Not sure they are really of any problem as the binding is working fine it seems.


Hello Georges,

thanks for the feedback.

The debug messages regarding GW_OPENHAB_RECEIVEONLY tell you, that the binding is querying the i/o layer for any message coming from the gateway (which normally contain some status information about externally initiated actuator changes) … this is normal and does not matter.

The retrieval of the limitation settings is disabled, now, as the Velux gateway seems to have a faulty protocol implementation (or a typo within the API documentation). Without a proper feedback from Velux, the binding will just ignore this set of commands.

Best regards, Guenther

Hi Guenther,

Thank you for the explanations!