ESP32 Becomes Unresponsive / Locks-Up / Drops WIFI / Needs Reboot

[Brummy]

For whatever reason, My ESP32 seems to stop working randomly. Sometimes once a day, sometimes multiple time, sometimes it'll go a few days. I have to power cycle it to get it running again.

Is this a Blerry issue? A Tasmota issue? A user issue!?

I'm using a NodeMCU-type ESP32 Devkit board. Haven't had any similar problems with other uses of it with just Tasmota. A buddy that also started using Blerry has had similar issues.

I'm running 7 InkBird TH2 sensors right now (problem started when I only had one a couple of weeks ago).
Thanks,
Brummy

[tony-fav]

I don't have time for a full response to this at the moment but can you try SetOption57 0 and report back if your average uptime improves? Also, jump in digiblur's discord for live help from a bunch of users and myself!

[Brummy]

Thanks,
DigiBlur recommended trying the dev version of Tasmota Bluetooth. I switched to that. If it doesn't work, I'll try SO 57 0.
Will let you know either way.
Appreciate the response.
-Brummy

[tony-fav]

My longer thought is that it's asking a lot of the radio to 1) deal with the regular wifi connection, 2) deal with BLE passive and active scans, then 3) do a scan of available networks. You could run into power supply issues or just random issues that cause the radio to seize. I have not been able to reproduce the issue on a dev-board myself. So, your update will be greatly appreciated!

However, I did have an ESP32 plug (Wyze WLPP1CFH) that was showing similar behavior, uptimes of ~1 day. Turning SO57 off, and I hit 10 days before I restarted stuff for an unrelated reason.

[Brummy]

I've asked a buddy that's having the same issue try the SO57 option. Will go a day or three and follow up (sooner if he or I see similar problems).

[osaether]

I have experienced this as well. I am using the TTGO T7 V1.5 ESP32 module and two Inkbird IBS-TH2 sensors.

[micahvandeusen]

I’m having the same problem. I have 4 Shelly 1 Plus with Tasmota32 solo1 BLE and thermostat either version 10.1.0.2 or 10.1.0.1. Most have only 1 sensor it is reading. They can go several days without issues and then require a reboot to start responding again. I’ll try the above option and report back if it’s not fixed.

[Brummy]

The dev version of Tasmota lasted about 40 hours before the problem popped back up.

My buddy had it pop up with SO57 0 on the latest release version shortly after making that change.

I'll try a different controller with only one inkbird on it.

I'll also use a different flashing tool than Chrome, but don't think that really matters.

[tony-fav]

Since you are using a development board, were you able to capture serial log data to see what's happening? Like I said, I have been unable to reproduce the issue locally. If we are to propose to the Tasmota devs that there is an issue somewhere, we need log data.

[digiblur]

I'll set up a couple here on the latest dev build and dump them to a file. I'll do some dev boards of various ones with the same files on various sensor types.

[devzwf]

I was not able to reproduce as well.
i am running both dev branch and release branch at the moment
with C3 and dev board
both with : {"SetOption57":"ON"}

of course with blerry
let me know if i can help

they all have to monitor :
about 5 to 7 PVVX
2 govee
2 Inkbird

[Brummy]

Pardon my lack of experience posting in github and the format.
Here's what I found from the time it last stopped working (2 log entries from today - is this what you need?):

First log entry found

Logger: homeassistant.components.mqtt
Source: components/mqtt/init.py:963
Integration: MQTT (documentation, issues)
First occurred: December 31, 2021, 4:57:18 AM (13 occurrences)
Last logged: 4:27:40 AM

Disconnected from MQTT server 192.168.1.216:1883 (7)

Second log entry found

Logger: paho.mqtt.client
Source: /usr/local/lib/python3.9/site-packages/paho/mqtt/client.py:2529
First occurred: December 31, 2021, 4:57:18 AM (13 occurrences)
Last logged: 4:27:40 AM

failed to receive on socket: [Errno 104] Connection reset by peer

[digiblur]

I think the log we are talking about is from Tasmota. I was going to drop the log via syslog to a file.

[devzwf]

@Brummy need to log from the device
the easiest is to push the log from taz to a syslog server and this way you have it available

edit: whoops digi was faster than me :)

[Brummy]

Thanks @devzwf and @digiblur
I've never used syslog, but just figured out how to set it up. I'll be ready next time it goes down.
Good thing about problems is it is an opportunity to learn new tools.

[hurricanepkt]

Just wanted to throw this in here. I've experienced the same issue with what i assume is the same device. Would additional logs be of use or a distraction?

[tony-fav]

Trying it. Crashed shortly after I set it up but that may have been the controller (reset to default Tasmota AP for setting up) Just redid it, so we'll see. Can't serial log right now but will get it hooked up shortly.

If you can, do an erase flash then flash latest dev. Jason2866 mentioned on a Tasmota issue that somehow some things that were screwing with BLE stability on old frameworks didn't get taken care of by an OTA and Reset 1 but did with a full flash erase.

[gdavidp]

I threw on this version on to one of my ESP32s with the standard Rule1 and Blerry:

Program Version	2022.01.3(bluetooth)
Build Date & Time	2022-01-19T22:07:21
Core/SDK Version	2_0_2/v4.4-2.0.2

I did erase the flash so it should have been a blank slate, will update if goes down.

[bschatzow]

Good timing, mine crashed last night after 48 hours. Trying it now.

[micahvandeusen]

Had a Shelly plus 1 crash with the new firmware. However I didn’t clear flash.

[gdavidp]

Newest Tasmota DEV firmware does not do anything for me, it is in this usual loop, displaying this every second:

15:21:05.282 WIF: Connect failed as AP cannot be reached

[osaether]

I erased the device and flashed the new FW above today and it became unresponsive after about one hour.

[BFLK]

I am using a so called ESP-32 D1 mini as a MQTT gateway for some Xiaomi BLE sensors and I think I am facing the same issue after upgrading Tasmota from 9.5.0 to 10.1.0. The device is unresponsive (MQTT and HTTP) and the issue is solved after a power reset - however it reoccurs after 1-2 days. I will rollback to 9.5.0 but it would be good if someone will be able to understand and mitigate this issue.

[BFLK]

I am using tasmota32-bluetooth.bin (the pre-compiled one) and for the Xiaomi Temperature and Humidity sensors I replaced the original firmware with the ATC one. There was no configuration needed on Tasmota side besides of the MQTT settings and enabling BLE. If there's a way to understand if I am using Blerry or the source level Tasmota driver, I'd be happy to check.

When checking the information section again, I realized that the press of the reset button is not the same as the power reset: Restart Reason | Software reset CPU

[tony-fav]

The repository you are in is for a project which uses Tasmota but is not Tasmota. If you are using stock Tasmota but not the project in this repository, please try to open a Tasmota issue on the Tasmota repository https://github.com/arendst/Tasmota/issues/new?assignees=&labels=&template=Bug_report.md

[BFLK]

I just realized the error. I was just googling around in order to understand this issue and I reached this topic. One way or another I managed to miss the fact that it was not in the Tasmota repository. Sorry for loosing your time and thank a lot for the fast replies. Have a nice evening!

[tony-fav]

It's actually great (for us) that you are getting the error NOT using this repo! Kind of another reason to believe that it's not this projects fault ;-) Thanks for doing the issue report if you get to it!

[BFLK]

I've raised an issue: arendst/Tasmota#14583

[micahvandeusen]

So was it stable with 9.5.0? That might mean it was something in a recent version?

[BFLK]

Yes, it was stable for a long time 9.5.0 as I don't recall ever resetting the device. Something to add, after reading this topic, I just pressed the reset button on the ESP-32 D1 mini and it recovered - I don't know if this is in any way different from a power reset. Something that I didn't state in the initial post is that I'm using the Tasmota32-bluetooth build.

[micahvandeusen]

The nightly reboot timer worked as a mitigation for the unresponsive/wifi dropping issue on my Shelly plus 1s. That is until just recently I had one of them go offline.

I tried the latest dev version of Tasmota (11.0.0.4) doing an OTA upgrade from https://github.com/tasmota/install/blob/main/firmware/unofficial/tasmota32solo1-bluetooth.bin?raw=true and I think it fixed the problem as I haven’t had any issues so far without the reboot timer.

[Brummy]

I've not replied lately. Kinda gave up and just used a smart plug with a Node Red automation to address the problem. Works good enough.
A couple of weeks ago I used one of the ESP32 I had trouble with before to set up two more InkBirds for my garden seedling nursery. Used the new version of Blerry and it's been working great.
I'm not logging it, but I do see the boot count increasing, but due to software resets. It appears the new version overcomes possible Tasmota (11.0.0.3) challenges.
Thanks again Tony!

[iLeftheris]

After firmware upgrade to 11.0.0.4(bluetooth) my ESP32-D0WDQ6 is working continuously for 48 hours
2 ATCpvvx devices with SetOption57 1

[patrickdk77]

Same here on 11.0.0.3 no reboots since it upgraded 15days ago
11.0.0.1 though still only 5days max I see

[BFLK]

The issue is not reproducible anymore in Tasmota v11.0.0 Olivia, so it was for sure something from upstream, and not tasmota-blerry. I now have 9days and 16hours of uptime on my ESP-32 D1 mini.

[tony-fav]

Really glad to hear the latest Tasmota is stable without custom compiles! I am also working on a compatibility layer to use the new BLE driver that's being developed, and it is working great!

[ceinmart]

Hi!

I'm quite new to using ESP devices...
Trying to do my BLE Tracker using the Tasmota instead ESPHome , since Tasmota appears to be more "friendly"...

So, I have a ESP32-DevKit (ESP32-wroom-32) , with last Tasmota version 13.2.0(bluetooth).
The berry appears to be installed successfully, at least after running the script to return the message that was installed.

However, I got into the issue where my ESP began to restart without stop, 2-3 seconds after boot, restarted again.
I set it to 4 level debug to serial and got this : **Guru Meditation Error: Core 1 panic'ed (IntegerDivideByZero). Exception was unhandled.
**
Have no BLE device configured yet... could this be the reason? or some code flaws?
Is there a way to enable a code debug and dump at serial, to show where they are trying to divide by zero?

3:10:55.347 CFG: Saved, Count 395, Bytes 4096
13:10:58.918 MQT: tasmota/discovery/xxxxxxx/config = {"ip":"xxxxxx","dn":"esp32_ble_tracker1","fn":["esp32_ble_tracker1",null,null,null,null,null,null,null],"hn":"esp32-ble-tracker1-1840","mac":"xxxxxxx","md":"ESP32-DevKit","ty":0,"if":0,"ofln":"Offline","onln":"Online","state":["OFF","ON","TOGGLE","HOLD"],"sw":"13.2.0","t":"esp32_ble_tracker1","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1],"swn":[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null],"btn":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"so":{"4":0,"11":0,"13":0,"17":0,"20":0,"30":0,"68":0,"73":0,"82":0,"114":0,"117":0},"lk":0,"lt_st":0,"bat":0,"dslp":0,"sho":[],"sht":[],"ver":1} (retained)
13:10:59.010 MQT: tasmota/discovery/xxxxxxx/sensors = {"sn":{"Time":"2023-11-03T13:10:59"},"ver":1} (retained)
Guru Meditation Error: Core  1 panic'ed (IntegerDivideByZero). Exception was unhandled.

Core  1 register dump:
PC      : 0x400eebbc  PS      : 0x00060c30  A0      : 0x800f061e  A1      : 0x3ffd3de0  
A2      : 0x00000001  A3      : 0x3ffd5ba0  A4      : 0x00000000  A5      : 0x00000018  
A6      : 0x00000001  A7      : 0x00000001  A8      : 0x3ffd5bb8  A9      : 0x00000001  
A10     : 0x3ffd0c8c  A11     : 0x3ffd5bd0  A12     : 0x0000aec5  A13     : 0x3ffd5bc0  
A14     : 0x00000008  A15     : 0x3ffd3dd0  SAR     : 0x0000000a  EXCCAUSE: 0x00000006  
EXCVADDR: 0x00000000  LBEG    : 0x40095eb1  LEND    : 0x40095ec1  LCOUNT  : 0xffffffff  


Backtrace: 0x400eebb9:0x3ffd3de0 0x400f061b:0x3ffd3ea0 0x400f1abd:0x3ffd3ec0 0x400f1e2e:0x3ffd3ee0 0x400f2b43:0x3ffd3f60 0x4012834c:0x3ffd3fa0 0x4012aec1:0x3ffd3fd0 0x4011798d:0x3ffd3ff0 0x401525a2:0x3ffd4010 0x4015f14e:0x3ffd4030 0x400e57af:0x3ffd40a0




ELF file SHA256: 0000000000000000

Rebooting...

[devzwf]

Please try with tasmota v11.x train
and not tasmota v13.x.x for your sanity

[ceinmart]

Thanks @devzwf , I did the downgrade, and is running for couple hours without issues.
This version also shows the ESP temperature, which tasmota v13 didn't...
Appears to run smoothly ...