Today I had an issue where my ObserverIP (attached to WS-1400-IP) lost its annual rain total from some 22" to 0. No problem I thought, I just edit it and set it back, and so I did. I did not think about it enough, apparently, because over the next hour I observed on my station's wunderground page that it registered a rain rate (which is really total rain in last 60 minutes), of 22", which staid for 60 minutes and then went back to 0.
This leads me to the conclusion that when MeteoBridge polls the ObserverIP it reads the annual total field and uses changes in the field to compute rain between two observations and then [rain0total-sum60] which I use (I am not using the standard WU support, but use my own template for reasons I'll leave out here) produces the observed behavior.
If we look at the ObserverIP when making such a change I see that the other rain fields remain at 0 (because it is not actually raining).
This is an interesting problem because editing a historical value on the ObserverIP causes that MeteoBridge to think rain actually fell.
If I am right, the question becomes: "What can be done to prevent this"? At the very least MB could add some sanity checking. I've seen it report that pressure readings appear out of range (in the log) and then ignoring them. In this case the rain0total sampled from one readout to the next changed by over 20". That cannot be right under any realistic circumstance.Observations are about 4 times a minute. In the most extreme circumstances rain rate will not exceed 20" per hour, or 20/(60x4) = 0.083" / observation. So perhaps MB could detect values over 0.01 or even 0.025 per observation interval and flag (and ignore them), but keeping the latest value for reference. In this example it would see the transition from 0 to 22 once (and reject it), keep 20 as the reference, and going forward would only see 0.
Of course this would not work if the edit in question was very small, but it would have to be smaller than the 0.01 or 0.025 suggested about. I doubt any real scenario would exist where a user would want to make that small an adjustment. However, there would be a workaround: Add 10.01 wait 30 seconds, and then subtract 10. MB would then ignore, but ObserverIP would effectively by incremented by 0.01.
Another option would be to get the ObserverIP firmware changed to have a field for reporting the amount of rain between two observations and have MB read that instead. The problem here is that the limits of the actual device would be reached. The tipping bucket on most stations has a size around 0.01" and thus for moderate rain rates the change between two observations would be 0 mostly.
Another alternative is to read the "Hourly rain rate" and numerically integrate that over the desired interval (template modifier can be any interval 0-60 seconds). That may not be very precise either though.
Other ideas?
Perhaps the sanity check idea is the best of all options in that it should be simple to implement, and is completely backwards compatible (but I would have to renew my MB license for it
