——- Wow, the forum just deleted my post as well ! I’ll try not to take it personally and hopefully this wont be duplicated ————
Hmm … OK, so a bit more on the inner workings of Firmware. The three log api calls all operate in a vary similar manner. In each case the OS is reading every entry from the log within the date range. In the case of the “no type” call, it will discard any “wl” and “fl” readings. In the case of “fl” and “wl” types, they discard anything but the specified type. So in this way the OS is reading the log from SPIFFs the same in in all three cases. If there was a SPIFFs problem then I would have thought all three responses would be impacted. Given that only “wl” is effected then it appears that’s not the problem.
But to rule out any possible data corruption of the “wl” log entries causing problems, have you tried doing a full “walk” of the log history using overlapping bite-sized “wl” requests. If you can cover the full range and the records look well formed then that should rule out data corruption in the “wl” records much the same as we have done for the others.
As you point out, a big difference between the three commands is the size of the response. The “wl” entry happens every hour and so there should be, give or take, 24 entries per day. In many setups this could be perhaps an order of magnitude more entries than station events. Thus the response from the “wl” query could be a larger packet. Having said that the buffer on the ESP8266 is 4k and will segment the response if needed. Hence a buffer overrun seems unlikely but not impossible. In one of your earlier responses you mention network connection problems coinciding with a large “wl” request. How consistent is this behaviour (i.e. always at a certain number of records) and is there any indication that the OS is resetting at this point?
So barring the above, I am kind of left with suspecting a network problem. An alternative way to get the OS view on wifi signal is to issue “http://os_ip/jo” command and look for the RSSI field in the returned json string. I know you have a couple of units and one works well on the wifi extender but I am bit old school and always keen to remove variables when testing. You wouldn’t need to have the expansion module/valves connected to do a bit of api testing just a strong connection to your main wifi router. But that’s easy for me to say as I don’t know how hard it is to “just 8-)” disconnect everything so your call.
UPDATE: I think the command to get RSSI is actually “http://os_ip/jc” but just going from the code on that one.