Add support for extra SilverCrest remotes/sockets

[simonhyde]

Different silvercrest remotes generate different codes, this adds support for remotes 0x5 and 0xD as described at couin3/RFLink#66 and fixes a bug in parsing of requests that made this remote incompatible with Home Assistant

[cpainchaud]

Hello and great job @simonhyde .

Can you tell me why you made a change in Plugin 4 (NewKaku)?

Thank you

[simonhyde]

Yep, that's the second commit (88e207e) that's actually unrelated to the adding extra support for extra remote controls, but simply improving the SilverCrest support.

When receiving commands from RF the SilverCrest plugin uses display_SWITCH, which does roughly printf("SWITCH=%02x",switchId). When parsing commands coming in over serial/TCP the plugin uses retrieve_Switch, which used to call retrieve_nibble, which only accepted a single hex digit and would reject commands that had 2. This causes problems with Home Assistant, which expects received and transmitted commands to be the same string. Thus when receiving RF commands the driver would print:

20;xx;Silvercrest;ID=000005;SWITCH=04;CMD=ON;

But, if you sent a command of the format:

10;Silvercrest;000005;04;ON;
or
10;Silvercrest;ID=000005;SWITCH=04;CMD=ON;

Then it would be rejected, because retrieve_nibble can't handle the 2 hex digits of SWITCH. "10;Silvercrest;000005;4;ON;" would work, but that's no good for HA because the string needs to be the same in both directions. So, I changed retrieve_Switch to call retrieve_byte instead, so that its expected format roughly matches that of display_SWITCH as it feels like the 2 should line up in their expected format.

Plugin_4 is the only other plugin that uses retrieve_Switch, and it assumes that the data will only ever occupy one nibble when constructing its RF packet to send, so now needs the extra "& 0xF" to reject any extra data which receive_byte may have parsed in the additional nibble.

[cpainchaud]

this makes sense, thank you!

[protree]

@simonhyde Thank you for your work.

Do you have more working remote IDs? I don't understand how to get working ones (000005 and 000000D work but 000004 doesn't....)

[protree]

Ok I see.

I get messages from a different protocol when I press the remote buttons like these for A On:

EV1527;ID=0e1cb1;SWITCH=0c;CMD=ON;
EV1527;ID=0e0585;SWITCH=0c;CMD=ON;
EV1527;ID=0e97ea;SWITCH=0c;CMD=ON;
EV1527;ID=0e8606;SWITCH=0c;CMD=ON;

Are they useful?

EDIT: The occur in a loop
IAN: 322055

[simonhyde]

(reposting old message from correct account)
Hi @protree
I only own 2 remote controls, and I've decoded and implemented those. We haven't (yet) worked out the algorithm used to generate the middle bits of the command.

If you can get the plugin running and connected over serial, you should see "SilverCrest packet =" messages. Each button should generate 4 different packets on loop as you press it multiple times. If you can capture the set of 4 packets for each button on your remote controls then it should be fairly easy to update this plugin to support those too. If you post them here I can have a look at adding the code and building you a test release to try out.

[simonhyde]

I don't think those would help (especially without a lot of investigation into how the EV1527 plugin works). The data I'm looking for is produced by this block of code

RFLink32/RFLink/Plugins/Plugin_016.c

Lines 78 to 81 in d0ce2f4

	const size_t buflen = sizeof(PLUGIN_016_ID ": packet = ") + 7;
	char printbuf[buflen];
	snprintf(printbuf, buflen, "%s%02x%02x%02x", PLUGIN_016_ID ": packet = ", packet[0], packet[1], packet[2]);
	SerialDebugPrintln(printbuf);

Because this uses SerialDebugPrintln the data is only sent over an RS232-style serial link, not the TCP socket. If you can only connect over TCP then this could would need to be modified to present this information over TCP too... If you are able to compile your own RFLink32 binary, you could change the code to call display_Name instead of SerialDebugPrintln, followed by another line of just display_Footer();
This will produce data that doesn't comply with the RFLink protocol, but should contain your decoded packets...
If you can't build your own binaries, I might be able to produce one for you if you can let me know which image it is that you're using

[protree]

Ok got it :)

Codes

## Küche
# A_ON
873070
83b440
88ae30
8216b0
# A_OFF
81d510
899220
8a59a0
847890
# B_ON
8216b4
88ae34
83b444
873074
# B_OFF
847894
8a59a4
899224
81d514
# C_ON
87307c
8216bc
88ae3c
83b44c
# C_OFF
89922c
81d51c
84789c
8a59ac
# D_ON
847892
81d512
899222
8a59a2
# D_OFF
8216b2
873072
83b442
88ae32
# MASTER_ON
81d51a
89922a
8a59aa
84789a
# MASTER_OFF
88ae3a
8216ba
87307a
83b44a

## Schlafzimmer
# A_ON
e97eac
e0585c
e1cb1c
e8606c
# A_OFF
e31c8c
efd32c
eb2a7c
e605bc
# B_ON
e58635
e4fd05
ea4fe5
ed31f5
# B_OFF
e7e945
ee97d5
ecb295
e2a4c5
# C_ON
e31c8e
efd32e
eb2a7e
e605be
# C_OFF
e1cb1e
e8606e
e97eae
e0585e
# D_ON
ecb297
e2a4c7
e7e947
ee97d7
# D_OFF
ea4fe7
ed31f7
e58637
e4fd07
# MASTER_ON
e605b2
eb2a72
efd322
e31c82
# MASTER_OFF
e97ea2
e86062
e1cb12
e05852

## Flur
# A_ON
16d030
142fb0
13ee70
1f9740
# A_OFF
1a0a20
1db1a0
157d90
1e5c10
# B_ON
13ee74
142fb4
16d034
1f9744
# B_OFF
157d94
1db1a4
1a0a24
1e5c14
# C_ON
142fbc
16d03c
1f974c
13ee7c
# C_OFF
1db1ac
1a0a2c
1e5c1c
157d9c
# D_ON
1db1a2
1e5c12
1a0a22
157d92
# D_OFF
1f9742
16d032
142fb2
13ee72
# MASTER_ON
1e5c1a
1a0a2a
1db1aa
157d9a
# MASTER_OFF
13ee7a
1f974a
16d03a
142fba

## Wohnzimmer
# A_ON
8d11b0
85d270
8c9540
87ca30
# A_OFF
8ef020
896410
867fa0
834b90
# B_ON
8c9544
85d274
8d11b4
87ca34
# B_OFF
896414
834b94
867fa4
8ef024
# C_ON
8d11bc
87ca3c
8c954c
85d27c
# C_OFF
834b9c
867fac
8ef02c
89641c
# D_ON
834b92
896412
8ef022
867fa2
# D_OFF
8d11b2
85d272
8c9542
87ca32
# MASTER_ON
834b9a
89641a
8ef02a
867faa
# MASTER_OFF
87ca3a
8d11ba
85d27a
8c954a

[simonhyde]

Interesting...The code assumes the first nibble (character) of these codes uniquely identifies different remote controls, but you have 2 different remote controls that produce different codes that both have 8 as the first nibble.

I've had a go at rejigging the plugin to handle this situation and distinguish between your 2 remotes which have a nominal remoteId of 8

If you can build your own image, give this a spin https://github.com/simonhyde/RFLink32/tree/silvercrest_newremote

It should map Küche to ID=8 and Wohnzimmer to ID=18

This is totally untested code, but it does compile...

I can hopefully do some preliminary tests to see if it still works with my existing remotes this weekend, and can provide you with compiled firmware images if you need them then.

[protree]

Thank you! :)

I have never build an image so if you could build one this would be great and I could test it.

[simonhyde]

Images built for the 4 different targets

build.zip

[simonhyde]

Did you have any luck with these images @protree ? I tested it and it seemed to work okay with my controllers and sockets

[protree]

Sorry I had no time until now, hopefully this weekend… I will give feedback, thank you :)

[protree]

Tested you build. Remotes are recognized, I get messages like

20;01;EV1527;ID=087307;SWITCH=00;CMD=ON;
20;02;Silvercrest;ID=00000008;SWITCH=00;CMD=ON;

As you can see the EV1527 plugin is beein called, too

When sending a command like 10;Silvercrest;000008;00;ON; the ESP32 crashes and reboots