After a reprogramming or restart, the ESP32 takes more than 5 minutes to send MQTT topics

Theengs OpenMQTTGateway Bluetooth gateways
1

Hi.

After a few years, I finally decided to update the Theengs OpenMQTTGateway versions (from 0.9.2 to 1.8.1) and the Theengs Decoder (from 0.6.2 to 1.9.9) in my environmental control unit ( Custom BLE beacon: Demultiplexing and publishing of multiple sensors in "manufacturerdata" parameter ).

My development environment is PlatformIO.

After recreating the personal BLE decoder in Theengs Decoder, as explained in the previous link, everything works fine, except that, after reprogramming or resetting, the ESP32 takes more than 5 minutes before it starts transmitting MQTT messages. After that, everything works fine, with messages transmitted approximately once every second. The BLE is configured in continuous scannig with the following parameters:

{
“bleconnect”: false,
“interval”: 10,
“adaptivescan”: false,
“intervalacts”: 10,
“intervalcnct”: 3600000,
“scanduration”: 1000,
“hasspresence”: false,
“prestopic”: “presence/”,
“presuseuuid”: false,
“minrssi”: -100,
“extDecoderEnable”: false,
“extDecoderTopic”: “undecoded”,
“pubuuid4topic”: false,
“ignoreWBlist”: false,
“forcepscn”: false,
“tskstck”: 2324,
“crstck”: 3016,
“enabled”: true,
“scnct”: 2776,
“onlysensors”: false,
“randommacs”: false,
“filterConnectable”: false,
“pubadvdata”: false,
“presenceawaytimer”: 120000,
“movingtimer”: 60000
}

Could you help me understand the reason for this latency on the first startup?

Thanks.

Tommaso

2

Hi @tommaso

I don’t think your issue has anything to do with any of the BTtoMQTT settings, even though you should change your “intervalacts”: to 3600000 or even higher, as your personal decoders do not require active scanning and you don’t want to unnecessarily have this continuous push on your sensor’s processing and its battery.

Also possibly setting “interval”: a little bit higher to 100, if you’re then still nicely receiving all the different BLE broadcasts from your sensor.

I suspect that there is an initial issue with connecting to your WiFi and/or MQTT broker. Can you serial monitor in VSC after an upload and post what is initially happening there?

3

Hi DigiH.

Yes, it seems there’s a problem connecting to the broker. But, with the hardware unchanged, this didn’t happen with the old version.

Furthermore, as you’ll notice from the attached logs, with the new version, startup after a reset is different than after a reprogramming.

This is the link where you’ll find the startup logs for the following cases: StartUp_AfterProg_V1.8.1.txt

StartUp_AfterRes_V1.8.1.txt

StartUp_V0.9.2.txt

Startup logs

Regards

Tommaso

4

Yes, there definitely seems to be some major to and fro starting with the Ethernet, still trying several WiFi connections etc. I’m not that familiar with all the startup code, so someone else might look into the logs into more detail.

Have you erased the flash when making the large upgrade jump from 0.9.2 to 1.8.1, or are you trying to start up with the previously saved configuration?

Are you using a custom environment for your gateway, and if it is in a portable configuration file, might it need updating when compared to the current related default pre-configured environments.

Have you also tested with a pre-built binary, and/or the current development version.

5

Hi @DigiH

Thanks so much for your replies.

I only noticed a couple of days ago that the version I downloaded is not 1.8.1, but the one from the development branch. I apologize if I’ve caused confusion and wasted your time with the incorrect version information.

I don’t use a portable configuration file; what I do when I want to update is download the entire version from the relevant branch on GitHub, and then modify the few parameters needed for my configuration.

In any case, I managed to resolve the waiting issue by following this procedure, which should only be done after a reprogramming

  1. Program with a complete flash erase.
  2. When the gateway starts sending MQTT messages after the connection to an Access Point times out, save the configuration with the command: mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoBT/config -m ‘{“save”:true}’
  3. Connect to the Gateway IP address, user: admin, leaving the password field blank.
  4. Go to Configuration->Gateway set the password and save.

The gateway restarts with the startup described in the log file StartUp_AfterReset_V1.8.1_Workaround.txt: there are no more waits, although there are still errors, likely due to the gateway first attempting a secure connection with the broker.

After startup, publications to the broker occur regularly, and the latency between BLE discovery and payload publication seems to be the same as with version 0.9.2.

Best Regards

Tommaso

1 Like