Since we don't have the up-to-date sources for arduinoImprovBootstrapper (https://github.com/ratgdo/mqtt-ratgdo/issues/2), we have to use the latest available version and patch it manually.
I'm not sure if you already fixed it. However, from the latest available source code, there appears to be an issue that delays the main loop since handleImprovPacket runs even when the board is already configured and connected to WiFi and MQTT. This method has 25ms delay.
This may also affect other functions that rely on precise timing.
I tried setting temporaryDisableImprove = true after the setup is complete, it removes the 25ms delay from the loop, but for some reason, MQTT ping responses and some other networking functions stop working correctly in the new tight loop. A workaround is to add delay(5); to the main loop, but it would be better to understand why it happens and apply a proper fix instead of this magic delay. Even delay(1); works, but not yield();.
Since we don't have the up-to-date sources for arduinoImprovBootstrapper (https://github.com/ratgdo/mqtt-ratgdo/issues/2), we have to use the latest available version and patch it manually.
I'm not sure if you already fixed it. However, from the latest available source code, there appears to be an issue that delays the main loop since
handleImprovPacketruns even when the board is already configured and connected to WiFi and MQTT. This method has 25ms delay.In the latest code at https://github.com/sblantipodi/arduino_bootstrapper/blob/98511aa78ec16d9827b4a960c05bfb39007c6ddf/src/WifiManager.cpp#L732, this delay is increased to 255ms. If you try to merge this change, the main loop is delayed so much that some functions stop working properly (debounce, obstruction pulse detection, etc) as they rely on the main loop time < 50ms.
This may also affect other functions that rely on precise timing.
I tried setting
temporaryDisableImprove = trueafter the setup is complete, it removes the 25ms delay from the loop, but for some reason, MQTT ping responses and some other networking functions stop working correctly in the new tight loop. A workaround is to adddelay(5);to the main loop, but it would be better to understand why it happens and apply a proper fix instead of this magic delay. Evendelay(1);works, but notyield();.