BLE and ESP32 dev environment

resolved

#1

Hello,

I see a lot of strugling around BLE function of ESP32, to sump up here is the results of my tests:

The wiki is updated with the good links


#2

I can now confirm that finally it is working ! At least for 24 hours
Thank you !


#3

Hi. I moved on to a Pi Zero W solution. Will try this again some time…


#4

I compiled as described but esp will disconnect from WiFi after a while


#5

How did u proceed, wanna move to raspi too as esp seems unreliable and unstable for the moment


#7

What about the ble temp sensor? Works also with it ?


#9

Please don’t hijack this thread dedicated to ESP32


#10

After how much time the esp is disconnecting?
Was it connected to the serial monitor to have some traces?


#11

HI,

I’m kind puzzled because I got a esp32 working right for almost two weeks after carefully followed those instructions but then I had a few problems with my MQTT (mosquitto) VM and found that my esp32 didnt handled that very well. So I did a git pull and tried the new 0.8 version. Now I’m back to “Task watchdog got triggered. The following tasks did not reset the watchdog in time: - IDLE (CPU 0)”. I didnt upgraded the arduino or any other library (at least, not that i know :slight_smile: ). Did I missed something? Is it possible that the arduino IDE updated a library automatically?


#12

Hi Florian,

Is there any setting that prevents Flora and Jia from being sent to MQTT when the ESP32 is not connected to serial port?

If I connect it to the computer it reads and sends the data to MQTT broker for the two and also for other BLE devices (at a rate of aprox. one read per minute).

However, when removed from the computer (I’ve tried with different 5V/2A power sources), scan works for some BLE devices that are sent to MQTT, but it doesn’t see any Flora or Jia. And LWT has quite a few entries and afterwards total silence. It’s like the damn thing has a mind of its own…

When connected to serial it port worked fine for more than 10 hours; however, on its own doesn’t get more than 20 minutes.

I’m using the libraries from the third option you posted with minimal SPIFFS.

Thanks


#13

Hi @PetricaM

Some questions so as to investigate.
I suppose that in both conditions the esp is located in the same place. When you are powering the esp32 without serial monitor, is it by the usb port ?
Is the board standalone or with sensors ?
Did you try with different boards ?

Regards


#14

Hi, Nope I don’t think so.
Could you give the history of traces in the serial monitor ?


#15

Hi Florian,

ESP32 without computer connection is located in the same area as the computer (less than 1 m radius).

I haven’t tried powering the unit from the USB port of the computer without reading from the serial port. I used two ways of powering: one with a 2.4 A microUSB brick (non detachable cable) from a ESP8266 OMG that I have running for more than one year and the other with the same microUSB cable that I’ve used for connection to serial.

Used with an USB metering, the power supply gives a stable 5.11 V and the board consumption in idle mode is 0.02 - 0.04 A (there’s only two digits on the board) and 0.11-0.12 A when sending payloads to MQTT (voltage decreases to 5.09 - 5.10 V then gets back to 5.11 V after values are received by MQTT).

I only have two different types of boards: ESP32 devkit (about the same size of a ESP8266) and WeMos D1 R32 and they’re giving the same results. I haven’t mounted any sensors (also compiled only BLE gateway, not with other sensors).

Actually I did set a HA statistical sensor for the LWT topic and it seems that also during serial connection the gateway is restarting (only Online and Offline appear in LWT and I see them also in serial, but there isn’t the full reboot sequence). Instead, when the board is independently powered, it doesn’t read any of the Flora or Jia and LWT topic is spammed a few times with Online and Offline. Then, after a while, the gateway is offline (now there are 12 hours since last activity; sometimes it would start again even after a long pause).


#16

Did you had this behaviour with the previous combination of environment/esp32 ble library/omg ?


#17

Hi Florian,

I haven’t used any ESP32 gateways for longer time periods until now as I did not had a stable build (all gateways and sensors that I have are based on ESP8266 or Arduino).

However, I didn’t use WifiManager with any of the ESP8266 and this was the sole modification I’ve initially done also for the ESP32 gateway (in order not to have to keep the wifi password on hand after flashing but rather pasting it directly into the sketch).

This morning I’ve disabled manual setup however did not uncommented CleanFS (so that I won’t need to manually input the wifi password). The next step would have been to try to disable multicore but I think there is no need for that since the board works fine now (connected to a 5V USB charger).

The good news is that I’ve checked the LWT topic and it appears there haven’t been any restart since morning…

Maybe ESP32 doesn’t like wifi manual connection after all?

I’ve checked the power meter yesterday and it was constantly indicating 0.11-0.12 A when the board wasn’t working anymore, although the wireless chipset was nearly cold (haven’t looked in the router log in order to see if it was still online and now the log is cleared :man_facepalming: ).

When working fine there was 0.02 - 0.04 A current draw in normal load and 0.11 - 0.12 A when sending data to MQTT so I think it was trying to reconnect to wifi and kept failing (I think this is consistent with the fact that the current IP lease for ESP32 is active since building it this morning without any downtime and current draw is as observed initially).

I’ll let you know of any development.


#18

Well, the rebel scum stopped working after about 6 hours…

And this is after about 10 minutes connected over serial (didn’t had debug enabled initially)

E (1579007) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (1579007) task_wdt: - IDLE0 (CPU 0)
E (1579007) task_wdt: Tasks currently running:
E (1579007) task_wdt: CPU 0: wifi
E (1579007) task_wdt: CPU 1: loopTask
[E][WiFiClient.cpp:213] connect(): lwip_connect_r: 113
failed, rc=
-2
try again in 5s


#19

You are not the first getting this error … I need to do some research on it.

Thanks for the details @petricam


#20

I have now the serial output:

Activated modules
BT
Get RSSI
OMG_TEst/OMGTest/BTtoMQTT/C47C8D66643F -64
Get service data
service_data
71209800593f64668d7cc40d0910020000
Get service data UUID
0000fe95-0000-1000-8000-00805f9b34fb
Processing BLE device data
mi flora data reading
5
0.00
0
Get Name
Tile
Get RSSI
OMG_TEst/OMGTest/BTtoMQTT/E1ADDF229BB9 -69
Task watchdog got triggered. The following tasks did not reset the watchdog in time:

  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: loopTask
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: loopTask
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: loopTask
    MQTT connection…
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    failed, rc=
    -2
    try again in 5s
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    MQTT connection…
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    failed, rc=
    -2
    try again in 5s
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    MQTT connection…
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    failed, rc=
    -2
    try again in 5s
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    MQTT connection…
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi
    CPU 1: IDLE
    Task watchdog got triggered. The following tasks did not reset the watchdog in time:
  • IDLE (CPU 0)
    Tasks currently running:
    CPU 0: wifi

#21

@petricam @thundergreen Thanks for the feedback,

Could you try to add
vTaskDelay(10);

just after

 void loop()
    {

in OpenMQTTGateway.ino


#22

Could you please show me the whole part how it should look like …I’m not that familiar with this :confused: