Replies: 14 comments 41 replies
-
|
Not sure what you mean by "R5 is not ESP32 base". According to NotEnoughTech it is ESP32-D0WDQ5-V3. As with other new devices, someone with the device and interest will have to analyze it, to see how it can work with Tasmota. There is no big time schedule behind the scenes. |
Beta Was this translation helpful? Give feedback.
-
|
@sfromis you are talking about https://itead.cc/product/sonoff-switchman-smart-wall-switch-m5/ |
Beta Was this translation helpful? Give feedback.
-
|
All the keywords are included in the title from Itead...
|
Beta Was this translation helpful? Give feedback.
-
|
From the pictures above I conclude your R5 is a battery powered RF transmitter. No ESP8266 or ESP32 present so no Tasmota support. |
Beta Was this translation helpful? Give feedback.
-
Dear theo hope that you’re well, actually sonoff R5 is a new Sonoff remote scene controller that is based on Bluetooth technology, it could be link with Sonoff M5 switch man in wall key and also with Sonoff mini R3 . It has 6 buttons and could be set as 18 action (single press , double press , long press) . We know that sonoff has used ESP32 ble series in M5 and Mini R3, so it could be very useful if tasmota also support R5 , also it could be very interesting using in HomeAssistant to trigger 18 different scenarios and automation. |
Beta Was this translation helpful? Give feedback.
-
If you mean supporting the Sonoff eWeLink-Remote protocol this is IMHO unlikely to happen. Better look into a technology that is already well supported by Tasmota : Zigbee |
Beta Was this translation helpful? Give feedback.
-
|
I try to sniff the RF with the tasmota Bluetooth, I did't see any packet on air. |
Beta Was this translation helpful? Give feedback.
-
|
AFAIK, it is not Bluetooth, but yet another proprietary 2.4 GHz protocol, and Tasmota Bluetooth is not a general interface anyway. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Looks like another rf433 switch. Using a Sonoff RF Bridge with Tasmota you can integrate like many other rf433 devices. Imho, this days a rf433 device... There are nice secure! battery powered zigbee switches. |
Beta Was this translation helpful? Give feedback.
-
|
It does not use rf433 device it is “eWeLink-Remote” , a new technology that sonoff just get to the public. it is a new device that don't use "Sonoff RF Bridge" . |
Beta Was this translation helpful? Give feedback.
-
|
Mhh, probably the R5 is a Bluetooth device. The M5 has no additional chip as far i can see in the video from NotEnoughTech. |
Beta Was this translation helpful? Give feedback.
-
|
any update on that? |
Beta Was this translation helpful? Give feedback.
-
|
Since the flash in the R5 is OTP there is no way to change it. The reading of that flash would just be used to reverse the used encryption/rolling code. |
Beta Was this translation helpful? Give feedback.
-
|
I got the binaries of both the M5-1C-80 and M5-2C-80 |
Beta Was this translation helpful? Give feedback.
-
|
any update on that? |
Beta Was this translation helpful? Give feedback.
-
|
@habablaxe afaik no one is working on this. The Tasmota crew wont do. We are focused on esp8266 and esp32 devices. No rewriting or writing vendor specific new firmwares to support one vendor only protocol. |
Beta Was this translation helpful? Give feedback.
-
|
Is there any chance that this device can be used with a Sonoff M5 flashed with tasmota? |
Beta Was this translation helpful? Give feedback.
-
|
too bad really. That was an excellent selling point for this line of product especially if one want to implement in a two way switch configuration or even 3 way. |
Beta Was this translation helpful? Give feedback.
-
|
Can someone please help me get my M5 back to stock firmware so that I can use the R5 with it? |
Beta Was this translation helpful? Give feedback.
-
|
Reflash the firmware backup you made when replacing it with Tasmota. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately I don't have that backup file anymore! |
Beta Was this translation helpful? Give feedback.
-
|
While I have no experience with that specific device, my general experience with Sonoff (and others too) devices is that a firmware image from one device will not work on another, as it includes an id tied to the MAC of each chip. |
Beta Was this translation helpful? Give feedback.
-
|
M5 is WiFi + Bluetooth. R5 is Ble. When an R5 connects with any compatible Sonoff product, I paired it with one of the power monitoring wall plugs out of curiousity, and it works but slowly. Seems that each R5 does have a unique ID stuck in there somewhere, I paired 4 R5 and all have the same Mac and save advertised services, but each registered a diff 6 digit identifier. I still have been unable to get more specific, but I'm working on it. I mean heck, the little switches are great to attach to the night stand. :p |
Beta Was this translation helpful? Give feedback.
-
|
Hello, Would also like to use the Sonoff R6. Is the Sonor R6 now supported via the M5 with Tasmota already? |
Beta Was this translation helpful? Give feedback.
-
|
Hi! |
Beta Was this translation helpful? Give feedback.
-
|
Hi! Bytes 0 - 12 are the same for all devices: Byte 13, as I understand it, device type identifier: 47 for R5, 46 for S-mate etc. All other bytes in the packet change their value with each press. Packets are sent at some interval (it has not yet been possible to accurately measure) while the button is pressed, but no more than 15-30 seconds (it has not yet been possible to accurately measure). |
Beta Was this translation helpful? Give feedback.
-
|
Hi, any progress with this? |
Beta Was this translation helpful? Give feedback.
-
|
Hi! No at this moment. |
Beta Was this translation helpful? Give feedback.
-
|
I just realized a bluetooth long-range communication called "BLE coded PHY" maybe that's the protocol the S-MATE and R5 use: https://www.esp32.com/viewtopic.php?t=20042 Also, I downloaded the firmware.bin file that belongs to the M5 and decompiled some of the code until I got this, then converted it to c++: #include <iostream>
int main() {
// Initialize string data
const char* uart_env_msg = "Uart ENV [%p], VHCI ENV [%p], PLF FUNCS [%p]\n";
const char* bt_controller = "btController";
const char* bt_controller_id = "50c0b9e";
const char* schm_proc_msg = "SCHM PROC %02x %02x, %p\n";
const char* coex_schm_file = "coex_schm.c";
// Initialize binary data
const unsigned char binary_data[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x14, 0x56, 0x41, 0x3F, 0x5D,
0x8D, 0xFB, 0x3F, 0x01, 0x00, 0x01, 0x00, 0x1C, 0x56, 0x41, 0x3F, 0x01,
0x00, 0x00, 0x00, 0x05, 0x08, 0x00, 0x00, 0x48, 0xDD, 0x11, 0x40, 0x81,
0xFC, 0x00, 0x00, 0x48, 0xDB, 0x11, 0x40, 0x07, 0xFD, 0x00, 0x00, 0xF4,
0xDC, 0x11, 0x40, 0x08, 0xFD, 0x00, 0x00, 0x44, 0xDC, 0x11, 0x40, 0x09,
0xFD, 0x00, 0x00, 0xF0, 0xDB, 0x11, 0x40, 0x0A, 0xFD, 0x00, 0x00, 0x9C,
0xDB, 0x11, 0x40
};
const char* ea_file = "ea.c";
const char* labels[] = {
"BL", "BH", "BB", "250B", "BBL6B", "BHH"
};
// Additional string data
const char* hci_tl_file = "hci_tl.c";
const char* huart_file = "huart.c";
const char* uart_env_check = "uart_env_p != NULL";
const char* bufptr_check = "bufptr != NULL";
const char* callback_check = "callback != NULL";
const char* size_check = "size";
// Print the string data
std::cout << uart_env_msg << std::endl;
std::cout << bt_controller << std::endl;
std::cout << bt_controller_id << std::endl;
std::cout << schm_proc_msg << std::endl;
std::cout << coex_schm_file << std::endl;
// Print the binary data in hexadecimal format
std::cout << "Binary data: ";
for (size_t i = 0; i < sizeof(binary_data); ++i) {
printf("%02X ", binary_data[i]);
}
std::cout << std::endl;
// Print additional strings
std::cout << ea_file << std::endl;
for (const char* label : labels) {
std::cout << label << std::endl;
}
std::cout << hci_tl_file << std::endl;
std::cout << huart_file << std::endl;
std::cout << uart_env_check << std::endl;
std::cout << bufptr_check << std::endl;
std::cout << callback_check << std::endl;
std::cout << size_check << std::endl;
return 0;
}If anyone can check so maybe could reach anything. |
Beta Was this translation helpful? Give feedback.
-
|
Could you share please how have you decompiled that image. I tried esp32_image_parser to make elf but it failed. I assume elf is needed for any further steps. |
Beta Was this translation helpful? Give feedback.
-
|
I did it using binary ninja |
Beta Was this translation helpful? Give feedback.
-
|
And converted it to C++ code using ChatGPT |
Beta Was this translation helpful? Give feedback.
-
|
Also, check this ewelink remote control app if it can be decompiled: |
Beta Was this translation helpful? Give feedback.
-
|
All of these strings are from esp32-bt-lib, more specifically, this exact version (see the version referred by the commit message, Most likely nothing from this output is from application code, unfortunately. |
Beta Was this translation helpful? Give feedback.
-
|
I also played an afternoon with one of this, posting what I've found, it may help someone's progress: BLE packet structure: Byte 16 is a some kind of counter, each press changes it's value: Bits 5-8 are having the following values (in row continous order, in hex): So the full sequence is: [
hi+lo
for hi in "dcfe98ba54761032"
for lo in "32107654ba98fedc"
]With each press the 16th byte of the packet will be the next value in this cyclic sequence. From here, the question comes up what will happen if we iterate (press) through a full cycle: So, unfortunately the encoding is depending on something else too. This is the point where I stopped :/ The AK80x SDK contains "xxtea" encryption but found no sign of that in the dumped M5 flash. For example, these filled: And POST/WS API endpoints on: Hope the above will help somebody. |
Beta Was this translation helpful? Give feedback.
-
|
I don't know if we could get something from the data without knowing the encryption but I recorded successive packets and the bytes 21-31 were the following: Given the above 11 bytes of data, XOR-ing the successive values, got the following: Only bytes |
Beta Was this translation helpful? Give feedback.
-
|
Okay, I have a proof of concept and can successfully read the button presses. Basic idea is to do the XOR operation with formerly captured encrypted packets that belong to a specific button. There you will see a pattern that the first few bytes are equal to each other only when XOR operation is done with payload of the same button. This works in my test in every case now with 100% success rate, but it is bit cumbersome to use und a WIP with very non-optimised code remnants. For use with the MI32 legacy-driver: |
Beta Was this translation helpful? Give feedback.
-
|
This is great |
Beta Was this translation helpful? Give feedback.
-
Excellent! This is also true for double, triple, quadruple (I didn't check further :) and long presses. |
Beta Was this translation helpful? Give feedback.
and others
-
Hi
I get the new sonoff R5 Scene Controller. and I didn't find any why to use it with Tasmota.
there is a plan to add support for it in the new M5 (main controller ) or in the M5?
I see that the R5 is not ESP32 base, and I didn't manage to understand what is the RF protocol/band that is used.
I assume that we need to add support it the M5 to read the RF packet from the R5.
I will be happy to help with this hacking.
Beta Was this translation helpful? Give feedback.
All reactions