[rain0total-sum24h=in] can be wildly inaccurate. I have a one-time alarm that triggers every morning at 4:00 am just to email me [rain0total-sum24h=in]. The email value is often wrong. For example, today it reported 1.0, but the actual rainfall recorded by the Meteobridge and the Davis console is 0.05. Yesterday my email reported [rain0total-sum24h=in] as 0.04, but the actual amount detected was 0.02. The day before that it reported 0.01, and Meteobridge and the Davis console recorded 0.01.
It seems like [rain0total-sum24h=in] is actually adding values from a longer period. If you allow for rounding errors, the above pattern appears as though Meteobridge has been adding the values for at least the previous three days.
Meteobridge 3.2 Bug **solved**
Moderator: Mattk
Re: Meteobridge 3.2 Bug
As far as I know the Davis console does not report rain amount of last 24 hours, but the ones of the current day. So you might compare different things. If you are looking for the Rain of today or yesterday, then you should use "daysum" or "ydaysum". Timezones and time of station and Meteobridge do also need to match.
Re: Meteobridge 3.2 Bug
I'm counting the number of rain bucket tips between 4:00 am and 4:00 am. Besides, there's no way to get it as wrong as it was. The cumulative rainfall over the three previous days was the same as the total reported on the last day for 24 hours.
Re: Meteobridge 3.2 Bug
Rain total from the previous day or the current day is not sufficient for my use case. I need to know, at 4:00 am, whether any rain has fallen in the previous 24 hours, and how much.
If there error were due to timezone I'd have to be living in a timezone with 72 hours in one day.
If there error were due to timezone I'd have to be living in a timezone with 72 hours in one day.
Re: Meteobridge 3.2 Bug
Something is unequivocally wrong with [rain0total-sum24h]. It started drizzling about 01:00 (first bucket tip recorded). By 03:34 two more tips were recorded for a total of 3 tips (0.03 inches). At 04:00 I received my email from Meteobridge reporting [rain0total-sum24h]=0.0.
Here is the one-time alarm rule:

The fact that the email was generated at all shows that Meteobridge "knew" [rain0total-sum24h] was NOT zero, so I don't know why the body of the email showed "0.0 mm of rain was detected in the last 24 hours."
Here is the one-time alarm rule:

The fact that the email was generated at all shows that Meteobridge "knew" [rain0total-sum24h] was NOT zero, so I don't know why the body of the email showed "0.0 mm of rain was detected in the last 24 hours."
Re: Meteobridge 3.2 Bug
When you upgrade to 3.6 I can try to debug. Doing that on an outdated release is not making much sense.
Re: Meteobridge 3.2 Bug
Pay to get someone to look at bug? No thanks.
Re: Meteobridge 3.2 Bug
Debugging code outdated since many releases? No thanks.
Re: Meteobridge 3.2 Bug
That's the choice you can make as a developer when you move to a subscription model: support existing customers, or require them to pay up to get your bugs fixed. It introduces some interesting financial incentives for developers to introduce annoyances that the customer can only fix by paying - a gentle kind of shakedown. It's made worse when there's not even a promise to fix the bugs upon paying the fee. As far as I can tell, the only promise is that bugs will not be investigated without the fee. With the fee they *might* be investigated and/or fixed.
Re: Meteobridge 3.2 Bug **solved**
I wonder that you warm up this after over half a year. As you had your chance to express your discomfort again, I think I can close this thread now.