MQTT failed connection causes 5-8 s. freezes

[KonstantinMastak]

I experienced strange glitches when everything (web interface, console output, button processing, etc.) freezed preriodically for some time. Firstly I though that it was because of using DS18x20 library, but then I decided to add the following line at then end of void stateloop():

if (state==0) setLed(1-led_inverted[0]);

While looking at blinking led AND on console I clearly observed the reason of problem - Sonoff completely freezes for 5-8 seconds each time it tries to connect to MQTT broker but fails doing so. After I provided correct MQTT settings, freezes vanished.

Yes, I can disable MQTT or I can provide correct MQTT settings, but from user perspective freeze happens right at the time when user wants to open web interface and set correct MQTT settings. If he is not fast enough, web server won't react on user action for some time, which is not user friendly.

Is there any solution to make MQTT broker connection not so everything-blocking?

[arendst]

If you were the first to mention this phenomenon I would start writing a long story about TCP/MQTT etc.

You're not. Many have gone this way before and some suggested to disable MQTT altogether. That's what has been introduced a while ago so I suggest you'll get a stable MQTT environment or just disable the whole thing.

[KonstantinMastak]

Thanks for answer! I researched a bit.. Am I right that the reason of the problem is in _client->connect call inside PubSubClient.cpp? If yes, this seems to be a known issue:

esp8266/Arduino#1420
esp8266/Arduino#2120

According to above links, somewhere inside ESP Arduino code TCP client timeout is hardcoded to 5 seconds and this timneout value is not affected by setting client.setTimeout. I hope they'' fix this. They also advise to use ESPAsyncTCP library instead of Client.h which is also a solution.

BTW, I think that these two lines should not exists in ds18x20_webPresent:

ds18x20_search();
ds18x20_convert();

You already perform this inside every_second(). I think, doing this twice can in some cases cause situation when ds18x20_read requests data from DS18S20 too early after previous ds18x20_convert call. Maybe, I'm wrong...

[khcnz]

This was why i suggested in another ticket that MQTT should default to disabled, its confusing when you start why its blocking up so much - i had the same issue. First thing you do when you try flash this is solder the pins, compile and deploy (not investigate all 500 configurations!) and then be confused why the webui is so slow.

Another 'fix' could be otherwise a longer retry period (or one with exponential backoff)?

[hamwong]

I think I got a little issue as well and issue should relate to this, my sonoff led got flicker every 5-15 seconds after upgrade from 4.0.5 to 4.0.8, I check on console and nothing found till i found web ui sometimes got no response, I tried few power reset and issue remain, than I found it may due to signal, it turns RSSI around 6x, when I switch to another AP (AP1 to AP2), flicker stop and works fine,

I think this will be a issue, as I found device will switch to other AP only when current using one is not able to get connect, no matter it's stable or not, RSSI high or low, can it be an option that once RSSI is lower than a set value, switch to another one?

[davidelang]

@khcnz, consider using pogo pins for flashing, that way you don't end up needing to solder pins to each unit.

The 'fix' is to get the base library fixed or switch to a different library.

[davidelang]

closing this as we cannot fix this in software