Have to reflash Sonoff RF Bridge after loosing WiFi connection

Theengs OpenMQTTGateway Sonoff RF Bridge (SRFB)
1

Hello,

I have a strange behavior on my Sonoff RF Bridges. At some point when they loose the connection to WiFi I have to reflash them to get them working again. Not only reflash, but erase first and then flash again. Just power cycling does not help. After reflashing I can power cycle them without issues, this only seems to appear after some time.

When I connect the not working RF bridges to my FTDI adapter, after a while I get the message “Try connecting to AP1” (or soemthing like that) on the serial monitor (then “AP2”, “AP3”…). It looks to me as if somehow the bridge “forgot” the WiFi settings. Unfortunatly I have no serial output for when the issue is appearing. Usually the bridge is not near a PC and is powered by USB. Is there a possibility to get OMG to log to a syslog server or something like that?

I applied the pilight hack to both of my RF bridges, but I had the same issue just using it without. I use VSCode with PlatformIO to compile and flash. Currently I am on the development branch and use the following environment settings:

[wifi]
build_flags =
    '-DESPWifiManualSetup="true"'
    '-Dwifi_ssid="mySSID"'
    '-Dwifi_password="myPASS"'

[RF]
build_flags = 
    '-DRF_EMITTER_GPIO=5'
    '-DRF_RECEIVER_GPIO=4'
    '-DRF_WS_RECEIVER_GPIO=4'

[env:rfbridge-RF]
monitor_speed = ${common.monitor_speed}
platform = ${com.esp8266_platform}
board = esp8285
lib_deps =
  ${com-esp.lib_deps}
  ${libraries.esppilight}
  ${libraries.esp8266_mdns}
  ${libraries.newremoteswitch}
  ${libraries.rc-switch}
  ${libraries.smartrc-cc1101-driver-lib}
  ${libraries.rfWeatherStation}
build_flags =
  ${com-esp.build_flags}
  ${RF.build_flags}
  ${wifi.build_flags}
  '-DZgatewayRF="RF"'
  '-DGateway_Name="OpenMQTTGateway_RF"'
  '-DZradioCC1101="CC1101"'
board_build.flash_mode = dout

I will try to flash one of my RF bridges using the master branch to rule out issues with the development branch. Is there anything else I can do to solve this issue? Has someone a hint what could probably cause this issue?

2

I don’t know. My two Sonoff Rf bridges have been rock solid the last 1,5 year. But they are still on 0.91.

3

If you use RF gateway you don’t need those libraries.

You can also remove:

Maybe it could help.

4

Thanks, I will try that.

These libraries are leftovers from my first test. I tried out different setups (SRFB, RF, RF2 and Pilight) and then simply did not remove them (mostly because I was unsure what to remove). I now removed the libraries and updated my RF bridges. Let’s see if the issues are gone. Unfortunatly this issues are not reproducable. I’m still not sure, what exactly is causing it. Last week i had to restart my Wifi and Mosquitto and I ran into these issues. Power cyclig them (after re-flash) is ot affecting them, also if I do this some hours later. I’ll try to find out more.

5

Today I had the issue again on one of my RFBridges, the other one is up and running. I set the log-level to trace and connected to the serial monitor. There I got the following output:

N: Attempting Wifi connection with saved AP: 0
N: Attempting Wifi connection with saved AP: 1
N: Attempting Wifi connection with saved AP: 2
N: Attempting Wifi connection with saved AP: 3
N: Attempting Wifi connection with saved AP: 4
T: .
W: disconnection_handling, failed 1 times
W: Attempt to reinit wifi: 0
T: .
....
W: disconnection_handling, failed 20 times
W: Attempt to reinit wifi: 0
T: .
W: disconnection_handling, failed 21 times
W: Wifi Protocol changed to WIFI_11G: 2
W: ESP8266: Forcing to wifi 2
T: .
W: disconnection_handling, failed 22 times
W: Wifi Protocol changed to WIFI_11G: 2
W: ESP8266: Forcing to wifi 2
T: .
...

The last 4 lines are then repeated over and over. I canceled it after the counter reached 700 and re-falshed my bridge (=erase flash and the flash again). After that it was able to connect again.

As far as I can tell this happens, when the RFBridge looses it’s wifi connection. It then is able to reconnect again, but after some time the connection is lost again. This goes on for some time, but at some point it doesn’t reconnect. This process of connect and disconnect goes on for about 1:30 hours and then “it’s dead, Jim!” and I have to re-flash (=erase and flash) it.

What I will try next, is to put it in a different location. The RFBridge currently connects to a repeater or an access point (depending on what signal is availalbe). Maybe it doesn’t handle it very well when one of them drops the connection (or it doesn’t like how the “Fritz!Box” handles the mesh-network). I will try and place it, where it’s near my main router and connects only to it. If anyone has any other ideas that would be much appreciated.

6

Does your repeater is b / g / n compatible on 2.4Ghz?

7

It is compatible, but it’s set to n+g only.

8

Would it be possible to set it to bgn and see if you get the same behaviour, I suspect that the gateway gets stuck in B mode.

9

I can try. I changed this some time ago, but I can’t remember why. I think I ran into some issues somewhere (hot related to OMG).

Edit: After changing the WiFi both RFBridges went offline and online a few times and then stayed offline. But after power cycling them, they came back online again.

10

And now do they stay online ?

11

For now they stay online, but as i said, this issue only occurs after some time. I have to watch them and see how it goes.

12

Hi all, happy to find I‘m not alone with this problem. Got an Avatto IR Gateway last days and have the exact same behavior. After reflashing it is connected to my wlan network for a few hours. After that I got the same messages in the serial Monitor.
This is not the only OMG Device I use, but the others have older version flashed.
This evening I flashed the precompiled binary instead the version the self-compiled variant, will see if it changes anything.

13

@DigiH Hello,

Are you getting this problem also with the Avatto IR board?

14

Hi @Noobud,

Could you detail your network configuration (mesh, repeater, simple router, brand model…)

15

No, I was just going to reply to @Noobud as well. Since I have flashed my initial Avatto with 0.9.5 when it came out, 5-6 days ago?!, it was up constantly, with the uptime showing the same. Only today, when I finalised my OTA setting and did several OTA update tests the Avattos were reset.

I am using

‘-DESPWifiManualSetup=true’

so no WiFi Mangaer functionality, also I assign satic IPs through DHCP on my router. Not sure if that woudl make a difference.

Also with the initial wired flash of 0.9.5 I used

board_build.ldscript = eagle.flash.1m64.ld

Oh yes, and I commented out

; ‘-DZmqttDiscovery=“HADiscovery”’

in [com-esp] as I don’treally need it, with everything being textually configured in my setups.

Other than the above everything is standard.

1 Like
16

Thank you all, I’ll try to answer your questions.
My Routers and Repeaters are all AVM Fritz Devices (Fritz!Box 7490, Fritz!Repeater 1750E, Fritz!Repeater 3000 and Fritz!Powerline 1260E). The IR Gateway is 2m away from the Fritz!Repeater 3000. The Wlan is a Mesh, the Repeaters are connected via ethernet to the Fritz!Box. Firmware on all devices is Fritz!OS 7.20/7.21.
The WLAN Settings are “automatic”. I think 2.4 GHz in this setting is g/n without b. But I’m not sure.

I’ve tried to compile OMG in different variants. With manual Wifi, Wifi Manager, different ldscript settings. The last config is this:

[env:avatto-bakeey-ir]
platform = ${com.esp8266_platform}
board = esp01_1m
board_build.ldscript = eagle.flash.1m.ld
lib_deps =
  ${com-esp.lib_deps}
  ${libraries.irremoteesp}
  ${libraries.esp8266_mdns}
build_flags = 
  ${com-esp.build_flags}
  '-DZgatewayIR="IR"'
  '-DTRIGGER_GPIO=13'
  '-DLED_SEND=4'
  '-DIR_EMITTER_GPIO=14'
  '-DIR_RECEIVER_GPIO=5'
  '-DGateway_Name="OpenMQTTGateway_AVATTO_IR"'
  '-DESPWifiManualSetup="true"'
  '-Dwifi_ssid="WLANName"'
  '-Dwifi_password="secret"'
  '-DMQTT_SERVER="mqttserverhostname"'
  '-DMQTT_USER=""'
  '-DMQTT_PASS=""'  
board_build.flash_mode = dout

All other things are standard settings. But still no difference to all the other tries.

17

It looks like the situation has improoved a little, at least for me. I’m not sure it it was switching WiFi to bgn, or fashing the latest dev-branch (v0.9.5). This morning both of my RF bridges where offline. It seems that at some point they lost the WiFi connection (as did some other devices), but were not able to restore it. The strange thing is, that one of them (the one that connects to my Fritz!Powerline 1260E), was able to reconnect at first, but then did it’s onnline-offline thing again for about 30 minutes and then stayed offline for 3 hours, then did the online-offline thing again for about 20 minutes, and then it stayed offline again until I power cycled it.

18

Seems that we have something going wrong with the Fritzbox router/repeaters.
Let me think about it and I will propose a test version for this kind of configuration.

19

@Noobud, have you tried OTA updates with this ldscript setting? I tried it with the same before, and had some issues with OTA updates not working correctly, and with

‘-DESPWifiManualSetup=“true”’

I found that

board_build.ldscript = eagle.flash.1m64.ld

gives me more than enough space for OTA updates, which work fine all the time now. Not too sure how much the 0Kb spiff partition with eagle.flash.1m.ld was affecting this.

20

Hi @DigiH
No I don’t tried it because the WiFi Disconnection problems. Flashed with 1m64.ld now, will see…