What you should be seeing on the network via wireshark is three API log commands coming from the App. One is for all water level log records by specifying the “type=wl”. Another is for all flow records with “type=fl”. And another for all other records by leaving the type filter off. The App then puts the three sets of data together to display the timeline/table. This is not particularly clear in the API specification but is consistent in the firmware and app code. Although I recall seeing a reason for splitting the request into three, I cant locate it at the moment. It may just be historical as “wl” and “fl” logging may have been added at a latter point in time.
For completeness, I should have suggested to do the same three commands from the browser (i.e. to also try “http:/os_ip/jl?&hist=21&type=wl” and “http:/os_ip/jl?hist=21&type=fl”). If you don’t have a flowmeter configured then the “fl” call should return “[]” and if you dont use a weather adjustment method then the “wl” call should also return “[]”. If you do have a weather adjustment method setup (i.e. via weather underground) then you should be seeing entries of the form “[0,”wl”,75,1493943439]” which represents 75% watering times.
Be good to check that these calls return valid data as well. From your comments above it sounds like you tried “http:/os_ip/jl?&hist=21&type=wl” from the browser but got no response rather than a “[]” response? If that is the case then there may be a firmware/hardware-side issue. Also, can you confirm your settings for flow meter and weather adjustment so we know what we should be seeing.
If the problem is network related then a few things worth trying. Firstly, it would be good to know the signal strength of the wifi connection between the unit and the extender. From memory the OS 3.0 creates an Access Point at boot time that you can connect to and scan the network. You might be able to see the signal strength for your extender’s SSID from there. Secondly, can you “ping” the unit from your mac and see what the delay time is. I connect to my OSPi via wifi->ethernet->powerline->wifi which is quite a trip and has a long ping of around 250ms but with no packet loss. Thirdly, it would be worthwhile relocating the unit near your primary wifi controller and again via the OS 3.0 Access Point connect the unit to the main wifi, i.e. remove the extender from the equation, and retry all of the tests. Finally, it might be worth swapping two of your units with each other (use export/import config from App to help) to see if the problem follows the unit or stays with the location (but this would require take a week to build up a sufficient log record.
Let me know how you get on.