Support for TEL FIX wall-mounted remote control for RadioLoop Motor

[manny73]

Hi,
I command my shutters with the TEL FIX. I think the protocol used from device is the Somfy-RTS but there are some issue.
I launch the program with these parameter ( the frequency is little more slow of standard)

rtl_433 -f 433.42M -R 167

and when I press STOP thi is the output

time : 2020-11-30 12:16:27
model : Somfy-RTS Id : 4653896
Control : ? (15) Counter : 7718 Address : 480347 Retransmission: 0 Integrity : CHECKSUM
WARNING: Undeclared field "mic" in [167] "Somfy RTS"

---

time : 2020-11-30 12:16:27
model : Somfy-RTS Id : 4653896
Control : ? (15) Counter : 7718 Address : 480347 Retransmission: 1 Integrity : CHECKSUM
WARNING: Undeclared field "mic" in [167] "Somfy RTS"

---

time : 2020-11-30 12:16:27
model : Somfy-RTS Id : 4653896
Control : ? (15) Counter : 7718 Address : 480347 Retransmission: 1 Integrity : CHECKSUM

and when I press the UP button

time : 2020-11-30 12:16:58
model : Somfy-RTS Id : 4653896
Control : ? (15) Counter : 7719 Address : 480347 Retransmission: 0 Integrity : CHECKSUM
WARNING: Undeclared field "mic" in [167] "Somfy RTS"

---

time : 2020-11-30 12:16:58
model : Somfy-RTS Id : 4653896
Control : ? (15) Counter : 7719 Address : 480347 Retransmission: 1 Integrity : CHECKSUM

Do you have any idea how to implement a fix?
I'm not expert in these branch, but i can learn!!

Congratulations for all your work

Riccardo

[zuckschwerdt]

The WARNING: Undeclared field "mic" is fixed now with 84114f2
The Somfy protocol is fairly complex so this would not be a false positive but truly this protocol.
I don't see why the control is always 15 it should reflect the button pressed? Do really all button pressed look the same in the output?

[manny73]

I've retry now and I can confirm you that! And me too it's seems strange. And the counter field increments correctly.
Perhaps there are another bites on the queue that specify the function of the pressed button?
Can I give you more details? If yes, how? The device is from BFT producer!
Thanks.

[zuckschwerdt]

You can use -vv or -vvv to see more info (seed and chksum) but all decoded data is already shown: control, counter, address.

[manny73]

I have bolded the hex code that perhaps difference the commands

Does it give you any ideas?

[zuckschwerdt]

The transmission is Manchester encoded, so 354b4ab54b4b532b4b4b4b4cd35300 is 86 78 66 2e 66 65 22 after decoding (every byte is decoded to a nibble, i.e 2 bytes -> 1 byte), and 86 fe 1e 48 48 03 47 after descrambling (a weak security feature).
E.g. try: rtl_433 -vvv -y 'f0f0f0f0f0f0f0ff354b4ab54b4b532b4b4b4b4cd35300' for each:

• f0f0f0f0f0f0f0ff354b4ab54b4b532b4b4b4b4cd35300
• f0f0f0f0f0f0f0ff354ccab2cb4cd32b4b4b4b4cd35300
• f0f0f0f0f0f0f0ff35354acccb32d2aacacacacd52d280

The bytes you marked are 6 f. The 6 is part of the seed (encryption), the f (=15) is the control.
E.g. for the three examples:

• 86 fe 1e 48 48 03 47
• 85 fe 1e 4b 48 03 47
• 88 fd 1e 54 48 03 47

The only change there is really the counter value.

Add bitrow_print(message_bytes, 56); here: https://github.com/merbanan/rtl_433/blob/master/src/devices/somfy.c#L126 and recompile to see those bytes.

You need to take lots more of those codes (vary the buttons and note what you pressed) then look closely what changes.

[manny73]

Thanks for your support.
I'll try but first I must learn and understand the environment.

[manny73]

Hi,
I've recompile code and add the suggested print.
This is the output from some test on two remote

Sample sequence on two remote

remote 1

STOP {56} 85 fe 1e b4 48 03 47
DOWN {56} 88 f2 1e b5 48 03 47
STOP {56} 85 fc 1e b6 48 03 47 
STOP {56} 85 f0 1e ba 48 03 47
UP   {56} 86 f2 1e bb 48 03 47 
UP   {56} 86 f5 1e bc 48 03 47

remote 2

STOP {56} 85 ff 22 9d 18 03 47 
STOP {56} 85 fc 22 9e 18 03 47 
 
DOWN {56} 88 f0 22 9f 18 03 47 
DOWN {56} 88 fc 22 a0 18 03 47 

UP   {56} 86 f3 22 a1 18 03 47

It's seems the first byte contains the command type:
88 DOWN
85 STOP
86 UP

What do you think about it?

[zuckschwerdt]

The first byte is the encryption seed, there should be no data there. The second byte is command and checksum, so the lower part should also not contain data.
But yes, it looks like the seed isn't random but actually the button code.
Since command is fixed to 0xf (which looks like not used currently) we can use that as idication that an actual command is in the seed.
Please test the new version and re-open if anything is still missing or wrong.