C1101 RCswitch driver

[xheen908]

PROBLEM DESCRIPTION

Last 3 years i Used openmqttgateway to Switch my RF 433mhz Sockets with wemos + c1101 over mqtt. Integration with Alexa anc mqtt is hortible. For some Tests with tasmota i figured Out there ist a easy was to use this in tasmota with virtual switches that can emulate Hue or wemo.

So my Problem is to get this runing in tasmota with C1101 transceiver

Openmqttgateway try to use this lib

https://github.com/LSatan/SmartRC-CC1101-Driver-Lib

I Missing it inside tasmota.

The openmqttgatay Code is similar INSIDE rcswitch but c1101 Driver parts Missing to use IT for RFsend && RFreciv

U plan to Fully implemitate this Driver?

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• Read the Contributing Guide and Policy and the Code of Conduct
• Searched the problem in issues
• Searched the problem in discussions
• Searched the problem in the docs
• Searched the problem in the chat
• Device used (e.g., Sonoff Basic): wemos d1 mini
• Tasmota binary firmware version number used: latest tasmota-sensor.bin
  • Pre-compiled
  • Self-compiled
• Flashing tools used: _____
• Provide the output of command: Backlog Template; Module; GPIO 255:

  Configuration output here:

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  Rules output here:

• Provide the output of this command: Status 0:

  STATUS 0 output here:

• Set weblog to 4 and then, when you experience your issue, provide the output of the Console log:

  Console output here:

TO REPRODUCE

Steps to reproduce the behavior:

EXPECTED BEHAVIOUR

A clear and concise description of what you expected to happen.

SCREENSHOTS

If applicable, add screenshots to help explain your problem.

ADDITIONAL CONTEXT

Add any other context about the problem here.

(Please, remember to close the issue when the problem has been addressed)

[barbudor]

There are alreay support for RC-Switch and Sonoff RF-Bridge with Portish firmware
433MHz remote control is dying in favor of Zigbee which is much more reliable and secure
No addition will come from the core developpper team in that domain.
Now if an external contributor wants to submit a PR for optionally support this, why not.

[xheen908]

I think there are Not so mich steps to get it runing

Only c1101 init and gpio mapping is Missing

I'm Not c++ Developer i can't do this by mysefe. :(

This F1000a Modul with self made anntena is so crap.

I Like to use this awesome c1101 it has high Ränge, i Love it.

OK using of 433 Socket ist Not secure.

Anyone can Support?

[sfromis]

CC1101 (which I assume that you mean) is currently not supported by Tasmota (except as part of the Keeloq driver). Someone would have to create a more generalized driver to get it supported, which is becoming less likely with RF 433 being so badly outdated.

[xheen908]

Ofc i can buy sonoff s20 or 26 and make it save.

But This c1101 Support more frequencies that r interestet

I Like the Idea to Open Garage door without modding the Base Hardware.

C1101 has much more distance as my wifi

[sfromis]

Your garage door has a horribly bad security if you could open it with the very basic RF 433 functions available with Tasmota. Anyway, someone really wanting CC1101 support would also be the one to create a driver.

[mkohns]

I found that repo using tasmota and a berry script.
Perhaps interesting?
https://github.com/andrew01144/Tasmota-SomfyRTS

[s-hadinger]

Interesting. I wasn't aware if this

[barbudor]

Interresting idea to use IRSend to generate a protocol that is over RF

[fightforlife]

I integrated the https://github.com/LSatan/SmartRC-CC1101-Driver-Lib in my Tasmota fork: https://github.com/fightforlife/Tasmota/tree/development_newSmartRC
The RCSwitch driver was modified to dynamically use the CC1101 if connected or the standard 433MHz module if connected. (depending on the PIN config)
Working fine for the last months.

[timaseth]

Could you please provide a step-by-step method to compile a bin for using the CC1101?
Thanks in advance.

[fightforlife]

Hi @timaseth,
you need to clone my fork: https://github.com/fightforlife/Tasmota/tree/development_newSmartRC
And then add the config you need for your setup. Mine looks like this for an ESP32 with BLE.

//platform_override.ini
[env:tasmota32-bluetooth-rf]
extends                 = env:tasmota32_base
build_flags             = ${env:tasmota32_base.build_flags} -DFIRMWARE_BLUETOOTH_RF
lib_extra_dirs          = lib/libesp32, lib/libesp32_div, lib/lib_basic, lib/lib_i2c, lib/lib_ssl, lib/lib_rf

//user_config_override.h
#define USE_BLE_ESP32                            // Enable new BLE driver
#define USE_EQ3_ESP32
#define USE_MI_ESP32                             // (ESP32 only) Add support for ESP32 as a BLE-bridge (+9k2 mem, +292k flash)
#define USE_SMARTRC
#define  USE_RC_SWITCH 

I will try to create a PR when I am finished integrating the driver.

[fightforlife]

Some feedback here:
I successfully integrated the CC1101 protocol. I allowed rcswitch to use the cc1101 with minimal changes and am currently implementing esplilight. Will create a PR when ready.
https://github.com/fightforlife/Tasmota/tree/development_newSmartRC

[timaseth]

Hi @fightforlife
I was able to successfully compile a 4mb bin for the ESP8266 using your repo.
My user config override has the following
#define USE_RC_SWITCH
#define USE_SMARTRC

My pins are as following but I am not getting any data.

I am sure I missing something here.
BTW, target is 433Mhz range.

Thanks in advance!

[fightforlife]

Looking good.
So if you only want to use the rcswitch library with the CC1101 you dont need the GDOs in your pin config. Just replace them with the RFPins.
GDO0 -> RFSend
GDO2 -> RFRecv

Then run the following command in console to test the SPI Connection: smartRCtestSPI.
If this is successful you can run the following commands:
smartRCsetMHZ 433.92
smartRCsetPA 12
smartRCsetRx

Now you should be able to see received RF signals on MQTT and console.

[xheen908]

IDK what i'm dooing wrong

my wireing looks like this

and my PIN setup like this

20:46:14.196 CMD: smartRCtestSPI
20:46:14.200 CC1101 SPI not connected!

[fightforlife]

It seems you compiled it correctly and set the correct pins. Otherwise the function would not be found.
This merely seems like a wiring issue.
Maybe you have a slightly different module, like one of these: https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.ebyte.com/en/pdf-down.aspx%3Fid%3D557&ved=2ahUKEwjn9_3bjqD-AhUGs6QKHYOyDU0QFnoECBwQAQ&usg=AOvVaw1DLqyT4IvXUOLHoEHQZ7Y4

[sheilbronn]

Hello, I'm also trying to connect a CC1101 board to a ESP32 Wroom.
The CC1101 board has the following wiring which I configured to the ESP32 (Module type ESP32-DevKit (0) as following:

CC1101 wiring pin - ESP32 pin - Tasmota config PIN - ESP32 Module parameter:

VCC - 3V3
GND - GND
SCK - G18 - GPIO18 - SPI CLK - 1
MOSI - G23 - GPIO23 - SPI MOSI - 1
GDO2 - G27 - GPIO27 - RFrecv
MISO - G19 - GPIO19 - SPI MISO - 1
CSN - G5 - GPIO5 - SPI CS - 1
GDO0 - G12 - GPIO12 - RFSend

However, I'm running Tasmota 13.1.0 and the command smartRCtestSPI returns

00:00:00.086 QPC: Count 1
00:00:00.093 SPI: Hardware using GPIO18(CLK), GPIO23(MOSI) and GPIO19(MISO)
00:00:00.100 TFS: File 'mcp23x.dat' not found
...
18:14:29.152 CMD: smartRCtestSPI
18:14:29.163 MQT: tasmota-esp32-wroomi/stat/RESULT = {"Command":"Unknown"}

Doesn't the standard ESP32 Tasmota firmware contain support for SPI or has this command become obsolete?
Has somebody succeeded running Tasmota32 with a CC1101?
Thanks for any hints!

[fightforlife]

The CC1101 driver is not in the standard tasmota. You have to compile it yourself with my driver from further up.
I did not have time to create a PR.
Currently I am running ESPhome instead of tasmota, so development on this is stalling.

[hanahonnakirei]

Hi, I wanted to ask you something, I followed the project to be able to send and receive with cc1101 module on tasmota and I was able to connect it and use it with 433 Mhz
First question, how come every time i restart tasmota i have to redo the 3 command
smartRCsetMHZ 433.92
smartRCsetPA 12
smartRCsetRx
and if i change from smartRCsetMHZ 433.92 to smartRCsetMHZ 315 it doesn't work?
Am I doing something wrong or is that how you designed the library?

Translated with DeepL.com (free version)

[fightforlife]

Hi there, the Init Function of the driver does the following:

void RfInit(void)
{

  ELECHOUSE_cc1101.setSpiPin(18, 19, 23, 5);
  //ELECHOUSE_cc1101.setSpiPin(SCK, MISO, MOSI, CSN);
  if (ELECHOUSE_cc1101.getCC1101())
  { // Check the CC1101 Spi connection.
    Serial.println("Connection OK");
    ELECHOUSE_cc1101.Init();
    ELECHOUSE_cc1101.setMHZ(433.92);
    mySwitch.enableTransmit(2);
    ELECHOUSE_cc1101.SetTx();
  }
  else
  {
  }
}

If you need different settings for the driver on startup you need to set them via commands, like you already do.
You can do this automatically, without manual intervention by using the autoexec.bat: https://tasmota.github.io/docs/UFS/#autoexecbat

[hanahonnakirei]

okay, though, I noticed one thing
in the xdrv_101_smartRc.ino driver code from line 99-111 it says so:

(default = 433.92).The cc1101 can: 300-348MHZ, 387-464MHZ and 779-928MHZ
*/
void CmndsmartRCsetMHZ(void) {
  if(ELECHOUSE_cc1101.getCC1101()) {
    if(XdrvMailbox.data_len > 0){
      smartRCConfig.frequency = CharToFloat(XdrvMailbox.data);
      ELECHOUSE_cc1101.setPA(smartRCConfig.frequency); <--------------- this line
      ResponseCmndFloat(smartRCConfig.frequency, 2);
    }
  } else {
    AddLog(LOG_LEVEL_ERROR, PSTR("CC1101 SPI not connected!"));
  }
}

this is the procedure that takes care of assigning the frequency, instead it assigns powerlevel

shouldn't it?:

(default = 433.92).The cc1101 can: 300-348MHZ, 387-464MHZ and 779-928MHZ
*/
void CmndsmartRCsetMHZ(void) {
  if(ELECHOUSE_cc1101.getCC1101()) {
    if(XdrvMailbox.data_len > 0){
      smartRCConfig.frequency = CharToFloat(XdrvMailbox.data);
      ELECHOUSE_cc1101.setMHZ(smartRCConfig.frequency); <--------------------
      ResponseCmndFloat(smartRCConfig.frequency, 2);
    }
  } else {
    AddLog(LOG_LEVEL_ERROR, PSTR("CC1101 SPI not connected!"));
  }
}

I tried changing it and now it works fine for me.... Thanks

Translated with DeepL.com (free version)

[arendst]

Note to self. THIS IS NOT STANDARD TASMOTA CODE but a fork.

[hanahonnakirei]

Why do you say this? Explain yourself better

[Jason2866]

Nothing to explain. cc1101 is not implemented in standard Tasmota in rcswitch driver lib.
So no support from Tasmota maintainer.

[awdark]

Has CC1101 been added?
https://tasmota.github.io/docs/Components-old/#gpio-conversion
198 | 4544 | CC1101 GDO0 | CC1101 RX Pin
199 | 4576 | CC1101 GDO2 | CC1101 TX Pin

I see that line and when I search through the source I do see the header files under lib_rf

[Jason2866]

No.

[awdark]

I appreciate the clarification thank you. I thought I was building it wrong!

[eadmaster]

can you share a binary build for ESP8266 or ESP32 i can try?

[xheen908]

Compiler it by your self, there is no release eadmaster ***@***.***> schrieb am Do., 16. Mai 2024, 13:03:

…

can you share a binary build for ESP8266 or ESP32 i can try? — Reply to this email directly, view it on GitHub <#14343 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE345GCR6HKI3C7ELOGGX3LZCSG7ZAVCNFSM5LR66C32U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TSNBVGY2TKOA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[eadmaster]

ok, i've managed to build the firmware and flash it on an ESP32.

i've found init requires all those pins to be defined:

SCK - G18 - GPIO18 - SPI CLK - 1
MOSI - G23 - GPIO23 - SPI MOSI - 1
MISO - G19 - GPIO19 - SPI MISO - 1
CSN - G5 - GPIO5 - SPI CS - 1

can i leave "SPI CS" unconnected/floating?

btw i have this module that apparently does not have a CS pin:

[sfromis]

A random search suggests that "CKN" pin really being "CSN", which indeed seems to be CS.

[eadmaster]

thank you for the tip, i thought it was "ClocK Negated", now it seems to be working fine!

[eadmaster]

little update: i've tested some rf remotes if have, and i've found only one that smartRCsetRx is not able to detect (not sure if it is a CC1101 limitation or the input buffer is too small):

rtl-433 log

$ rtl_433 -a 4
rtl_433 version 21.12 (2021-12-14) inputs file rtl_tcp RTL-SDR SoapySDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/andy/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Registered 176 out of 207 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-207 ]
Detached kernel driver
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Sample rate set to 250000 S/s.
Tuner gain set to Auto.
Tuned to 433.920MHz.
Allocating 15 zero-copy buffers
baseband_demod_FM: low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-05-30 13:59:42
model     : Smoke-GS558  id        : 29163
unit      : 25           learn     : 0             Raw Code  : 0e3d79
*** signal_start = 60851688, signal_end = 61000533, signal_len = 148845, pulses_found = 282
Iteration 1. t: 204    min: 95 (128)    max: 313 (154)    delta 3098
Iteration 2. t: 204    min: 95 (128)    max: 313 (154)    delta 0
Pulse coding: Short pulse length 95 - Long pulse length 313

Short distance: 120, long distance: 344, packet distance: 1763

p_limit: 204
bitbuffer:: Number of rows: 5 
[00] {151} 4f 5e 38 27 af 1c 13 d7 8e 09 eb c7 04 f5 e3 82 7a f1 c0 
[01] {33} 90 7b fa d3 00                                           : 10010000 01111011 11111010 11010011 0
[02] {33} 90 7b fa d3 00                                           : 10010000 01111011 11111010 11010011 0
[03] {33} 90 7b fa d3 00                                           : 10010000 01111011 11111010 11010011 0
[04] {32} 90 7b fa d3                                              : 10010000 01111011 11111010 11010011 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-05-30 13:59:58
model     : Smoke-GS558  id        : 17344
unit      : 25           learn     : 0             Raw Code  : 087819
*** signal_start = 64882621, signal_end = 65031479, signal_len = 148858, pulses_found = 282
Iteration 1. t: 204    min: 95 (186)    max: 314 (96)    delta 2789
Iteration 2. t: 204    min: 95 (186)    max: 314 (96)    delta 0
Pulse coding: Short pulse length 95 - Long pulse length 314

Short distance: 260, long distance: 571, packet distance: 1762

p_limit: 204
bitbuffer:: Number of rows: 5 
[00] {151} 4c 0f 08 26 07 84 13 03 c2 09 81 e1 04 c0 f0 82 60 78 40 
[01] {33} a1 82 98 93 00                                           : 10100001 10000010 10011000 10010011 0
[02] {33} a1 82 98 93 00                                           : 10100001 10000010 10011000 10010011 0
[03] {33} a1 82 98 93 00                                           : 10100001 10000010 10011000 10010011 0
[04] {32} a1 82 98 93                                              : 10100001 10000010 10011000 10010011 

EDIT: i've tried building a cmd based on what rtl_433 sniffed, but it seems it is not working correctly:
RfSend 0x4f5e3827af1c13d78e09ebc704f5e3827af1c120f7f5a6907bfad3483dfd69a41efeb4c0", 288, 1, 1, 174

Replaying the signals with a broadlink rm4pro seems to work as expected, even if the original remote is sending different codes everytime the button is pressed (cycling codes?)

The remote was bundled with this kit: Unitec 48110

[eadmaster]

for those interested , here it is my test build.

I hope this could be turned into a PR, because the fightforlife fork is now quite outdated and it is missing some new useful features like deepsleep.

[fightforlife]

I just got this notification and updated my fork to the latest dev.
I switched all my devices to esphome some time ago because of easier config with HA (no mqtt) and btproxy.
But the RF stuff ist definitely better in Tasmota and easier to integrate. I will check if integration of this is possible in esphome. Otherwise I will switch back to Tasmota for RF stuff