Add new decoder for Velux shutter remote control - io-homecontrol protocoll

[dwarning]

Recently I asked for differences in decoding Velux remote controller KI 313 signals with RTL_433 in flex decoder mode compared to manual decoding by the Pulseview tool, see https://groups.google.com/forum/#!topic/rtl_433/HxjH97Tkgys.

Attached is a zipped .cu8 file. Please look in the region from 540ms to 620ms for the four 7ms chunks. The second attachement is a screenshot from Pulseview with one data sequence decoded by the UART decoder 38.4k, 8N1 lsb first bitorder. In discussion with Karl Lohner the outcome was that there are some uncertainties regarding the start bit configuration in Pulseview and the capabilities of the built-in flex Decoder.

g001_868.91M_1024k.zip

The third attachement shows the decoding result for the Velux Controller in different operating modes like up, down and stop. by issuing the command two times to observe crc and rolling Code.

This is inline with a former work http://redd.it/cz8trb by z_rrr who sniffing the SPI between uC and RFIC in a Somfy remote which is also part of the io-homecontrol alliance.

I would like to ask for a new FSK_PCM Decoder, name it FSK_UART like Christian has suggested with the capability of specifing all needed decoding parameters, like Baudrate, protocol and start/stop bit configuration.

Don't hesitate to ask for more informations you need for implementation and testing.

Thank you, Dietmar

[merbanan]

Regarding the signal I now think that the logic just simple make sure that both parties are sure of the command steps. If one party is not sending a reply the other party will probably repeat this signal.

If one is bored this can be tested by switching of one of the motors and then trying to command it whilst recording the radio transmissions.

[Hofyyy]

@merbanan: Do you need a Hardware to get the master key or what is needed? Like: https://www.ebay-kleinanzeigen.de/s-anzeige/z05-somfy-tahoma-box-smart-home-alexa-haussteuerung-ohne-codes/1793061952-87-9461

[paller]

The description in this pdf is probably pretty close to the actual design. But logic dictates that before encryption can occur both parties must have the encryption key.

"The emitter (the remote control) issues its encryption key to the receiver (e.g. an io roller shutter) once and once only."

So this can happen in plain text or be scrambled somehow. Imo scrambling is the only option ie a shared secret. And with the protocol being backed by an association this is how you share the secret.

Anyway this is probably quite complicated. The fastest path forward is probably to reverse engineer a bridge or something like that.

Since it's possible to clone a remote, and it's possible to have multiple remotes per receiver, I'm thinking it's possible to sniff the AES key when this is done. You have to press the little button with the gear icon when allowing a new remote to control a receiver, as there is no prior information shared between the existing setup and the new remote, I'm assuming the key is exchanged somewhat unencrypted. Don't know if anyone has looked into it.

[paller]

I'm trying to figure out if it's possible to obtain the AES key in some way. I have used rtl_433 -f 868.7M -w filename.cu8 while

1. Cloning one remote to another (what Velux describes as remote A to B)
2. The TaHoma box auto detecting IO-control devices in the home, where it correctly finds both windows and is able to control them after discovery.
3. The background chatter of the house with no IO-control being used. This is just to better understand what I'm looking for in 1 and 2.

I tried converting it into .sr and had a look at it in PulseView, doesn't mean much to me. There seems to be some modulation but it's not decoded by rtl_433. If anyone wants to have a look at it I would be happy to upload the .cu8 files, else pointers to how I can turn it into something meaningful (demodulated data in hex) would be appreciated.

[merbanan]

@paller well I assume the aes key is not transmitted in plain text. It could be XORed with a fixed key. And because we don't know the method how to derive it the least path of resistance is to look at the actual code. Looking at actual transmissions can be time of the universe hard. Looking through the code is a year hard.

I don't exactly remember the logic but I still think my conclusion stands.

Anyway this should work:

rtl_433 -c 0 -R 0 -X "n=uart,m=FSK_PCM,s=26,l=26,r=300,preamble=5555ff,decode_uart" -f 868.7M

[manny73]

Hi, from few days, I have an "eolis 3D wirefree" wind sensor and the superb rtl_433 send to my mqtt broker some data, but perhaps the data are incomplete. For better decoding io-homecontrollorer protocol, below I report some example

JSON received on the broker mqtt

{ "time": "2022-05-13T12:02:36", "protocol": 189, "model": "Somfy-IOHC", "id": 2524602, "dst_id": 1057226752, "msg_type": 246, "msg": "0927d1000000", "counter": 2583, "mac": "cc106de9fc0c", "mic": "CRC" }

{ "time": "2022-05-13T12:02:36", "protocol": 189, "model": "Somfy-IOHC", "id": 2524602, "dst_id": -16777216, "msg_type": 246, "msg": "0927d1000000", "counter": 2584, "mac": "92ab4ea62d88", "mic": "CRC" }

{ "time": "2022-05-13T12:02:36", "protocol": 189, "model": "Somfy-IOHC", "id": 2524602, "dst_id": 2130968576, "msg_type": 246, "msg": "0927d1000000", "counter": 2585, "mac": "afe360b970d0", "mic": "CRC" }

Code from shell

rtl_433 -d 1 -c 0 -R 0 -X "n=uart,m=FSK_PCM,s=26,l=26,r=300,preamble=5555ff,decode_uart" -f 868.7M

time : 2022-05-13 11:20:51 model : uart count : 1 num_rows : 1 rows : len : 160 data : 33f60000043fba8526000927d10000000a11a860 codes : {160}33f60000043fba8526000927d10000000a11a860

---

time : 2022-05-13 11:20:51 model : uart count : 1 num_rows : 1 rows : len : 208 data : 33f60000043fba8526000927d10000000a11a860b8eefd1dc479 codes : {208}33f60000043fba8526000927d10000000a11a860b8eefd1dc479

---

time : 2022-05-13 11:20:51 model : uart count : 1 num_rows : 1 rows : len : 72 data : 33f60000043fba8526 codes : {72}33f60000043fba8526

---

time : 2022-05-13 11:20:51 model : uart count : 1 num_rows : 1 rows : len : 208 data : 33f60000043fba8526000927d10000000a11a860b8eefd1dc479 codes : {208}33f60000043fba8526000927d10000000a11a860b8eefd1dc479

---

time : 2022-05-13 11:20:51 model : uart count : 1 num_rows : 1 rows : len : 208 data : 33f6000000ffba8526000927d10000000a12a8518f0be7f34426 codes : {208}33f6000000ffba8526000927d10000000a12a8518f0be7f34426

---

time : 2022-05-13 11:20:51 model : uart count : 1 num_rows : 1 rows : len : 200 data : 33f6000000ffba8526000927d10000000a12a8518f0be7f344 codes : {200}33f6000000ffba8526000927d10000000a12a8518f0be7f344

---

time : 2022-05-13 11:20:51 model : uart count : 1 num_rows : 1 rows : len : 208 data : 33f6000000ffba8526000927d10000000a12a8518f0be7f34426 codes : {208}33f6000000ffba8526000927d10000000a12a8518f0be7f34426

---

time : 2022-05-13 11:20:51 model : uart count : 1 num_rows : 1 rows : len : 208 data : 33f6000000ffba8526000927d10000000a12a8518f0be7f34426 codes : {208}33f6000000ffba8526000927d10000000a12a8518f0be7f34426

---

time : 2022-05-13 11:20:51 model : uart count : 1 num_rows : 1 rows : len : 208 data : 33f60000047fba8526000927d10000000a13917d383cd8c2f5f8 codes : {208}33f60000047fba8526000927d10000000a13917d383cd8c2f5f8

---

time : 2022-05-13 11:20:51

Congrat for your awesome great work

[mtdcr]

I submitted https://github.com/merbanan/rtl_433/pull/2258 to improve packet detection for both one- and two-way remotes at the parser level. Feedback from subscribers of this issue would be welcome.

[obones]

For what it's worth, there is an entire repository dedicated to decoding the protocol: https://github.com/Velocet/iown-homecontrol It has a reference to this discussion, I thus thought it would be interesting to cross reference it.

[druckgott]

Does it maybe work if we have enough examples to use chatgpt to decode some connections in the code and to analyze the code, I'm really interesting in this because I have 6 shutters and I don't want to by 2 boxes to have this working with homatoc 🤔

[beaune33]

The Link layer seems to be encoded already: https://github.com/Aldohrs/iown-homecontrol/blob/main/LinkLayer.md. Does this include the missing information here?

[merbanan]

Yes it looks fairly complete. We could add aes support and key input via command line. Then we could decode messages for real.

[zuckschwerdt]

We could add aes support and key input via command line.

We should establish some kind of default post-processor to do these things in a flexible way. It should be transparent but enrich with decoded and aggregated data and possibly de-duplicate.

But there are things like https://github.com/kokke/tiny-AES-c and OpenSSL could be employed also.

[beaune33]

That would be great :-)

[gdt]

Where are we on this issue? Is there a path to adding support to rtl_433 at least in part? Even if a flex decoder with a comment linking to the other project. I would like to see us capture information from issues into the code base and close the issues.

[mtdcr]

I guess it's pretty complete since #2258 was merged. Of course it would be possible to make the output more verbose, if that's wanted.

Commands get transmitted without being encrypted. AES would only be needed to verify signatures.

[gdt]

Do you mean "this issue should be closed"? That's how I interpret your comments.

[beaune33]

Wasn’t the question how to figure out the right encryption key a main topic in this discussion? As far as I understand the situation, this information is available now, but there is no implementation using it. Am I wrong?

[gdt]

Issues are not supposed to be questions :-) I am trying to ask the question: Given that a PR was merged, of the desired functionality, what is missing, and is anyone actually working on it. Right now we have an issue that cannot be absorbed in 30s and I don't know which way is up.

[druckgott]

Is this now working?

[gdt]

We still need someone to figure out what's done, what's next, and do it. This issue is too hard to understand.