How can you reset EFM8BB1? about rf-bridge-efm8bb1 HOT 55 CLOSED

Try this version (not the latest) https://github.com/arendst/Tasmota/raw/development/tools/fw_efm8bb1/RF-Bridge-EFM8BB1-20190220.hex
some newer versions do not run stable in our test in raw mode

from rf-bridge-efm8bb1.

@Portisch @gerardovf
Yes, bug in Tasmota. Fix will be online soon.
If you cant wait change in latest dev version... in file support.ino
Find void SerialSendRaw(char *codes, int size) and add after
uint8_t code;
add line
size = strlen(codes);
Bug found and fixed by Andrethomas
Ps. Whitespaces are no more a problem too

from rf-bridge-efm8bb1.

Solved the problem :

• installed Tasmotizer to flash (struggled some time with installing this on Linux Deb laptop)
• re-flashed RFBridge with Tasmota (as explained in the special flash proc for RFBridge)
• downloaded the tasmota project from github
• firmwate upgrade with Portisch selecting the latest hex file from the download (with correct wiring)

But it seems that I have to use different B0 codes than for my old Bridge ?
Has the sniffed B1 and bitbucketconverter been changed due to updates ?
(I had to re-snif codes and rund bitbuck again for my next rfbridge , old B0 codes do not activate my rf receivers)

from rf-bridge-efm8bb1.

The firmware is here https://github.com/arendst/Tasmota/tree/development/tools/fw_SonoffRfBridge_efm8bb1

from rf-bridge-efm8bb1.

I enabled the watchdog timer: eb4ac0d

Untested!!

from rf-bridge-efm8bb1.

@Portisch Just to keep you updated on this issue. It's very rare but it's still happening. It can take days before the EFM8BB1 stops sending 'ACK'.
I installed your watchdog timer version (eb4ac0d).
The only difference I can think of is that I'm sending long 'B0' payloads through MQTT.
Today after not receiving ACK, I first did a soft reboot on the bridge with no success and then I powered down the bridge (it's connected to a Sonoff S20 with Tasmota that allows me to take the power out from the bridge remotely)

from rf-bridge-efm8bb1.

The limit of the command data len is:
#define RF_DATA_BUFFERSIZE 112

If you send more data bytes than RF_DATA_BUFFERSIZE the data will truncated. The uart ist than just waiting for the sync end (0x55) and start transmit of the truncated data. But this will be done with the "real" len what mabye higher than RF_DATA_BUFFERSIZE. So the code tries to access data from RF_DATA[>RF_DATA_BUFFERSIZE] what can lead to an access violation.

I tried to fix it here: b24bed8
You should get a AKN but the RF transmit would not work because the data is truncated if more than 112 bytes are getting received.

from rf-bridge-efm8bb1.

@Portisch I'll check it inmediatly!
I see 'RF_DATA_BUFFERSIZE' is used in 'RF_DATA[RF_DATA_BUFFERSIZE]'
In 'RF_Handling.c' there's an index actual_byte used in several assigments (RF_DATA[actual_byte] = )
Everytime the index is incremented (actual_byte++;) it would be safe to check it's value (if (actual_byte > sizeof(RF_DATA))). It is already done in void Bucket_Received(uint16_t duration)
I don't see it done in void PCA0_channel0EventCb()

I'm receiving spurious data (maybe from a neighbour's remote?) ¿does this data make sense?

18-09-20 10:16:06 Received topic 'gvf/cega/bridge1/tele/RESULT' With message: '{"RfRaw":{"Data":"AAA423F001180370DEF1AE55"}}'
18-09-20 10:16:07 Received topic 'gvf/cega/bridge1/tele/RESULT' With message: '{"RfRaw":{"Data":"AAA423DC00D20352DEF0D755"}}'
18-09-20 10:16:07 Received topic 'gvf/cega/bridge1/tele/RESULT' With message: '{"RfRaw":{"Data":"AAA423E600F0033EDEF1AE55"}}'
18-09-20 10:16:08 Received topic 'gvf/cega/bridge1/tele/RESULT' With message: '{"RfRaw":{"Data":"AAA423E6010E0366DEF1AE55"}}'
18-09-20 10:16:09 Received topic 'gvf/cega/bridge1/tele/RESULT' With message: '{"RfRaw":{"Data":"AAA423E601180352DEF1AE55"}}'
18-09-20 10:16:10 Received topic 'gvf/cega/bridge1/tele/RESULT' With message: '{"RfRaw":{"Data":"AAA42404035C032ADEF1AA55"}}'

18-09-20 22:47:01 Received topic 'gvf/cega/bridge1/tele/RESULT' With message: '{"RfRaw":{"Data":"AAA4242C00FA033EDEF1AE55"}}'
18-09-20 22:47:01 Received topic 'gvf/cega/bridge1/tele/RESULT' With message: '{"RfRaw":{"Data":"AAA423E6012C017CDEF1AF55"}}'
18-09-20 22:47:01 Received topic 'gvf/cega/bridge1/tele/RESULT' With message: '{"RfRaw":{"Data":"AAA423F000F00352DEF1AE55"}}'

18-09-20 23:12:58 Received topic 'gvf/cega/bridge1/tele/RESULT' With message: '{"RfRaw":{"Data":"AAA422A601040352DEF1AE55"}}'
18-09-20 23:13:00 Received topic 'gvf/cega/bridge1/tele/RESULT' With message: '{"RfRaw":{"Data":"AAA423E600F00348DEF1AE55"}}'
18-09-20 23:13:01 Received topic 'gvf/cega/bridge1/tele/RESULT' With message: '{"RfRaw":{"Data":"AAA4240401360384DEF1AE55"}}'
18-09-20 23:13:01 Received topic 'gvf/cega/bridge1/tele/RESULT' With message: '{"RfRaw":{"Data":"AAA4221000FA037AEF78D755"}}'

from rf-bridge-efm8bb1.

I am having the same problem as described (also running tasmota 6.2.1)
The signals im sending are:
AAB017041401E60101021221F21011001010101010110100101355
AAB0250514024D02B6011901D61FE02000202020202020000000000000002020202020200000000455

from rf-bridge-efm8bb1.

@simo878 Try using last patch from @Portisch. Since I installed it I had no more problems.
b24bed8

from rf-bridge-efm8bb1.

@gerardovf awesome, just flashed it, will see how it goes!

from rf-bridge-efm8bb1.

I'm trying the b24bed8 build and I have still the same problem with non-responding EFM-chip.
I am sending bucket commands.

from rf-bridge-efm8bb1.

@ErikAndren I can confirm that this last version is working for me since more than two weeks (I'm using Tasmota 6.2.0).

from rf-bridge-efm8bb1.

@ErikAndren What data, how often and so on do you send?

from rf-bridge-efm8bb1.

Via home assistant (HA):

Every sunset HA sends:
payload_on: "AAB04E051401260AA000E70522298601000303000300000303000003000300030003000303000003030000030003000300030300000300030300030000030300030000030003030000030003000303000455"

and 5 seconds later HA sends:
payload_on: "AAB04E0514012F0AA000E90522297C01000303000300000303000003000300030003000303000003030000030003000300030300000300030300030000030300030000030003030000030003000300030455"

Every sunrise HA sends:
payload_off:
"AAB04E051401260AA000E70525298601000303000300000303000003000300030003000303000003030000030003000300030300000300030300030000030300030000030003000300030003000303000455"

adn 5 seconds later HA sends:
payload_off: "AAB04E0514012E0AA000E90522297C01020303000300000303000003000300030003000303000003030000030003000300030300000300030300030000030300030000030003000300030003000300030455"

from rf-bridge-efm8bb1.

@ErikAndren You're missing the 'command' part in your info. I understand you are using topic "cmnd/mydevice/rfraw"

from rf-bridge-efm8bb1.

Over the webinterface console: no problems

00:01:51 CMD: RfRaw AAB04E051401260AA000E70522298601000303000300000303000003000300030003000303000003030000030003000300030300000300030300030000030300030000030003030000030003000303000455
00:01:51 RSL: RESULT = {"RfRaw":"ON"}
00:01:53 RSL: RESULT = {"RfRaw":{"Data":"AAA055"}}
00:02:03 CMD: RfRaw AAB04E0514012F0AA000E90522297C01000303000300000303000003000300030003000303000003030000030003000300030300000300030300030000030300030000030003030000030003000300030455
00:02:03 RSL: RESULT = {"RfRaw":"ON"}
00:02:05 RSL: RESULT = {"RfRaw":{"Data":"AAA055"}}
00:02:14 CMD: RfRaw AAB04E051401260AA000E70525298601000303000300000303000003000300030003000303000003030000030003000300030300000300030300030000030300030000030003000300030003000303000455
00:02:14 RSL: RESULT = {"RfRaw":"ON"}
00:02:16 RSL: RESULT = {"RfRaw":{"Data":"AAA055"}}
00:02:23 CMD: RfRaw AAB04E0514012E0AA000E90522297C01020303000300000303000003000300030003000303000003030000030003000300030300000300030300030000030300030000030003000300030003000300030455
00:02:23 RSL: RESULT = {"RfRaw":"ON"}
00:02:25 RSL: RESULT = {"RfRaw":{"Data":"AAA055"}}

So maybe a ESP firmware bug? (Tasmota?)

from rf-bridge-efm8bb1.

I'm using the "cmnd/sonoff/RfRaw" MQTT command
The problem is intermittent e. g. it works for a couple of days then it just stops responding until I power cycle the RF bridge.

I will try to update the Tasmota.

from rf-bridge-efm8bb1.

Do not update Tasmota. Just wait until this happen again. Then try if the RF Bridge (Tasmota) ist running or freezed. If running the use the console with this command:

RfRaw 177

The bridge should beep

from rf-bridge-efm8bb1.

Good point. I will wait for the next time and report back the result.

from rf-bridge-efm8bb1.

Reporting back, it's been 3 days and not a single error since flashing that build (previously would error out after a few hours every time)

from rf-bridge-efm8bb1.

I could replicate the issue tonight.
The home assistant script did not turn on the lights as expected.
When I manually toggle the command via home assistant it did not work at first. Then after waiting a while it started to work again (watchdog kicking in?)
Turning it on and off 4 times in a row with about 3 - 5 seconds pause between makes it unresponsive again.
Tasmota logs look like this:

9:16:25 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"}
19:17:53 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"}
19:21:05 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"}
19:21:06 MQT: tele/sonoff/RESULT = {"RfRaw":{"Data":"AAA055"}}
19:21:16 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"}
19:21:17 MQT: tele/sonoff/STATE = {"Time":"2018-10-10T19:21:17","Uptime":"1T01:40:26","Vcc":3.182,"Wifi":{"AP":1,"SSId":"Piffi","RSSI":100,"APMac":"90:5C:44:7D:9C:AA"}}
19:21:18 MQT: tele/sonoff/RESULT = {"RfRaw":{"Data":"AAA055"}}
19:21:22 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"}
19:21:24 MQT: tele/sonoff/RESULT = {"RfRaw":{"Data":"AAA055"}}
19:21:25 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"}
19:21:27 MQT: tele/sonoff/RESULT = {"RfRaw":{"Data":"AAA055"}}
19:21:29 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"}
19:21:31 MQT: tele/sonoff/RESULT = {"RfRaw":{"Data":"AAA055"}}
19:21:32 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"}
19:21:37 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"}
19:23:14 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"}

I would expect to get a {"RfRaw":{"Data":"AAA055"}} after each command.

from rf-bridge-efm8bb1.

Maybe there is some kind of race condition if you try to send commands to quickly in a row?

from rf-bridge-efm8bb1.

The bridge can't receive UART data if something is ongoing. For this are the chip resources too limited. Maybe Tasmota can implement a queue for transfer data to the RF chip!?

from rf-bridge-efm8bb1.

Sure, all commands received while processing a command could be dropped but it stops responding to any command even though it is done with the current command.

Tasmota implementing a queue would be handy but the EFM chip should still be able to cope with this situation

from rf-bridge-efm8bb1.

@Portisch In "uart.c", ¿could you try moving the acknowledge of the interrupt AFTER the actual read/write is performed?
//Buffer and clear flags immediately so we don't miss an interrupt while processing uint8_t flags = SCON0 & (UART0_RX_IF | UART0_TX_IF); SCON0 &= ~flags;

from rf-bridge-efm8bb1.

I spoke too soon, the problem has reappeared however more intermittently

RfRaw 177 does not beep when in error state

from rf-bridge-efm8bb1.

@simo878 Currently I'm using a Sonoff S20 with Tasmota to power the Bridge. This way I can power it down when it gets unresponsive; till the problems get solved it is a quick and dirty solution :-)

from rf-bridge-efm8bb1.

I was testing this with the console interface of Tasmota:

00:11:40 CMD: RfRaw AAB04E051401260AA000E70522298601000303000300000303000003000300030003000303000003030000030003000300030300000300030300030000030300030000030003030000030003000303000455AAB04E051401260AA000E70522298601000303000300000303000003000300030003000303000003030000030003000300030300000300030300030000030300030000030003030000030003000303000455

This "long" UART data get transmitted 1 time instead of 2 times. The second one is dismissed because the transfer of the first one isn't completed. -> working as aspected

RfRaw AAB04E051401260AA000E70522298601000303000300000303000003000300030003000303000003030000030003000300030300000300030300030000030300030000030003030000030003000303000455AAB04E051401260AA000E70522298601000303000300000303000003000300030003000303000003030000030003000300030300000300030300030000030300030000030003030000030003000303000455AAB04E051401260AA000E70522298601000303000300000303000003000300030003000303000003030000030003000300030300000300030300030000030300030000030003030000030003000303000455AAB04E051401260AA000E70522298601000303000300000303000003000300030003000303000003030000030003000300030300000300030300030000030300030000030003030000030003000303000455

This will transmit the data one time only. But after transmit the bridge beeps. -> Watchdog reset -> working as aspected

I spoke too soon, the problem has reappeared however more intermittently

RfRaw 177 does not beep when in error state

This doesn't mean the bridge is down! You have to use a com port terminal to check if the bridge is alive.

Finally -> there is a bug on the Tasmota side.

from rf-bridge-efm8bb1.

@Portisch My approach is not to blame RF-Bridge firmware. When I get no confirmation "{"RfRaw":{"Data":"AAA055"}}" I first send a restart command to Tasmota from a script in the Raspberry Pi (using 'curl http://192.168.0.123/cm?cmnd=Restart%2099'). If that doesn't help then I power down the Sonoff bridge using a Sonoff S20.

from rf-bridge-efm8bb1.

I know, but it isn't a fault by the EFM8BB1 firmware. I am sure if you sniff the UART data on the pins at J3 you will not see any data between Tasmota and the RF chip anymore when it stopps working. So the problem is the UART master -> Tasmota

from rf-bridge-efm8bb1.

Same issue for me, but with the latest version
Sonoff RF Bridge 433 - R2 V1.0
Sonoff-Tasmota v6.5.0
RF-Bridge-EFM8BB1-20181127.hex

@Jason2866, the UART issue has been resolved in this latest version?

from rf-bridge-efm8bb1.

@mioke77 There are no know problems. I use this version a few month with my 2 Rf Bridges.

from rf-bridge-efm8bb1.

Sonoff RF Bridge 433 - R2 V1.0
Sonoff-Tasmota v6.5.0
RF-Bridge-EFM8BB1-20181127.hex

It happened again :(

I can access it via http, I can send RfRaw 177 but it does not beep

08:14:13 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"} 08:14:48 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"} 08:15:08 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"} 08:16:49 CMD: rfraw 177 08:16:49 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"} 08:17:10 CMD: rfraw 177 08:17:10 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"} 08:20:02 MQT: tele/sonoff/STATE = {"Time":"2019-05-05T08:20:02","Uptime":"0T13:46:20","Vcc":3.174,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":50,"Wifi":{"AP":1,"SSId":"NET2.4GHz","BSSId":"F8:94:E6:FA:B4:47","Channel":2,"RSSI":100,"LinkCount":1,"Downtime":"0T00:00:03"}} 08:20:55 CMD: rfraw 177 08:20:55 MQT: stat/sonoff/RESULT = {"RfRaw":"ON"}`

@Portisch could be a hardware issue with my RF bridge?

from rf-bridge-efm8bb1.

I can confirm I suffer from the same issue, after several days of working properly.
Exactly the same as described in previous posts.
tasmota v6.5.0 + Portisch

After power cycle it works again but only few transmissions. Then it stops completely, does not receive signal even from native Sonoff Rf fob.

Certainly not an issue with rf bridge hardware as I have 2 and tested both. The same behavior.

from rf-bridge-efm8bb1.

I'm having the exact same issues as described above. I send RF raw codes over MQTT to Sonoff RF Bridge R2 with Tasmota v8.1.0 flashed with Portisch firmware. After a power cycle of the bridge I can send a few codes, then after a few hours the EFM8BB1 stops responding to the RawRF codes I send - a reboot of the devices has no effect - I need to do a full physical power cycle of the bridge before the RF chip starts responding again.

Did anyone come up with a solution to this? Some kind of combination of Tasmota version + Portisch version? The codes I send are for my Dooya binds:

Ex.:
"RfRaw AA B0 35 05 08 12FC 05DC 02D0 017C 22B0 0123322323233223233223323232233232233232232323232332322323323232233232322332323224 55"

This issues is making my bridge useless for the purpose of automatic blinds, so I would love to know how to fix this!

from rf-bridge-efm8bb1.

@troelssiggaard Have you checked if Tasmota doesn't complain about blank spaces?
Have you tried: "RfRaw AAB035050812FC05DC02D0017C22B0012332232323322323322332323223323223323223232323233232232332323223323232233232322455"?
@Jason2866 @Portisch

from rf-bridge-efm8bb1.

@troelssiggaard Have you checked if Tasmota doesn't complain about blank spaces?
Have you tried: "RfRaw AAB035050812FC05DC02D0017C22B0012332232323322323322332323223323223323223232323233232232332323223323232233232322455"?
@Jason2866 @Portisch
@gerardovf
I mean, it works for some time, so I don't see why some spaces would make it not work eventually.

from rf-bridge-efm8bb1.

@troelssiggaard Have you checked if Tasmota doesn't complain about blank spaces?
Have you tried: "RfRaw AAB035050812FC05DC02D0017C22B0012332232323322323322332323223323223323223232323233232232332323223323232233232322455"?
@Jason2866 @Portisch
@gerardovf
I mean, it works for some time, so I don't see why some spaces would make it not work eventually.

You're right! In file 'xdrv_06_snfbridge.ino': SerialSendRaw(RemoveSpace(XdrvMailbox.data));

from rf-bridge-efm8bb1.

This does mean Tasmota does remove white spaces and the are no problem.
It seems not every Portisch firmware is stable with Rf raw. Try the one (is not the latest)
from Tasmota github https://github.com/arendst/Tasmota/blob/development/tools/fw_efm8bb1/RF-Bridge-EFM8BB1-20181127.hex

from rf-bridge-efm8bb1.

@Jason2866 That is the Portisch hex that I've used. But have tried several versions...

from rf-bridge-efm8bb1.

Sorry cant help any further. My two RF Bridges do run several month without a problem.
I use rf raw too.

from rf-bridge-efm8bb1.

Same here.
Installed tasmota 8.xxx and portisch on my second rfbridge.
As soon as I send a rfraw with data the bridge blocks and needs a power restart. The command does not create the rf putput.
My old rfbridge accepts these command without any problem.

from rf-bridge-efm8bb1.

Same here.
Installed tasmota 8.xxx and portisch on my second rfbridge.
As soon as I send a rfraw with data the bridge blocks and needs a power restart. The command does not create the rf putput.
My old rfbridge accepts these command without any problem.

No problem on my bridge (Tasmota 8.1.0.4). Maybe has to do with the messages you are sending? (length,...)

from rf-bridge-efm8bb1.

Not solved. The bridge still gets blocked after some unpredictable time (hours or day). The webui is still working but the sending/receiving gets blocked. Only a power down/up restarts the bridge.
I am sending rfraw Commands 2 times with a 1 sec delay To make sure that they get received at the receiving end.
Should I use a bigger delay between 2 transmits ?
What is the recommended delay between 2 transmits ?

from rf-bridge-efm8bb1.

Suffering from same issue here: have to do a power cycle for the rfraw commands to work again

from rf-bridge-efm8bb1.

The same. Is it hardware issue with new Sonoff RF revisions?

from rf-bridge-efm8bb1.

@Jason2866 are you sure that the version which you recommend is a not the latest?
RF-Bridge-EFM8BB1-20190220.hex it is a latest Portisch fw 0x04.

from rf-bridge-efm8bb1.

The build numbering is not changed always. We deleted the version in Tasmota github which haf problems with rfraw. You can try the others too.

from rf-bridge-efm8bb1.

I also face the same problem with Tasmota 9.1. Apparently, the issue should be reopened.

from rf-bridge-efm8bb1.

@lustyffh try to flash version which recommends @Jason2866. For me it works like a charm more than 3 months!

I just forgot to wrote a comment that @Jason2866 recommendation helpful.

from rf-bridge-efm8bb1.

Hi, Have the same issue. I have to do a power cycle for the rfraw commands to work again. The link of @Jason2866 is not availabe. van you help me with the working flash version?

from rf-bridge-efm8bb1.

Thank you, I will try

from rf-bridge-efm8bb1.

@lustyffh try to flash version which recommends @Jason2866. For me it works like a charm more than 3 months!

Hi, just writing to confirm that this fix works indeed. 2 weeks now without a single halt.

from rf-bridge-efm8bb1.

Works fine for me too. Thanks

from rf-bridge-efm8bb1.