Given the original commentary in this thread, I can’t believe I overlooked the fact that the controller might have been resetting (it is out in the yard, some way away from where I am normally controlling things though)! This is indeed why it’s losing its network connection.
At the moment, I can quite consistently cause a controller reset by attempting to view the log from my iPad. It usually resets two or three times before it comes back again, [based on the OLED display messages] resetting sometimes when connecting to the network and sometimes when the “NTP syncing…” message is displayed.
I have also managed to ‘step through’ all of the type=wl messages in the log by requesting suitably small date ranges. Whether it’s the number of log messages or something else, I can typically only retrieve a maximum of about 195 log entries before I cause a reset.
The type doesn’t seem to matter now. The only reason that type=wl messages seemed to be the cause is that there were always more of them. I can now (with another day’s log messages in store) reliably cause a reset simply doing a normal (no type parameter) jl request through the API — I can no longer retrieve all of my ‘normal’ log messages in a single API request. The date range that I Can use for a successful request does seem to be a lot smaller if I use the type=wl parameter though, so I’m not sure where that leaves us with regard to all API requests being treated in much the same way.
Just for the record, the RSSI values for my five devices are: -51 (problem controller), -70, -75, -21, -69.
And yes, I could unplug everything and just bring the controller into the house, but this raises another question I’ve had. My WiFi extenders use discrete SSIDs, that are different to my main WiFi network. Is there any way to get the OpenSprinkler to pick up a different SSID than the one nominated when it first starts up?
But I should point out that I have taken both my iPad and my laptop out to the controller, connected through the same WiFi extender to the controller, and observed the described problem. I’m afraid I’m not familiar enough with WiFi networks to know what actually happens with a WiFi extender, but I would expect ‘local’ traffic to stay local (i.e. I would expect that my iPad or laptop will simply communicate through the extender, like a local hub or switch, to the controller and that packets will not be sent all the way back to the router (not because it’s a router per se, but because it the ‘core’ of the WiFi network).
Just picking up on one final point, you comment that the ESP8266 buffer size is 4k. I can see that the largest log requests that are successfully serviced fill just under three ethernet packets… that’s a little under 3 x 1518 (less headers), which is getting pretty close to 4k, or just one buffer of data…