Power Modul: https://www.espace-domotique.fr/de/energeasy-connect/energeasy-connect-box-home-automation-multi-protokoll-espace-domotique-al001-1847.html
IO Modul: https://www.espace-domotique.fr/de/energeasy-connect/energeasy-connect-modul-io-homecontrol-din-schiene-espace-domotique-md031-1878.html
or a living room variant:
the old version looks like the old Tahoma Box:
Does anyone have information or experience about these devices?
German Information would be the best…
Thanks a lot.
That looks interesting, indeed @Hein.
It would be especially interesting whether it a) works offline without a cloud and b) can be integrated in OpenHAB.
Hi,
at the official io Homecontrol Site:http://www.io-homecontrol.com/index.php/en/the-brands
the brand Overkiz can be found.
There are some descriptions in english. In the flyer for the Din Rails System they write “Online/Offline Mode”.
It seems that overkiz is the producer of the conexxon box. It’s mentioned in the pdf from the “OVERKIZ MINIBOX”.
Does nobody use these devices?
Ok, some more news, good and bad. The good new is that I now have a KLF 200 and that it worked—once. I was able to learn the Somfy roller shutters to the KLF in interface mode and could indeed control them via the Web interface. Then I tried to be smart and tried to change the password for the Web interface. Big mistake. Not only does Velux have quite strange ideas about the quality of a password (only letters and digits), but then I could not log in anymore with the new PW. Great. Well, I did a factory reset and now I am no longer able to re-learn the roller shutters. Did anyone have a similar experience?
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:
https://www.youtube.com/watch?v=sPJsDK2htGs
Then you need to re-program each individual roller shutter again from scratch, again explained very well by the same guy:
https://www.youtube.com/watch?v=bZNUSvfCrD4
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):
https://www.velux.com/products/home-automation#io_homecontrol
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!
Tobias
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 https://github.com/gs4711/org.openhab.binding.velux (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" {
Text item=VELUX_BRIDGE_STATUS
Text item=VELUX_BRIDGE_FIRMWARE
Text item=VELUX_BRIDGE_IPADDRESS
Text item=VELUX_BRIDGE_SUBNETMASK
Text item=VELUX_BRIDGE_DEFAULTGW
Text item=VELUX_BRIDGE_DHCP
Text item=VELUX_BRIDGE_WLANSSID
Text item=VELUX_BRIDGE_WLANPASSWD
Text item=VELUX_BRIDGE_DO_DETECTION
}
*.rules file:
rule "Velux-Somfy Action"
when
Item gSomfyVirtual changed
then
gSomfyVirtual.members.filter( s | (s.state as DecimalType) == 2).forEach[item |
var actionItem = gSomfyActual.members.findFirst[name.equals(item.name.toString + "_Open")]
actionItem.sendCommand(ON)
]
gSomfyVirtual.members.filter( s | (s.state as DecimalType) == 1).forEach[item |
var actionItem = gSomfyActual.members.findFirst[name.equals(item.name.toString + "_Close")]
actionItem.sendCommand(ON)
]
end
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.
Cheers,
Tobias
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…