Decode Smartwares SH5-TDR-F remote

[akemper]

Hi,

I want to expand sources to decode also signals from SH5-TDR-F remote with self-learning receivers. I started capturing the received signal. It consists of eight identical, sequential bursts as illustrated in the attached picture. While the overall timing and leading sync pulse are pretty obvious, I don't understand how the individual bits itself are encoded.

The total of 32, constant-length low periods suggest 32 bits being encoded in every burst, but I have no clue how this maps to either one, two or three toggling pulses in-between these. Furthermore, there is always one more "one-toggle" as compared to the "three-toggles", thus ensuring a constant length of the overall burst. Anybody having either a good hint or even better understanding how the individual bits might be encoded?

Thx
Andreas

[Cilyan]

Hello there!
Just go interested in this too. I'll be posting my scans later for comparison, the environment I'm in right now is very noisy (probably due to my alarm system). I was thinking that maybe the encoding was a kind of "tristate", with actually 0, 1 and F being encoded? (This is a theory, totally out of the blue, just thinking).

Here is button 1 ON of the remote.
Mine would read 1122 1232221232131322222222222132212
Your would read 1122 312321321312232222222222131321
Shame that for a start, the number of groups is not the same... But at least it seems to start with this "122", I've got some samples where the first "1" is not there and the low state duration between it and the rest of the code is globally very random, so I wonder if that could be just an artifact?
This trace look similar:
#135 (comment)

[Cilyan]

Looks like simple Intertechno on 64 bits in the end...
If you read french: https://blog.domadoo.fr/guides/principe-du-protocole-homeeasy/
I'll check tomorrow.

[akemper]

Hi Cilyan,

thank you very much for the valuable hints! From what I've seen so far I fully agree with you. Two things I didn't have in mind so far were:

1. "0" and "1" being endcoded with different total lengths, thus giving the constant length "gaps" in-between the pulses
2. Each individual bit being encoded again into two, thus ending up with a total of 2 * 32 = 64 bits or even 2 * 36 (DIM extension) = 72 bits.

With this in the end also this remote might use a flavor of the Intertechno V3 protocol, as described in FHEM post.

Thx
Andreas

[Cilyan]

Good, so I was able to confirm that the protocol is very like the one describe on the domadoo website, and that they call "HomeEasy" protocol.

The frames are coded like this:

RRRRRRRRRRRRRRRRRRRRRRRRRRFNBBBB

• RRRRRRRRRRRRRRRRRRRRRRRRRR is the remote control ID, on 26 bits.
• F is the "group flag" that tells if all devices should react (ALL ON/ALL OFF buttons).
• N is the ON/OFF, with 1 is ON, 0 is OFF.
• BBBB is the button number, which is also 1 (0b0001) when the group flag is set.

Then, there is a "second pass", where 0 is converted to 01 and 1 to 10.

Decoding a received frame is done backward, but the most valuable information is the remote ID, which is the same in every frames.

Now, however, I still need to workout the protocol timings. For the moment, that doesn't work. I used the branch from @atsage (https://github.com/atsage/rc-switch) to be able to send 32 bits of code (64 pulses) and the two protocol timings I tested were

{ 110, {  2, 23 }, {  2,  3 }, {  2, 12 }, false }

and

{ 275, {  1,  9 }, {  1,  1 }, {  1,  5 }, false }

but neither work well. On some very rare occasions, when there is noise on the frequency, I manage to switch off the plug, which lets me think I'm not far away, but this is totally unreliable.

[Cilyan]

@akemper If I try to match your graph (by eye, it's not easy), these are the parameters I find:

• remote: 62020608
• SINGLE (no group)
• ON
• Button nb 4

I hope it matches something on your side.

[Cilyan]

Some more good news.

• The plug needs a last "0" 65th pulse, or that won't work. It doesn't seem to change and in my tests for the moment, it is always 0.
• The precision of the pulse length is not very important, I managed to make it work with a "basis" of 220µs to 275µs. However, it is not to the point that the necessary sync bit at the start can be replaced by a 1. The low state delay is too different between both (2550µs for sync, 1330µs for 1).
• There is a necessary delay between retries (the remote sends the same command several times at each press of the button and the separation time between these copies is important). Below 10000µs (10ms), the plug doesn't always react and the probability of reaction decreases as we lower this separation time.

Some bad news... RCSwitch is unable to send such a protocol. First, because the delay between retries cannot be modified, second because RCSwitch sends the sync bit after the code, not before, and finally because we need to send 65 pulses in addition to sync pulse, which is larger than even what the unsigned long long allows.

To support this protocol, one would first need to change RCSwitch to allow more than 64 pulses to be sent (there is code lying around with implementation over an array of bytes, but not always very tidy), then have an option to send the sync pulse at the beginning of the frame, and finally have an option to introduce delay between retries.

I'll think about that, but seeing how the project deals globally with PRs, I will probably stay on a solution tailored to my needs, which will probably be to pre-compute the pulses on the computer and send then to the arduino over serial, which the arduino will then apply.

Here is a basis ready to be modified for such a job: https://github.com/raimohanska/intertechno-433-on-off/blob/master/intertechno-433-on-off.ino

[akemper]

Good, so I was able to confirm that the protocol is very like the one describe on the domadoo website, and that they call "HomeEasy" protocol.
I agree that this is most likely at least one of the known names for this protocol.

The frames are coded like this:

RRRRRRRRRRRRRRRRRRRRRRRRRRFNBBBB

* `RRRRRRRRRRRRRRRRRRRRRRRRRR` is the remote control ID, on 26 bits.

* `F` is the "group flag" that tells if all devices should react (ALL ON/ALL OFF buttons).

* `N` is the ON/OFF, with `1` is ON, `0` is OFF.

* `BBBB` is the button number, which is also 1 (0b0001) when the group flag is set.

I have two of these remotes and also took traces from different keys there. When I have some more time (most likely during next weekend) I will further verify this, while I'm pretty sure these general assumptions are correct from what I've seen already.

Then, there is a "second pass", where 0 is converted to 01 and 1 to 10.

Yes, this is a bit tricky. I started using https://github.com/1technophile/rc-switch as being part of OpenMQTTGateway, It does not yet seem to support a second pass, but at least looks like being 64bit-enabled from what I've seen so far.

Decoding a received frame is done backward, but the most valuable information is the remote ID, which is the same in every frames.

Now, however, I still need to workout the protocol timings. For the moment, that doesn't work. I used the branch from @atsage (https://github.com/atsage/rc-switch) to be able to send 32 bits of code (64 pulses) and the two protocol timings I tested were

{ 110, {  2, 23 }, {  2,  3 }, {  2, 12 }, false }

and

{ 275, {  1,  9 }, {  1,  1 }, {  1,  5 }, false }

I spent some time during the afternoon to further drilldown into my traces. From there my "decoding string" would be finally { 260, { 1, 10 }, { 1, 1 }, { 1, 5 }, false }

[akemper]

@akemper If I try to match your graph (by eye, it's not easy), these are the parameters I find:

* remote: 62020608

* SINGLE (no group)

* ON

* Button nb 4

I hope it matches something on your side.

Could well be, but unfortunately I don't remember which trace I attached. What kind of encoding did you choose for the remote ID? 26bits to eight digits suggests octal base?

[Cilyan]

Could well be, but unfortunately I don't remember which trace I attached. What kind of encoding did you choose for the remote ID? 26bits to eight digits suggests octal base?

This is just decimal. If corresponds to "11101100100101110000000000" in binary. But maybe I made a mistake while reading the bits from the trace.

[akemper]

Some more good news.

* The plug needs a last "0" 65th pulse, or that won't work. It doesn't seem to change and in my tests for the moment, it is always 0.

Very good point, which I noticed during the afternoon as well, due to counting a total of 66 pulses. What I did not yet check / understand if this might be some kind of preamble or extended sync. Mentioning the idea of a preamble is mainly due to additional functionality in the above mentioned rc-switch fork for the gateway. I did not yet understand what this is about, but could well be that this belongs to the Keeloq routines included in the fork.

* The precision of the pulse length is not very important, I managed to make it work with a "basis" of 220µs to 275µs. However, it is not to the point that the necessary sync bit at the start can be replaced by a 1. The low state delay is too different between both (2550µs for sync, 1330µs for 1).

I didn't test this myself yet, but just saw sometimes a bit of jitter in my traces. Especially the sync was not always a clear {1,10} but sometimes at least closer to {1,9}. However, from comparing sample and averaging over all bursts I'm quite confident regarding the schema / timing posted below.

* There is a necessary delay between retries (the remote sends the same command several times at each press of the button and the separation time between these copies is important). Below 10000µs (10ms), the plug doesn't always react and the probability of reaction decreases as we lower this separation time.

In total I've always seen eight identical bursts. Furthermore, I found that the low interval between two bursts is 41 times low level, i.e. from the falling edge of the 65th bit to the rising edge of the sync pulse. The mentioned fork of rc-switch supports in addition a guard interval, hoping that this can be used to separate repetitive bursts.

Some bad news... RCSwitch is unable to send such a protocol. First, because the delay between retries cannot be modified, second because RCSwitch sends the sync bit after the code, not before, and finally because we need to send 65 pulses in addition to sync pulse, which is larger than even what the unsigned long long allows.

As mentioned I want to go into more detail there with the enhanced version of rc-switch, hoping that most of the points might be covered there. Thus good to have at least a more detailed understanding what is required in addition.

To support this protocol, one would first need to change RCSwitch to allow more than 64 pulses to be sent (there is code lying around with implementation over an array of bytes, but not always very tidy), then have an option to send the sync pulse at the beginning of the frame, and finally have an option to introduce delay between retries.

I'll think about that, but seeing how the project deals globally with PRs, I will probably stay on a solution tailored to my needs, which will probably be to pre-compute the pulses on the computer and send then to the arduino over serial, which the arduino
will then apply.

I have a similar thinking there, i.e. I would prefer to merge this into the official repo. But let's see how to get it working at all.

Here is a basis ready to be modified for such a job: https://github.com/raimohanska/intertechno-433-on-off/blob/master/intertechno-433-on-off.ino

[akemper]

Some more good news.

* The plug needs a last "0" 65th pulse, or that won't work. It doesn't seem to change and in my tests for the moment, it is always 0.

Very good point, which I noticed during the afternoon as well, due to counting a total of 66 pulses. What I did not yet check / understand if this might be some kind of preamble or extended sync. Mentioning the idea of a preamble is mainly due to additional functionality in the above mentioned rc-switch fork for the gateway. I did not yet understand what this is about, but could well be that this belongs to the Keeloq routines included in the fork.

* The precision of the pulse length is not very important, I managed to make it work with a "basis" of 220µs to 275µs. However, it is not to the point that the necessary sync bit at the start can be replaced by a 1. The low state delay is too different between both (2550µs for sync, 1330µs for 1).

I didn't test this myself yet, but just saw sometimes a bit of jitter in my traces. Especially the sync was not always a clear {1,10} but sometimes at least closer to {1,9}. However, from comparing sample and averaging over all bursts I'm quite confident regarding the schema / timing posted below.

* There is a necessary delay between retries (the remote sends the same command several times at each press of the button and the separation time between these copies is important). Below 10000µs (10ms), the plug doesn't always react and the probability of reaction decreases as we lower this separation time.

In total I've always seen eight identical bursts. Furthermore, I found that the low interval between two bursts is 41 times low level, i.e. from the falling edge of the 65th bit to the rising edge of the sync pulse. The mentioned fork of rc-switch supports in addition a guard interval, hoping that this can be used to separate repetitive bursts.

Some bad news... RCSwitch is unable to send such a protocol. First, because the delay between retries cannot be modified, second because RCSwitch sends the sync bit after the code, not before, and finally because we need to send 65 pulses in addition to sync pulse, which is larger than even what the unsigned long long allows.
As mentioned I want to go into more detail there with the enhanced version of rc-switch, hoping that most of the points might be covered there. Thus good to have at least a more detailed understanding what is required in addition.
To support this protocol, one would first need to change RCSwitch to allow more than 64 pulses to be sent (there is code lying around with implementation over an array of bytes, but not always very tidy), then have an option to send the sync pulse at the beginning of the frame, and finally have an option to introduce delay between retries.
I'll think about that, but seeing how the project deals globally with PRs, I will probably stay on a solution tailored to my needs, which will probably be to pre-compute the pulses on the computer and send then to the arduino over serial, which the arduino
will then apply.
I have a similar thinking there, where I would prefer to merge this into the official repo. But let's see how to get it working at all.
Here is a basis ready to be modified for such a job: https://github.com/raimohanska/intertechno-433-on-off/blob/master/intertechno-433-on-off.ino

[Cilyan]

I made it work, at least for my plugs, it could be nice if you can confirm this works for you too.

You can check integration of the feature in 1technophile#2 (if Florian does answer, I don't know if he is willing to/has time to work on this), or the feature is already available in https://github.com/Cilyan/rc-switch (be sure to be on dev branch, I followed 1technophile's branching).