Just an update...  I did succeed in disabling all AJAX widgets (including clean gauges) on a public page.  Perhaps there is a better way than what I performed, but here is a brief synopsis of what I did:

1. Created a JavaScript (.js) file to disable / clear all setTimeouts() on the page, this script sets it's function that clears the timeouts to run 150 seconds after the page is loaded.  I found running the script immediately does not stop the first set of AJAX calls from re-submitting themselves, but waiting for the first re submission, then clearing the timeouts works well.
2. Created a copy of my WordPress theme template page to enqueue the .js file in the page footer.
3. Modified the WordPress page with the gauges to use the new page template with the enqueued .js file in the footer.

The documentation states that clean gauges are supposed to do AJAX refreshes about every 2 minutes.  However looking at the Apache log file, each clean gauge on the page is causing a separate AJAX call every minute for as long as the page is being viewed.  In my case, this equates to 8 AJAX calls per minute for every Web browser session.  Please consider the amount of http requests that could happen if twenty or thirty users are viewing that page. 

Perhaps there is a setting in the Weather Station database to control the AJAX timeout period -- I have not found it yet though -- and it would affect all pages with gauges.  The process above creates a "static" page with gauges or any other AJAX refreshed widgets.  Using a separate page template allows me to have a "static" external page, and still have a dynamically refreshed internal page for the gauges or other AJAX refreshed widgets.

Respectfully,

Ken Clifton, Salisbury, NC, USA

Hello Ken!

Sorry to come after the battle 😉

First of all, know that all these Ajax calls are cached, so if there's no new value, there's no access to database for these calls. But I understand you would like to reduce http requests (if you have a huge traffic, it could be annoying).
For now, Weather Station has no parameter for this (maybe could it be an improvement in 4.0?) so if you want to modify this behavior, the best thing to do is not to modify js files and templates but just modify the time parameter (just one line for each control). To do this, just search for the following string :

$time = 1000 * (120 + rand(-20, 20)); 

in the file named includes/traits/DataOutput.php... You will find 5 occurrences for the 5 "live" controls. You just have to modify the "120" value which is the query refresh (in seconds). You can set it to, for example, "3600" so the refresh cycle will be every hour (which is a good value, I think, but it's up to you...).

Hope it helps... 

And I wish you a wonderfull winter holiday too 😉

Hello Pierre!   First, I wish for you a wonderful holiday season.

Thank you for taking time to reply regarding this, and for pointing me to the "includes/traits/DataOutput.php" file.   Being very conservative, I changed all the occurrences of  "$time = 1000 * (120 + rand(-20, 20));"  to "$time = 1000 * (240 + rand(-20, 20));", which is the interval that I run the wp-cron job.

Unfortunately, the behavior I described about each widget doing an AJAX refresh still appears * after * the four minute delay (240 seconds) -- if the user leaves the Web page up / open in their browser.   I believe this is caused by the widgets setting the next timeout period to be around 60 +/- 20 seconds as evidenced by the attached Apache access.log file.   If you find time to review the log you will see the wp-cron job running every four minutes and the initial Ajax refreshes, but after the first four minutes go by the refreshes happen every minute. 

I did want to notify you so that you can consider what is happening, since it creates a lot of un-necessary traffic.  With the cron job happening every four minutes I do not believe there is a reason to refresh the widgets every minute, since there could not be any new / changed information to display.

This is not a big issue, since I have a page template with an additional .js file enqueued to clear all timeouts that I can put back as the "page template."   When designing the site, I did not consider that some users would leave the page up all day long watching the gauges repaint.  Over the years I have found that scaling up applications to more users can be challenging.

Thanks again for this beautiful plugin, I have really enjoyed visualizing weather data with it to find relationships.  Currently I have a radar chart with wind source and solar irradiance that helps me to predict solar production depending on wind direction / source ???? .

Respectfully,

Ken Clifton, Salisbury, NC, USA