Hi all you guys suffering from the non-integratabiliy of io-homecontrol.
Long time ago, I started a thread (here) in the old forum where we actually tried to reverse engineer the io-homecontrol protocol. We learned a lot but bottom line is: we didn’t manage it:
nor the USB mouse Set&Go from Somfy. The USB sniff showed some encrypted traffic, some of it we understood, some not.
nor the touch remote. Using the USB port and booting the remote into UART mode.
nor the evaluation board of the RF chipset. you can get the application notes but not the protocol description as it’s licsensed
nor any pressure to velux
nor trying to find a way from another company be it somebody on the io-homecontrol alliance
nor waiting to the some-what documented KNX interface - it seems to be never developed.
Well, however: Now there seems to be something in the bush, this time the driver is Bang & Olufson.
Velux is working on a IP gateway!!! If somebody is linked to B & O please try to get such a gateway before Global Availability so we can go from there (much easier then, wireshark is your friend). Maybe sombody knows somebody working in the HiFi domain that could try to get such a unit as Velux seems to deliver the gateway to B&O dealers/customers before GA.
I’ll try my way too - both directly to Velux and via a HiFi store I know well.
This should give us some momentum, right? Chime in, if you think this is christmas to us!
thanks for the info. I currently think about buying a velux window with full automation for the window and binds. Unfortunately, your older link doesn’t work anymore.
So if I understood you right, there is currently no way to integrate a motorized Velux window/binds into openHAB?
Older versions of the Velux blinds could be configured to bypass the io homecontrol features to allow direct control of the motors. I had planned to use Hunter Douglas DBMZ Z-Wave controllers to drive the blinds. However, the blinds I purchased (Velux FMK 24 Volt) had the bypass feature removed, so I am left with blinds that don’t work.
I did manage to bypass io board in the blind itself but because of the location of the blinds (very high up and I don’t like heights!), I haven’t been able to test this.
Despite lots of searching, I haven’t found anthing that works with io homecontrol without paying them a large licence fee.
yes we are aware of the 24V solution for some of the product. But this thread was about the nice way: a IP Gateway with some sort of API.
So far, the only hope is this B&O Gateway made by Velux. I haven’t had any success to source one.
I followed the Io-homecontrol discussion and read some boards. But it seems there’s not a out of the box solution.
Therefore I built a “handcrafted” solution. I use two Velux Integra Solar shutters and connected the disassembled remote controllers to the raspberry GPIO. With some python script that controls the remote controller buttons and that is subscribed to a mqtt topic I’m able to open and close the shutter. ATM I can only completely open or close them, but It’s only a matter of programming and time to create a more sophisticated solution.
For me this is a working solution and a lot of fun to built it. And it was my first soldering project
I had a look at Fakro windows. They use Zwave and are much cheaper. Quality should be good, as a friend reported. So maybe I will try those for the attic…
I have just cancelled an order for 2 Velux roof mounted windows. They were specified by the Architect for our new home that we are currently building. The issue I had was that I want to be able to control all devices via openHAB or more specifically only one control system (which is why I have chosen openHAB).
I have been testing the Fakro window actuators over the last few days and despite some initial issues getting them configured they are looking good.
I’ve read the old IO homecontrol discussion.
First of all thanks a lot for your effort to make a io-homecontrol gateway!
I have several IO homecontrol products and I would like to control them via LAN and Internet without the Somfy Cloud!
I have from Somfy several external venetian blinds and a TaHoma Pad IO, from Velux integra windows, shutters and a few KLR 200 control pads.
I’ve read that you’ve tried to reverse engineer Velux KLR 200, Somfy SET&GO and the TaHomaBOX without sucess
The TaHoma Pad IO (https://www.somfy.de/produkte/1824029/tahoma-pad-io) is a linux based system and it has an USB port (to upgrade the firmware) and also capable to connect to WiFi networks (to check weather informations).
I don’t know how but if it is possible I would extract you a system image from this device to help your work or if there is any other way I can support your further efforts please let me know.
It would certainly help. But this would mean to spend around 500€ for such as “gateway” and chances are that the Tahoma Box authorizes the Tahoma Pad in which case “3rd party” USB commands won’t be accepted. It could also well be that they use the same USB communication as we have seen using the somfy set&go (why engineer another one) and we learned that they are AES encypted. Something with .Net or java would be good, as this can be nicely disassembled to learn what’s going on.
My B&O idea looks more promising but I have to get a chance to get one.
So, if you have one anyway, yes please provide a system image. if not, don’t buy one, just for us
I have contacted my local Velux and B&O dealers but none of them have heard about the new “Velux io homecontrol gateway”. They promised to contact me as soon as the product is available.
I know exactly what you’re trying to say here as I had the very same idea. But let me clarify the real problem here:
The RF chipset per se is not the problem - it’s readily available
The encryption uses a AES key which we couldn’t retrieve either by disassembling nor by sniffing or any other means. We checked the mouse (set’n’go) and found that the USB serial communication data is encrypted (but not all bytes). This means that the encryption is done in the microprocessor (on hardware) or in the application (on software set’n’go etc…) This makes it very hard to understand what’s going on. Albeit and if I remember correctly some commands can be replayed by sampling them and resending it and for some of the commands we were successful.
the chipset lacks any documentation on the protocol. The specification is only available when being a party in the io-homecontrol alliance. This is how they keep it „under control“. My personal and also my business experience says that this only works in a long-term strategy when opening up at least the APIs. I will bet that there will eventually be some interfacing products to integrate more nicely to 3rd party but until they realize how important that this will be in a IoT digital market, they will sell their own product suite which - sadly - are pretty much closed and in plain english just s***.
to sum up: yes the ADF7022 chips solve some Layer 1, Layer 2 issues but what we really need is more insight in Layer 7 or catching the next chance on any product that will be more suitable for us - such as the B&O gateway I found.
Remember our goal: it is not about breaking the AES or going into security issues - what we want is to use a product (such as the set’n’go mouse, which is affordable) but „speak“ to it. I don’t have any problem to let the pairing (key exchange) be performed by the vanilla mouse but after that we should get some API’s. After this, writing a binding is a piece of cake. None of the io-homecontrol alliance will ever be that powerful as openHAB they will never reach the speed of binding coverage needed for a true end-to-end IoT market. What they should do is to provide a gateway either with local API’s (such as the HUE) or with remote, cloud API (such as Netatmo) if they want things to be „under control* - too bad they are not rooted in the IT business and will probably never make it - but exactly this is paramount of importance for a vendor such as Velux.
The quest isn’t over - we will wait a catch the next train! Maybe they realize to catch their train when LORA and NB-LTE will be available and rethink the strategy.
leutholl, thank you very much for explanation. I hoped this aes stuff would be part of that chip as it clains to be “io-homecontrol” compatible ;-(
I’m a bit surprised that people did successfull replay attacks. Seems that some implementor of this super-secure thing did not make his homework
At the io-hc homepage they write that an individual key is used for each installation. So I guess the key exchange is done at the “learning” phase. Maybe the key could be grabbed in this phase - that would not break the encryption but would allow to “learn” a custom device (e.g. arduino). But that’s probably a bit offtopic here, i’ll look for a better thread for this thoughts
I think they are two keys. One is called something like „system key“ which is exchanged upon pairing for any remote (even the 1-way remote does this). The other key is the AES encrypted payload between the uP and the RF chip (or at least we think it’s AES encrypted). The replay wasn’t really a full success but as far as I remember they window (our actuator) did move - maybe it was only during the key exchange phase which is how windows identify themselves (so that people know which window is which) and logically for key exchange the encryption is different (or not on at all).
Even after pairing, what we have seen is that the payload is also encrypted (between set’n’go software and the mouse, sniffing USB) what we haven’t done (and we should do it) is to sniff the SPI/I2C whatever bus is in between the uP and the RF - I don’t think this one is encrypted as the RF chip manual doesn’t mention anything about payload decryption capabilities. I remember I did sniff in between the uP and the RF chip but at this time I canceled the work for whatever reason I don’t know anymore
I ordered a new scope yesterday which is excellent in serial debugging and if I get some time I might revamp my effort on this touch-pad remote of which I have plenty (I can afford to break one) which has the same architecture as the mouse. Can’t promise anything tough.
Maybe an outside view of our effort would be very revealing in terms of understanding how far away we are. Please read any comments/threads especially in the old forum as we shared quite some insight at this time (I think we even shared hex dumps on the USB mouse).
