Tasmota: RF Interference?

[jobingr]

I have multiple Sonoffs running on Tasmota including. 2 normal, 2 dual, power, slampher and 4 pro.

All my non RF enabled Sonoffs operate as expected. The ones with RF (4CH Pro and Slampher) hardware seem to have random button press events. I have enabled debug level 4 on web interface and it seems that the API registers this as button presses followed by MQTT signals.

Here is example from console log on 4CH Pro showing issue:

`15:29:24 APP: Button 3 level 1-0

15:29:24 MQT: tasmota/sonoff41/stat/RESULT = {"POWER3":"OFF"}
15:29:24 MQT: tasmota/sonoff41/stat/POWER3 = OFF
15:29:24 APP: Button 3 level 0-1
15:29:24 CFG: Saved to flash at F8, Count 3700, Bytes 1648
15:29:29 WIF: Checking connection...
15:29:29 WIF: Connected
15:29:50 WIF: Checking connection...
15:29:50 WIF: Connected
15:30:03 APP: Button 3 level 1-0
15:30:03 MQT: tasmota/sonoff41/stat/RESULT = {"POWER3":"ON"}
15:30:03 MQT: tasmota/sonoff41/stat/POWER3 = ON
15:30:03 APP: Button 3 level 0-1
15:30:04 CFG: Saved to flash at F7, Count 3701, Bytes 1648`

Button 3 has not been pressed. Other buttons on this device also come up. Same happen on Slampher.

I have tried debugging this by pairing these devices with RF remotes. Real RF signals give similar debug outputs and are reported as real button presses. My guess is that there are stray signals on RF band causing activation. I am in Africa and it could be that the bands read from are allocated to some other application in country? Is it possible to software disable RF commands or further troubleshoot this?

Any suggestions for further debugging from my side? Does Tasmota have option of bypassing RF signals?

[arendst]

RF signals are hard wired to either gpio0 (RF) or another microcontroller (4CHpro).

The schematics are in the itead wiki. Perhaps you can cut a wire on the board.

[jobingr]

Did mod on my 4ch pro. Pin 11 of U7 syn470r ( the Rf chip) is SHUT pin. It is connected to ground and internally pulled hight. I disconnected this pin from ground effectively putting chip in shutdown mode.

So far so good. my Open Energy also use 433MHz for communication so I guess that is the source of interference.

Will give feedback if this totally resolves issue and look at mod on Slampher then

[jobingr]

Thanks for Tasmota... it is great!

[nmaggioni]

Hey @jobingr, did you get around to disabling interactions with the uC? Your tip on U7's pin let me get rid of random interferences, but the module still freezes for a few minutes (as it goes in _learning mode_) if a button is accidentally double-pressed.

[jrial]

Will give feedback if this totally resolves issue and look at mod on Slampher then

So, did it?

Reason I ask is we're struggling with the same, and before I attack the thing with the soldering iron, I want to ensure that I'm not lifting that pin in vain.

[legalimpurity]

FYI DONT RIP OFF THE CHIP (U7), i just did and now the whole device is dead.

[e-t-h]

I had the same issue. The 4ch pro switched when I sent a 433MHz signal of an other switch. For some reason the 4ch pro had taught in this code. I was able to clear it by using S5 (pressing until green LED flashed).
To be safe for the future have cut the conducting path coming out from pin 10 (DIN) and short circuited the path to the U8 to ground (at pin 9). If you are careful you can reconnect it later, if you'll need the RF functionality.

[HEM59510]

I had the same issue. The 4ch pro switched when I sent a 433MHz signal of an other switch. For some reason the 4ch pro had taught in this code. I was able to clear it by using S5 (pressing until green LED flashed).
To be safe for the future have cut the conducting path coming out from pin 10 (DIN) and short circuited the path to the U8 to ground (at pin 9). If you are careful you can reconnect it later, if you'll need the RF functionality.

Hello, do you think the result is the same if i remove U7 component ?

[e-t-h]

I would think that should work also, although I wouldn't solve it that way. If you do so ground the pin 10 to provide a stable input to the STM (U8). (figure it out, the risk is 15 bugs and 6 weeks delivery time..).

jobingr's approach seems to be a very good solution also. I don't have checked if my approach lead to the same issue like nmaggioni described. But I suppose so. I'll check it later and give a statement.

[HEM59510]

Thanks !

I would think that should work also, although I wouldn't solve it that way. If you do so ground the pin 10 to provide a stable input to the STM (U8). (figure it out, the risk is 15 bugs and 6 weeks delivery time..).

jobingr's approach seems to be a very good solution also. I don't have checked if my approach lead to the same issue like nmaggioni described. But I suppose so. I'll check it later and give a statement.

Thanks, let s us informed. (my need is to disable definitely RF)

[Thoky81]

Is there any chance to map the S5 button? What GPIO it use? Thanks

[HEM59]

Hello,
Do you know if jobingr's approach (Pin 11 disconnected) the rolling code process (waiting a RF signal) would be disabled ?
To be more precise, my question, if i push 2 times quickly button channel, my sonnof would still wait a signal ?