ESP32 freezes after first bot command

[phenix1990]

Hi,

thanks for the great work.

When I activate getBotResponse it takes several seconds before my bot reacts. After that the LED (only active while while command) stays on and after some time ESP lastwill goes to offline. I always can send only one command.

When i deactivate getBotResponse its super fast and i can send multiple commands. But would be really good to have a feedback. I also would process the "success" status myself, but with deactivation I only get status "connecting" or "commandSent".

Is it possible to just get the status, without the ESP32 is waiting for something? I got bot firmware 4.9, maybe its also related to a new firmware version? (dont know the release date of 4.9)

[devWaves]

the issue is probably the NimBLE library. 1.3.8 breaks that functionality. Use version 1.3.7

the response is used in the code so the esp32 can retry on failed attempts or busy responses

[pixelpox]

Hi,

I was experiencing the same issue. Making sure that nimBLE is at 1.3.7 seems to have fixed the issue for me.

Thanks for the question and answer :)

[1liminal1]

Such a shame, this was so stable until I I wanted to change it to press buttons, not on off.

So Ive changed NimBLE to 1.3.7 and its still crashing, now when I close a curtain.

So I just need to change this and then recompile/ upload to device? Nothing else?

So clearly Im doing this wrong. How do I roll back a library?

Thanks :)

[devWaves]

@1liminal1 using the program mqtt explorer, delete all relevant mqtt topics before turning on the esp32. the mqtt auto discovery topics may be messing things up if you used the MACs with different names a few times when testing

if platform io is giving issues, try arduino. the libaries work a bit differentely. It looks like u have 1.3.7 NimBLE but could be arduino core stuff also giving u issues

[1liminal1]

Thanks mate,

Appreciate it!

I have cleaned up MQTT

But it appears to be the PSU, so I've changed that out.

Just testing over the next 24

Thanks again for getting back so quick, I'm pretty reliant on this now LOL

[broyuken]

Just chiming in on this, I ran into the same issues. I'm also on 1.3.7 for NimBLE. I cleared out mqtt explorer and will continue to monitor as well. I am extremely reliant on this, as it makes my coffee in the morning 5 minutes before my alarm goes off :)

It was working fine for weeks, not sure why its suddenly crapping out and going unavailable in home assistant. Hopefully clearing out the mqtt topics fixes it.

[phenix1990]

update from my side: i also wasnt able to make this run with 1.3.7 NimBLE and getBotResponse activated. But it was good enough for me to have it running without the exact state.

But my problem is that also that it is working for a while an suddenly the bridge goes offline. As I also open the house door with it i need a 100% reliable system. Now i just send the bluethooth command to trigger the bots direct from raspberry pi but also this stopped working for one of the bots, dont know why. Signal strenght is about 70, should be ok.

Now im thinking of buying the bridge from switchbot.

[devWaves]

@phenix1990 if you are using extra long device names and/or MQTT topics names try with the default names. some people have said they had issues with long names, but I personally haven't been able to reproduce that.

You should not need to change any of the advanced settings to get up an going.

You can always try the Arduino IDE if you can't get it going with PlatformIO.

If you are also getting issues with sending the BLE commands directly from a RPi then a switchbot bridge probably won't solve those issue. It will also go through the internet with the bridge instead of all locally

[broyuken]

Mine started going offline after running a few commands again. It’s not a long name, switchbothub01 so that’s not it, it was running stable for the longest time, then I hit a power issue and fried my esp32. I replaced it with a new board and this one’s been having issues. Are there certain esp32 boards that work better than others?

[devWaves]

@broyuken I have used 3 different types of esp32 dev boards for this project. I havent tried with the newer s2/s3 model ones, just the basic esp32 wroom

What model do you have? I have used the wemos d1 mini esp32, the esp32-wroom-32U with external antenna, and the quinled esp32 with external antenna. All work for me

Have u tried using the esp32 for something else like tasmota or esphome? I did have an esp32 that read a very high temp when I installed tasmota once, but I broke the usb port on it. That situation could cause issues of it overheating?

[broyuken]

This is the one I’ve been having trouble with. I also have a hiletgo one and that seems to work fine.

3PCS ESP32 ESP-32S WiFi Development Board Unassembled NodeMCU ESP32S Microcontroller Processor Integrated Chip CP2102 https://a.co/d/fIQ366r

[devWaves]

@broyuken ok so I did some quick googling but haven't found the exact info as there is a lot of misleading info

the ones that I have all use the ESP-WROOM-32 variation, the one you have issues with is the esp32s. I havent found the exact diff between the esp33 wroom and the esp32s, but it sounds like the esp32 wroom is the espressif version and esp32s is ai-thinker?

esp32 wroom datasheet https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32_datasheet_en.pdf

esp32s datasheet https://www.es.co.th/Schemetic/PDF/ESP32.PDF

There also exists esp32-solo which is single core which probably wont work and the esp32-s2 which has no bluetooth and 2 cores with diff speeds. also the c3 which has less rom/ram and s3 which is BLE 5

I have updated my documentation to let people know to get the wroom version as I know that one works

[phenix1990]

I bought now a new esp32 wroom 32u due to the external antenna but same problem here, with default settings it's sending one command and then going offline.

I just changed wifi and mqtt settings for connection and added 2 bots. I let all other settings unchanged.

Really strange. I saw a parameter for debugging, but cant get any content when starting serial monitor. Anything else to do in the settings?

[devWaves]

@phenix1990 ur positive ur using NimBLE 1.3.7? sending one command and the esp32 stopping is exactly what having version 1.3.8 does

If u have the debugging set to true and the esp32 is flashed, unplug then replug the esp32 in and then open the serial monitor. Sometimes the serial monitor only works if u open it afterwards. and Baud rate in serial monitor needs to be set to 115200

I have many esp32-wroom-32u so I know that one works

if using arduino u can delete all the libraries from Documents/Arduino/libraries if u want to start fresh

if you are using platformIO, I updated the platformio.ini file to specifically pull only version 1.3.7 NimBLE and not anything above 1.3.7

[devWaves]

v6.12 solves the NimBLE v1.3.8, v1.4.0 issues