Thanks, I did capture events and they do show up on otherwise valid API responses. The good thing is that they seem to show up one at a time, unlike other issue known to me (which effects several readings in a row). It should be possible to filter these out, stay tuned.

During the testing for @jcloudm I noticed that issue was much more prevalent than I thought. The only difference is that it usually manifests itself as negative jump in the readings, thus not effecting Rachio as much as it could.

Due to this I’ve tried to rush the fix for the problem, but for now I’m in the process of testing it.
Courageous of you can modify the cron-job URL to beta.wufyi.com/?.. to try out the fix ahead of time, for now I’ve setup a testing station for @jcloudm station at BETAMDT pws (link). I’ll continue monitoring it and if everything works without issues, roll out the fix to wufyi / GitHub.

Hi coozie, I’m getting ready to roll it out, a test code is running and I’m making sure no unexpected errors creep up. It is a significant deviation from how wufyi has worked up to now, so testing / debugging took longer than expected.

Sorry about numerous failures today. Alas my host is currently under DDoS attack: https://www.dreamhoststatus.com/. The good news is that in the future wufyi continue to function even if the front end is offline. The internal scheduling service I’m testing does not require Apache / Web host to function.

Backend redesign is taking a bit longer to optimize / debug. wufyi will be largely moving away from 3rd party cron service.

That doesn’t mean I’ve left the legacy code as is. I’ve optimized it a bit and I’m seeing the failure rate improving.

In case I’m still going to be facing major issues with the new backend by tomorrow (hope not), I have a backup plan of parsing the access log for the webhost (which logs 503 errors as well) and executing any failed job(s) which are detected.

Meanwhile the best course of action I could recommend is to simply disable the email notification for the failed cron-job. I know it is not optimal, but I promise it is only temporary.

Google analytics, of all things, seems to be the primary cause of 503 errors. I’ve been sending anonymous “success / offline / error…” hits to G.Analytics to keep track of server usage / peak times / results and it used to be the fastest part of the whole process (much faster than WU or AcuRite interface for example). As part of today’s optimization, I’ve disabled google analytics and 503 failure rate dropped to 0…

Google, you’ve let me down.

In any case, I’ll continue debugging the new backend, since it will help avoiding cron-job load peaks in the future, but meanwhile 503 issues appear to be solved.

@Smarks Sorry Beta changes are not live yet, you are seeing artifacts of wunderground’s official API feed (which leaves much to be desired). Unfortunately I’ve been dealing with a few deadlines at work and Floridian hurricane prep so any big changes are being a bit delayed.

For now feel free to change url you use within your cron job to start with beta.wufyi.com instead of just wufyi.com. This should take care of these spikes.

@Gene I am seeing precipitation totals basically duplicated across days. Any thoughts on what could be going on here? It started to snow on Sunday night through Monday afternoon. Tuesday was sunny and 0 precipitation.

Sorry for the issue @Hooper, sent you a PM with info about how to switch to beta. Alas I’m experiencing a few issues with memory management (not directly related to what you’ve experienced) and that is why changes haven’t made it yet to general wufyi code.