[WiFi] read all lines from slow servers

[TD-er]

As suggested by @clumsy-stefan here: #1669 (comment)

The suggested fix is based on this PR in the ESP8266 Arduino examples. (PR 5113)

I would like to know if someone who is experiencing issues with slow servers, if they see this line in the logs:

"Timeout while reading input data!"

If so, please report it, so I can make the timeout setting configurable.
Later I will make the function safeReadStringUntil use a callback construction and let it operate async.
For now the function is blocking, so it may cause all kind of issues.

[sassod]

I saw a lot of these when thingspeak plugin was active and mandatory 15s interval was applied, the data was sent successfully and after that the warning appeared. But next data sent was again successful and again the warning appeared.

…

On Sat, Sep 8, 2018, 15:19 Gijs Noorlander ***@***.***> wrote: As suggested by @clumsy-stefan <https://github.com/clumsy-stefan> here: #1669 (comment) <#1669 (comment)> The suggested fix is based on this PR <esp8266/Arduino@4fdff07> in the ESP8266 Arduino examples. (PR 5113 <esp8266/Arduino#5113>) I would like to know if someone who is experiencing issues with slow servers, if they see this line in the logs: "Timeout while reading input data!" If so, please report it, so I can make the timeout setting configurable. Later I will make the function safeReadStringUntil use a callback construction and let it operate async. For now the function is blocking, so it may cause all kind of issues. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1720>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADPy_58jLgO0CHcqDEj1yOJloFt-MhPlks5uY8PdgaJpZM4Wf3kW> .

[TD-er]

@sassod Was this with the controller queue included? (PR merged yesterday, but I made a lot of test builds.)

[sassod]

I haven't updated all the nodes some are running builds dated May or April but some have been updated to early September releases, I will need to check if the most recent releases are still producing this info. Unfortunately I'm not gonna be able to check because almost all have deep sleep enabled and I'm away from home till 16th of September. Maybe someone else can check the status if thingspeak plugin is sending multiple data one after ankther with 15s delay

…

On Sat, Sep 8, 2018, 15:30 Gijs Noorlander ***@***.***> wrote: @sassod <https://github.com/sassod> Was this with the controller queue included? (PR merged yesterday, but I made a lot of test builds.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1720 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADPy_2_Dus7A50_B74rlxa-oXQdOzvVPks5uY8aCgaJpZM4Wf3kW> .

[TD-er]

The change introduced with yesterdays merge is meant to be used for controllers like Thingspeak.
The controllers themselves manage their own queue and only send new values when the minimal interval has passed since last send.
So you don't have to use the Message Delay value anymore. (that one blocks the whole ESP)

Only thing I haven't checked is if the result of millis() increases when in deep sleep. (this just occurred to me)

[clumsy-stefan]

I only have "HTTP : C009 connection failed" in the logs (on firsth sight) and no TImeouts as described... but probably the same root cause?!

[TD-er]

@clumsy-stefan Looking at the code, that error will occur when

• client.connect returns something other than 1
• WiFi is not connected
• Hostname cannot be resolved (when using DNS)

As far as I can see, the timeout cannot be set, but is 5000 msec for WiFiClient.

[clumsy-stefan]

I've upgraded my server to a newer and faster HW/SW.... interestingly since then the units run without issues and reboots.... it really seems, that when the server is really slow or has tcp/network problems the client can get into some strange state... eg. having to many parallel open sessions or waiting too long for a result...

[clumsy-stefan]

quick update, all units runing with latest commit from yesterday (self compiled):

nb: now I also do get the timeouts in the logs ... I only see reboots, when the server is not running/answering... other than this they seem to work fine..

Name / date / UPTIME (over 30 hours, most of them)....
sonoff_basic_06_sysinfo 2018-09-12 08:20:08 2125
sonoff_basic_08_sysinfo 2018-09-12 08:20:21 2125
sonoff_dual_01_sysinfo 2018-09-09 16:37:51 1594
sonoff_pow_01_sysinfo 2018-09-12 08:20:17 1364
sonoff_pow_02_sysinfo 2018-09-12 08:20:23 2126
wemos_mini_01_sysinfo 2018-09-12 04:24:45 1896
wemos_mini_02_sysinfo 2018-09-12 08:19:59 2131
wemos_mini_03_sysinfo 2018-09-12 08:20:14 2131
wemos_mini_04_sysinfo 2018-09-12 08:20:07 1991
wemos_mini_05_sysinfo 2018-09-11 19:40:42 1371
wemos_mini_06_sysinfo 2018-09-12 08:20:07 2130
wemos_mini_07_sysinfo 2018-09-12 08:20:19 1585
wemos_mini_08_sysinfo 2018-09-12 08:20:16 2129
wemos_mini_09_sysinfo 2018-09-12 08:20:30 2129
wemos_mini_10_sysinfo 2018-09-12 08:19:55 2128
wemos_mini_11_sysinfo 2018-09-12 08:20:14 2128
wemos_mini_12_sysinfo 2018-09-12 08:20:31 2128
wemos_mini_13_sysinfo 2018-09-12 08:19:49 2127
wemos_mini_14_sysinfo 2018-09-12 08:20:03 2127
wemos_mini_15_sysinfo 2018-09-12 08:20:15 2127
wemos_mini_16_sysinfo 2018-09-12 08:20:26 2127
wemos_pro_01_sysinfo 2018-09-12 08:20:14 2126