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
thanks
Andrea
Hi,
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: 0.1.1.0.41.0 on the KLF.
Thanks,
Kristoffer
Could you please post your affected areas of ITEMS, RULES and Sitemap?
It will be helped to troubleshoot it
Absolute - sorry about this:
velux.things:
Bridge velux:klf200:home [ bridgeURL="http://10.10.10.251:80", bridgePassword="xxxxxxxx", timeoutMsecs=4000, retries=10 ] { }
velux.items:
// 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" }
velux.rules:
rule "PushButton of group velux"
when
Item gVeluxbrigde changed
then
// waiting a second.
Thread::sleep(1000)
// Foreach-Switch-is-ON
gVeluxbrigde.allMembers.filter( s | s.state == ON).forEach[i|
// switching OFF
sendCommand(i, OFF)
]
end
sitemap:
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:
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.
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.
Tobias,
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)?
Cheers,
Guenther
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!
cheers.
It is available through netamo as well.
https://shop.netatmo.com/dkk_dk/indoor-climate-control.html
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 
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 ?
yes!
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 
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 ?
Did you make any hands dirty?
It is bidirectional and semi-stateful. If I manipulate the window with a classic remote the app will only know that the saved position is not valid (or might not be valid). By pressing the value slider button it seems to retrieve the window position without sending a new position and then the slider snaps to this read value.
I ordered an Apple TV Gen4 as it can act as a homekit server. Did anybody here had some success with the homekit binding. My vision is that Apple TV has the objects of velux under control and openhab also connects to this server (local net). for every OH item there will be a homekit object and I would have to create 1:1 rules that keeps this dummy object in sync with the real velux object. Not sure if the velux object will directly be visible in OH - I don’t know the binding that well.