what's the status of io-homecontrol (velux)

[leutholl]

What would be the cheapest way to control several velux roof windows of the 2013 generation (io-homecontrol only and no 24V rollershutter support anymore) with openhab? Do I really have to buy a tahoma/somfy box (and how to integrate this one?) dis-assembling a cheap velux remote is not a solution for me as I have several windows (a cheap remote can only control 1 product and only one channel (so either window or blinds or ONE window) I also have blinds which must be controllable over io-homecontrol. The gateway of velux is pure crap as it can just send commands (sort of one-way) to a group of the SAME actor and only has 1 set of relais input. io-homecontrol is a great protocol and bi-directionally with quite some intelligence but we are lacking gateways. Is there any update on what to do?

leutholl

[Romain Bourdy]

Hi,

I have the exact same concerns, I considered unscrewing my remote ( http://www.powersystemsdesign.com/low-power-mcu-delivers-long-battery-life-in-velux-touch-screen-remote-control?a=1&c=1399 ) and according to what I found it has a SPI bus but I didn't take the time to buy an arduino and sniff it.

Good luck

-Romain

[leutholl]

Thanks Romain.

I might start a reverse engineer track (and I already did) to hack the touch remote... where's the SPI bus? on the touch or on the old-stylte remote? It "could" be best to get the old-style remote with real keys and a lcd to reverse engineer as I fear that the touch is too embedded for this (although I successfully logged into the boot loader over USB) - I need more time and this could be hard to do.

Thanks

[Romain Bourdy]

Hi,

 I google the io-homecontrol that has SPI pins, can't remember but will google it again.

 How did you manage to attach to the bootloader ? That could be a good starting point !

[leutholl]

like this (see attached).

Warning! Be very careful not accicently press a letter key that will erase your application rendering your remote bricked. You will have to to send it to Velux to re-flash as we can't get hold of the application binary image and upload it by our own. I did that (accidentaly) and must send it to my local support and hoping that they can reflash the application. The bootloader will always respond. So, you can't delete the bootloader. Velux will upload the application via z-modem kind of terminal protocol. But there seems no way to download (or upload?) it from the device to the pc.

if you have a working unit - please start it up without connecting it to usb during the boot time. as soon as the application is booted, connect the usb, open the terminal session (I'm on osx - there will be a usbmodem device unter /dev that you can talk to like a serial port - it's even autobaud when using USB) if you can get a response from the application other than the bootloader (which should not be running after the application has been started) you can then, try to "talk" to the application. If that works we might have a chance so use it as a gateway/interface). I can't test it anymore as I bricked my remote...

please share any info about he SPI - as this could be another possibility to emulate keypressed and alike... can't find any info on the web... please help me out.

sooner or later, we're going to achieve our goal - even if it means to contact the company who designed the application (I can't remember the company name but I think it's danish) asking for a simple API over USB.

I was also thinking of writing a io-homecontrol application from scratch using the SDK/DDK of the transceiver chip.

thanks.

[Romain Bourdy]

I've manage to attach but the output is mostly garbage to me:

[...]Ma maison[...]Toutes les fen�tres[...]V Amis[...] V Stephen[...]V Ethan[...]Ventilation[...]En mon absence[...]R�veil[...]Bonne nuit[...]Confort int�rieur[...]Vacances[...]Econom. d'�nerg.[...]Test[...]

What bauds settings did you use ?

Regards,

-RB

[leutholl]

Thanks man! That looks like they indeed implemented some sort of USB control. Will get my remote working so I can go from there. I'd load your dump in a hex editor to find any delimiter.

do you see any interaction? that is: if you type on your keyboard or push a soft-button on your remote, does the terminal reflect any changes? As I couldn't play around with my remote how do scenes work? It might be the best idea to trigger the scene based on a button touch emulation (if that's controllable by USB) as I don't think we have a low-level control of io-homecontrol.

will catch you on hangeout

thanks

[Romain Bourdy]

I according to my fiddlings, it seems that every action that triggers a wireless command is reported on the console, during "open" or close sequence its quits chatty so I even guess it prints feedbacks. Got two other remotes, will try later on to see if action on 1 remote triggers feedback on the second one. Would be nice. Waiting to have a talk with you, as you seem to know what you're doing ;) I saw few patterns in my first dump but I'm pretty sure my baud settings are not correct, too many "." char in the dump.

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/AinJdyyDtG0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/groups/opt_out.

[sgr...@gmail.com]

I would like to join the effort as I have two touch remotes and love reverse engineering :) But before I get there let me confirm one thing, when you say you bricked your remote, that is because you sent a destructive command while in boot loader mode, right? So there shouldn't be too much risk to brick it while in application mode? Do you guys have a page or wiki somewhere to log our findings on the protocol?

Sam

[leutholl]

Great to hear the velux victims are helping themselves ;-)

I bricked the remote by accidentally pressing a letter key during the bootloader cli. Stupid me, I played before googling the web.

We managed to get a trace of the communication between the uC and the io-homecontrol chip which we think is a 1:1 dump of the SPI interface (MOSI/MISO). There doesn't seem to be a "tag" to differentiate between uc and radio chip and without documentation the binary storm is hard to interpret. I tried to find patterns and yes they are some but you can't find the command list in any spec pdf of the radio chip that you need in order to understand what the uC is doing with the radio chip. I think they did that on purpose to prevent activities as the one we're trying to do. any now and then there is some clear text ascii of the command names of the remote buttons / scene but it doesn't help.

It'll be great to get your view. Please find the files in the attachment.

Romain and I really think we have to get some progress on the business track rather than the technical track that is to write an open letter to the developers to finally start to implement some APIs on the USB port.

PS: My bricked remote was returned successfuly - I got a new flash form the company during warrantee.

[leutholl]

[Romain Bourdy]

Hi There, is there any progress on you side ? I've lost all control over my velux since I added the blind and didn't take time to fix yet.

All the best,

-Romain B.

[Sam Grimee]

not yet, still stuck with a bad usb cable (or burnt usb port on the remote) and didn’t have time to buy one yet.

But given your traces below, it seems indeed that the best route is the management path, or get a KLF100 interface: http://www.io-homecontrol.com/images/io-homecontrol/pdf/io-Velux_EN.pdf

Sam

[milymat]

Please keep us informed.

It would be awesome to control io-homecontrol via OH.

[Romain Bourdy]

Re-opened my remote and found the hardware reference :

Touch panel : http://www.ampire.com.tw/en/p1-product-detail.asp  - 3.5"–AM320240L Series
GUI : touchgfx.dk
uC: EFM32 Cortex-M3 ( http://www.silabs.com/ )

 Anyone want to contact them ? Or maybe can explain how to crack it fully open without breaking ?

Rgds,
-Romain

[luca...@gmail.com]

Hi all!

I own 3 spare remotes (the ones with hardware buttons - not touch) from Integra roof windows (from 2009) and I need to control all of it from the home-automation PLC ( 750-831 from Wago ).

Now I'm considering to connect all of the buttons of a remote to arduino's outputs.

The arduino ethernet would receive modbus command from PLC and it should be programmed to act the buttons of the remote through menus and functions as I would do with my fingers.

Buttons are connected to the NEC chip of the remote in a matrix of 5x2 an should be sufficient to use 7 outputs of the arduino to control all of them through optocouplers.

This approach is very simple and permits to control basic functions  (select single or group of blinds and opening/closing it).

Of course connecting via USB/Serial would be cleaner approach.

Regards and an happy new year!

Luca

[luca...@gmail.com]

OK,  I missed the essential: I would like to help.

The hardware inside the remotes I own is:

NEC V850ES/JG2 32bit risc microcontroller
 
http://am.renesas.com/products/mpumcu/v850/V850esjx/v850esjx2/Documentation.jsp

ANALOG DEVICES ADF7020 transceiver

http://www.analog.com/en/rfif-components/rfif-transceivers/adf7020-1/products/product.html

IC 95128WP 256Kbit and 128Kbit Serial SPI Bus EEPROM

A graphic display of which I found no information googlin' around.

Regards. Luca

[Thomas Eichstädt-Engelen]

Hi Luca,

you could also considering using a cool piece of hardware called "TinkerForge" (see www.tinkerforge.com). We used it to implement pretty much the same UseCase and the openHAB Binding is ready to use :-)

Best, 

Thomas E.-E.

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.

[Vincent Danjean]

Hi,

On 06/01/2014 18:29, luca...@gmail.com wrote:
> I own 3 spare remotes (the ones with hardware buttons - not touch)
> from Integra roof windows (from 2009) and I need to control all of it
> from the home-automation PLC ( 750-831 from Wago ).

[...]

> Buttons are connected to the NEC chip of the remote in a matrix of
> 5x2 an should be sufficient to use 7 outputs of the arduino to
> control all of them through optocouplers.

I did this kind of thing (using optocoupler controlled by 1-wire switches)
to "manipulate" remotes of unknown blind found installed into my home.
It works well, but optocouplers generate a voltage drop (not sure of
this English expression, "chute de tension" in French) that is not
present with plain contact (buttons of the remote). For my remotes, the
effect is that the remote stop working as soon as the battery discharge
a bit (whereas it still works if I manually push the button).
I also have 4 Integra roof windows with remotes. I use two of them.
I was planning to use a third one with the same kind of hack
(optocouplers directed by 1-wire switches) but I never find the time
to really do it.
Not that this is not the perfect solution: the list of button is
not the same, for example, when it is raining or not when I want to
open the window. Or when I want to open the blind and there is snow
that block the blind. The display give a feedback, but here we would
not have this feedback...

> This approach is very simple and permits to control basic functions
> (select single or group of blinds and opening/closing it).
>
> Of course connecting via USB/Serial would be cleaner approach.

What I've seen in other forum is people that remove all io-homecontrol
logic and that directly control the motors. I'm not sure I'm ready
to do this ;-)

Regards,
Vincent

> Regards and an happy new year!
>
> Luca
>
> Il giorno lunedì 28 ottobre 2013 02:53:21 UTC+1, leutholl ha scritto:
>
> What would be the cheapest way to control several velux roof windows of the 2013 generation (io-homecontrol only and no 24V rollershutter support anymore) with openhab? Do I really have to buy a tahoma/somfy box (and how to integrate this one?) dis-assembling a cheap velux remote is not a solution for me as I have several windows (a cheap remote can only control 1 product and only one channel (so either window or blinds or ONE window) I also have blinds which must be controllable over io-homecontrol. The gateway of velux is pure crap as it can just send commands (sort of one-way) to a group of the SAME actor and only has 1 set of relais input. io-homecontrol is a great protocol and bi-directionally with quite some intelligence but we are lacking gateways. Is there any update on what to do?
>
> leutholl
>

> --
> You received this message because you are subscribed to the Google Groups "openhab" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at http://groups.google.com/group/openhab.
> For more options, visit https://groups.google.com/groups/opt_out.

--
Vincent Danjean Adresse: Laboratoire LIG - Bât. INRIA Rhône-Alpes
Téléphone: +33 4 76 61 55 10 655 avenue de l'Europe
Fax: +33 4 76 61 52 52 Montbonnot Saint Martin
Email: Vincent...@imag.fr 38334 Saint-Ismier cedex

[luca...@gmail.com]

Hi Vincent,

thanks for pointing out these issues.

Il giorno lunedì 6 gennaio 2014 23:01:03 UTC+1, Vincent Danjean ha scritto:

 Hi,

On 06/01/2014 18:29, luca...@gmail.com wrote:
> I own 3 spare remotes (the ones with hardware buttons - not touch)
> from Integra roof windows (from 2009) and I need to control all of it
> from the home-automation PLC ( 750-831 from Wago ).
[...]
> Buttons are connected to the NEC chip of the remote in a matrix of
> 5x2 an should be sufficient to use 7 outputs of the arduino to
> control all of them through optocouplers.

I did this kind of thing (using optocoupler controlled by 1-wire switches)
to "manipulate" remotes of unknown blind found installed into my home.
It works well, but optocouplers generate a voltage drop (not sure of
this English expression, "chute de tension" in French) that is not
present with plain contact (buttons of the remote). For my remotes, the
effect is that the remote stop working as soon as the battery discharge
a bit (whereas it still works if I manually push the button).
  I also have 4 Integra roof windows with remotes. I use two of them.
I was planning to use a third one with the same kind of hack
(optocouplers directed by 1-wire switches) but I never find the time
to really do it.

It's even worst: I was considering to put two optocoupler each button to accomplish the two row - five column matrix of buttons!!
Optocoupler selection will have major importance then.

I saw an ack, googling around the internet, where the arduino shared common ground with the remote (an older model than mine) and arduino's output were coupled with common use transistors. I think this is not applicable because of the button matrix here......

 

  Not that this is not the perfect solution: the list of button is
not the same, for example, when it is raining or not when I want to
open the window. Or when I want to open the blind and there is snow
that block the blind. The display give a feedback, but here we would
not have this feedback...

A friend suggested me to connect the arduino to the display via the serial line from the CPU and try to read data there:
I think it is not feasible because the display looks like a graphic display, not a text display and should be hard to obtain decent feedback.....

On the other side I just need to do simple jobs:
- close blind at night or when we're out, reopen at wake up or when we're back at home;
- control blind position at summer to have decent light and keep the house fresh;
- open windows in summer as soon as the outside temperature outside drops to have a little cooling.

> This approach is very simple and permits to control basic functions
> (select single or group of blinds and opening/closing it).
>
> Of course connecting via USB/Serial would be cleaner approach.

What I've seen in other forum is people that remove all io-homecontrol
logic and that directly control the motors. I'm not sure I'm ready
to do this ;-)

Nor I am!! The remotes already carry out automatic functions, timing and I would prefere to maintain all these up and running!! Simply I feel it's a pity not to have all of them integrated with rest of domotics.
 

  Regards,
    Vincent

Regards
 Luca

[oscart...@gmail.com]

Hi all,

I am also really interested in your project. I have two Velux roof windows and it would be nice that I can control these with my own made home automation system

Op maandag 28 oktober 2013 02:53:21 UTC+1 schreef leutholl:

[leutholl]

The silence on our motivation to reverse-engineer io-homecontrol explains it's complexity. Number 1 issues are: no documentation. The chipset used is not documented on it's layer 7 protocol. even with successful sniffing on SPI or on the UART over USB on the touch remote, we can't understand framing, direction, timing well enough to at least resend a packet that's being accepted. Yet alone the complexity of the bi-directional radio interface and exchange of managed objects.

The currently available gateway from velux and alike are not going to make us smile. They are limited to a single "channel" commands for a single product or a group of products. And they all lack feedback of the bi-directional RF feature.

Similar limitations still apply when breaking out a remote with mechanical buttons and "closing" them by means of an optocoupler or open-collector.

As for me - I wait until somebody (most probably a manufactor which is a member of the io-homecontrol alliance) comes up with an ethernet gateway where a high-level api could be present. Or, another (semi)-open home-automation platform that is closer coupled to some of these manufactors will make it happen and provide api's.

If somebody finds a documentation about io-homecontrol, please share it here as things could change dramatically with some sort of standard documentation.

another thing to try would be to write an open letter to some key contacts, asking them for documentation or roadmap info.

leutholl

[sgr...@gmail.com]

according to this post (in french) http://www.multiroom.fr/overkiz-inteconnectivite-autour-du-protocole-io-homecontrol/  it seems that the company overkiz has developed a platform called Kiz Box that supposedly can talk IO Homecontrol

see http://www.ubifrance.com/uk/Posts-3108-Overkiz-runs-your-appliances-remotely-and-efficiently-with-kiz-box

I have not found yet the cost of this baby...

[Lukas Leuthold]

Thanks - it seems that the product is not yet available and comes with a subscription. I think we all are looking for a simple gateway with some sort of API control. I have found this:

http://takljusmoduler.velux.se/vms-DK/Documents/PDF/VMS%20Application%20Program%20Description-EN.pdf

from velux itself - maybe they are going into the "right" direction. All my effort so far ceased to prosper. ;-)

leutholl

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/AinJdyyDtG0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.

To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.

For more options, visit https://groups.google.com/d/optout.

[milymat]

Maybe you can use this usb device for io homecontrol. http://www.shop-io.de/io-homecontrol-produkte/somfy-set-go-io

[Romain Bourdy]

Hey that really looks brilliant, but couldn't see any linux or opensource app using it, more luck than me ?

Thanks !

-RB

On Sat, Jul 26, 2014 at 1:04 AM, milymat <mily...@gmail.com> wrote:

Maybe you can use this usb device for io homecontrol. http://www.shop-io.de/io-homecontrol-produkte/somfy-set-go-io

[Lukas Leuthold]

I saw that a long time ago. I tried to understand the app but it's written in Quartz (predecessor of .NET). But an idea would be to sniff on USB. If somebody has a unit let me know - it might even be a plain serial device over USB - and in this case It's much easier to hack it.  

I've been nudging my Velux represantive over and over again. He's internally looking for help - we've found a pdf on velux.se indicating a IP-IO Gateway. Hopefully this one will come soon!

leutholl

[jkubia...@gmail.com]

Any chance that you could say who your representative is?  I want to develop a crestron interface in US (where, I think that the frequencies are different than in Europe, possibly making everything more difficult). 

[Romain Bourdy]

Hi there,

 Finally took the time to crack my remote open, we can find the following chips:

 - ATmel MXT112e : http://www.atmel.com/microsite/maxtouch_eseries/mxt112e.aspx ( Touch screen ?)

 - is62wv51216bll-55bli (ram?)

 - efm32 gecko mcu  http://www.silabs.com/products/mcu/lowpower/pages/efm32g-gecko.aspx

 - E8564 ( I2c clock ???) https://www.spezial.com/commercio/dateien/produktbeitraege/RX-8564CF.pdf

Testpins labelled :

 - 3v3

 - gnd

 - chg

 - res 

 - sda

 - sci

Does that ring a bell for someone suggesting an idea by connecting this to an arduino or something ?

Cheers,

-RB 

[Lukas Leuthold]

Yes that's what I found also. And I even hooked up my bus analyzer to the I2C but what I read there wasn't easy to understand. I think it's the same data that's available under the usbtty access which we tried to analze but gave up since:

- data might be encrypted

- there seems to be sequentical frames, meaning that the same command leads to different telegrams

- it's bidirectional and it seems that the remote acknowledges the action feedback from the actor - so we have to understand both ways

- we don't know it it's read only or if data that we would send is interpreted on the usbtty.

What is easy to see is the names of the objects that indeed are transmitted over the air (I guess that's used when somebody wants to copy the settings from one touch remote to another - I tried that and the names are transferred as well)

Buttom line: Sniffing between the Gecko and the RF chip is extremely hard without documentation - would be really easy with documentation. I2C or the ttyusb could be on a higher level, but that would mean that one still has to use the remote and it could also be that the I2C is only used to communicate with the EEPROM which is storage and has nothing to do with what we want to achieve.

Way forward recommend from my standpoint is to sniff the USB with this little device from tahoma. I tried to understand the architecture of the application but it's in Quartz, the predeccesor of .NET and it's delievered all in one dll/application making it difficult to re-use. But what would help us is to by this USB mouse and sniff on the USB. I'll bet it's easier to understand compared to the touch remote hacking. There are two things that we would need: 1) buy the product or use one if somebody has it and test it for universal commands (not just for configuration as it is on the flyer) and 2) find a good USB analyzer, either software or hardware-based. But I don't have any experience sniffing USB but I'm sure it's possible, probably on a UNIX system.

Third route is to make pressure to our velux channels (all of us simultanesouly) to provide a decent IP-to-iohomecontrol Gateway with open API's.

Hope that helps.

leutholl

[leutholl]

Brief update! I ordered a somfy set&go and will hack it this way... hope it works. If the USB is plain readable, we might be in luck and a binding wouldn't be that far....

Am Montag, 28. Oktober 2013 02:53:21 UTC+1 schrieb leutholl:

[Sam Grimee]

I just ordered one too, let’s crack this thing...

--

[Rainer Müller]

woohoo i'm really curious if this works! i called somfy a week ago and asked them about their tahoma box. i just wanted to know if there is a way to use this box without their cloud connection, but no chance! there are not even a command line options to interact with this piece of crap. the guy from somfy said this has "security reason. i hate those closed systems. look at android, the open way is the key :-)

[leutholl]

Mine arrived today. Short test: Hook it up on OSX to create if it creates a tty.usbmodem and: VOILA it does!!!! That means the application on windows will most definitely talk to Set&Go stick over serial (over usb). Which in turns means (at least I hope) that the data can be sniffed on it's way in clear text (meaning ASCII) and a future application/binding would have it simple on the connectivity side. Next steps would be to really see traffic and start to interpret it.

That's good! it means that there is a higher level of programming interface available and the logic happens on the stick itself. Therefore we have to understand this kind of "API"

More news soon!

leutholl

[leutholl]

I invested some time today. Here is what I found:

- Application is written in plain C++ and uses the QT library for GUI etc... but not for communication to the serial port

- I can log all messages between the application and the mouse in both directions. They are not very chatty.... see here

- disassembly or attempt to decompilation of the application reveals some internals such as possible handled commands and the state machine but for me, it's not meaningful enough.

- when sending a command with a remote the mouse is silent, that means that it doesn't notify the application in any way of what's going on the radio interface (clearly, the session setup must be requested by the application as windows, rollershutters, sensors only reply to it, so it's a polling system)

- the entire thing works only if security keys were exchanged before as it's encrypted. I did that from my remote (the touch pad) to the set&go application, it then found my 8 products and as able to send the indentification command so the motors moved but I wasn't able to control it by means of up, down, stop etc... I still don't get it: is the set&go only a configuration tool or is something wrong with my velux products that I can't move them from set&go?

- chipset in the mouse is a ATMEL uC and a ADF7020 which can be put in io-homecontrol mode which is undocumented to the public. Wether or not the serial messages are the same as the SPI between the uC and the RF chip is not clear to me, i.e. what is the uC doing and bringing added value? it might be that the uC bootstraps the RF and behaves transparently afterwards, or it really interprets data and "transcode" it on the way.

- That brings me to an idea where I need your help. Please, if you get a set&go and install it, it will ask for a firmware update. At this time say yes but prior be prepared in forking the URL that's being accessed to retrieve the image. This image could help us. I can't make it happen to re-flash it again, it's just happy now and set&go starts as expected - I should have logged the traffic on the serial and on the internet at this stage. Maybe you can do it and help me here.

That's it for the moment...

[exr...@gmail.com]

I found this:
ftp://ftp.analog.com/pub/RFL/ADF7022/ADF7022%20Eval%20Note%20Rev%201.0.pdf

I don't know if its help

Am Montag, 15. September 2014 16:32:37 UTC-7 schrieb leutholl:

I invested some time today. Here is what I found:

- Application is written in plain C++ and uses the QT library for GUI etc... but not for communication to the serial port

- I can log all messages between the application and the mouse in both directions. They are not very chatty.... see here

- disassembly or attempt to decompilation of the application reveals some internals such as possible handled commands and the state machine but for me, it's not meaningful enough.

- when sending a command with a remote the mouse is silent, that means that it doesn't notify the application in any way of what's going on the radio interface (clearly, the session setup must be requested by the application as windows, rollershutters, sensors only reply to it, so it's a polling system)

- the entire thing works only if security keys were exchanged before as it's encrypted. I did that from my remote (the touch pad) to the set&go application, it then found my 8 products and as able to send the indentification command so the motors moved but I wasn't able to control it by means of up, down, stop etc... I still don't get it: is the set&go only a configuration tool or is something wrong with my velux products that I can't move them from set&go?

- chipset in the mouse is a ATMEL uC and a ADF7020 which can be put in io-homecontrol mode which is undocumented to the public. Wether or not the serial messages are the same as the SPI between the uC and the RF chip is not clear to me, i.e. what is the uC doing and bringing added value? it might be that the uC bootstraps the RF and behaves transparently afterwards, or it really interprets data and "transcode" it on the way.

- That brings me to an idea where I need your help. Please, if you get a set&go and install it, it will ask for a firmware update. At this time say yes but prior be prepared in forking the URL that's being accessed to retrieve the image. This image could help us. I can't make it happen to re-flash it again, it's just happy now and set&go starts as expected - I should have logged the traffic on the serial and on the internet at this stage. Maybe you can do it and help me here.

That's it for the moment...

Am Mittwoch, 10. September 2014 12:35:14 UTC+2 schrieb leutholl:

[leutholl]

It doesn't really help. Here's some insight of another session:

The initialization phase consits of:

1) power on/init package:

Write request 0x02 0x04 0xFA

Read response (and only if the mouse is plugged in after plugged out, otherwise no response): 0x43, 0x05, 0xff, 0xb9

2) radio command 1:

Write request 0xC0 0x00 0x25 0x01 0x00 0x00 0x06 <17 bytes data> 0x8F <2 bytes of data> 0x60 <10 bytes of data> 0xC0

Read response 0xC0 0x00 0x95 0x01 0x00 0x00 0x04 <lots of data in 3 frames, 1 pattern of 15bytes which will be seen later (let's name it pattern A) and 2 pattern of 15 bytes which is repeated in this response> 0xC0

interpretation: read RF io-homeontrol address (pattern A is included in every package which send a command to io-homecontrol), read hardware serial etc...

3) radio command 2:

Write request: 0xC0 0x00 0x25 0x01 0x00 0x00 0x0C <31 bytes of data> 0xC0

Read Response: 0xC0 0x00 0x25 0x01 0x00 0x00 0x0B <15 bytes of pattern A> <5 bytes always changing> <11 bytes of a new pattern B> 0xC0

interpretation: read something other (maybe a hashed security key) as this is pattern B which is at the end of every package sent to io-homecontrol). The application seems to retrieve 5 bytes of information.

4) radio command 3:

Write request: 0xC0 0x00 0x25 0x01 0x00 0x00 0x0C <31 bytes of data> 0xC0

Read response: 0xC0 0x00 0x25 0x01 0x00 0x00 0x0B <15 bytes of pattern A> <5 bytes always changing> <11 bytes of pattern B as seen before> 0xC0

interpretation: The application seems to retrieve 5 bytes of information.

After that the application is started and is ready for auto-scan. Note that these packages can be replayed and the mouse will accept it (it sends a acknowledge byte 0x55 "U") and if you send corrupt data is will be a not-acknowledge byte (don't remind which one). So I can bring the mouse in a "healthy state" manually with a bit of a sense of timing.

So far something must be transferred which I simply can't find in the byte stream and this is the hardware serial number. If you start the application and goto help, about you can see the software and hardware serial number. the hardware serial is printed on the PCB and consits of two parts 7-digit integer number and 3-integer digits followed by a "A".

My mouse has:

5067501A003 (as appearing on the application) and it is printed on the PCB: 5067500 (small mismatch) and somewhere else (A003)

this information must be transmitted somewhere along these packages so far but I can't find it. I tried different encoding (negative, 7bit, ascii, hex, numbers in integer, byte swap, MSB/LSB...) without success.

What would be very interesting is to compare these packages with somebody's other mouse/other hardware serial (I tell you what to do).

together we can make it...

leutholl

[Sam Grimee]

good job so far!

I have a mouse, let me know what you use to inject or replay binary traffic to the serial port. I have started playing with the python Serial package, in progress.

First, sorry to say I have already upgraded the firmware on the mouse, just before you sent the message. I have parsed the app binary to try and find a URL for the firmware but could not find it. I wonder if it is embedded in the binary as a resource?  One thing that must happen is that the app must query the mouse for its version. If we find that we might be able to simulate an outdated version and trigger a new download from the app.

I have been playing to see what is happening at USB level. I have captured traffic during initialisation, key transfer and window identification using vmware fusion on mac and its embedded usb capture capability.  To visualise, I had to patch their viewer to support the timestamps captured by fusion in my locale, but got it to work (ping me if you need this). See attachment, look for device 6.

So in a linux vm I can analyze the usb traffic and found that it is indeed just a serial connection, and there doesn’t seem to be any other usb messages involved apart from discovering the mouse class and config and setting up the serial line speed to 115200 8N1 on EP0. After that everything seems to happen on usb EP1 and EP2 which are the serial line in and out. EP3 (interrupt messages from serial port) seems not used.

I can replay the initialisation sequence with this snippet in python. Going forward I think I can forget working at USB level and switch to pure serial.

The USB descriptors for my mouse are attached, I assume you have the same…

I’d like to write a small protocol analyser/visualizer in python based on your findings below to make our task easier

Sam

[leutholl]

Great to hear! Here is my setup:

VirtualBox on OSX running WinXP. installed Device Monitoring Studio to sniff COM3 which is created over USB (I agree, it's only serial comm, that's good!). I run the software in Demo mode which quite after some time and only 5 session possible per day. Still enough time to copy the hex values over to word. Then I keep track on the communication on word and use the middle column to append 0x to each byte. Having this I can copy paste the string to ReaTerm which allows to send Hex bytes in this format. There are two buffers (one buffer which I will use for the actual content, and the other one for the ACK 0x55 which I must send right after some(!) of the packages (not all need this and the mouse is fine). That's my test bench before moving to java or something.

Despite the firmware we can do a great test now:

Please try to record the same packages as in my word. You will get other values which we need to compare (only start up needed). Please state your mouse firmware serial found in the app (I agree it must be transmitted along these procedure). If you are afraid of sending the serial to a public forum, email me or hide some digits/bytes.

The firmware URL doesn't seem to be embedded as a URL in the exe (at least I didn't find it in 30min...) - that's strange where does it know the URL from? What I don't get is if they really is a win driver and it might happen there. My hypothesis is that it is just a serial driver over USB. I think the first three bytes and the three responses from the mouse if newly plugged in, is to identify the firmware version (but that's not the hardware serial).

Another great idea would be to flip the communication. simulate the mouse as the packages are more static. But then a little program must be used to keep the ACK in time and somewhere in the registry should be the COM port used (I guess that's happend during installation).

How many products and what kind do you have?

The mouse seems to be in io-homecontrol master mode as it is always requesting the communication never responding to it. commands over the air from another remote are not logged from the mouse.

Another important info is that the ATMEL processor on the board really is driving the serial communication. Although the io-homecontrol RF chip allows RF over UART passthrough, the ATMEL is creating the commands. Reason: after some brute-force or a series of invalid commands (I think even valid commands repeated which doesn't make sense according to the state machine) the USB disconnects (hear windows PnP sound) then comes back.

What do you think where should we spend our focus: on the serial comm, disassembling the exe or sniffing the SPI/UART between the ATMEL and the RF chip?

Could you deinstall the application, re-install it to see if it tries to upgrade firmware? Maybe when the registry is clean, it will always check. If yes, we log and analyze the code of the firmware which should be easier to hack compared to the exe (which unfortunately is written in C++ and they are no DEBUG symbols, it would be A LOT easier if it was written in C#.NET, JAVA or VB.NET

Thanks for the momentum..

leutholl

[Sam Grimee]

I will have a look when I am back home, where my mouse and windows are… I have 2 windows with one roller shutter each. The in my next home I have 6 of each, so eager to crack this open ;-)

So without the mouse here, but based on my previous capture, here is what I see on the wire. Sorry no word, these are exports from vusb-analyzer.

OUT:

02 04 FA

-> same as you

IN:

43 05 FF B9

-> same as you. Interesting to note that these 4 bytes come in one at a time, contrary to the rest of the communication.

radio command 1

OUT:

0000: C0 00 25 01 00 00 06 5A D2 B5 AA 04 9F 4C D3 F6  ..%....Z.....L..

0010: BB 65 73 C1 1C A9 EC C1 93 F7 72 9A 44 F1 35 0D  .es.......r.D.5.

0020: 81 2C B6 94 9F 05 C0 

-> you had: Write request 0xC0 0x00 0x25 0x01 0x00 0x00 0x06 <17 bytes data> 0x8F <2 bytes of data> 0x60 <10 bytes of data> 0xC0

-> the format is similar, but the 8F and 60 do not correspond

IN:

frame 0:

0000: C0 00 95 01 00 00 04 6F F8 7F 48 07 50 F7 A0 E7  .......o..H.P...

0010: 8E BD 26 75 BE 4D 96 F2 32 59 6E 9B DC 25 35 1E  ..&u.M..2Yn..%5.

0020: D4 00 EB 25 C2 09 BF 25 86 2F C6 B5 35 25 BE 03  ...%...%./..5%..

0030: 3C 12 5D 69 24 97 70 66 9A CC E6 78 CA B4 CE     <.]i$.pf...x…

frame 1:

0000: EE 2C E3 3D 06 9B 4A 9D 09 E1 77 05 1A B1 BF 37  .,.=..J...w....7

0010: 05 83 61 E7 7E E8 F9 47 BB 53 DD 0E 7A 22 A8 DE  ..a.~..G.S..z"..

0020: E1 42 60 F4 E6 31 72 FB F1 44 17 7F FD 0D 9D C8  .B`..1r..D......

0030: 81 34 CE 70 45 EB 34 9D 09 E1 77 05 1A B1 BF     .4.pE.4...w….

frame 2:

0000: 37 05 83 61 E7 7E E8 07 9D 09 E1 77 05 1A B1 BF  7..a.~.....w....

0010: 37 05 C2 E0 4D D4 42 AD C0                       7...M.B..

common bytes in bold

pattern A in red

-> you had: 

> 0xC0 0x00 0x95 0x01 0x00 0x00 0x04 -> same

> <lots of data in 3 frames -> same

> 1 pattern of 15bytes which will be seen later (let's name it pattern A)  

> and 2 pattern of 15 bytes which is repeated in this response -> where?

> 0xC0 -> same

radio command 2

OUT:

55

0000: C0 00 25 01 00 00 0C 73 72 D0 D2 66 7C 52 5D 9A  ..%....sr..f|R].

0010: 49 15 82 37 54 2F B7 A8 0D A4 82 D4 CF 79 8C 34  I..7T/.......y.4

0020: 62 4A 16 9F BF F6 C0                             bJ.....

> you had: Write request: 0xC0 0x00 0x25 0x01 0x00 0x00 0x0C <31 bytes of data> 0xC0 -> same

IN:

55

IN:

0000: C0 00 25 01 00 00 0B 6F F8 7F 48 07 50 F7 A0 E7  ..%....o..H.P...

0010: 8E BD 26 75 BE 4D EF FE 58 2D 5E 91 58 77 47 35  ..&u.M..X-^.XwG5

0020: 04 7A 43 1D 46 F3 C0                             .zC.F..

pattern B in blue

-> you had: 0xC0 0x00 0x25 0x01 0x00 0x00 0x0B <15 bytes of pattern A> <5 bytes always changing> <11 bytes of a new pattern B> 0xC0

> interpretation: read something other (maybe a hashed security key) as this is pattern B which is at the end of every package sent to io-homecontrol). > The application seems to retrieve 5 bytes of information.

OUT:

55

radio command 3:

0000: C0 00 25 01 00 00 0C C9 B8 7E 9D F3 47 83 ED 84  ..%......~..G...

0010: 3D 2C D2 BB 58 3F 69 3B F5 8F 3B 9D A4 BF 89 74  =,..X?i;..;....t

0020: 40 90 64 D9 F6 DC C0                             @.d....

-> you had: Write request: 0xC0 0x00 0x25 0x01 0x00 0x00 0x0C <31 bytes of data> 0xC0

IN:

55

0000: C0 00 25 01 00 00 0B 6F F8 7F 48 07 50 F7 A0 E7  ..%....o..H.P...

0010: 8E BD 26 75 BE 4D EF 1E 5B F6 5C 91 58 77 47 35  ..&u.M..[.\.XwG5

0020: 04 7A 43 1D 46 F3 C0                             .zC.F..

-> you had: Read response: 0xC0 0x00 0x25 0x01 0x00 0x00 0x0B <15 bytes of pattern A> <5 bytes always changing> <11 bytes of pattern B as seen before> 0xC0 -> same

> interpretation: The application seems to retrieve 5 bytes of information.

What do you think where should we spend our focus: on the serial comm, disassembling the exe or sniffing the SPI/UART between the ATMEL and the RF chip?

I think at first the serial protocol, because we have it easily and it is likely to be high level

Then some help from disassembling, for example to find the hashing algorithm used. I have some success with Hopper Disassembler but nothing useful yet.

I am not familiar with SPI sniffing, but interested ;-) Although it is likely going to be low-level commands? What do we need, a logic analyser? An arduino (I have a few available).

Sam

[leutholl]

Great! Thanks for letting me know.

Which software and hardware revision do you have in the mouse (see menu help, info...) both numbers relate to the mouse as I found out.

I played around with my oscilloscope and found this:

- The startup procedure as we have it here in Hex is ATMTEL communication only! No communication happens to the ADF7020. The first communication is when somebody hits Autoscan (which makes sense as this really needs RF).

- I noticed something interesting. The chip on the mouse is a ADF7020 which is a general purpose ISM RF chip and not prepared to io-homecontrol. The ADF7022 has the io-homecontrol stack in silicon and it would be a lot easier to interface it with a ADF7022. Upside of the ADF7020 is that it is documented and that it is available without being a member of the io-homcontrol alliance. Se there are 14 registers which can be written or read-back over the data 3-wire port (in, out, clk). But then there is also a configuration port in addition to the data port (in, out clk). That means that the io-homecontrol magic happens either on the ATMEL or in the software. I think it happens in the software/application as we can't de-cipher the serial content yet - I still think it is encrypted/hashed. Short test would be to rename a product from i.e. shutter0 to shutter1 and trying to find the difference compared to rename to the same name (I didn't do this yet).

I can hook up my logic analyzer to see what's going on on the config and data 3-wire. together with the documentation we would then know what's needed for io-homecontrol from a config point of view. They claim data is AES 128bit so we can't understand the data but if the security key is the hash of the algorithm this would be available on the serial during key exchange. However they might use another key (a static product/alliance key) which is hardcoded.... not easy...

best way forward:

- get the firmware file / URL

- rename a product and sniff

- bus analyzer on the data and config port to see if this matches the hex comm we see on the serial (I think no, but maybe our "pattern" show up)

- get another product from velux or somfy without display (higher form of intelligence) - just some buttons and see 1) which chipset, 7020 or 7022 and 2) sniff and compare the SPI.

- there seems to be a number of test points aligned as a JTAG. If somebody have experience in JTAG we might be able to debug the prog in the ATMEL

- get somebody that knows how to disassemble/de-compile a C++ compiled exe. The exe is too big for me and my experience.

Just my 2cent.

[Lukas Leuthold]

some news (not the best one)

- i changed the name of a product by incrementing one digit. Result of request is all 32bytes have changed. 32x8=128 which could be AES 128bit encryption. Is somebody here that can confirm that if changeing the cleartext slightly while keeping the key constant the hash would completely look different (all 32bytes?) or would it lead to minor changes?

- I disassembled the exe and found that it has logging capabilities either to file or console. However I didn't find out how to activate logging. Normally command line switches are strings referenced in assembler which can be found easily (i.e. /log or -log or --log etc...). But there are so many strings since the exe is big and xml,html,verbose output and internal labels (among a list of all implemented io-homecontrol commands/states, which is quite long). The command line returns shortly after invoking the exe. We have to find the right switch or registry flag. Bringing the application to log would help a lot!!!!

- Speaking of registry. The other exe (Updater....) stores the last checked and next check date in the registry.  And the URL is stored there as well, it's simple: The updater goes to this URL (try it manually and get cleartext) in which there is another link to the Updater.exe along with MD5, version, release notes. Notes that this doesn't speak to the mouse at all. The decision to put the mouse either into applicationMode or bootloaderMode is in the real exe. I do wonder were it gets the firmware file (or byte streams) from. There seems to be a lot of resources embedded in the exe! If they release a new exe we might be able to find it by comparing. we could log the traffic on the serial (heck, it won't be serial anymore...) while updating.

The registry key if the main exe is under "Somfy" and the key of the Updater is something like "Caphyon"

- the main app seems to be compiled by gcc used by Code Blocks IDE. 

Do we have somebody around here which is into API hooking or helping with finding the logging switch?

The key to the AES encryption should be stored in the exe but it could be code that calculates the 32bytes. Or it is read from the mouse. But we didn't saw it yet?!

Let's go into logging mode.... anybody?

leutholl

[iviru...@gmail.com]

I found the following registry key:

HKEY_CURRENT_USER\Software\Somfy\Set&Go io\General\LoggerActivated

I tested it by creating this entry as a string with the value of "1". I got a logfile at c:\users\<username>\AppData\Local\Somfy\Set&Go io\logs

I didn't know if there are any helpfull messages in there, because my mouse isn't here at the moment...

HTH (a litte bit ;-)).

...

[leutholl]

Thanks! That's helpful.

I did the test as well first it didn't log but then I changed the local to english (en_US) and played along with other stuff and suddenly it logged. See attachement.

It's great to find the code during disassembling. Search the logfile text in the referenced string section. A good hook is the "Key retrieve succeeded" as the code nearby must validate the key and if somebody understands memory and CPU registers it might be possible to get the key.

Another thing is that it is prepared to debug to the console output. I've found this:

Text strings referenced in Set_Go_i:.text, item 5075

 Address=005084F2

 Disassembly=MOV DWORD PTR SS:[ESP+4],Set_Go_i.00737BA4

 Text string=ASCII "'. All debug output redirected to console."

Don't know if that's really a debug feature that can be activated somehow (I checked for other registry key entries but didn't find any related to this).

...

[iviru...@gmail.com]

Hi,

I do have a fully usbmon-Dump while upgrading the firmware of the Set&Go device.I will not post it here in publicity. To whom can I send the dump for a further investigation?

[Lukas Leuthold]

That great! thanks. Please email me. <username>@gmail.com

[sreva...@gmail.com]

That's great! I missed the capture thinking it would be 'obvious' and come over the network first and not be embedded in the set&go application. If you could send it my way it would be appreciated: srevans444 at gmail.com.

[sam]

No big success to report here, but some progress on the decoding of the usb serial protocol. See attached pdf.

I am also attaching a snippet of code I am using to poke around with the mouse. Nothing clean yet... but it can replay some exchanges to the point of the key exchange. Possibly further but I did not get to it yet.

The worrying part is that the 'identify' command in the UI that causes a device to move back-and forth multiple times is triggered with only one message. This means that it sends an 'identify' command to the device, and not a series of 'open' and 'close' that we could have re-used later on :-/

Anyway the first think to do is to understand how the frames are encrypted. Looking into the win app for this... there is a piece of code that says 'already encrypted frame' but it is never called... need to keep searching.

If anyone can make more sense of the serial exchange please share! 

Also I would be interested in seeing a complete sniff with another mouse: launch app, exchange key from remote, discover devices, get device info, identify.

[Lukas Leuthold]

That's great progress! Thanks so much and please continue to get past the key exchange step in the replay. (does the key rotate or is it static?)

Yes identify command is only one command and the actor knows how to "identify" itself - it doesn't send move back or forth. But then I realized that Velux actors are not 100% compatible with the somfy mouse (possible with all somfy product). Velux seems to not implement all the features that iohomecontrol would suggest. As there is support for end position, sensors, information of installer company and version etc... all these fields are blank and if you put the application on logging mode you can indeed see the null point exception are happening at this step - so I guess some of the fields are nullified. The UI reacts in a ways to not show the nullified fields - i.e. there is not installer company text box, nor any support for sensors (although my velux windows have sensors attached and my touch remote can speak to them, but don't see the sensors as a standalone io product) - it would be interesting to produce artifiical rain to see if the RF activity is different in this case. As somfy is more advanced and velux only implemented to mandatory fields, this means that the Set&Go is really for nothing else than identifying and copying to other remotes. As you can see in the manual and other screenshots, Set&Go would provide more control over an actor (if fully compatible) and in this case we would be in a position to intercept the packet of a movement command and possibly (with your effort) replay it.

About the response being constant:
I had the feeling that the ATMEL uC only "reads or writes" the registers of the RF chip. It could well be that the hex traffic we see is just the content of registers combined with a command and register address. Read the manual of the RF chip, it basically provides an interface (API) to read and write registers. We don't have the 7022 register documentation. But if we study the 7020 registers and we can think of some special registers used for io-homecontrol of the 7022 chip which is supposed to have io-homecontrol support "in-the-chip". But we also know that io-homecontrol can be done with a 7020. So the AES part of logic when having a 7020 deivce (such as our mouse) is probably done in the computer and not in the ATMEL (if I remember correctly I saw some usage of the HMAC library when decompiling). That would explain why the request is encrypted (ready to be written to a register) and the reponse is more a dump of registers which (depending on the state machine of the RF protocol) seems to have pretty much static content). Then I read about "code protection" (see below) and revised my feeling - but maybe it's a combination of both.

Does anybody know how AES behaves? Is the ciphered text always the same of the cleartext is the same or does it change (rotate, timing, randomize etc...) - and also: is the ciphered text changed completely upside down (all bytes showing different content) if the clear text only changes a single bit somewhere? When I look at the requests/challenges this seems to be the case. I can't think of any other reason why the initial request/challenge shouldn't be static apart from sequencing, timing etc...

Did somebody find out when/where the hardware and software version of the mouse is being transmitted? This must happend at the first bunch of commands as the GUI already shows it (about dialog) and it matches more or less what's written on the pcb in the mouse.

I've lost the momentum to continue on the hex/bit level (but please continue as you guys are clever...) and am trying to find a way on the "commercial side" to get some of the documentation of the 7022. It's a hard as the technical stream, but at least we should try.

About security. I think there are two keys. One which is provided to all io-homecontrol alliance member which implement, therefore they are inter-compatible (such as our somfy-velux setup where we never exchanged keys manuall or automatically) - let's call that system key. And then there is a key for every product (actor/sensor) as this is the key that must be transmitted (when clicking "find products") to the remote which then sends back the key of the remote (or a response based on the received key) to the actor/sensor so the pairing is locked and can't be redone for new remotes unless the key exchange happens from remote 1 to remote 2 (where Set&Go can help). Let's call that product key. The product key must be visible on the hex dump but the system key won't possibly show up and it must be stored in the exe file so the application can decrypt the packages since the buiness logic happens on the unencrypted side).

I also had the impression that the hex dump we see really has nothing to do with io-homecontrol. The same framing and patterns are used during firmware reflash/update. It also starts with the C0... commands and uses the ACKs. And it sends thousands of packages / telegrams. This could be "code protection" which is activated on the ATMEL it's quite a clever system to control what can be re-flashed and what not. In this mode the chip reveals itself as a DFU updater end-device possibly a standart implementation when the bootloader loads the "update routine" where the software fuses are reset for E2PROM access. Then it sends word by word, address for address with the new content and after a reboot all is back as it was before but the new program will be launched. What I don't know is if "code protection" can also be active for interfacing during runtime. If yes, that would explain why we see encrypted traffic which encyrption has nothing to do with io-homecontrol but rather is a "code protection" encryption. The exe application might be "factory paired" with the chip so it decrypts the commands/API to get back to cleartext (or the case if the API is just a longer handle to the RF chip registers).

One thing is clear for me: Since io-homecontrol is AES encrypted and Somfy used the 7020 chipset which doesn't offer encryption on-the-chip, the encryption must be done either in the exe application or in the ATMEL code. That's good to know because it means that (once we understand io-homecontrol) we can use the 7020 chip (easily sourceable) speak with the registers in a already "encrypted" content and natively support io-homecontrol. If there would be a 7022 chip then I would start with sniffing the SPI and config pins to understand how to "operate" the chip from the outside world (we would then see the product key or id in "clear text" in a io-homecontrol ready reigster) - better to interface, but almost impossible to source/procure.

side note: some variation in the response could reflect that the sender transmitt layer 1/2 info such as "used channel" and RSSI

leutholl


Am 15.10.2014 um 00:09 schrieb sam <sgr...@gmail.com>:

> <full-capture-with-comments.pdf>

[milymat]

Great Job Guys!

Any new updates?

[kai.hu...@googlemail.com]

There is a little light at the end of the tunnel ;-).

I will give you further information at the weekend:

My Setting:

Velux Windows (3)

Each Window has a Shutter and a Light Rollo

So I have 9 clients and 3 touch controls :D

Also got the little USB Mouse and the traffic is captured.

I managed to replay the "identifying" commands in the app with a Java Program (Java is the only language I am good at), which are totally different on every request but could be replayed, which makes a rolling code possible.

I have found a link to some guy who has managed to crack the 1 directional communication protocol, I will post the link later here. This communication contains a rolling code, some secret bytes and also an XOR-Encryption.

Have you managed to get a relation between mouse TTY commands and RF transmission? Or in other words: Which of the data sent to the mouse is really transmitted over air. Perhaps we could use the mouse as a hardware transmitter and mix it with the protocol information of that guy (some of the information are gathered from patents ^^).

I also did some analysis on the windows app, and found two encryptions. But I am not experienced in disassembling.(Will post them later, too).

I also spent some time on key exchange between program (mouse) and remote control. It might be possible that i have found the key in that communication. (Two different remotes with two different keys on it, I will also give infos...)

Cheers

[Lukas Leuthold]

wow that's good news and a real highlight today.

Can't wait to study your infos/link/resources later. 

leutholl

[Kai Hufenbach]

Hi folks,

sorry for my late reply.

It is the first time for me to do  reverse engineering, but lets begin with the links:

Receive data with an dvb-t stick:

http://sdr.osmocom.org/trac/wiki/rtl-sdr

Could someone try this to find out, what data is exactly sent from the mouse.

And second: Someone who cracked somfy protocol:

http://pushstack.wordpress.com/2014/04/14/reversing-somfy-rts/

How to receive with a DVB-T USB Stick:

http://pushstack.wordpress.com/2014/05/17/somfy-rtl-sdr/

My Idea would be: Try to find out, if we can send arbitrary data with the mouse, so we could use the ordinary 1-way protocol as a first shoot.

You can analyze *.exe applications with a tool called signsrch, this searches for crypto signatures in the exe 

AES Rijndael S / ARIA S1 [..256]

SSH RSA id-sha1 OBJ.ID. oiw(14) secsig(3) algorithms(2) 26 [..15]

AES... symmetric encryption. Should be the algorithm, used for the 128 bit somfy encryption.

I did some sniffing on the pairing of my touch device and the mouse.

The following in the process is interesting:

- The structure send/answer does always have the same structure, BUT: The sent data is always different -> Perhaps a rolling number + encryption (something simple like XOR or a static key) is used, so the whole data is different

- The received data is always the same

In the process of the symmetric key exchange I think, that no special encryption like Diffie Hellmann is used. So it should be possible to sniff the key in cleartext. 

I have attached a document with the sniffed key exchange with two devices and two different programmed keys. Its too late for me to try it with the third device to look if there is more correspondence. Perhaps I can do it tomorrow.

Comparison of possible key sniffings:

CE3C870CC06016 222AA587BFA149CE 99 B9814B7C428349536422282ED1387B6D A5A474AC257B50ED97 6C70 18A7C4D6CBC0

CE3C870CC06016 D38B5687BF50E83D 99 175C69A483E17B7B82980851149E3517 A5A474AC257B50ED97 7804 18A7C4D6CBC0

                            <Key?>             <????>                                                                                              <Hash?>

ToDo:

What Data is send really over air? (DVB-T Stick)

Reverse Engineer (olly dbg) the application and look for uses of encryption. (I have no experience with that)

Cheers

[Kai Hufenbach]

Sorry i was wrong with my assumption:

The Key seems to exchanged in the receiving frame after that, beginning with:.. 35...

C00035010000086FF87F480750F7A0E78EBD2675BE4D8FC685A499 3771C3B490B53099F46C98FAAD446A54258463EE3C0EC6936BBDFE C0

C00035010000086FF87F480750F7A0E78EBD2675BE4D8FC685A499 46EBE4B0BFC09E5AEC5ACC8543C8546F31098A5704FD8D1F71B0AC C0

C00035010000086FF87F480750F7A0E78EBD2675BE4D8FC685A499 46EBE4B0BFC09E5AEC5ACC8543C8546F31098A5704FD8D1F71B0AC C0

Checked that with 3 remotes, two have the same key.

Those are 54 bytes difference, two much for "just" a key....

The package i checked before seems to be some kind of "handshake".

And still, every time, a package is sent, it is different (but repeatable). Strange...

Cheers

[Jens Ihnow]

Hi,

I'm wondering why are you post about Somfy RTS, this thread is about io homecontrol.
Both worlds are different, for example io homecontrol is bi-directional communication and encrypted and so on.
That's why the Set and Go is so interesting, it might help to get the plain communication done.
Still looks like the intelligence is in the Software, what makes it harder to get it done...

Bests

[milymat]

Hi Guy,

are there any updates?

[milymat]

Hi,

maybe someone with the TaHoma Connect Box can try hacking around. I think the box is running under linux. So maybe someone can do some magic

[leutholl]

finding a way forward, I would like to ask you about our options. I see the following next steps:

1) give up and hope for a miracle from outer space such a Velux Gateway (do a search for VMS Gateway from Velux and KNX)

2) continuing on the 1-way protocol. As for me, that would be sufficient, I only want to open or close single windows or groups. Don't need feedback - they close when it rains without the remote, so it's still safe. The windows still react on the 1-way protocol as I have some basic Velux remotes that work (even with groups, depending how you learn them)

3) continuing reverse-engineering the application

4) try to sniff the traffic between the ATMEL and the RF chip (not the radio interface itself)

5) try to sniff the radio interface

6) write an open letter to a clever place

7) somebody with a Tahoma box sending us an image of the linux volume in order for us to have a look how it's built (chances are, they use the usb mouse internally - I don't think Somfy R&D'd two separate protocol stacks)

I don't use my mouse so it is available for somebody who wants to continue our study we have so far.

[Sam Grimee]

I am not giving up and never will, I have bought a lot of windows, shutters and spotlights that I absolutely want to link to my KNX network.

I have considered these options from your list:

3) reverse engineer the app: I have spent lots of time on this already with no big sucess yet, I have not been able to figure out the encryption scheme

5) I have the tools to do this but I think it is too much hassle and we should attack at a higher layer because of the encryption, if we figure out 5) we also have 3)

7a) I have access to a Tahoma box. It uses a USB mouse indeed, not the same as set and go but I have not opened the mouse (yet) to compare the chips. Happy to get an image dump but I have not found a way to get it. The box has port 22 open but I cannot figure out the password. When opening the tahoma, it is all in one chip, I did not find a useful port to connect to. Ideas welcome.

but the best option so far seems to be:

7b) hack the protocol used by tahoma clients. Indeed, web browsers and smart phones talk to the cloud and the cloud relays orders to the tahomo that then generates the required IO traffic. So for example from a web browser, it is a flash application and it is easy to sniff the exchanges. I am trying to reverse that and the goal would be to have a library that talks to the cloud, impersonating a tahoma box. You would still need to buy a tahoma for this to work, but it would give a very clean implementation with 2-way and everything. It is also surprisingly responsive for a cloud model, no issue there.

Now the protocol that is used is this: http://en.wikipedia.org/wiki/Action_Message_Format

I am in the process of playing around in python to try and get some windows moving: https://pypi.python.org/pypi/PyAMF

I think it is very promising…

--

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/AinJdyyDtG0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/9275cbd1-189e-4fb4-81ef-237b14de8261%40googlegroups.com.

[Romain Bourdy]

Hi Lukas,

I would definitely be interested fiddling with the mouse, can you contact me with your price ?

Regards,

-Romain

--

You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/AinJdyyDtG0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.

[milymat]

A guy in the fhem forum got It work.

Only German http://forum.fhem.de/index.php/topic,28045.0.html?PHPSESSID=gd287077vm0qin888ko9mu7fo6

[Sam Grimee]

This is awesome! I have tested in today on a tahoma and it seems to work fine. Installed on a small linux box (r-pi type). All my velux and somfy devices were recognised and can be controlled via the HTTP or telnet interface! A dream come true.

Here is a short summary of what I had to do to make it work:

sudo su -

wget -qO - https://debian.fhem.de/archive.key | apt-key add -

apt-get install apt-transport-https

echo "deb https://debian.fhem.de/stable ./“ >>  /etc/apt/sources.list

echo 'Acquire::https::debian.fhem.de::Verify-Peer "false";' > /etc/apt/apt.conf.d/30nohttps

apt-get update

apt-get install fhem

apt-get install libxml-simple-perl

(download the 26-tahoma.pm file from the post)

cp 26_tahoma.pm /opt/fhem/FHEM/

tail -f /opt/fhem/log/*.log &

/etc/init.d/fhem start

go to http://server:8083 

or telnet server 

Enter the fhem command to declare your tahoma account:

define tahomaDev tahoma ACCOUNT your-a...@mail.com your-password

All your devices should be discovered automatically.

then send the command “save” to commit the configuration to disk, 

Thanks for sharing…

On 21 April 2015 at 10:58:13, milymat (mily...@gmail.com) wrote:

A guy in the fhem forum got It work.

Only German http://forum.fhem.de/index.php/topic,28045.0.html?PHPSESSID=gd287077vm0qin888ko9mu7fo6

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/AinJdyyDtG0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/8274d3c8-e3bd-4ab0-9ccd-bd6b6ca3c041%40googlegroups.com.

[Kai Hufenbach]

Hi,

we have done some investigations on the mouse. I will post infos as soon as possible.

-> Actually we know the protocol, but not the usage of it.

Sam, could you describe your hardware settings? Do you have io-homecontrol? Which kind of radio hardware do you use?

Cheers

Kai

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/etPan.55364fc1.643c9869.2f3%40sgrimee-mbpr.

[Rainer Müller]

Hi!

is this an offline solution or do you still make use of the somfy cloud?

The box looks fine, but unfortunately somfy prefers to use their own servers for this ... :-(

BR, Rainer.

2015-04-21 15:25 GMT+02:00 Sam Grimee <sgr...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/etPan.55364fc1.643c9869.2f3%40sgrimee-mbpr.

[Lukas Leuthold]

cool! as much as I respect and praise this progress, I would like to point out that there is still a thahoma Box involved. Problem is the license model and vendor lock-in issue we're all aware of.

The somfy set&go seems still the way to go or use an interface (even if interprocess communication) on the tahoma box itself to speak to the io-homecontrol "driver" directly without the use of the cloud services and creating the account/license. What we need is the io-homecontrol capability of somfy and not their added value such as GUI, Cloud, timeswitch and other business logic - we all use OH for this. 

if the entire filesystem / volume of the tahoma box could be uploaded to a img file we could run it on a VM and then study it further hoping to see that it uses the same protocol as the set&go mouse (which I could bet on). It's serial after all be it the mouse on USB or internally a tty. 

I've sent my mouse to Romain which gives it a new spin to rev-engineer it further. As we managed to identify the products using the mouse chances are high we could speak to the device by sending acutal movement commands (the hurdle to take is the encryption key)

Thanks so much for all your invest and effort to make it happen. 

leutholl

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/etPan.55364fc1.643c9869.2f3%40sgrimee-mbpr.

[Sam Grimee]

Yes it is io-homecontrol.

I have tested only with velux windows for now, will test soon with velux shutters and spotlights, as well as somfy shutters. All IO, the tahoma box comes with a IO usb mouse.

For this I use a tahoma box from somfy which is indeed a cloud solution. Not my preference at all, but the only thing I got to work so far.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAAHJF_u5dMpZ9n6xLTydbcTH5rfDUtisQYqYcV1UWXhn2VRpSA%40mail.gmail.com.

[Sam Grimee]

yes, cloud :-(

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CANA6HJDXKrFmD6V2Q-9EA70JJc%2BMLPfJM8FyKFptVYas_2v6dw%40mail.gmail.com.

[Sam Grimee]

completely agree, the end goal remains local control.

If someone can lend a hardware USB analyzer I can have a look at the protocol between the box and the mouse. As you say I would expect it to be the same as set&go, so we will have the encryption issue.

I have not been able to find how to get a dump on the tahoma, there is no port I can see I can connect to...

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/ACCC1841-89B8-4B3C-943D-6F6FD6289C4F%40gmail.com.

[Lukas Leuthold]

yepp!

can somebody that owns a tahoma box answer some questions:

- is it linux based? which distro?

- can we ssh to it? which account/pwd? local or remote auth? root or user?

- is there a tty with traffic unter /dev when sending io-homecontrol? what about receiving and them the ratio between?

- does the application use any so libraries that highlight to make us of AES or other security? if yes which one?

- what happens when there is no WAN connectivity while sending io commands?

- etc....

if ssh works we could image the filesystem to be distributed to some volontiers for further study whithout buying the HW. 

[Kai Hufenbach]

Can somebody dump the traffic between mouse and tahoma box and send it to me. I need different commands and Windows.

AS mentioned before: I think we got everything now!

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/6C4525D5-30B1-4BBC-B30F-0978CD9B9639%40gmail.com.

[Sam Grimee]

Can somebody dump the traffic between mouse and tahoma box

Can anyone lend me a hardware USB analyzer for the duration of the test?

I will post pictures of the board when I get a chance, to get your ideas of how to get a dump of the image. I haven’t found any suitable port to connect to. 

There is an ssh service running, but haven’t found the credentials to connect to it. I saw on a forum that it should be the tahoma cloud user credentials but it doesn’t seem to be the case.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAAHJF_v_7RU4DpOFLxRzBi_J9_oCzKjUAbib97xTcjGOKyk7-w%40mail.gmail.com.

[Kai Hufenbach]

Sam,

there is a Software Called: Advanced Serial Port Monitor (http://www.aggsoft.com/de/serial-port-monitor/download.htm). This software offers a "Spy-Mode". I used the software to dump the traffic.

Could you please try the following: 

Box -USB-> PC(SPY) -USB-> Mouse

The software is restricted to somewhat 1000 lines but that should be enough for testing. (I for myself bought a license).

When you have a dump please post it here so I can anlyze it.

I need:

Opening of Window A

Closing of Window A

Opening of Window B

Closing of Window B

Opening Shade A etc...

I'll post findings as soon as possible after that.

Cheers Kai

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/etPan.5548788a.469cbff2.81d2%40sgrimee-mbpr.

[Lukas Leuthold]

Didn't we do this already? I did post the sniffed traffic between Set&Go and the mouse. We even had some protocol assumption/replay etc...  

Or are you talking about the Somfy Tahoma Box traffic to the "internal mouse"?!

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAAHJF_vAK3pkd4hDtn0Wm5ZKexjk%2B97j1piVsA0P3EdU7eXXhw%40mail.gmail.com.

[Sam Grimee]

yes we did it for the set&go, here it is for tahoma to tahoma mouse, basically to see if it is the same protocol

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/90345F71-34F2-4BE4-AAD6-9A4DEC31E361%40gmail.com.

[Kai Hufenbach]

Sorry Lukas,

correct me if I am wrong:

The tahoma box is connected to a mouse via usb connection. I want exactly this sort of traffic, as the mouse seems to speak a standardized protocol.

I need this traffic, as I am unable to guess commands. Set & Go only supports "test" (Which I am able to reproduce).

@Sam: Cant find the dump you mentioned.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/etPan.5548d610.3ff71b3d.81d2%40sgrimee-mbpr.

[Sam Grimee]

I did not take a dump of tahoma->mouse yet, and it may take a while (to find a windows machine…)

Did you manage to decode the messages from set&go? (even if they are not the commands we are looking for). 

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAAHJF_s5gXHyi7yTQUwh%2BWxN1FNC%2Bi8xBvZv36E4vYp49-ui6A%40mail.gmail.com.

[Kai Hufenbach]

yes :-)

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/etPan.5548d7dd.2a49d85a.81d2%40sgrimee-mbpr.

[Romain Bourdy]

Kai,

Please tell us more about your findings !

Regards,

-Romain

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAAHJF_u8p5g3-7_CRcmXztojF%3DLaNyGs6ktPkWU%3D%3DP4JeBS_dA%40mail.gmail.com.

[Kai Hufenbach]

Hi,

ill give you a little preview:

The protocol is dynamically encrypted. (Means: Part of the content are used as key.)

PC -> Mouse: Random part(each packet is different)

Mouse -> PC: Static part, perhaps because of poor perfomance in mouse, but it has the same principle (thats why the packets are always the same)

This protocol contains the following infos:

"Please open Device 5 with the following key".

More information is given, after i could verify with a tahoma dump, as I do not own a tahome (thought of buying...).

Kai

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAN0QK5Y6P8fm%2Bd9u3WKq95hq0PewhYvdS_%2BwdZCv14nPTu5rfA%40mail.gmail.com.

[Romain Bourdy]

Sounds pretty good, waiting for a proof of concept ! 

Did you manage to get the feedback also ?

Regards,

-Romain

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAAHJF_tXJC%3DfsDobJmDZKx7YTGyGFO4h5Bz1mwnAb2FfQiSY-w%40mail.gmail.com.

[Romain Bourdy]

Hi,

Have you made any progress on this ?

Thanks !

-Romain

[Kai Hufenbach]

Hi,

currently I am waiting for some dumps of a tahoma. I will give information and a proof of concept then very soon.

I am hoping for Sam to provide those infos.

In the current setting a mouse will be necessary as dongle. But it will be platform independent as the mouse acts as an RS232 device. I can only test for velux windows + shades + blinds.

Cheers

Kai

[Kai Hufenbach]

If someone else has a tahoma + Windows PC I can guide through the process of dumping data.

[sam]

the good news: when I plug the set-and-go mouse into the tahoma instead of the original mouse, it still works and I can still control blinds. This means the S&Go mouse has all the hardware needed to control devices.

Now for the capture, without a hardware USB analyser, I am wondering about the hardware connection. The tahoma is a USB host and has a type A plug. To connect is to the PC as a pass-though, I need a USB cable with two such plugs. I have made one by cutting to USB cables and wiring together the green and white on each side. But when I enumerate devices on the PC, I do not see anything that would represent the Tahoma. So I do not get a COM port that I would use for the pass-through to the mouse.

Can you explain how to make the connection?

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/AinJdyyDtG0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAAHJF_v840ZocxXuEPzmv5yxgozrCmsON2e-50%3DGJ4TFVg-%3Dvw%40mail.gmail.com.

[Romain Bourdy]

Could be easy, do you see any unrecognised usb device ? If yes, find the USB VDI PID REV and so on from the properties. Then plugs your mouse, it's using a somfy.inf file with othre numbers, just create a new file with correct value but same drivers. Should do the trick.

Get back to me on google talk if unclear, it should work.

[Kai Hufenbach]

Hi Sam,

thanks for your efforts.

I have just mailed the support at aggsoft they have another product which should fit our requirements:

https://www.aggsoft.com/tcp-com/

There could be another scenario (if your diy cable works):

-> Use the mouse from set&go

-> Connect it to pc.

-> Connect TAHOMA

For Bridging use the Bridge Software to connect (I think a Host is needed, which can be bridged to the other port) (If stuck we can write mails to the support). With this software it should also be possible to capture the traffic.

I would try it on my own, but i actually do not have the mouse here.

Cheers

Kai

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAOyZS90hTS7tRe-wDmLJ0feeWK7U4CGB2iXRp9XafScx4-Jatw%40mail.gmail.com.

[Sam Grimee]

Thanks both, but I think it will not cut it.

On the software side I’m fine, I am on mac but I have software for bridging and logging serial ports, and it would be easy to write one otherwise.

The problem is hardware, the USB port on most PC cannot behave as a slave: http://electronics.stackexchange.com/questions/56907/emulate-usb-device-with-usb-host

I think however that there is a simplification that could help: we are only interested in the data at serial line level, not at USB level. So I could use two USB to serial adapters and a cross-over in the middle. This will work if the software on the Tahoma is not strict on checking device ID or trying to update the firmware before setting up and using the serial connection. Worth trying, I will when I get a chance.

Also I have taken pics of the PCB of the Tahoma, I think someone asked for that before. Let me know

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAAHJF_s-7v8EXHmFfFEQKHmJyasd2gE_JxD2pKUKWA%2B%2Byc%2B-GQ%40mail.gmail.com.

[Romain Bourdy]

Hi,

Just wondering ... Has someone tried to connect a velux klr 200 remote in serial mode to see if it's behaving the same ? Would be awesome to save from buying a mouse for those who bought integra velux with bundled remote !

Best Regards,

-RB

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/etPan.555ca21e.2830e591.161d%40sgrimee-mbpr.

[Lukas Leuthold]

yes me..... I can see activity but I can't send anything - seems to be "listen mode" only, intercepting the SPI between uP and RF chip. at least I don't know how to send anything, maybe it's possible though. Interestingly when I name a window I can see somewhat cleartext rushing over on the serial com representing the name. This might save the name to the actor itself as I think you can copy your actuators from KLR200 to another KLR200 and the name "comes along".....

It's been over a year I sniffed the traffic and I think I don't have the doc anymore. :-(

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAN0QK5YkU-S8Ev%3DP9oWKTiXYNeNrFMaq758ZAQjWat%2Bp2JgXkw%40mail.gmail.com.

[Romain Bourdy]

We'll I've sniffed it's boot too, I still have the docs in my outbox, but would be nice to hook it onto a Tahoma box !

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/7AB29182-382C-409E-A6A5-D3983D510FA3%40gmail.com.

[Kai Hufenbach]

There are some USB sniffers round there:

http://www.totalphase.com/products/beagle-usb12/ -> Very cheap one ^^

But I have found something different:

https://github.com/matlo/bb_usb_sniffer

It seems you can build your own usb sniffer with a beagleboard.

Sam, if you are familiar with beagleboard it would be great. Otherwise I will try to find someone who posesses a sniffer (or order a beagleoard on my own).

Cheers

Kai

[Sam Grimee]

Kai,

yes I have found these but

- totalphase beagle-12 is still close to 500 eur, I have been researching all second hand sites I could find…

- I happen to have a beagleboard black, but not sure that code works with the black version. According to this it may not: http://hackaday.com/2013/07/02/usb-sniffing-with-the-beagleboard-xm/

- The project led to this one, that appears to be active: https://github.com/dominicgs/USBProxy 

I’ll try and keep you posted

Sam

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CAAHJF_utqAtTUAHTFdrbHeqZC7xdMKnqZEgs2g_ZuJ5DZy8P3g%40mail.gmail.com.

[milymat]

Hi Guys,

Was there any progress made?

[Kai Hufenbach]

Hi Guys,

out test windows arrived last week and I managed to erect it for labratory use.

Now we will check the dump from the remote USB on the window. That is the last chance.

I hope the mouse is able to send the data.

If it does not show any progress we would need to do further RF investigations.

Cheers

Kai

@Sam: Thanks for your effort!

 

[Hubertus Hettenkofer]

Hi all,

there is a thread in the forum of FHEM:

http://forum.fhem.de/index.php?topic=28045.0

Mike3436 has a modul for FHEM to interact over the web-api with the somfy-server.

may bee this is a option.

best regards

Hubertus

[Rainer Müller]

Hi Hubertus,

this is only working online via the somfy servers and only as long as they do not decide to change their API,

a real solution should work offline as well, without the need of an established internet connection ...

BR, Rainer.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/92fdf03f-aa2a-4af0-9f31-e14fbf863613%40googlegroups.com.

[Kai Hufenbach]

Short update:

What we found out so far yesterday:

- we have an opcode candidate for moving window/shutter

- params are also included

- far more understanding of the protocol

I'm looking forward to next Thursday!

Kai

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/CANA6HJCXEP%3DeEzz1wdqRj0PNgmtYE8%3DxDF-mmQPWn-bY2MJiag%40mail.gmail.com.