WD or Meteotemplate minor quirk with rain for day

Not sure where this quirk resides, with WD or MT.

I am using WD’s MT API updater, every 3 seconds, to update my new MT site. On April 1 I noticed that MT was showing .33" of rain for the day, however that is the rain total for March 31, ending at about 6 PM.

Where I first noticed this was in the rain block on MT, when there had been no precipitation in April at that point in time. (image attached)

Looking at the sql database on my site, the data shows as below.
Below is the last records for 3/31, and first records for 4/1.

2019-03-31 23:45:00 35.4 35.4 35.2 56.3 30.19 3.3 12.0 311.0 0.33 0.00 21.3 28.7
2019-03-31 23:50:00 35.2 35.4 35.2 56.5 30.19 2.1 9.0 309.0 0.33 0.00 21.2 29.2
2019-03-31 23:55:00 35.2 35.2 35.1 56.7 30.20 2.1 9.0 309.0 0.33 0.00 21.3 29.2
2019-04-01 00:00:00 35.1 35.2 35.1 57.0 30.20 2.7 10.0 314.0 0.33 0.00 21.2 28.7

2019-04-01 00:05:00 35.0 35.1 34.9 57.6 30.20 1.8 8.0 306.0 0.00 0.00 21.4 29.2
2019-04-01 00:10:00 34.9 34.9 34.9 57.6 30.21 4.0 11.0 303.0 0.00 0.00 21.2 27.8

However data that was imported enters that last entry for each day as 23:59 hours instead 00:00 hours, as show on a previous day with rain.

2019-03-21 23:49:00 36.6 36.6 36.6 93.0 29.95 8.1 4.7 301.0 0.16 0.00 34.7 28.9
2019-03-21 23:55:00 36.5 36.5 36.5 93.0 29.95 8.1 5.5 306.0 0.17 0.01 34.7 28.8
2019-03-21 23:59:00 36.5 36.5 36.5 92.0 29.95 10.4 5.1 46.0 0.17 0.01 34.3 27.5
2019-03-22 00:05:00 36.4 36.4 36.4 92.0 29.95 3.5 2.5 347.0 0.00 0.01 34.3 31.3

2019-03-22 00:10:00 36.4 36.4 36.4 92.0 29.95 3.5 1.9 293.0 0.00 0.01 34.3 31.3
2019-03-22 00:14:00 36.3 36.3 36.3 92.0 29.96 8.1 2.3 305.0 0.00 0.01 34.2 28.6

Quick edit of the sql database cleared this up, but based on the above I suspect that precipitation will always be carried to the next day, which throws totals off at least for the first database entry. The forecast calls for rain over the next couple of day so I will monitor closely.

What is not clear is if this is a WD problem or an MT problem?


This is a MT problem and is related to the processing speed of the server
my main MT on hosted server works fast and I never see this but I have a test MT on a local synology box that is slow and I have to check and edit the midnight data value the day after rain

I would not suspect a slow hosting server, as I use 1and1. When preforming some sql database tasks, that MT states may take a while, they actually finish in just a few seconds.

Had 0.2" of rain yesterday morning, the first rain for the month. Today my MT page showed that 0.4" of rain for the month.

Edited the 00:00:00 hour data for today, and that corrected the error.

What does the screen display that WD generates real-time show for rainfall?

Are you graphing the rainfall on the native WD graphic screen so you can see when the amounts occurred, and how much the base program recorded as having fallen?

Everything on WD is correct. The issue appears to be in the timing or the time stamp of the last data for the day.

Seems to be a conflict of when a day ends, be it 23:59:59 or 00:00:00. The sql database that MT maintains records the last entry for a day as 00:00:00, which is actually the next day. I would have to capture the actual packet that WD’s Meteotemplate publication app is actually sending in the api.php to my website’s. I do have it setup to update every 3 seconds.

Hi Brain;
ver 10.37s bld 93

I have the same issue with the Meteotemplate rain totals due to the midnight carry over of the previous day rain total. This occurs with the 5 second update rate. The problem has been occurring since the change over from clientraw to the API. It is fairly easy for me to fix the first line of the day in the database using the Meteotemplate editor. A possible solution could be to not do the API update for the 00:00 minute. The database will still get the 5 minute average or max value in the array depending on the variable.
Thanks,
Gus


Gus,
Exactly the same as my symptoms. It is a quick edit, but will need to do it 120+ times a year, which is a bit of annoyance.

I’m also on ver 10.37s bld 93

Have either of you asked Jachym to take a look or improvise specific code changes to check for this, and do a one-time correction? It sounds as if you have analyzed this very well, have found what quirk makes the error occur. I would assume he could quickly do a check for that at the turn of midnight and do automatically what you guys have been doing manually.

Your analysis is very thorough. Hat’s off to your persistence and dedication to accurate data collection. Knowing what the error is caused by, and how it is fixed should make the programming much easier.

Dale

I have, and his initial response was to edit the database. I’ve posted follow-up the next time it occurred, after the next rain event, but no response, and no other user has said they have the same issue.

Gus is the only other person to post they also have experienced this. Maybe the rest of WD/MT users are still relying on clientraw.txt to update MT.

I use 1 minute updates as do others, but the 3 second update may be a problem at midnight

one solution is WD does not send a fast update to meteotemplate around that midnight change over time at the change of a new month (or even just around midnight any day?)?

It’s midnight on any day that recorded precipitation. I first noticed it on the first of the month, but it also occurred on the 5th/6th.

I’m having WD send both the clientraw to have FreshWDL work, and also the API sending Meteotemplate data to the SQL database on my server.

And not having had anything but copious quantities of snow (and more to come by the sounds of it in another day or so) I’ve not followed the day to day periods. I am hoping for just plain rain soon.

Dale

try this update
http://www.weather-display.com/downloadfiles/weatherdisplaytest.zip

Update installed, will advise if this fixes the problem. It has rained today, so I will check after midnight.

Downloaded and running. Haven’t had any rain so far today.
Gus

I’m afraid that had no effect.

Editing the rain for 00:00:00 timestamp to 0.00 corrects the totals shown by MT.

the time in the MT data is actually UTC
so maybe I need to not send around that midnight time change instead of local midnight time change?

UTC midnight would be 8 PM my time. Not sure that would have any effect.