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).
Never saw the USB-io Transceiver WM before this seems to be a pretty good alternative to go local only.
The other option still is to use the TaHoma API, which still means using Somfys servers. But this would be an option in case you already have a Tahoma Box which is capable of controlling RTS and IO devices.
IMHO the Connexoon still requires an internet connection.
The Connexoon_Windows_EN product-sheet mentions a non-internet based pairing (pages 10,12), but still asks you to log into somfy-connect.com network (pages 11,13).
Yeah the KLF100 is 230V only (I think) and a single channel is just some kind of joke.
I bought a KLR100 remote off eBay with the intention of doing a dry-contact interface, but it seems like I’d have to make something that can navigate the menus, and past history with that kind of thing has been poor (i.e., not tracking state perfectly so getting out of sync and stopping working). Velux needs to get with the program and offer a multichannel US version of the KLF100 for a reasonable price (say, <$200).
