ESP32s Disconnecting after a while when using BLE.

[maxi1134]

Before submitting a problem please check the troubleshooting section https://github.com/1technophile/OpenMQTTGateway/wiki/Troubleshooting

Describe the bug I fresh-install OMG (0.93) and plug 5 ESP32s around the house.

They report/detect my watch for a while. They also have a blinking led on them.

After a while, they disconnect from the Wifi and MQTT. (Their status on MQTT become Offline and I cannot see them on my Unifi APs connected devices)

To Reproduce Steps to reproduce the behavior:

1. Install OMG on an ESP32 with BLE detection enabled
2. Wait between 2 and 20 hours
3. See disconnected ESP32s

Expected behavior For the esp32s to not disconnect from wifi/mqtt

Screenshots

Environment (please complete the following information):

• OpenMQTTGateway version used (v0.93)

Additional context As you can see in the screenshot, sometimes the ESP32 (Kitchen in this instance) will reconnect for a while before disconnecting again.

I've also tried modifying this line: https://github.com/1technophile/OpenMQTTGateway/blob/a4f571e77e0a9e0e9314160077588c4e9d7ab3b9/User_config.h#L146 But unfortunately, it seems to not be present anymore in the latest version.

What I would really like to know, is if this can be fixed at all on ESP32s. As to know if I should invest in some Raspberry pis to use for room-presence instead of ESP32s!

Thanks for reading!

[1technophile]

Hi,

could you indicate the env used and the type of router please?

[maxi1134]

The Environment used is: default_envs = esp32dev-ble And the router is the USG by Ubiquiti coupled with 3 AC-pro aps.

[1technophile]

Thanks, I suppose that you are using wifimanager to set your credentials, would it be possible to set them with manual config and set your credentials there and report if you get the same behaviour

[maxi1134]

That's already what I've been using.

[wimpie007]

@1technophile Have you ever considered adding a 'force bg' instead of 'bgn' wifi option? I had similar dropouts with my espeasy esps, and the issues were fixed when forcing the modules to use BG only. https://github.com/letscontrolit/ESPEasy/issues/1987 https://git.koehlerweb.org/frodovdr/ESPEasy/commit/6643eb4aaa653476948b25299a92d421e65aa528

[1technophile]

@1technophile Have you ever considered adding a 'force bg' instead of 'bgn' wifi option? I had similar dropouts with my espeasy esps, and the issues were fixed when forcing the modules to use BG only.

Never heard about that, thanks for pointing it. I'm trying to reproduce the issue noticed here, if I succeed I will try this tip

[maxi1134]

@1technophile Are you saying that you are not getting any disconnect on ESP32s?

[1technophile]

For the moment here is the state of my M5stick-c: {"uptime":84064,"freeMem":50168,"rssi":-79,"SSID":"ATT5Yhz4v8","ip":"192.168.1.85","mac":"D8:A0:1D:47:27:7C","modules":"ONOFFIRBTGPIOInputHADiscovery"}

let's see how it goes

[1technophile]

The sitck reached: {"uptime":171804,"freeMem":49924,"rssi":-73,"SSID":"ATT5Yhz4v8","ip":"192.168.1.85","mac":"D8:A0:1D:47:27:7C","modules":"ONOFFIRBTGPIOInputHADiscovery"} 47 hours

After this it reconnected automaticaly: {"uptime":2040,"freeMem":54552,"rssi":-70,"SSID":"ATT5Yhz4v8","ip":"192.168.1.85","mac":"D8:A0:1D:47:27:7C","modules":"ONOFFIRBTGPIOInputHADiscovery"} I will try the tip given by @wimpie007 and see how it goes

[1technophile]

@maxi1134 could you try with this branch please: https://github.com/1technophile/OpenMQTTGateway/tree/force_wifi_b_esp32

So as to see if the ESP32 automaticaly reconnects

[maxi1134]

I am trying to run it but get the ESP32 won't connect anymore to the Wifi. I think that perhaps my B/G is disabled. I am investigating.

This is the error code I receive: WM: [0] [ERROR] Connect to new AP FailedWM: [2] [EVENT] WIFI_REASON: 203

I used Wifi manager since manual settings didn't worked.

Edit: Got it to run, I'll let it run until it crashes and report back!

[1technophile]

ok thanks for the feedback.

As a second test you could also try with the development branch to set a static IP so as to don't use DHCP (mentionned here as a potential solution)

[maxi1134]

Update:

They are now been running for over 36 hours with no permanent crash. They did disconnect sometimes but always reconnected.

I will update once they reach 80 hours without issues.

[1technophile]

That's a good news! Thanks for your feedback.

[maxi1134]

They are now up for 80 hours. I believe that the use of the B band solved my issue completely.

Thanks a lot! I can finally get to work on automations using this!

[1technophile]

Great, If you don't mind, I'm going to implement the modification differently ; if the esp is not able to reconnect, try to connect with the b band. When it is done would you be ok test it ?

[maxi1134]

I would be happy to test it out once it is coded!

I can set it on a couple of my ESP32s and see if it is stable as just using the B band.

I'm also experimenting with multiple scan intervals to see if that affects the stability. But so far anything between 60 and 55555 seems to work while using the B band.

[wimpie007]

Great that BG option works. :) I would prefer a fixed "use BG instead of BGN" option: that way, we KNOW what is going on instead of an automatic option. (but the automatic option doesn't exclude the 'forced' one of course) regards and thanks for OMG!!

[1technophile]

Thanks for having found the issue @wimpie007 !

Yes we could code it this way:

• automatic per default (if reconnection not working go to BG than go to B)
• force B always
• force BG always

Your thoughts?

[wimpie007]

@1technophile perfect! 👌

[wimpie007]

Another remark: this is also an issue with 8266s, not only with ESP32's...

[1technophile]

@maxi1134 & @wimpie007 I have implemented the automatic fallback protocol mechanism here for tests.

Here is how the algorythm works: If never connected to MQTT after 10 attemps reset the board If connected to MQTT and failures > maxConnectionRetry + ATTEMPTS_BEFORE_BG switching to B+G If connected to MQTT and failures > maxConnectionRetry + ATTEMPTS_BEFORE_B switching to B If connected to MQTT and failures > maxConnectionRetry + ATTEMPTS_BEFORE_B + ATTEMPTS_BEFORE_BG switching back to normal mode

If you have time may it be possible to test the modifications?

[1technophile]

First results are quite encouraging

[maxi1134]

@maxi1134 & @wimpie007 I have implemented the automatic fallback protocol mechanism here for tests.

Here is how the algorythm works: If never connected to MQTT after 10 attemps reset the board If connected to MQTT and failures > maxConnectionRetry + ATTEMPTS_BEFORE_BG switching to B+G If connected to MQTT and failures > maxConnectionRetry + ATTEMPTS_BEFORE_B switching to B If connected to MQTT and failures > maxConnectionRetry + ATTEMPTS_BEFORE_B + ATTEMPTS_BEFORE_BG switching back to normal mode

If you have time may it be possible to test the modifications?

I'll try to give it a go very soon! I am having some issues IRL which prevents me from doing involved work on my Automation System. (quick question at the same time, does the OTA works for this? Because This would save me a lot of time while testing new stuff for you! )

[1technophile]

Thanks, OTA should work, here is an example of board definition with OTA:

;esp32 exterieur
[env:esp32dev-ble-ext]
platform = ${com.esp32_platform}
board = esp32dev
board_build.partitions = min_spiffs.csv
lib_deps =
  ${com-esp.lib_deps}
  ${libraries.ble}
build_flags = 
  ${com-esp.build_flags}
  '-DZgatewayBT="BT"'
  '-DGateway_Name="OpenMQTTGateway_ESP32"'
upload_protocol = espota
upload_port = 192.168.1.82
upload_flags =
  --auth=OTAPASSWORD
  --port=8266
upload_speed = 512000

[maxi1134]

Could you let me know what you use for OTA?

I am currently using Atom with PlatformIO but it asks me for an account to use their OTA tool.

[1technophile]

VSC with PlatformIO

[maxi1134]

@maxi1134 & @wimpie007 I have implemented the automatic fallback protocol mechanism here for tests.

The link is not working. If you send me the right one I have an hour in front of me and could try this now.

Gives me a 404 error when trying to access: https://github.com/1technophile/OpenMQTTGateway/tree/force_wifi_b_esp32

[1technophile]

oh yeah sorry, it is now merged into the development branch: https://github.com/1technophile/OpenMQTTGateway

[maxi1134]

Sorry for the delay! Been very stressed with the whole pandemic situation.

I tried compiling the new code but get this when trying ot us emanual wifi configuration:

.pio\build\esp32dev-ble\src\main.ino.cpp.o:(.literal._Z22disconnection_handlingi+0x24): undefined reference toreinit_wifi()' .pio\build\esp32dev-ble\src\main.ino.cpp.o:(.literal._Z10setup_wifiv+0x1c): undefined reference to forceWifiProtocol()' .pio\build\esp32dev-ble\src\main.ino.cpp.o: In functiondisconnection_handling(int)': C:/Users/Maxi/Documents/PlatformIO/OpenMQTTGateway-adaptative_wifi/main/ZgatewayBT.ino:594: undefined reference to reinit_wifi()' .pio\build\esp32dev-ble\src\main.ino.cpp.o: In functionsetup_wifi()': C:/Users/Maxi/Documents/PlatformIO/OpenMQTTGateway-adaptative_wifi/main/ZgatewayBT.ino:594: undefined reference to forceWifiProtocol()'

[1technophile]

Hmm, try to clean your environment maybe (with the little bin in the blue bar) and restart VSC

[sucralos]

Had the same issue as @maxi1134 in the development branch, the functions reinit_wifi() and forceWifiProtocol() are not defined if ESPWifiManualSetup is set. I had to define these to get it to compile (just moved them to separate ifdef and check for ESP32 or ESP8266), and it seems to work with that fix.

[1technophile]

I corrected it in the development branch, I have also bypassed an ESP32 Arduino Framework bug that prevented automatic reconnection one time out of 2. You can test all these changes there: https://github.com/1technophile/OpenMQTTGateway/tree/development

[1technophile]

Hi, do you have some feedback to give about the last modifications?

[sucralos]

Yes, been running three instances on ESP32 for almost 4 days now. No issues what so ever. I have a few wifi disconnects bit during this time but no delay in reconnecting. Well done! :)

[1technophile]

Great, thanks for the feedback!

[1technophile]

I'm closing the issue, if you have comments don't hesitate to add them here and reopen it