Home | Support | Status Page

83886.07 inches of rain -- Solved!

Troubleshooting
#1

I’m posting this in case anyone else runs into this problem, to save them some time. (I know that @rraisley has also had this happen to him).

Early this summer I installed my own PWS, an Acurite 5-in-1. Worked just fine with Weather Underground until the middle of August, where for a couple of weeks it recorded 83886.07 inches of rain per day, and then automagically (that’s a technical term for IT folks) fixed itself. It started again on Dec. 7. I went out of town for 3 weeks for Christmas thinking it might automagically fix itself again, but no such luck. The daily recording on WeatherUnderground always looked ok, but the weekly and monthly were messed up, and that is what Rachio was picking up. Started looking at it closer, and I noticed that on days when it recorded precipitation, the total accumulated amount was correct at 11:54pm, but at 11:59pm it showed 0. Checked the Acurite device’s time, and discovered that it was now one minute faster than my phone was showing. Set it back one minute to match my phone time, and all is well with WeatherUnderground again. My guess is that the Acurite (unlike it’s name would make you think) runs ever so slightly fast, and the time got out of sync. Since it is hooked up to the internet, I would have thought it would have picked up the time from there, but silly me!!!

Good news is that it appears to be fixed.

#2

Is it really solved, though? If it gets the 83k figure /somewhere/, wouldn’t that just change when it gets it? It’s not like it adds the total in from the next/previous day.

I certainly /hope/ it’s fixed, and if it is, this may be the way to do it. We’ll, uh, you’ll see. :wink:

#3

Intersting, I’ve also had the issue with RTC running out of sync with real wold on the acurite display, difference is my display did not send data to WU, thus wrong time was more of an inconvinuence than anything. I ended up having to send mine for RMA rapair back to Acuririte, but it took a few weeks for them to get it back to me. Alas they opt for repairing fialed unitrs, rather than more expedited replacement policy.

Point of my post is that time will likely go out of sync again. Keep monitoring and logging the time difference. You will likely have to send the display back to AcuRite before it is repaired as it should have been to beging with.

#4

Well, the symptoms are not 100% consistent. When I had the problem last October, the 83866.07 number showed up at the 11:59pm time. And the day we switched to regular time instead of Daylight Savings, the symptoms went away.

When the problem started on Dec. 7, the 11:59pm time always shows 0 for the accumulated precipitation. My guess is that internally the programs use times right down to the seconds and then just displays the minutes. And when that last time of the day is off what the WU program is expecting, it goes to the wrong place to finish the calculations for the daily precip amount. My guess is that someone didn’t program for the time to be off that little bit (In the olden days, I was taught that 5% of my code was to actually do what you wanted it to do, and 95% of the code was to account for everything else that could possibly go wrong!)

The 83886.07 number is still fishy to me — I have a gut feeling that it is somehow related to the number of seconds in a day – 86400. And that when the time is off, it somehow subtracts the same number from that 86400 every time. (Again, back in the old days where more than once I accidentally coded a LOAD instead of a LOAD ADDRESS in assembler — results were ALWAYS unpredictable — there’s an old joke: Novice: What’s the difference between a Load instruction and a Load Address instruction?” Old Hand: About a week of debugging.)

I’m pretty certain it’s coding that is not expecting that time difference, but I haven’t been able to figure out how to contact Weather Underground support (Other than email, which I’ve never had them respond to)/ And they may not have the resources or time to debug and fix it anyway as it probably isn’t a common occurrence.

In the meantime, I will keep an eye on it.

#5

I was seeing this problem too (station KCASANMA368). Just before local midnight every night, the AcuRite would send a huge rainfall amount to WeatherUnderground. I believe this impossible amount of rain cost my station its little gold medal (not sure what that means in WU).

My AcuRite display contains a V100 processor that appears to handle the radio data from the sensors, the display, and the user interface (the buttons and menus). It also contains an off-the-shelf ESP8266 processor which can be found in many WiFi-capable appliances. Hacking around inside the display, one can determine that the V100 sends ASCII (human-readable) data to the ESP8266 which it forwards over HTTP as the WeatherUnderground data.

E.g. a typical message from the V100 to the ESP8266:

(2250,0,0,40,0,2993,37,93,0,0,1,2,0,0,0,)

The zero after the 40 is the rainfall amount, in inches, times 100. It would change to 8388607 once each day before local midnight.

8388607 expressed in hexadecimal is 0x7FFFFF. If there’s any signed 24-bit arithmetic going on in the V100, this would be the largest positive integer value. Maybe it’s an overflow, or maybe it’s a maximum value that some loop is supposed to be lowering, and that loop bugs out just before local midnight for some reason. Or maybe the V100 uses that value as a special sign to inform the ESP8266 to do some daily chore, perhaps that triggers when the ESP8266 gets the current time from the internet and updates the V100’s clock. I shouldn’t guess.

I don’t have WiFi turned on on my AcuRite display because it has what I consider to be a security flaw. If it ever loses touch with my WiFi router, it goes into its configuration mode where it sets up a no-password WiFi network of its own where it can be reached at http://192.168.4.1 . The display publishes a wide-open web page there with all my WiFi information, including the WiFi password - in plain text. So this can be an easy target for anyone looking to access my full home network. I keep the display’s WiFi turned off now.

But the ability to log my data with WU is one of the main reasons I bought this AcuRite. So instead of using the display’s built-in WiFi, I put an old Raspberry Pi in place of the ESP8266. I forward the data to WU with the Pi.

The Raspberry Pi keeps its time-of-day clock updated over the internet, so it always has the correct time. Nothing on it can be accessed without a secure login, so it avoids that AcuRite HTTP security hole. My code on the Raspberry also watches for “impossible” values like 83886.07 inches of rain in a day, and will simply drop such reports without forwarding them to WU. The AcuRite updates the web every few seconds and a single skipped report each day is harmless, and keeps bad data out of the WU database.

The downside of this is that the AcuRite display no longer gets weather forecast data from Dark Skies, but I heard that was about to stop working anyway. The AcuRite display’s clock also needs to be manually set, but that’s a twice-a-year thing. Worth the trouble to keep the WU data pure.

Regards

#6

Did you actually see the wrong data on the stream? I was under impression that the issue lies with Acurite getting date from the response and clearing rain total in case of a it detects that the day has changed, this effectively meant that the first reading WU got each day was the previous day’s last reading. WU servers than freaked out and interpreted the data as delta readings, wereas each reading is interpreted as increase over last, maxing out at 0x7FFFFF.
Dropping the first packet (or better zeroing out the rain value before forwarding it) of the day should solve the issue.

#7

I am seeing the 8388607 value on the serial line between the two processors inside the AcuRite display. I should have kept my debugging logs; they’d be worth a thousand words here.

Again, I should not guess why that value is being generated by the V100 side of the connection. I do suspect that it is a signal of some sort, and not meant to be forwarded to WU.

My experience started with discovering the HTTP security issue and needing to turn the WiFi off, but wanting to preserve the product’s WU integration. It was only after I put in the Pi as the display’s internet connection that I became aware of this strange rainfall value being exchanged, and that led me to finding the same bad data reflected in my WU graphs.

I was willing to write the bad data off as a side-effect of my hack to get the ESP8266 out of the picture, but then I discovered other people - presumably people who had not also bypassed a part of their display - reporting this same bug.

To be clear: the display’s WiFi is a two-way street. Outbound data goes to WU for public consumption. Inbound data includes the weather forecast information for the V100 to display on the LCD, plus the current NTP date information, and perhaps more. While the data from the V100 to the ESP8266 was easy to eavesdrop, I was unable to locate or decode any data coming back from the ESP8266 to the V100, and so I cannot comment on what is or is not happening now that the ESP8266 isn’t connected to the net.

And to repeat: I do drop (do not forward to WU) any report from the V100 processor of rainfall more than 1000 inches per day. Since I put that filter in place, I do not see bad rainfall totals on my station logs at WU any longer.

1 Like
#8

Glad you were able to dig in deeper than I could. I finally gave up on my Acurite. I was losing power at my house often (once a week for a couple of months) and I travel a lot. After some (but not all) of the power outages the Acurite would reset it’s time and date to a date in 2018 and start over at midnight. So the 83888607 would start happening again. And I couldn’t fix it except by being home and resetting everything at the device itself. Had to go!