Io-homecontrol / velux - something's in the bush

Better news. I solved the problem with not being able to learn after the factory reset. The problem seems to have been that with the first learning cycles the Somfy roller shutter motors had memorized the io ID of the KLF 200 and then no longer responded to a new learning attempt from the KLF 200, which resulted in the messages of no new product being found that I saw. For the record and others to fix the same problem should they run into it, the solution was to reset the Somfy roller shutter motors to factory settings, the guy here explains this process very well:

Then you need to re-program each individual roller shutter again from scratch, again explained very well by the same guy:

After this process was done, I was again able to learn the roller shutter motors using the KLF 200 web interface and also record programs (which in my [English] interface are called programs, not scenes). I can thus confirm that, yes, the KLF 200 is able to learn and control Somfy io roller shutters (the latter so far with the KLF 200 local web interface). Interestingly, Velux themselves tells us on their website that, in order to control their products via an app, we should buy a Somfy TaHoma Connect box (which means for me that io products are and have to be compatible with each other, across companies):

At this point I have been able to confirm points (1) to (4) from my February 16 post, with the small constraint that for (4), one can only run pre-recorded programs/scenes, but one can record as many programs as needed and each roller shutter can be in multiple programs, so that one can have programs for individual roller shutters and programs that combine multiple roller shutters. Sorry for being so verbose, but I wish I had found a detailed description before and from other posts in this thread it seems that others are looking for the same information.

Now I am trying to integrate the bridge into my OpenHAB 2.2 installation (point (5) from the February 16 post). The straightforward approach did not quite work yet, I will keep you updated. Anyway, thanks to all who helped me along so far, it’s really nice to get such good support!


Good news, everyone, I now also figured out point (5). Because I am still on the official version 2.2, I had to use org.openhab.binding.velux-2.2.0-SNAPSHOT.jar from (which I had expected and which I simply copied to OpenHAB’s openhab2-addons directory). It now turns out, however, that the documentation on the mentioned GitHub page is incorrect (w.r.t. the needed options to link to the KLF 200 and some of the syntax of the options—in many cases ALLCAPS are needed) at least for this pre-compiled 2.2.0 snapshot version. The correct configuration is as follows (the Expire binding is needed in addition; example with 2 sets of shutters as defined on the KLF 200, with an open and a close action/scene/program each).

*.things file:

Bridge velux:klf200:home   [ bridgeURL="http://192.168.x.y", bridgePassword="velux123", timeoutMsecs=4000, retries=10 ] {
    Thing   scene   RS_Shutters1_Open              [ sceneName="RS_Shutters1_Open" ]
    Thing   scene   RS_Shutters1_Close             [ sceneName="RS_Shutters1_Close" ]
    Thing   scene   RS_Shutters2_Open              [ sceneName="RS_Shutters2_Open" ]
    Thing   scene   RS_Shutters2_Close             [ sceneName="RS_Shutters2_Close" ]

*.items file:

// Velux KLF 200 bridge channels
String  VELUX_BRIDGE_STATUS     "Velux Bridge Status"                { channel="velux:klf200:home:STATUS" }
String  VELUX_BRIDGE_FIRMWARE   "Velux Bridge Firmware version"      { channel="velux:klf200:home:FIRMWARE" }
String  VELUX_BRIDGE_IPADDRESS  "Velux Bridge IP Address"            { channel="velux:klf200:home:IPADDRESS" }
String  VELUX_BRIDGE_SUBNETMASK "Velux Bridge IP Subnet Mask"        { channel="velux:klf200:home:SUBNETMASK" }
String  VELUX_BRIDGE_DEFAULTGW  "Velux Bridge Default Gateway"       { channel="velux:klf200:home:DEFAULTGW" }
Switch  VELUX_BRIDGE_DHCP       "Velux Bridge DHCP Enabled [%s]"     { channel="velux:klf200:home:DHCP" }
String  VELUX_BRIDGE_WLANSSID   "Velux Bridge SSID"                  { channel="velux:klf200:home:WLANSSID" }
String  VELUX_BRIDGE_WLANPASSWD "Velux Bridge WLAN Password"         { channel="velux:klf200:home:WLANPASSWORD" }
Switch  VELUX_BRIDGE_DO_DETECTION "Velux Bridge Detection mode [%s]" { channel="velux:klf200:home:DETECTION" }

// one group for the actual items that talk to the KLF 200
Group gSomfyActual  "Actual Velux/Somfy Action Items"
// one group for the virtual items used for control on the sitemap
Group:Number gSomfyVirtual "Virtual Velux/Somfy Action Items"

// Velux/Somfy scene channels
Switch  SomfyRS_Shutters1_Open  "Somfy Shutters1 Open"  (gSomfyActual) { channel="velux:scene:home:RS_Shutters1_Open:ACTION", expire="1s,command=OFF" }
Switch  SomfyRS_Shutters1_Close "Somfy Shutters1 Close" (gSomfyActual) { channel="velux:scene:home:RS_Shutters1_Close:ACTION", expire="1s,command=OFF" }
Switch  SomfyRS_Shutters2_Open  "Somfy Shutters2 Open"  (gSomfyActual) { channel="velux:scene:home:RS_Shutters2_Open:ACTION", expire="1s,command=OFF" }
Switch  SomfyRS_Shutters2_Close "Somfy Shutters2 Close" (gSomfyActual) { channel="velux:scene:home:RS_Shutters2_Close:ACTION", expire="1s,command=OFF" }

// Velux/Somfy scene actual controls (virtual)
Number  SomfyRS_Shutters1 "Somfy Shutters1" <rollershutter> (gSomfyVirtual) { expire="1s,command=0" }
Number  SomfyRS_Shutters2 "Somfy Shutters2" <rollershutter> (gSomfyVirtual) { expire="1s,command=0" }

*.sitemaps excerpt:

Frame label="Rollershutters" {
	Switch item=SomfyRS_Shutters1 label="Roller Shutters 1" mappings=[1="▼", 2="▲"]
	Switch item=SomfyRS_Shutters2 label="Roller Shutters 2" mappings=[1="▼", 2="▲"]
Frame label="Infos/Settings" {

*.rules file:

rule "Velux-Somfy Action"
	Item gSomfyVirtual changed
	gSomfyVirtual.members.filter( s | (s.state as DecimalType) == 2).forEach[item |
		var actionItem = gSomfyActual.members.findFirst[name.equals( + "_Open")]
	gSomfyVirtual.members.filter( s | (s.state as DecimalType) == 1).forEach[item |
		var actionItem = gSomfyActual.members.findFirst[name.equals( + "_Close")]

Of course, no guarantees, yet things seem to work now for my configuration. There may still be some situations that I need to check, such as what happens when the system start up or reboots, but I hope this helps some of you. So long story short, you can control Somfy io roller shutters from OpenHAB using the Velux KLF 200.



1 Like

Guys, I’ve a question.

At the moment I have 5 velux + 5 roller shutter managed via KLR-200 (one for each velux). No wires, everything is wireless.

I would like to know if KLF-200 is the right solution to connect everything to OH via experimental binding. In case, how to connect the gateway to all 5 devices … is there a way to “download” the configuration of each KLR-200 in the gateway KLF-200?

I hope this is clear enough


After upgrade to 2.3 lastest snapshot of OH and also the Velux binding, the scene will not start.

All scenes and the bridge is online.

I get following info in the log:

15:59:59.066 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'Bathroom_window_100' received command ON
15:59:59.069 [TRACE] [ab.binding.velux.handler.VeluxHandler] - handleCommand(velux:scene:home:Bathroom___window___100:ACTION,ON) called.
15:59:59.100 [INFO ] [home.event.GroupItemStateChangedEvent] - gVeluxbrigde changed from OFF to ON through Bathroom_window_100
15:59:59.122 [TRACE] [ab.binding.velux.handler.VeluxHandler] - handleCommand(): working with channelId ACTION.
15:59:59.134 [INFO ] [smarthome.event.ItemStateChangedEvent] - Bathroom_window_100 changed from OFF to ON
15:59:59.216 [TRACE] [ab.binding.velux.handler.VeluxHandler] - handleCommand(): working with channelSubId .
15:59:59.233 [TRACE] [ab.binding.velux.handler.VeluxHandler] - handleCommand(): working with PROPERTY_SCENE_NAME Bathroom - window - 100.
15:59:59.250 [TRACE] [ab.binding.velux.handler.VeluxHandler] - handleCommand() cannot handle ON/OFF on channel ACTION.

I have the same items, things etc., which was working correctly under 2.2 of OH and Velux binding.

Any ideas about this issue?

Im still running firmware: on the KLF.



Could you please post your affected areas of ITEMS, RULES and Sitemap?
It will be helped to troubleshoot it

Absolute - sorry about this:


Bridge velux:klf200:home   [ bridgeURL="", bridgePassword="xxxxxxxx", timeoutMsecs=4000, retries=10 ] {  }


//  Group for simulating push buttons
Group:Switch:OR(ON, OFF) gVeluxbrigde "PushButton"
Group window
Group windowclose
Group windowopen
Group windowflow
Group windowhalf

Switch  Bathroom_window_0   "Luk vindue"        (window,windowclose,gVeluxbrigde)     { channel="velux:scene:home:Bathroom___window___0:ACTION" }
Switch  Bathroom_window_flow    "Åben flow"     (window,windowflow,gVeluxbrigde)     { channel="velux:scene:home:Bathroom___window___flow:ACTION" }
Switch  Bathroom_window_50  "Åben 50 %"         (window,windowhalf,gVeluxbrigde)     { channel="velux:scene:home:Bathroom___window___50:ACTION" }
Switch  Bathroom_window_100 "Åben helt"         (window,windowopen,gVeluxbrigde)     { channel="velux:scene:home:Bathroom___window___100:ACTION" }


    rule "PushButton of group velux"
        Item gVeluxbrigde changed
        // waiting a second.
        // Foreach-Switch-is-ON
        gVeluxbrigde.allMembers.filter( s | s.state == ON).forEach[i|
            // switching OFF
                sendCommand(i, OFF)


Text label="Badeværelse" icon="toilet" {
	Switch  item=Bathroom_window_0 mappings=[ON="Klik"] icon="window-closed"
	Switch  item=Bathroom_window_flow mappings=[ON="Klik"] icon="window-closed"
	Switch  item=Bathroom_window_50 mappings=[ON="Klik"] icon="window-ajar"
	Switch  item=Bathroom_window_100 mappings=[ON="Klik"] icon="window-open"

Kept it short and only took the example with controlling the basic of a window.

From my point of view, everything looks so good.
Two things that irritate me a bit:

  1. Are you sure the VELUX Bridge is online?
    I also had some problems with the bridge, at that time the bridge was not reachable.
    Since then, I’ve also integrated the channels (items) on the bridge to see if it’s reachable.

  2. Your scene names Bathroom___window___100 can it be that they are misinterpreted?

15:59:59.069 [TRACE] [ab.binding.velux.handler.VeluxHandler] - handleCommand(velux:scene:home:Bathroom___window___100:ACTION,ON) called.

15:59:59.233 [TRACE] [ab.binding.velux.handler.VeluxHandler] - handleCommand(): working with PROPERTY_SCENE_NAME Bathroom - window - 100.

Yes - the bridge is reachable and online in PaperUI. Im also able to get IP address, firmware etc.
All scenes are also status of online in PaperUI.

When i come home, i will try to make a scene on the KLF, where spaces are not included and test this.

Thanks for your help!

Just a quick note about the update to 2.3: I did the OpenHAB update as described in the release notes, then replaced the org.openhab.binding.velux-2.2.0-SNAPSHOT.jar with the org.openhab.binding.velux-2.3.0-SNAPSHOT.jar file, adjusted the configuration of the *.things and *.items files to those mentioned in the documentation for the binding (i.e., the versions of the channels without ALLCAPS in the *.items file and using bridgeIPAddress=“192.168.x.y” instead of bridgeURL=“http://192.168.x.y” in the *.things file), and after restarting the service things work just fine.

If you start fresh from 2.3 then please note that my comment about the documentation of the binding not being entirely accurate is no longer correct, just follow the example from the documentation and things should work. Nonetheless, I like my implementation with the virtual items better than that in the original documentation, but that’s probably in the eye of the beholder. If you want to use my version just adjust the channels and the bridge configuration from my example above according to the documentation and it should work for you.

just a question: Is there a reason to avoid ALLCAPS within the items file? At which point is there an invalid description (pls. advise via PM)?


BTW: the binding for 2.4.0-SNAPSHOT is available now.

Hi everone.
I created this thread two years ago. While we were striving for the best integated solution we stumbled across reverse-engineering, somfy usb, all sorts of KLF etc… From today on in my country Velux Active is ready to ship and I ordered this product. Something like this was announced over a year ago and it was the reason why I stopped working the KLF way. Thanks to homekit integration we should have the API we are looking for - but they are public so it needs internet and their cloud services. Once I get the new gateway I will sniff around and let you guys know if there is a local way to get access to some APIs. Even if not, looping back over “internet” homekit would work to me. For a local gateway Apple TV can be used which terminates public “API calls” to the local network.

Anyway, I will have a look and learn how it works behind the scene. so far it seems to be my most preferred way and I actually welcome the algorithms coming from Netatmo to be running in the closed system.

Hoping you find this interesting. The price is actually not that bad!


1 Like

It is available through netamo as well.

But I honestly fail to understand, what chosing thie “Active” rather than the KLF 200. I guess I´ll need to wait for the API to see if it´s any different. But I really doubt that.

Active is not a KLF. Active is cloud-based and the added value besides remote control is that they took the artifical intelligence algorithm of Netatmo to control roof windows and blinds for best room climate - also using Netatmos sensors as a OEM product (it does not work with the Netatmo sensors, you must use Velux sensors - but inside is Netatmo). local access is possible by using the Velux App or Apple Homekit. Homekit is the magic word here as this means we can integrate Velux in the frist time of history through any smart home solutions without limitations. KLF have their limitations and inventory is not accessible by means of API. With homekit this is transparent and inventory of discovered velux/io-homecontrol objects will be visible to any client. So we’ll see how far we can get it using HomeKit. In parallel I will also study the local API (if they are any) or sniff the traffic between the app and the Active Gateway to understand what’s going on for a possible future openhab binding - having this would enable local traffic without looping through any cloud/public IP.

If anybody wants to have some KLF100, I have 8 of them that I can sell cheap because they will be of no value any longer using the Active Gateway.

I do not agree. KLF 200 does indeed have an API, as far as I understand. It doesn´t need cloud service at all.
Having Netamo, as well as the KLF 200, and OpenHab, I can do the same. Infact even though I do have Netamo, I really dont need it.
I can control all my Velux toproof windows from my mobilephone right now, sitting here at work 40km away from my home, through myOpenhab.

I really couldn´t care about Homekit. I use Android :slight_smile:

Why do I need Velux Active? I really try to understand the difference between KLF 200 and Velux Active. Beside beeing made by Netamo, which for sure is possive, rather than Velux, who I really hate, I can not see any functions I havn´t already got.

The only limitation i miss, (actually it applies to all Velux windows, they´re simply to stupid) is an active statement from the window, telling me if it´s open/closed, and if open, how much.
Since there are no sensors available, I cant tell if my windows are open or not. I have to create a rule for this in OpenHab, and rely on it behave as it´s suppose to.
I did however add a single Xiaomi door/window sensor to one of my windows, just to test this. Now I know when this window is open or closed, but I don´t know how much. And this is probably the only way, unfortunatly. (I have 8 Velux windows, so next step is to add more sensores).

What am I missing?

PS forgot to mention, all my windows are integra and controled wireless through the KLF200.

The KLF does not have real APIs. What the binding is doing is just invoking some HTTP Post/Get towards the webserver of the KLF as it would have been a user touching a button. You cannot create rules, schedules, it’s limited in numbers of managed windows/blinds, it does not have any intelligence in terms of climate control, etc…. I call this “pressing a button behind the scene” but this is far away from real APIs. API’s would have services such as getRegisteredWindows, getStateWindow(ID), setStateWindow(ID), deleteSchedule(ID) etc…. HomeKit goes into this direction but not all functionality is exposed on the API and still must be performed on the GUI (such as schedules, threshold to air out a room when CO2 is exceeding etc…). Still, I can query windows, set the state, having two way communication. It’s not fire and forget. Active Gateway comes with alogithms made by Netatmo that are very clever - it’s not a easy thing to do with opehab, while you can certainly create a rule that opens a window when CO2 from any sensor is exceeding, you cannot easily do things like predictive climate controls of rooms taking into account the local wheather, knowing if opening the window will really make for comfort better, be self-learning on your personal preference of how you want your climate etc… Active does that, can manage 100 objects incl sensors, gives your the readout of the sensors and the readout of any window and blind position because it’s fully managed. KLF is just “another remote”. Active is a management solution. Not the same thing to me.

As much as I love openhab and the centralized approach of having rules etc… I begin to realize that sometimes it’s very good to have de-centralized alogrithm that run by their own, having a roadmap of a climate vendor (Netatmo in this case) - improving it transparently to us etc… still I want integration. And this is what the “Active” can do, both of this tasks actually. We will see what we can do locally on the Gateway itself - could well be that we fall back to the “pressing a button behind the scene” but I welcome what they did. Read the FAQ it proves that they waited another year so the solution is mature enough to be actually usefull. As to me, this is what I wanted. KLF’s appreciated but not needed any longer to me.

Just my opinion and I respect everyone that goes the KLF way. It’s not bad at all…

Are you sure about that two way communication, and get/set StateWindow? If thats correct, this gateway is for sure interesting. But this is Velux (and Netamo), using a very old wireless technologi… They have had a lifetime to do somthing like this… Why now? And why cloud based together with Netamo ?

It’s io-homecontrol. Newer remotes (with display) were always two-way communication. You can tell by reading the picrogram of io-homecontrol. so the protocol was always there and as you know we tried to decrypt it and found that there is indeed a response coming. However we couldn’t understand the payload so we gave up and back then we identified some other gateways they claimed to have with some B&O integration and another one with KNX. but they never appeared, we couldn’t order it neither. 2017 they announced that they were woring on Smart Home integration. No wonder, as the touch-panel remote is costly and it would be much more meaningful to have Android and iOS based remotes since this is software only. But this would need a gateway sending io—homecontrol in both directions. This is why I stopped and waited for this product. And now (1 year later) it’s ready. I’m quite sure that they wanted to start by their own (velux internally) but then realized they lack knowhow of:

  • writing software for iOS and Android

  • having a cloud backend

  • smart climate algorithm that takes into account local wheater condition without an outdoor sensor

  • accurate hardware sensors especially CO2 which is not easy to do and Netatmo were always ahead of others.

Theses are pretty much the core competence of Netatmo.

at the same time Netatmo looked for partners. Conditions are they can brand the product with “xxxx with Netatmo” - and this is now the case. It reflects perfectly what happens in the industry at the moment and it’s a very common pattern. Sometimes even with a compony acquisition or merge.

Strategically I find this to be very clever. Velux is not any longer a closed system - this is mainly because of the consequence of Netatmo and their API integration strategy that they always had. I wouldn’t be surprised if I can find my velux windows and blinds in my user account on Netatmo - because such integration would make much sense.

As much as I praise the new solution. I have to make my hands dirty when I actually hold the gateway in my hands - WireShark included :wink:

I have the KLR200 remote (the one with color display). I really wonder why it´s not possible to see the windowstate, when you say it´s possible. I have a feeling, that the window itself can not set it´s state. If thats true, Netamo or anyone else will not be able to change that.

Interesting! I would really like to avoid all cloud stuff. For that case i was looking at the KLF. How is this Velux Active different then the Connexoon in terms of API reverse engineering / wireshark.

Hi Thomas, can you pls explain how to get the klf200 finding the somfy shutter, should i only reset the io motor and then let the klf200 search for it or must i do more to let the klf200 find the somfy io shutter ?