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 https://github.com/couin3/RFLink/issues/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 (https://github.com/cpainchaud/RFLink32/pull/95/commits/88e207e137b04ec2d0f80745d850e117a796c819) 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

https://github.com/cpainchaud/RFLink32/blob/d0ce2f495021b5946b03cebb3de271919885cadf/RFLink/Plugins/Plugin_016.c#L78-L81

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