The status of the gateway is unstable about esp32_bletracker HOT 12 CLOSED

Taking a look to this post
maximelouet/iot-sitting-posture-assistant@0f7714c
the problem was solved lowering the MQTT_KEEPALIVE to 10

from esp32_bletracker.

Which version are you using? The one on the master or develop branch?
WIFI_CONNECTION_TIME_OUT is just a timeout used to reset the ESP32 in case it's no able to connect to the wi-fi.
In case you have build with Arduino Ide be sure to use my modified BLE library as described in the documentation.
To investigate the issue could be useful take a look the logs in the console. The disconnection could be caused by a crash, in this case if you have build with PlatformIO, the file firmware.elf and the back trace printed in the console can be used to find where is the issue.
Anyway I have never encountered so many disconnection.
This is the state of my tracker using the latest develop version. Disconnections are forced by me after an OTA update.

from esp32_bletracker.

Hi,
I have checked and my ESP is stable since its start

from esp32_bletracker.

Thank you for your hard work that added the ability to add a mac via the web interface. I have uploaded the latest version of your firmware version 2.1 via the Arduino IDE. I still have frequent breaks. The library I used [this one you specified] (https://github.com/shogunxam/ESP32-BLE-Arduino)

Here I put the esp32_blu_arduino library

I filled in the latest firmware version 2.1, in the settings I specified only the SSID and password and the address of the MQTT server

Спасибо за ваш труд, что добавили возможность добавления mac через веб интерфейс. Я залил последнюю версию вашей прошивки версии 2.1 через Arduino IDE. У меня по прежнему частые разрывы. Библиотеку я использовал эту, которую вы указали

Вот сюда я положил библиотеку ESP32_BLE_Arduino

Залил последнюю прошивку версии v2.1, в настройках я указал только SSID и пароль и адрес MQTT сервера

from esp32_bletracker.

The last time I had a similar problem was router's issue.
Could you please check the logs? You have to enable the debug level for logs from the UI. So we can understand if it's a crash or only a disconnection from the MQTT broker.
I suggest also to build with Platform.IO because it uses newer libraries. The BLE Library is the correct one.
Is the Wi-Fi signal strength enough between the ESP and the access point? Mine is 2 meters from the router and I haven't a disconnection since 2 days

from esp32_bletracker.

Вот что пишется в логах. MQTT брокер у меня установлен на synology в докере и имеет порт 2883. Другие шлюзы как WLED, Redmond for Sky работают нормально. У меня коммуникационный шкафчик и шлюз у меня находится от роутера в 50 см.

Here is what is written in the logs. The MQTT broker I have installed on the synology in the Docker and has a port 2883. Other gateways like WLED, Redmond for Sky work fine. I have a communication locker and my gateway is located 50 cm from the router.

Может тут неправильно настроил?
Maybe I set it up incorrectly here?

from esp32_bletracker.

from esp32_bletracker.

Could you please play with the value of MQTT_KEEPALIVE and MQTT_SOCKET_TIMEOUT you find at the top of the file
ESP32_BLETracker/main/main.ino

Below there is an explanation of the two parameters.
If you are using Arduino IDE I suggest to upgrade the PubSubClient library to the latest version (currently in Platform.IO configuration I'm using the version 2.8).
Moreover in always in the in Platform.IO configuration I'm using MQTT_KEEPALIVE=30 and MQTT_MAX_PACKET_SIZE=1024, you can add the last one in the main.ino under the others simply adding the line
#define MQTT_MAX_PACKET_SIZE 1024

MQTT_SOCKET_TIMEOUT is how long the client will wait for data to arrive. For example, after sending the initial CONNECT, it is how long it will wait for the CONACK to arrive before deciding the connection is dead. Or when trying to read a complete packet from the network, how long it will wait between individual bytes. It isn't related to anything regarding the MQTT protocol itself - its just basic TCP timeout handling solely on the client.

MQTT_KEEPALIVE is an MQTT protocol defined timeout. It is how long either end of the connection should wait without having received any data from the other side before deciding the connection is dead. So to be clear - this is when the underlying TCP connection is still open, but no data is flowing. When the keepalive timer expires (typically, a 2x grace period is used), the connection is considered dead and should be closed. As an 'abnormal' disconnection, it will trigger any Will message provided by the client on the original connect. The client includes its keepalive timer value as part of the connect packet - so the broker knows what keepalive interval to expect the client to honour.
Just to reiterate, this along applies whilst the TCP connection is open - if the TCP connection drops, they the Will will send straight away (assuming the client didn't first send a proper MQTT Disconnect packet).

from esp32_bletracker.

from esp32_bletracker.

Hi,
I checked the log of my two ESP32s with the latest version of your great release and have no disconnections on both ESPs.
They work perfectly.
Thanks again for your hard work.

from esp32_bletracker.

Ура!! Заработало как надо.
Hurray!! It worked as it should. 🥳

В Arduino IDE изменил параметр MQTT_KEEPALIVE to 10, как вы и написали и все заработало. Теперь нет частых разрывов.
In the Arduino IDE, I changed the parameter MTU_KEEP ALIVE to 10, as you wrote, and everything worked. Now there are no frequent breaks.

Из истории видно, что разрывов нет
The history shows that there are no gaps

from esp32_bletracker.

Glad to hear that. I will do some test with this value too, and if it continues to work as it should I will set 10 as default.
I close this issue.

from esp32_bletracker.