New Sonoff RF Bridge Board Layout (R2 v2.2)

[cwttdb70]

PROBLEM DESCRIPTION

There is a new version of the Sonoff RF bridge board, R2 v2.2, which as a different configuration than past versions. While I was able to flash Tasmota using this guide:
https://tasmota.github.io/docs/devices/Sonoff-RF-Bridge-433/

I was not able to figure out which pins to connect to flash Portisch.

Any help that could be provided would be greatly appreciated, and we could use any information gleaned here to update the guide for this device.

Here are images of the new board.

REQUESTED INFORMATION

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

• [x ] Read the Contributing Guide and Policy and the Code of Conduct
• [x ] Searched the problem in issues
• [x ] Searched the problem in discussions
• [x ] Searched the problem in the docs
• [x ] Searched the problem in the chat
• Device used (e.g., Sonoff Basic): Sonoff RF Bridge___
• Tasmota binary firmware version number used: 9.5.0_
  • [x ] Pre-compiled
  • Self-compiled
• Flashing tools used: ESP-flasher___
• 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

N/A

EXPECTED BEHAVIOUR

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

SCREENSHOTS

If applicable, add screenshots to help explain your problem.
N/A

ADDITIONAL CONTEXT

Add any other context about the problem here.
N/A

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

[barbudor]

It has been identified that this new version is more than a layout change as they change the whole MCU part.
It is no more an EFM processor and Portish firmware may not be compatible as-is.
Also no one as yet digged into the communication between the ESP and this new MCU which may be I2C instead of serial.

You are currently on a totally new and unexplored land until someone with the device, the skills, the time and the willingness dives into this.

[ascillato]

So, it is working fine. That is the expected console output.

[Tediore]

Correct. The issue OP is referring to is not being able to flash Portisch though (which is expected given the board revision)

[barbudor]

For now, no one can tell if Portish would be compatible (as-is) with je new MCU (although they seem to share the same 8051 core).
As Portish software is not developed by Tasmota team, this would probably better be discussed with the Portish project.

[cwttdb70]

Since it sounds like this new board is unflashable with Portisch, and my 433 MHz fob does not work with stock Tasmota, I now have no use for the board. If anyone here wants to try to hack the new RF chip to make it work with Portsich (which appears to be long abandoned, last commit March 2019), or otherwise thinks they might be able to figure out how to make the board recognize alternative 433 MHz signals, i'm happy to send you the board free of charge.

[CyberMod-Studio]

It has been identified that this new version is more than a layout change as they change the whole MCU part. It is no more an EFM processor and Portish firmware may not be compatible as-is. Also no one as yet digged into the communication between the ESP and this new MCU which may be I2C instead of serial.

You are currently on a totally new and unexplored land until someone with the device, the skills, the time and the willingness dives into this.

Sonoff Official Developer said the 433 recive chip is SYN470R or WS490F.

[sedlacekdavid]

Same problem here.

It's a new design without EFM processor. Seems like the first chip has remained same and the second one is different. Maaan I needed an RF gateway so ordered this :/

[cwttdb70]

Hey David,

To get the commands to show up in console for your Sonoff RF Bridge, did you have to run MQTT or anything like that, or did you just open up the console and start pressing buttons on the fob? Sorry, i'm a bit of a beginner on stuff like this. I'm flashed with Tasmota, and commands are not showing up for me when I press buttons on my remote.

If It turns out that I can't use this bridge as desired to control my electronic blinds, then i'm happy to send the bridge free of charge to someone who has interest in trying to hack the new RF chip.

[xbeastx]

@davidturchak

Unfortunately mine R2 v2.2 refuses to enter a download mode. I'm using the same FT232RL . I did try to revert RX and TX , did try holding pairing button with no success. No hw modifications performed yet. Any suggestion ?

Same for me... By some reason it's not entering to download mode...
My steps:

• hold pair button
• insert uart to my usb port
• release pair button

See com port but it's show:

A fatal error occurred: Failed to connect to Espressif device: No serial data received

Tried change tx/rx with no luck

[hw-schrauber]

Do you use J2 or J3?

[xbeastx]

J2...

[xbeastx]

ok. got it work. you need hold pair button to use download mode all the time...

[davidturchak]

Do you use J2 or J3?

I'm using J2

[cwttdb70]

Since it sounds like this new board is unflashable with Portisch, and my 433 MHz fob does not work with stock Tasmota, I now have no use for the board. If anyone here wants to try to hack the new RF chip to make it work with Portsich (which appears to be long abandoned, last commit March 2019), or otherwise thinks they might be able to figure out how to make the board recognize alternative 433 MHz signals, i'm happy to send you the board free of charge.

[bjwo]

Aaahrgh, I'm also affected by this. Got a new RFBridge from itead yesterday.

@Portisch can you help? It seems all new RF Bridges sent out by itead have a new (incompatible?) layout.

[cwttdb70]

I was able to find a r2 v1.0 board here that is still compatible with Portisch. I would suggest messaging the seller first to confirm they still have more.

https://www.amazon.com/dp/B0833VHSCD?psc=1&ref=ppx_yo2_dt_b_product_details

[bjwo]

I was also successful flashing the Tasmota 10 firmware to the RF Bridge using the J2 connectors and holding down the pairing button.

However, in the Tasmota console, I cannot find any events from the Sonoff 433MHz door sensors. Can you guys confirm that the Tasmota FW is working as expected with hardware revision v2.2 and your sensors?

[Jason2866]

I do not think you are doing something wrong. I see 2 possibilitys

• The door sensor is crap
• The protocol how the rf mcu communicates has changed and Tasmota spits out garbage

[Jason2866]

Many door / windows sensors do NOT have a close function.

[johnjoemorgan]

@barbudor Here the yaml for the RF binary door sensor (works with smoke alarms, motion etc.) I have not come across a RF sensor device that report 2 states - just ON or "Nothing"

  - platform: mqtt
    state_topic: tele/rfbridge/RESULT
    name: Boys Door
    value_template: '{{value_json.RfReceived.Data}}'
    payload_on: 'AD76B9'
    payload_off: 'AD76B9off'
    device_class: door
    qos: 1
    off_delay: 5
    unique_id: boys_door

[Jason2866]

I have ones with different codes for open/close. Search on the big chinese selling platform for rf window sensor open close and you will find.

[bjwo]

Ah it seems like the Sonoff DW2-RF sensors are crap. Why wouldn't they implement 2 different events for open and close!? It didn't even cross my mind that this was a possibility. $60 down the drain.

[dbuezas]

Direct hack for R2.2:
https://community.home-assistant.io/t/new-sonoff-rf-bridge-board-need-flashing-help/344326/17

[ascillato]

Yes, I think that is the way to go for this new hardware revision. That is not supported yet in Tasmota.

[Jason2866]

Was my idea too. Others where faster than i😉. Support in Tasmota is easy

[dbuezas]

FTR: It does work in Tasmota w/o modifications. The problem is the limitations on protocols, b/c nobody knows how to flash the other chip.

[ascillato]

Yes, the new Sonoff RF Bridge Board Layout (R2 v2.2) works with Tasmota but it does not have the extended protocols support done in the Portish Firmware due to this board has a different RF Chip that is not flashable with Portish Firmware. The communication protocol that this new chip uses to send information to the ESP8266, is the same as before.

So, this new version works with Tasmota but it does not support Portish Firmware upgradings in the RF chip. The modification you linked could be an alternative to make new protocols be supported in Tasmota bypassing this RF Chip. That should work, but today, this change is not supported in Tasmota. Some development is needed. I'm just clarifying all this for anyone reaching this thread.

[schmurtzm]

Hi, thanks to dbuezas, I have bypassed the EFM (direct hack) on my R2 v2.2 and successfully tested it with Tasmota.
Also I propose alternative way to cut the USB data lines on the back of the board :

Also I finally flashed it with a customized version of RFlink32 because I don't like to use raw data for my automations.

[CyberMod-Studio]

Sonoff官方开发者称433接收芯片是SYN470R或WS490F

[Jason2866]

English only.

The official Sonoff developer says the 433 receiver chip is the SYN470R or WS490F

What type of receiver is not mandatory. With the direct hack it will work.
Compiling Tasmota with #define USE_RC_SWITCH and assigning the GPIOs for Transmitter and Receiver and it will work (GPIO4 ---> receiver, GPIO5 ---> transmitter)

[UbiConcept]

They are using a new processor, they switch from a EFM8 to a Chinese cheaper version OB38R08A1 from On-Bright. It is not compatible with Portish without modifications.

[UbiConcept]

We were successful in flashing this new processor using a MSM 9066 from syncmos that we had. This processor has ISP functionality but we didn't test to see if it was enable on brand new device. After flashing it with an ISP loader we were able to update the software from tasmota (with some changes in the protocol). We do not use stock portish, we use our own software based on original portish.

[UbiConcept]

Portisch "as is" does not work on his new processor, you need to adjust it to this processor 8R08A1. We use our own software for that part

[lucas685]

Portisch "as is" does not work on his new processor, you need to adjust it to this processor 8R08A1. We use our own software for that part

Can you please share this software with us?

[UbiConcept]

wont be of much help to you as it does not implement most functionality of Portisch and only decodes our own protocol

[lucas685]

Oh, understood. Thanks for the information. Do you know if with this firmware i can read ht6p20 codes?

[UbiConcept]

I think so but i'm not sure we didn't do much test with the original firmware

[UbiConcept]

for anyone wanting to play with it

[alexsomesan]

Awesome! Thanks a lot!

[alexsomesan]

OK, it seems the chips don't come with the ISP bootloader or the fuse that allows entering ISP at reset by asserting P1.6 low is disabled. Reset via the RST pin is also disabled via fuse.
This is disconcerting as it means any eventual flashing of a custom firmware on out-of-box boards will have to involve I2C. Official programmers seem hard to come by so I would not expect "normal" users to be able to flash via ICP.

There might be an option to emulate the ICP protocol in Tasmota, but that mean reverse-engineering the ICP protocol of the official programmer. I don't have one and cannot find one to purchase at a "normal" price (in Germany).

@UbiConcept would it be a lot to ask of you to record the I2C traffic during a flashing session with the ICP and share it with us?
I imagine the protocol can't be too elaborated, but without an ICP in hand, not much to go on there. Thanks!

[mightymos]

OK, it seems the chips don't come with the ISP bootloader or the fuse that allows entering ISP at reset by asserting P1.6 low is disabled. Reset via the RST pin is also disabled via fuse. This is disconcerting as it means any eventual flashing of a custom firmware on out-of-box boards will have to involve I2C. Official programmers seem hard to come by so I would not expect "normal" users to be able to flash via ICP.

There might be an option to emulate the ICP protocol in Tasmota, but that mean reverse-engineering the ICP protocol of the official programmer. I don't have one and cannot find one to purchase at a "normal" price (in Germany).

@UbiConcept would it be a lot to ask of you to record the I2C traffic during a flashing session with the ICP and share it with us? I imagine the protocol can't be too elaborated, but without an ICP in hand, not much to go on there. Thanks!

SyncMOS software package contains firmware files for the MSM9066. I've decompiled the same into assembly which appears to be valid 8051 instructions. However there are some confusing parts. It does not help that the disassembler may be mislabeling SFRs since they are not all standard in 8051. Or my assembly is just rusty.

How good are you with 8051 assembly?

Software package here:
http://www.syncmos.com.tw/technical.php?language=english

EDIT:
I am also seeing the MSM9066 on Aliexpress for $34 USD. Is it certain the OB38S003 can be read (or only erased/reflashed) with programmer across IIC bus?

[mrpatate76]

i not a programmer at all, but i really wish this to work,
did you see that aprt of the manual, it seem that you can access the isp under certain condition:

18.4 Initiate ISP Service Program
To initiate the ISP service program is to load the program counter (PC) with start address of ISP service program and
execute it. There are four ways to do so:
(1) Blank reset. Hardware reset with first programmable ROM address blank ($0000=#FFH) will load the PC
with start address of ISP service program. The hardware reset includes MAX810 (power on reset) and
external pad reset. The hardware will issue a strobe window about 256us after hardware reset.
(2) Execute jump instruction can load the start address of the ISP service program to PC.
(3) Enter’s ISP service program by hardware setting. User can force OB38S003 enter ISP service program by
setting P1.6 “ active low” during hardware reset period. The hardware reset includes MAX810 (power on
reset) and external pad reset. The hardware will issue after hardware reset. In application system design,
user should take care of the setting of P1.6 at reset period to prevent OB38S003 from entering ISP service
program.
(4) Enter’s ISP service program by hardware setting, the P1.1(RXD) will be detected the two clock signals
during hardware reset period. The hardware reset includes MAX810 (power on reset) and external pad
reset. The hardware will issue to detect 2 clock signals after hardware reset.
During the strobe window, the hardware will detect the status of P1.6/P1.1. If they meet one of above conditions, chip
will switch to ISP mode automatically. After ISP service program executed, user need to reset the OB38S003, either by
hardware reset or by WDT, or jump to the address $0000 to re-start the firmware program.
There are 8 kinds of entry mechanisms for user different applications. This entry method will select on the writer or ISP.
(1) First Address Blank. i.e. $0000 = 0xFF. And triggered by Internal reset signal.
(2) First Address Blank. i.e. $0000 = 0xFF. And triggered by PAD reset signal.
(3) P1.6 = 0. And triggered by Internal reset signal.
(4) P1.6 = 0. And triggered by PAD reset signal.
(5) P1.1 input 2 clocks. And triggered by Internal reset signal.
(6) P1.1 input 2 clocks. And triggered by PAD reset signal.

[mightymos]

i not a programmer at all, but i really wish this to work, did you see that aprt of the manual, it seem that you can access the isp under certain condition:

18.4 Initiate ISP Service Program To initiate the ISP service program is to load the program counter (PC) with start address of ISP service

I purchased an msm9066 programmer and when I attempted to read the chip it indicated it was locked. To interact with the chip the SMAP AC flashing software required a chip erase. I do not know if there was any ISP, I think another commenter in the thread had checked. Lock bit is discussed on pg. 80, sec. 18.2 lock bit.

It would be cool if someone could bypass the restrictions and obtain a dump of the stock firmware.

I am working on an alternative firmware for the OB38S003 but it will take time:
#13283 (comment)

[UbiConcept]

rf chip is the same as before, just the 8 pin version https://img.ozdisan.com/ETicaret_Dosya/453934_1928180.pdf

[UbiConcept]

have fun... good luck

[Jason2866]

Hello @mightymos
Would be great if you manage to (re)write a custom firmware for the RF MCU of the actual RF Bridge!
(Flashed your custom RF window firmware, works nice!)

[mmmmm009]

Hi,

Brand new 433RFBridge R2 V2.2

1. First I flashed standard TASMOTA and set it as BRIDGE
   I was able to read code from my single-button 433 button,
   the code was.... not always the same
   (my old tasmota reads always the same code)
   in hex format (in tasmota console) there is often a difference in one letter/number when reading a code

2. than I flashed SENSORS, set template {"NAME":"Sonoff Bridge","GPIO":[32,0,0,0,1152,1120,0,0,0,320,0,0,0,0],"FLAG":0,"BASE":25}, did resistor/cuts modification
   and I get the same results (non consistent code)

any idea how to fix it?
thx.

[ludoerider]

THE SOLUTION is resolved here : #13283 (reply in thread)

Hello all,

just received the Sonoff RF Bridge R2 V2.2 (2021.01.19)
and y try to flash the ESP8285 on this board with an arduino UNO, it's possible indeed and i have following this schema :
https://makeitmore.fun/smarthome/how-to-flash-sonoff-devices-using-arduino, (3v3, rx, tx, gnd and rst)

The sending Led (TX) blink but the receive (RX) seems "blocked", all the time light is On (or lowest Led On) ...
When i try to flash with Tasmotizer, he see the PORT COM (i have push on the Pairing buton within 2-3 second and entering in prog mode)
After i have just the return : Failed to connect to ESP8266: Timed out waiting for packed header

I try to understand the step, because i think in this part of flash, it's not necessary to cut or modify the board actually, right ?

(Later, cut wire to bypass decoder etc...)

But in the first time i try to flash the board with Tasmota (by exe or online it's the same)
(if i start the RF board, he working fine too with the original version of sonoff program, board is not broken)
Any idea or a step that i haven't ?

Thanks a lot
Ludo.

[ludoerider]

yes i'm going to check if it's a real 3v3 , but i think :-)
And also already tested the RX to RX or TX to RX, nothing change...
Well, then i think, i'm going to buy a real USB to Serial UART board, and check this
Thanks a lot guys.

[sfromis]

If you happen to have a NodeMCU around, that can also be used as a good USB/serial adapter. If you buy an adapter, make sure to not buy one which does not have the capability of supplying at least 150 mA of 3.3V power, a lot of those boards cannot. Recommendations here:
https://tasmota.github.io/docs/Getting-Started/#serial-programmer

[ludoerider]

Woww, really thank you so much, i have a Node @home : D1 Mini with CH340G and directly do the job, great
Now, I try to configure Tasmota ... 👍

BUT important with the "D1 Mini" : it's necesarry to connect the TX of D1 Mini to TX of Sonoff RF and RX of D1 Mini to RX of Sonoff RF (yes i don't know if it's the label or whatever, but the inverse doesn't work !!)

[ludoerider]

Not easy guys ...
I have testing the configuration with tasmota, later tamota-sensors version .bin, i see some Rf data but not mine ;-) when i push the buttons on my remote control !
The hack is done : added 2 resistors in USBRXD and USBTXD, (power the board just by the pin 3v3 and GND, the board working fine with GUI, configuration etc, not from USB input, not necesarry for the moment)

I have a little question about the other wire ... actually not cut the wire near to RST point !
But it's really important to cut too the wire on top of left on U1 ?
https://community-assets.home-assistant.io/original/4X/5/0/6/506bc975aec3fcc34d40986b8094ade4f39af995.jpeg

(actually not cutted) , i walk step by step to prevent any damage ;-)

My material is 2 differents DIO and Chacon remote control - DIO 1.0 ref 54760 433.92Mhz and Chacon ref 54662, no result actually !

Also testing :
RfProtocol a
RfRaw 177
Changed template : {"NAME":"Sonoff Bridge Ludo","GPIO":[32,0,0,0,1152,1120,0,0,0,320,0,0,0,0],"FLAG":0,"BASE":25}

I think I'm close to the solution with your help ;-)
Thanks a lot

[Suschibomber]

THE SOLUTION is resolved here : #13283 (reply in thread)

Hey I'm from Germany and I just ordered the sonoff rf bridge from china at aliexpress. It should be there in 10 days. Since I unfortunately understand too little of circuit boards I do not want to do anything wrong and rather ask before again.

What changes do I have to make on the hardware side of the board? Do I have to cut any wires and if so what is the best way to do that? With a screwdriver or rather with a knife?

Do I have to order any resistors and solder them?

Which Tasmota version do I have to use and which template do I have to set?

How do I do that with the RfProtocol and the RfRaw 177 ?

And does the Portisch firmware work at all with version 2.2? Do I need it to read commands?

I always use a FTDI adapter FT232RL USB to TTL for flashing. Do I have to pay attention to anything there?

Sorry for the many questions. I thank you in advance.

[clove0]

So I feel like an idiot...but I snapped the pin on the 6 legged IC when soldering in the physical hack.

...does anyone know what chip that is...I want to avoid through another piece of e-waste in the landfill.

[mightymos]

Where on the board is the IC located?

It's probably the SYN113/SYN115 transmitter or a pin equivalent.
See here:
https://www.rhydolabz.com/documents/33/SYN113-SYN115-datasheet-version-1-1-.0.pdf

[sfromis]

U5 in the board image in the first post here. Not very readable. According to previous posts in this thread:

The official Sonoff developer says the 433 receiver chip is the SYN470R or WS490F

[mightymos]

Ok, I looked at my board and U5 is certainly the transmitter chip.

[mightymos]

It actually appears the chip might be a PT4455 transmitter chip because pin 4 on that chip is apparently the data input line. That is, when I toggle the TDATA (P0.7) on the microcontroller, pin 4 is what toggles on the transmitter IC. I really do not recall why I have the PT4455 datasheet, so it's still possible it is another chip:
https://datasheet.lcsc.com/lcsc/2005221602_PTC-Princeton-Tech-PT4455-TP_C559023.pdf

[Blackspell01]

Hey there,
I understand that currently it is not possible to use portisch on this rf bridge regardless of the direct hack method. But can someone please explain if it is somehow possible to "rebuild" the old v1.0 or 2.0 layout with an esp + 433 receiver/ transmitter? My goal is to control some warema ewfs shutters which use Manchester encoding. I previously tried to sniff the codes with aircast on my raspberry pi which didn't work unfortunately. Thanks for your answers

[sfromis]

That template is only relevant if you did the hardware modification to connect the RF part directly to the ESP8266, circumventing the small MCU with limited protocol support. Without the hardware modification, my impression (do not have the hardware) is that you can still use the normal Tasmota template for the old revision of the Sonoff RF Bridge, but that is with the limited protocol support then, and no Portisch.

[Blackspell01]

Ah ok thanks.
With a second esp chip will I be able to sniff and send Manchester encoded codes? Im really confused honestly…

[sfromis]

You need no second ESP chip, the one already in the bridge can handle RF, as long as the hardware is modified as suggested. Or without that, I think that you still have the more limited default protocol support, with the regular template instead of the one intended to be used with modified hardware.

I have no answer to whether your specific codes will be supported, but as Tasmota is using the RC-Switch project (when the hardware is modified) support is up to that project.

[Blackspell01]

You need no second ESP chip, the one already in the bridge can handle RF, as long as the hardware is modified as suggested. Or without that, I think that you still have the more limited default protocol support, with the regular template instead of the one intended to be used with modified hardware.

I have no answer to whether your specific codes will be supported, but as Tasmota is using the RC-Switch project (when the hardware is modified) support is up to that project.

I do have the hardware modification. Is it possible to get the raw code at least? As it seems, Manchester is not supporter by rc switch.

[Blackspell01]

Ok never mind, I got my codes through a different method using aircontrol. Last question: as Ive already cut those specific traces on the sonoff device, I won't be able to return it. Therefore, will it be possible to use the bridge at least for sending those sniffed Manchester codes? Or can I literally throw this thing away...

[clove0]

Hoping this helps someone out there...

I've been picking away at this for quite some time and finally had a bit of a breakthrough today.

I was trying to detect and then reproduce RF signals from a simple 433MHz remote but was unsuccessful in doing so. What I didn't realize is it was actually the "sniffing" of the FF signals that wasn't being done properly by the device.

If you're serious about figuring this stuff out, I highly recommend buying one of these to sniff the codes:
https://www.aliexpress.com/item/1827580191.html?spm=a2g0o.order_list.order_list_main.5.2d71180237TG2x

Then download and install "Universal Radio Hacker":
https://github.com/jopohl/urh

Then watch this video below to get an idea of how the software works:
https://www.youtube.com/watch?v=sbqMqb6FVMY&ab_channel=hubmartin

You will also have to download and install a different driver for this to work. Use Zadig-2.8 to do this.

For me, I had a simple on/off remote for a desk lamp. Here's what I did:

1. File->Record Signal
2. Settings are as follows:

• Device: RTL-SDR
• Device Identifier: (click refresh button it should show up as RealTek)
• Frequency: should be close but not exactly 433MHz, I chose 433.92MHz (don't ask me why this is apparently important)
• SampleRate: 1M
• Bandwidth: 1MHz
• Gain: depends....if the signal is so loud you can't see it all on the screen maybe turn down
• Frequency correction: 1
• Direct Sampling: disabled
• DC correction: on

3. Click record and then press the button on your remote that you want to emulate.
4. Save somewhere and the signal appears on the first window.
5. Change to ASK modulation on this window and change signal view to demodulated.
6. here you should see a series of short pulses and long pulses...short means "0" and long means "1". You can also measure the distance between the beginning of one pulse and the beginning of the next pulse...for me it was 1ms. I have no idea why but you have to divide this by 4 to get the "Pulse" value seen on tasmota RF Communication page.
7. At this point I basically counted the 1's and 0's to form a binary string which I then converted to decimal. The full command is as follows:

RfSend 1735098664,32,1,1,250 ...where the first number is the converted decimal, the second is the length being 32bits, protocol 1, repeat 1 (just means send once), with a pulse of 250µs (1/4 of the 1ms recorded earlier).

Actually being able to see the RF signals rather than relying on sniffing through tasmota helped immensely. Its a bit like having an oscilloscope but for radio waves. Otherwise...you're trying to do this blind.

Also...you definitely don't need the Sonoff bridge to do this. If you already bought it, then fine do the hardware hack and set the template to "{"NAME":"RFB v2.2","GPIO":[1,1,1,1,1152,1120,1,1,1,288,1,1,1,1],"FLAG":0,"BASE":18}" and use the steps above to properly decode RF signals. If you haven't bought the Sonoff yet..just buy one of these with an ESP32 and set the pin to RFSend. Its much cheaper and I actually found the signal to be cleaner than those produced by the sonoff.

[Jason2866]

Commands can not be done in a row. For this you need Backlog

[Jason2866]

But this commands are ONLY when the native RfBridge is used!
The RfSend command has all inckuded RfSend 1735098664,32,1,1,250

[Blackspell01]

ok and how would i convert my command from above to the rfsend format? I think i need to specify the time somewhere

[the-mentor]

@clove0 do you mind sharing a working link to the aliexpress item you've mentioned?

[clove0]

@the-mentor all links seem to still be working still but the first one was:

"Digital USB2.0 USB TV Stick Dongle FM DAB DVB-T RTL2832U+R860 for SDR TV Tuner Receiver Recorder With Antenna For Laptop PC"

..approximately $27.30 CAD

[lunakoa]

I have the original "black" version of the Sonoff RF bridge, but looks like the portisch and whatever hardware they used is magic because it picks up things my Wemos D1 with SRX882 or an RXB6 module can't. I have a simplier regen module I can try as well. But it is amazing watching them run side by side and seeing signals from 433mhz devices on the Sonoff but I do not see

But before I mess around with this more and burn time and money, what hardware do I need to get portisch to work.

In short how to a build a unit like the original "black" versions with an esp8266 (wemos d1 mini) with portisch compatible hardware? Can I purchase an EFM8BB1 module flash it with portisch and have the same signals?

On a side note, another thing I am not ruling out is the antenna, I tried to a wire 6.5" as well as the helical one that comes with the SRX882.

[sfromis]

Maybe the relevant tweaks are on the hardware side.....

Since you use a D1 Mini - very commonly, those are clone boards with a much weaker 3.3V voltage regular than the original, which quite plausibly can be an issue making builds work.

[lunakoa]

Good point, I will look into genuine Wemos D1 mini or at least look for one with 300mA regulator.

I think I have one already, but if you know of a good source for genuine Wemos D1 mini, let me know.

[sfromis]

The original ones have a 500 mA voltage regulator, and the obvious source is Lolin itself. Of course, I'm not saying that lack of 3.3V power is the issue, I was just mentioning a thing to remember.

[lunakoa]

You know there is a bit of Deju Vu here for myself. I have some nodemcu V3 I purchased because of the regulator issue with Wemos D1 mini.

I will switch gears and build off of those.

[lunakoa]

Thanks for all your help, I switched to a nodemcu V1 I had with a rxb6 module and am seeing how well it performs. I also have a different wemos d1 mini with an SRX882. We'll see how it pans out, but initially it looks like the nodemcu w/ the rxb6 is matching the performance black sonos. There are so many iterations to try out, but I think at least I got something working.

[mightymos]

This is not at all ready for use by regular users.
However I have successfully decoded radio packets on the R2 v2.2 with the onboard microcontroller.
The goal is to create the equivalent of "Portisch" alternative firmware but for the R2 v2.2 sonoff bridge.
One benefit is that no hardware modification would be required.

Thank you:
https://github.com/mightymos/RF-Bridge-OB38S003

[primaltechguides]

Anyone want to check my Sonof RF Bridge R2.2 guide for Tasmota
Flashing, Direct Hack Mod and linking to Home Assistant.

https://www.youtube.com/watch?v=k-FLN1cM4jk

[Jason2866]

When using Tasmotizer, the wifi credentials can be applied there. No need to do the Tasmota AP dance.
Imho a more specific name would be nice. Why not "Tasmota-RF_Bridge"?

[heisenberg2980]

@primaltechguides does this hack allow you to send commands to RF devices as well (e.g. RF blinds) or only receive commands?

[marcos-mvs]

Hello, guys!
First off all, thanks for the splendid work you have done!

I have a Bridge R2 v2.2 flashed with tasmota-sensors.bin 13.1.0 and already did the HW direct hack.
Configured GPIO4 and GPIO5 to RFrecv and RFSend respectively and enabled all supported protocols with "RfProtocol a" command.
From here i can see that everything appears to be working as i can successfully receive a button press in one of my RF remotes:

Now i want to control some blinds that use AC114-01B remotes (AC114 protocol) but had no luck, nothing shows up at the console when i press the remote buttons.
Looking at the source code in https://github.com/arendst/Tasmota/blob/v13.1.0/lib/lib_rf/rc-switch/src/RCSwitch.cpp file i can see that the support for AC114 protocol seems to be already there (protocol 20 - line 136), so what I'm missing?

Looking at this issue on the RC-Switch original project (sui77/rc-switch#163) they suggested changes to RCSWITCH_MAX_CHANGES (in RCSwitch.h) to 150 or even 167 to accommodate 66 bits of AC114 protocol.

the version of rc-switch used in tasmota defaults this value to 67 (https://github.com/arendst/Tasmota/blob/v13.1.0/lib/lib_rf/rc-switch/src/RCSwitch.h, line 62). If I'm understanding this right, it will limit support for protocols with a maximum of 32 bits?

Is there a way to change the value of RCSWITCH_MAX_CHANGES to check if the remote is recognized? Will I need to compile a customized version?

[Jason2866]

It has been a while when playing around with rc-switch. Iirc it has unwanted side effects increasing this value by default to the max value. But if it works for your use case.
So change it and compile a version.

[marcos-mvs]

well, i´ve managed to compile a custom version using gitpod, increasing RCSWITCH_MAX_CHANGES to 150 and 167.
Started to receive something from the remote, but not every press and not every button. Also, the messages were not recognized with protocol 20 as expected, but mostly protocol 8 with 64 bits or protocol 16 in some cases.
I tried to send the received data through RfSend, but the messages were not identified by the shutters.

[szsz]

Have you had any success with this? Were you able to send and receive raw codes?

[marcos-mvs]

I had to pause this project due to lack of time. I had modified the protocol parameters based on information from other forums and libraries, I used something like this config in RCSwitch.cpp and I was able to receive the commands successfully, but I was unable to send them:
{ 200, { 25, 3 }, { 3, 1 }, { 1, 3 }, false }

Unfortunately, the workspace I was working on in GitPod was automatically deleted, and I lost the changes I had made, so I can't confirm this data.

I will start again next year, trying to write code that allows me to sniff the raw received signals through tasmota, similar to the RFRaw command (when we use Portisch)

[anomajaya]

Hello,

Can anyone please send me a link to download the stock firmware of Sonoff RF Bridge R2.2 please.
I have accidentally fleshed it with Tasmota Sense without backing up the stock rom.

Thank you.

[sfromis]

Such a link would not be very useful, as Sonoff has the "habit" of locking their binary images to the MAC of each chip.

[pookieman]

Hi .. apologies if this has been answered a few times, the thread is pretty long now.

I've got the Sonoff RF Bridge Board Layout (R2 v2.2) and attempting to use tasmotizer. I've got it connected to the UART usb, after putting the header pins on. But it seems like the tasmotizer program can't see the sonoff RF.

I can see the TX flashing as it's trying to connect

Serial port /dev/tty.usbserial-14120
Connecting......................................_____

my question is do I need to cut those 2 tracers in order for this to work? I've not done that yet :)

and anything else I need to do?

thanks

[tpaivaa]

@pookieman
at least for me it worked if you hold the reset button while connect the usb serial (powering)
after that flashing works fine.

[the-mentor]

Anyone here knows which pin the transmitter is connected to (im asking about stock aka without the direct mod hack) ?
@mightymos since you're working on the firmware maybe you'll know ?

[mightymos]

Here are the pinouts for the ESP8265 portion.

Sonoff R2.2 Pinout Info

** J2 connector to ESP8265
LOG pin to GPIO2 (pin 14) (UART TX during flash programming)
TX pin to GPIO1 (U0TXD)(pin 26)
RX pin to GPIO3 (U0RXD)(pin 25)

** J3 connector to ESP8265
USBRXD to GPIO4 (pin 16)
USBTXD to GPIO5 (pin 24)


** J3 connector to J2 connector
RXD to TX (by way of R1 1 kohm)
TXD to RX (by way of R2 1 kohm)


** ESP8265
GPIO0 (pin 15) to push button
GPIO12 (pin 10) to pad on back of board
GPIO13 (pin 12) to R22 to LED2 (wifi led)
GPIO14 (pin 9) goes to pad on back of board (and pulled (up?) to power through R15
GPIO15 (pin 13) is pulled to pulled to ground through R18


OB38S003
Configuration can be set during flashing to make RESET pin function as reset.
Applying 3.3 V and then removing it causes reset to occur (is pin pulled low normally internally?; edge triggered?).

[the-mentor]

Hmm I wonder why this ESPHome config doesn't work seems like the transmitter is connected to GPIO01

remote_receiver:
  pin: GPIO03
  dump: raw
 # dump: all
 # dump: rc_switch
  filter: 100us
  tolerance: 50%
  idle: 2ms

remote_transmitter:
  pin: GPIO01 
  carrier_duty_percent: 100%

[mightymos]

Have you been able to get receiving working?
I do not see how it could be if you are using rcswitch, because rcswitch operates on amplitude keyed radio signals.
There are two ways to get those signals to the ESP8265 - [1] hardware modifications, [2] reprogram microcontroller to "mirror" those radio pins to pins connected to ESP. [2] is pretty cumbersome right now but possible.

Otherwise, the microcontroller is sending serial data to ESP (not signals).
So you would need to interpret that data.

This person posted this yaml for that:
mightymos/ReedTripRadio#11

[the-mentor]

@mightymos thanks for the reply it finally clicked for me what the hardware hack is doing and why receive worked but didnt identify protocols etc.

Does send work the same way? or send is connected directly to the hardware?
I have 2 RF bridge when i send from one i see the signal on the other if the sender is an RF with tasmota
i'm having problem getting the sender to work if the sender is ESPhome.

Also I see that you are working on a firmware modification that will work in pass-through mode so the hardware hack wont be required.
Can i support your work somehow ?

[mightymos]

Tasmota sends serial bytes to the little microcontroller, which then converts between raw signals for radio transmit/receive ICs.
The stock protocol would be a similar but more limited version like this:
https://github.com/Portisch/RF-Bridge-EFM8BB1/wiki

You apparently can do the same thing with ESPHome (I think).
Instead of using the rcswitch component, use rf_bridge instead:
https://esphome.io/components/rf_bridge.html

On the firmware modification, I did write an Arduino sketch that allows programming the microcontroller from the ESP8265. However, it is difficult to use (i.e., only flashes one hex file line at a time now) and will not work for a first flash because entering flashing handshake apparently needs to happen on microcontroller start up. However, the reset function on the microcontroller is disabled on stock device. So either an official programmer or externally powered ESP board is required to flash. And stock firmware has not been dumped so there is no way yet to revert to stock.

It would probably just be frustrating to try out this alternative firmware when all you want to do is get ESPHome working.
If you get it working, it might help people if you post your yaml as a git gist or something like that.

[the-mentor]

for anyone that is interested in the direct mod that requires no soldering
now its possible due to the hard work of @mightymos.
The below thread has more information and I'm correctly working on a step by step guide.

mightymos/RF-Bridge-OB38S003#4

[sfromis]

Basically looks like an alternative to Portisch, for the different MCU 😄

[diepeterpan]

I added more documentation and created pull requests on the @mightymos firmware and flasher; thank you @mightymos and everyone else's help for the firmware and flasher.

• https://github.com/diepeterpan/RF-Bridge-OB38S003. - added more explanation on the two different flash files and usage.

• https://github.com/diepeterpan/OnbrightFlasher/blob/main/flashing-guide-by-example.md - a guide to flash a new unit using a WeMos D1.

So far I have successfully flashed to units, both using passthrough mode, one running Tasmota and the other ESPHome.

[sfromis]

Well, that's what I just told you, with the example of getting TPMS data via MQTT, available to any tool able subscribe, including HA. It can work fine for picking up data, but if you want to also be able to transmit, the cheaper SDR dongles can't do that. But yeah, those dongles need a USB port to sit in, my test setup is with an old Raspberry Pi for that. For some time, I also got data from a weather station the neighbor had running, but not seeing anything there now.

[the-mentor]

@mikeandike150 I can jump on a quick call (discord/zoom etc) with you and quickly share what I've done and how I've got my Sonoff RF running ESPHome to control my fans etc

As someone said here before me Universal Radio Hacker is a tool that help you reverse engineer RF signals.
I spent a lot of time and effort trying to get the signal and re-transmit it on ESPhome and tasmota and that was a total waste of time.

Also if you want this is the SDR that i used to sniff the traffic with URH
https://vi.aliexpress.com/item/1005005952682051.html

EDIT: I dont think you need to build a device with RF the sonoff RF bridge is good enough to do everything except decoding signals for complicated stuff like FAN remotes.

[mikeandike150]

That would be awesome, thank you for the offer. What's your preferred way to connect?

Also, sounds good, thanks for the heads up. We can discuss more on the call but quick follow up: Are you saying that the Sonoff can't decode fan (complicated) signals ever or once you use URH to figure out the keys then it can?

[the-mentor]

add me on discord username thementor666 and we'll continue from there

Edit: depending on the signal some simple signals you can decode on the device and some like my ceiling fan you cant decode the signal on the Sonoff but if you decode it on URH and then configure the sonoff to transmit the signal then you wont have any issues.

[mikeandike150]

@the-mentor it looks like I'm unable to add you for some reason. I created a quick discord channel so we can both hop on: https://discord.gg/qYjqT6mH