meteohub.de

Here is an interesting one....it's been raining and my total for the month is larger than the total for the whole year! All the files have been updated several times and I checked the raw files that I use with WD Live - they have the same thing - so it's not WD Live - it appears to be in the Meteohub as for some reason it's not updated annual total as the rainfall increases..... Weird..or bug! Here is a pic - it't been this way for over 2 hours now...

This was reported the WD-Live section of the forum two weeks ago. Meteohub calculates the monthly/annual rain totals every six hours (and daily totals every one hour) in order to reduce processing overhead, so during periods of heavy rain you will notice some discrepancies until the next recalculation takes place.

Thanks for pointing that post out as it didn't turn up for me in a search..


But - it must be more than every 6 hours as I'm at almost 9 hours and still no change in the Annual total....and I'm actually over that amoumt for just the day now.....? So not sure what the calucation time is - but I would think that it's a pretty minimal calc to add to the annual and monthly total - but I'm not programmer either.... Maybe a request for the wish list or the new hardward next year....

Well - 14 hours and no updates to the annual rain data an we have had a ton of rain. If this is on purpose (24hr calculation period) and not a bug - then I seriously question that approach.... The annual rain data looks like it is even in the main clientraw file....to not update that annual rain data makes it seem unreliable from an outside observer...

Well I ran Weather Data Recomputation and then it updated it - I hope I don't have to do this every time it rains....Yes....as you can tell.....I'm a little frustrated as I paid over $200 (US) from ambient and I have probably spent 30 hours trying to just figure a very buggy system and program - so needless to say I'm frustrated with the performance of the meteohub...and here is another one that I discovered in the Meteohub Log File for the last 3 days:

"wmr928eval (15.08.2008 19:28:02): no sensor found to match export name th1"

I have a Davis vantage pro and don't have a th1 configured anywhere.....ughhhhhhhhhh! Now I will try rebooting...

We are getting a ton of rain and it's doing it again.... I am convinced that there is major bug with all rain data... The records are wrong, the graphs are wrong, and it is not updated again - it starting doing it correctly - but then just stopped again..... On the graphs - it shows yesterdays total rainfall, which was on a friday - it shows it as last Sunday.... This definitely needs some work...

Are people rebooting every night?

:(

Take a deep breath or two!

If your [month1_rain0_total_in] and [day1_rain0_total_in] variables look right then the data is getting logged and the problem is that it's just not updating as fast as you'd like. Given that your daily totals on the WD-Live chart look right, then we can safely assume this is the case. When Boris gets back on the 28th we can ask him about speeding up the frequency of rolling calculations during stormy weather.

As for system restarts, it can't hurt to let it reboot nightly, especially with a VP2 -- some of them (including mine) have that stupid USB controller bug where they lose sync and stop communicating with the computer/Meteohub, so the nightly reboot ensures that doesn't go on for more than a day should it happen. At the same time, the restart clears any volatile or backlogged junk from the system and gets the CPU back on top of things.

What does your system load look like on the System Info tab? If it's regularly above 1.00 on any of the three columns, then you're overtaxing the processor and it might be delaying 'less important' tasks like recomputing monthly rain totals in favor of keeping up on ongoing logging and other more important tasks.

AAMFlyer wrote:This definitely needs some work...

Not surprising, since WDL support is still in the process of development.

Don't be alarmed by the "wmr928eval (15.08.2008 19:28:02): no sensor found to match export name th1" message.

wmr928eval is the general data computation process valid for all stations. It computes time-compacted data from the raw data, so at this level there is no difference what weather station connected. Anyway "wmr928eval" might not be a very clever name for this ;-)

The reported warning has to do with default sensor setting for weather display and WSWIN export settings. If the messages irritates you, you can go to the WSWIN page set some proper assignments of sensors and press "save". Unmark ongoing generation of WSWIN data if not needed by you. This should make the message disappear. As it has no impact and just generates a warning, I am not sure if I would call it a bug.

Please keep in mind the load of functionality when judging about the system. It is a system still under heavy development and it has to struggle with the limits of the NSLU2.

terrax wrote:Anyway "wmr928eval" might not be a very clever name for this ;-)

I'm sure the name made sense at the time it was first devised... ;)

Meteohub has come a long way from its starting point. :)

My apologies - I'm taking 3 deep breaths and based on the other comments - I didn't realize it was still that new and under a lot of development!

WMR928eval issue is addresed - Thanks!

Rain Data - I have been parsing my files and it is not updating on the meteohub side - it matches what WD Live is displaying. After recomping my weather data yesterday - it recalculated monthly and annual data over night - but it appears to be more like 12-16 hours and not 6 hours...we got more rain again and we'll see when it updates today... Rain records though are still wrong as the number for highest daily rainfall and highest 1 hour rainfall is actually the total annual and total monthly figure....so records is also incorrect....

System Load - maybe perhaps this has something to do with it as I have seen loads well below 1.0 but have also seen loads peak well above 1.0 and close to 2.0 at times...right now I am uploading 2 clientraw files every 1 minute and Weatherunderground Rapid Fire every 3 mintues...does rapid fire use a lot of load - I can take that off and back to every 5 minutes or so...those are the only things I am doing...

Thanks so much!!!!

On a very unscientific survey I seem to typically have figures between 0.5 and 1.5 for the 5 minute figure, the 1 minute figure occasionally approaches 3[1].
I upload WDL files at 15 minute intervals (30 mins for daily)
A small html file is uploaded very 15 minutes, and another every 5 minutes.
I also have WSWIN data being generated 'on going'.


I get the impression that some people have a lot more than that going on!

Later: Almost forgot! For most of the day I also have WeatherDisplay sending requests to MH using the http logging protocol - so that's a request every 3-4 seconds or so!
When I need to recompute aggregated data I tend to stop WD to help keep the load down.

[1] Today I decided to find out what the figures mean! For those who don't know the System figure show the average number of processes in the queue in the last 1 minute, 5 minutes and 15 minutes (or something like that...).

Pretty much -- it's essentially defined as the average percentage of processor utilization during the respective time period. Thus any system load above 1.00 means the computer is attempting to cram more processing into the system than the current CPU is capable of handling in the given amount of time, which results in requests queuing up and becoming delayed. If your long-term (15 minute) average is below 1.00, then you should be in good shape, but if it's regularly above that the NSLU2 is struggling to keep up with everything you're demanding of it. For instance, you'll notice during data recomputation the load shoots up dramatically, often above 3.00.

My load right now is 0.96, 0.89, 0.87, and that's with 10-second rapid fire to Weather Underground and an average of seven graphs and an all-sensor data file uploaded via FTP every ten minutes.

I actually had to do a lot of fiddling with my cron schedule (mainly by staggering graph creation) to keep the average load below 1.00. This is another issue where having some more horsepower to work with will be very welcome in the future!

Thanks - that helps on processing time! My 15 min avg is well below 1.0 as I am not even close to that many processes and I have taken off Rapid Fire and I may change a few numbers so they don't match on the Cron schedule!

As for my rain data - we'll see what happens next time - so far it's just slow updating from what I can tell and I am also now rebooting each night.

Although the records are still off - since I just started the station - my monthly and annual rain total is 2.39 inches which is over 5 days and 3 rain events....but the records are incorrect...I gues something for the developer to look at!

sevenless wrote:I actually had to do a lot of fiddling with my cron schedule (mainly by staggering graph creation) to keep the average load below 1.00.

If I wanted to shift one of the every 15 minute tasks from, say every 15 minutes, i.e. */15 * * * *
to a staggered version that is a minute earlier, is there a simpler alternative to 14,29,44,59 * * * *

That style is fine for the 15 minute task, but if I wanted to shift the 5 minute one the list would be pretty long - so maybe there is a more efficient notation? I did look at man crontab(5) but didn't notice anything obvious.

Couldn't you just do every 14 or every 16 minutes and that itself would seperate the minutes - at some point in time they be together for a single process something like every 4 hours - but most of the time would be off by 1 minute.... */14****?