Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Rod Yager]

No.  You always get all available data for a complete day (00:00:00 to 23:59:59 
local time).

So in UTC+10, the first entry in the returned data is   00:00:00 UTC+10  
(14:00:00 UTC the previous day)  and the last entry in the returned data is 
23:59:59 UTC+10  (13:59:59 UTC  same day)
and in UTC-4, the first entry in the returned data is   00:00:00 UTC-4  
(04:00:00 UTC same day)  and the last entry in the returned data is 23:59:59 
UTC-4  (03:59:59 UTC the  next day)

Consider a request for data for 20190520 made in the UTC+10 timezone.
If the request is made at 01:00 on May 31 local time,   (15:00 May 30 UTC), the 
API will return all data for 20190521. ie. Observations made from 00:00 May 21 
to 23:59 May 21 local time.  (14:00 May 20 UTC to 13:59 May 21 UTC)
If the request is made at 11:00 on May 31 local time,   (01:00 May 31 UTC), the 
API will return all data for 20190520. ie. Observations made from 00:00 May 20 
to 23:59 May 20 local time. (14:00 May 19 UTC to 13:59 May 20 UTC)


I think that the same request for data for 20190520 made in the UTC-4 timezone 
has the following behaviour (judging from what I’ve seen reported on this 
thread)
If the request is made at 11:00 on May 30 local time,   (15:00 May 31 UTC), the 
API will return all data for 20190520. ie. Observations made from 00:00 May 20 
to 23:59 May 20 local time. (04:00 May 20 UTC to 03:59 May 21 UTC)
If the request is made at 21:00 on May 30 local time,   (01:00 May 31 UTC), the 
API will return all data for 20190519. ie. Observations made from 00:00 May 19 
to 23:59 May 19 local time (04:00 May 19 UTC to 03:59 May 20 UTC)


So it appears that Weather Underground is doing the following.

1. Determining whether current date at the station is the same as the current 
date UTC.
2. If the two dates are different, adjust the date in the request to “allow 
for” the date difference.
3. Return the data between 00:00 and 23:59 (local time) on the adjusted date.

Step 2 is unwanted and undesirable.


If Weather Underground doesn’t fix this, wunderfixer needs to work out whether 
the local time date is the same as the UTC date. If it is, send the request as 
usual.
If the local time date is currently ahead of the UTC date, adjust the request 
to ask for the day before the date you actually want.
If the local time date is currently behind the UTC date, adjust the request to 
ask for the day after the date you actually want.


Rod







On 31 May 2019, at 3:14 pm, Andrew Milner 
mailto:andrew.s.r.mil...@gmail.com>> wrote:

. so does this just simplify to the fact that in the api the date is taken 
as being the UTC date?
ie if one requests data for 20190529, and timezone is +3 you get back data for 
UTC00:00 29 may to 23:59 29 may
which is 03:00 29 may local to 23:59 29 may local AND 00:00 30 may local - 
02:59 30 may local

so to get the data for 29 may local it would be necessary to
1. get data for utc 28 may and discard utc 00:00 - 20:59
2. get data for utc 29 may and discard utc 21:00 - 23:59

or have i not understood correctly?


On Friday, 31 May 2019 05:48:09 UTC+3, Rod Yager wrote:

I constructed a cron job which exectued  wunderdates --date=2019-05-30  twice 
every hour, once 2 minutes before the hour and once 2 minutes after the hour.

Consistent with my earlier post, between 00:00+10 and 09:59+10 the reply from 
the api had data which belonged to 2019-05-31 - the day after the requested 
date. Before midnight, and after 10am local time, the reply from the api had 
data which belonged to 2019-05-30 (as requested).

I've pasted below some representative samples of the last 3 lines of the 
wunderdates output.

Before midnight on May 30: Request is for May 30 data. Replies are May 30 data  
Local Date = UTC date.

Thu May 30 20:58:02 2019 UTC+10
epoch: 1559213100 date_epoch_local: 2019-05-30 20:45:00 utcepoch: 1559212100 
date_epoch_utc: 2019-05-30 10:45:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-30T10:45:00Z obsTimeLocal: 2019-05-30 20:45:00
epoch: 1559213400 date_epoch_local: 2019-05-30 20:50:00 utcepoch: 1559212400 
date_epoch_utc: 2019-05-30 10:50:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-30T10:50:00Z obsTimeLocal: 2019-05-30 20:50:00
Number of WU records:  251


Thu May 30 22:58:03 2019 UTC+10
epoch: 155922 date_epoch_local: 2019-05-30 22:40:00 utcepoch: 1559219000 
date_epoch_utc: 2019-05-30 12:40:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-30T12:40:00Z obsTimeLocal: 2019-05-30 22:40:00
epoch: 1559220300 date_epoch_local: 2019-05-30 22:45:00 utcepoch: 1559219300 
date_epoch_utc: 2019-05-30 12:45:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-30T12:45:00Z obsTimeLocal: 2019-05-30 22:45:00
epoch: 1559220600 date_epoch_local: 2019-05-30 22:50:00 utcepoch: 1559219600 
date_epoch_utc: 2019-05-30 12:50:00 tz: Australia/Sydney obsTimeUtc: 
2019-05-30T12:50:00Z obsTimeLocal: 2019-05-30 22:50:00
Number of WU records:  275


Thu May 30 23:58:02 2019 UTC+10
epoch: 1559223900 date_epoch_local: 2019-05-30 23:45:00 utce

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Andrew Milner]

. so does this just simplify to the fact that in the api the date is 
taken as being the UTC date?
ie if one requests data for 20190529, and timezone is +3 you get back data 
for UTC00:00 29 may to 23:59 29 may 
which is 03:00 29 may local to 23:59 29 may local AND 00:00 30 may local - 
02:59 30 may local

so to get the data for 29 may local it would be necessary to 
1. get data for utc 28 may and discard utc 00:00 - 20:59
2. get data for utc 29 may and discard utc 21:00 - 23:59

or have i not understood correctly?


On Friday, 31 May 2019 05:48:09 UTC+3, Rod Yager wrote:
>
>
> I constructed a cron job which exectued  wunderdates --date=2019-05-30 
>  twice every hour, once 2 minutes before the hour and once 2 minutes after 
> the hour.
>
> Consistent with my earlier post, between 00:00+10 and 09:59+10 the reply 
> from the api had data which belonged to 2019-05-31 - the day after the 
> requested date. Before midnight, and after 10am local time, the reply from 
> the api had data which belonged to 2019-05-30 (as requested).
>
> I've pasted below some representative samples of the last 3 lines of the 
> wunderdates output.
>
> Before midnight on May 30: Request is for May 30 data. Replies are May 30 
> data  Local Date = UTC date.
>
> Thu May 30 20:58:02 2019 UTC+10
> epoch: 1559213100 date_epoch_local: 2019-05-30 20:45:00 utcepoch: 
> 1559212100 date_epoch_utc: 2019-05-30 10:45:00 tz: Australia/Sydney 
> obsTimeUtc: 2019-05-30T10:45:00Z obsTimeLocal: 2019-05-30 20:45:00
> epoch: 1559213400 date_epoch_local: 2019-05-30 20:50:00 utcepoch: 
> 1559212400 date_epoch_utc: 2019-05-30 10:50:00 tz: Australia/Sydney 
> obsTimeUtc: 2019-05-30T10:50:00Z obsTimeLocal: 2019-05-30 20:50:00
> Number of WU records:  251
>
>
> Thu May 30 22:58:03 2019 UTC+10
> epoch: 155922 date_epoch_local: 2019-05-30 22:40:00 utcepoch: 
> 1559219000 date_epoch_utc: 2019-05-30 12:40:00 tz: Australia/Sydney 
> obsTimeUtc: 2019-05-30T12:40:00Z obsTimeLocal: 2019-05-30 22:40:00
> epoch: 1559220300 date_epoch_local: 2019-05-30 22:45:00 utcepoch: 
> 1559219300 date_epoch_utc: 2019-05-30 12:45:00 tz: Australia/Sydney 
> obsTimeUtc: 2019-05-30T12:45:00Z obsTimeLocal: 2019-05-30 22:45:00
> epoch: 1559220600 date_epoch_local: 2019-05-30 22:50:00 utcepoch: 
> 1559219600 date_epoch_utc: 2019-05-30 12:50:00 tz: Australia/Sydney 
> obsTimeUtc: 2019-05-30T12:50:00Z obsTimeLocal: 2019-05-30 22:50:00
> Number of WU records:  275
>
>
> Thu May 30 23:58:02 2019 UTC+10
> epoch: 1559223900 date_epoch_local: 2019-05-30 23:45:00 utcepoch: 
> 1559222900 date_epoch_utc: 2019-05-30 13:45:00 tz: Australia/Sydney 
> obsTimeUtc: 2019-05-30T13:45:00Z obsTimeLocal: 2019-05-30 23:45:00
> epoch: 1559224200 date_epoch_local: 2019-05-30 23:50:00 utcepoch: 
> 1559223200 date_epoch_utc: 2019-05-30 13:50:00 tz: Australia/Sydney 
> obsTimeUtc: 2019-05-30T13:50:00Z obsTimeLocal: 2019-05-30 23:50:00
> Number of WU records:  287
>
>
> 10 hour period after midnight on May 31. Request is for May 30 data. 
> Replies are May 31 data.  Local Date is 1 day ahead of UTC date
>
> Fri May 31 00:02:02 2019 UTC+10
> Could not get Weather Underground data.
> Reason: No JSON object could be decoded
> Could not get Weather Underground data. Exiting. 
>
>
> Fri May 31 00:58:02 2019  UTC+10
> epoch: 1559227500 date_epoch_local: 2019-05-31 00:45:00 utcepoch: 
> 1559226500 date_epoch_utc: 2019-05-30 14:45:00 tz: Australia/Sydney 
> obsTimeUtc: 2019-05-30T14:45:00Z obsTimeLocal: 2019-05-31 00:45:00
> epoch: 1559227800 date_epoch_local: 2019-05-31 00:50:00 utcepoch: 
> 1559226800 date_epoch_utc: 2019-05-30 14:50:00 tz: Australia/Sydney 
> obsTimeUtc: 2019-05-30T14:50:00Z obsTimeLocal: 2019-05-31 00:50:00
> Number of WU records:  11
>
>
> Fri May 31 02:58:03 2019 UTC+10
> epoch: 1559234700 date_epoch_local: 2019-05-31 02:45:00 utcepoch: 
> 1559233700 date_epoch_utc: 2019-05-30 16:45:00 tz: Australia/Sydney 
> obsTimeUtc: 2019-05-30T16:45:00Z obsTimeLocal: 2019-05-31 02:45:00
> epoch: 1559235000 date_epoch_local: 2019-05-31 02:50:00 utcepoch: 
> 1559234000 date_epoch_utc: 2019-05-30 16:50:00 tz: Australia/Sydney 
> obsTimeUtc: 2019-05-30T16:50:00Z obsTimeLocal: 2019-05-31 02:50:00
> Number of WU records:  35
>
>
> Fri May 31 05:58:02 2019 UTC+10
> epoch: 1559245500 date_epoch_local: 2019-05-31 05:45:00 utcepoch: 
> 1559244500 date_epoch_utc: 2019-05-30 19:45:00 tz: Australia/Sydney 
> obsTimeUtc: 2019-05-30T19:45:00Z obsTimeLocal: 2019-05-31 05:45:00
> epoch: 1559245800 date_epoch_local: 2019-05-31 05:50:00 utcepoch: 
> 1559244800 date_epoch_utc: 2019-05-30 19:50:00 tz: Australia/Sydney 
> obsTimeUtc: 2019-05-30T19:50:00Z obsTimeLocal: 2019-05-31 05:50:00
> Number of WU records:  71
>
>
> Fri May 31 08:58:03 2019 UTC+10
> epoch: 1559256300 date_epoch_local: 2019-05-31 08:45:00 utcepoch: 
> 1559255300 date_epoch_utc: 2019-05-30 22:45:00 tz: Australia/Sydney 
> obsTimeUtc: 2019-05-30T22:45:00Z obsTimeLocal: 2019-05-31 08:45:00
> epoch: 1559256600 

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Rod Yager]

I constructed a cron job which exectued  wunderdates --date=2019-05-30 
 twice every hour, once 2 minutes before the hour and once 2 minutes after 
the hour.

Consistent with my earlier post, between 00:00+10 and 09:59+10 the reply 
from the api had data which belonged to 2019-05-31 - the day after the 
requested date. Before midnight, and after 10am local time, the reply from 
the api had data which belonged to 2019-05-30 (as requested).

I've pasted below some representative samples of the last 3 lines of the 
wunderdates output.

Before midnight on May 30: Request is for May 30 data. Replies are May 30 
data  Local Date = UTC date.

Thu May 30 20:58:02 2019 UTC+10
epoch: 1559213100 date_epoch_local: 2019-05-30 20:45:00 utcepoch: 
1559212100 date_epoch_utc: 2019-05-30 10:45:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T10:45:00Z obsTimeLocal: 2019-05-30 20:45:00
epoch: 1559213400 date_epoch_local: 2019-05-30 20:50:00 utcepoch: 
1559212400 date_epoch_utc: 2019-05-30 10:50:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T10:50:00Z obsTimeLocal: 2019-05-30 20:50:00
Number of WU records:  251


Thu May 30 22:58:03 2019 UTC+10
epoch: 155922 date_epoch_local: 2019-05-30 22:40:00 utcepoch: 
1559219000 date_epoch_utc: 2019-05-30 12:40:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T12:40:00Z obsTimeLocal: 2019-05-30 22:40:00
epoch: 1559220300 date_epoch_local: 2019-05-30 22:45:00 utcepoch: 
1559219300 date_epoch_utc: 2019-05-30 12:45:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T12:45:00Z obsTimeLocal: 2019-05-30 22:45:00
epoch: 1559220600 date_epoch_local: 2019-05-30 22:50:00 utcepoch: 
1559219600 date_epoch_utc: 2019-05-30 12:50:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T12:50:00Z obsTimeLocal: 2019-05-30 22:50:00
Number of WU records:  275


Thu May 30 23:58:02 2019 UTC+10
epoch: 1559223900 date_epoch_local: 2019-05-30 23:45:00 utcepoch: 
1559222900 date_epoch_utc: 2019-05-30 13:45:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T13:45:00Z obsTimeLocal: 2019-05-30 23:45:00
epoch: 1559224200 date_epoch_local: 2019-05-30 23:50:00 utcepoch: 
1559223200 date_epoch_utc: 2019-05-30 13:50:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T13:50:00Z obsTimeLocal: 2019-05-30 23:50:00
Number of WU records:  287


10 hour period after midnight on May 31. Request is for May 30 data. 
Replies are May 31 data.  Local Date is 1 day ahead of UTC date

Fri May 31 00:02:02 2019 UTC+10
Could not get Weather Underground data.
Reason: No JSON object could be decoded
Could not get Weather Underground data. Exiting. 


Fri May 31 00:58:02 2019  UTC+10
epoch: 1559227500 date_epoch_local: 2019-05-31 00:45:00 utcepoch: 
1559226500 date_epoch_utc: 2019-05-30 14:45:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T14:45:00Z obsTimeLocal: 2019-05-31 00:45:00
epoch: 1559227800 date_epoch_local: 2019-05-31 00:50:00 utcepoch: 
1559226800 date_epoch_utc: 2019-05-30 14:50:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T14:50:00Z obsTimeLocal: 2019-05-31 00:50:00
Number of WU records:  11


Fri May 31 02:58:03 2019 UTC+10
epoch: 1559234700 date_epoch_local: 2019-05-31 02:45:00 utcepoch: 
1559233700 date_epoch_utc: 2019-05-30 16:45:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T16:45:00Z obsTimeLocal: 2019-05-31 02:45:00
epoch: 1559235000 date_epoch_local: 2019-05-31 02:50:00 utcepoch: 
1559234000 date_epoch_utc: 2019-05-30 16:50:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T16:50:00Z obsTimeLocal: 2019-05-31 02:50:00
Number of WU records:  35


Fri May 31 05:58:02 2019 UTC+10
epoch: 1559245500 date_epoch_local: 2019-05-31 05:45:00 utcepoch: 
1559244500 date_epoch_utc: 2019-05-30 19:45:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T19:45:00Z obsTimeLocal: 2019-05-31 05:45:00
epoch: 1559245800 date_epoch_local: 2019-05-31 05:50:00 utcepoch: 
1559244800 date_epoch_utc: 2019-05-30 19:50:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T19:50:00Z obsTimeLocal: 2019-05-31 05:50:00
Number of WU records:  71


Fri May 31 08:58:03 2019 UTC+10
epoch: 1559256300 date_epoch_local: 2019-05-31 08:45:00 utcepoch: 
1559255300 date_epoch_utc: 2019-05-30 22:45:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T22:45:00Z obsTimeLocal: 2019-05-31 08:45:00
epoch: 1559256600 date_epoch_local: 2019-05-31 08:50:00 utcepoch: 
1559255600 date_epoch_utc: 2019-05-30 22:50:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T22:50:00Z obsTimeLocal: 2019-05-31 08:50:00
Number of WU records:  107


Fri May 31 09:58:03 2019 UTC+10
epoch: 1559259900 date_epoch_local: 2019-05-31 09:45:00 utcepoch: 
1559258900 date_epoch_utc: 2019-05-30 23:45:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T23:45:00Z obsTimeLocal: 2019-05-31 09:45:00
epoch: 1559260200 date_epoch_local: 2019-05-31 09:50:00 utcepoch: 
1559259200 date_epoch_utc: 2019-05-30 23:50:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T23:50:00Z obsTimeLocal: 2019-05-31 09:50:00
Number of WU records:  119

After 10AM on May 31: Request is for May 30 data. Repli

Re: [weewx-user] Abnormal Rain amount

[Andrew Milner]

I recommend you read the user guide.  There is a section on removing bad 
rain values.  Once you have edited the archive table the easiest way to 
recreate the high/low values is to use the wee_database utility to drop 
daily and rebuild daily.  It is all in the user manual.  Seriously though 
you will learn a lot by just reading through the user guide and the 
customisation guide and even if some things do not make much sense at first 
there is loads and loads of good information in them.



On Friday, 31 May 2019 04:22:33 UTC+3, dave.sp...@gmail.com wrote:
>
> Thanks. I was able to edit the archive database. 
>
>  
>
> My next question is where is the record high/lo data stored in? I need to 
> remove those entries?
>
>  
>
> Thanks
>
> Dave
>
>  
>
> *From:* weewx...@googlegroups.com   > *On Behalf Of *p q
> *Sent:* Thursday, May 30, 2019 6:12 PM
> *To:* weewx...@googlegroups.com 
> *Subject:* Re: [weewx-user] Abnormal Rain amount
>
>  
>
> You can start by tweaking the StdQC section in weewx.conf to limit the 
> erroneous values.  I don't know what causes it. I get random winds of 40 
> mph when I've never seen real wind above 20 in my sheltered location.
>
>  
>
> To fix it, I stop the weewx service (sudo /etc/init.d/weewx stop on my 
> raspberry PI). Make a backup copy of the database (/var/lib/weewx/weewx.sdb 
> is the default)  and then edit the database to remove the bogus entries. 
> You can use any SQLite database editor, but I copy it to my Windows PC and 
> edit it with DB Browser. You'll want the archive table. DB Browser lets you 
> filter the results. Look in the rain or maybe rainRate field. I'd just null 
> out the bad records or put in 0s. 
>
> Save and copy the file back and restart Weewx and you should be good to go.
>
>  
>
> When you're editing the db, one thing I find useful is to check the 
> dateTime field of the records that I'm editing. This is stored as unix 
> Epochs. Easiest way to convert to human readable time is to use a online 
> tool like https://www.epochconverter.com/
>
>  
>
> Good luck
>
>  
>
>  
>
> On Thu, May 30, 2019 at 4:02 PM > 
> wrote:
>
> Hello everyone, I am fairly new to running weewx and so far I love it. I 
> am running it on a raspberry pi with a separate MySQL server and HTTP 
> server. Here is my problem. This morning I was looking at the weather data 
> thru the http server and I noticed that I received a very large amount of 
> rain, but in fact there is no rain at the place of my sensor. So I have a 
> couple of questions. 1st – Is there a way to see what triggered the large 
> amount of rain? It measured 5+ inches of rain. 2nd – Is there a way to 
> adjust or remove that entry so it doesn’t skew the data? 3rd – I have 
> seen this a couple of times, but is there a way to help prevent this?
>
>  
>
> Thanks
>
> Dave
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/19e001d5173b%249ed27680%24dc776380%24%40gmail.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>  
>
> -- 
>
> Peter Quinn
> (415)794-2264
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to weewx...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/CAA1SM234TY4DEEGgtUb_3y08VprjFPGUaZ1KON7DSSfsKHx5PQ%40mail.gmail.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/37bdf145-3a10-4847-a3f4-7c5537eb2e46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [weewx-user] Abnormal Rain amount

[dave.spicer2012]

Thanks. I was able to edit the archive database. 

 

My next question is where is the record high/lo data stored in? I need to 
remove those entries?

 

Thanks

Dave

 

From: weewx-user@googlegroups.com  On Behalf Of p q
Sent: Thursday, May 30, 2019 6:12 PM
To: weewx-user@googlegroups.com
Subject: Re: [weewx-user] Abnormal Rain amount

 

You can start by tweaking the StdQC section in weewx.conf to limit the 
erroneous values.  I don't know what causes it. I get random winds of 40 mph 
when I've never seen real wind above 20 in my sheltered location.

 

To fix it, I stop the weewx service (sudo /etc/init.d/weewx stop on my 
raspberry PI). Make a backup copy of the database (/var/lib/weewx/weewx.sdb is 
the default)  and then edit the database to remove the bogus entries. You can 
use any SQLite database editor, but I copy it to my Windows PC and edit it with 
DB Browser. You'll want the archive table. DB Browser lets you filter the 
results. Look in the rain or maybe rainRate field. I'd just null out the bad 
records or put in 0s. 

Save and copy the file back and restart Weewx and you should be good to go.

 

When you're editing the db, one thing I find useful is to check the dateTime 
field of the records that I'm editing. This is stored as unix Epochs. Easiest 
way to convert to human readable time is to use a online tool like 
https://www.epochconverter.com/

 

Good luck

 

 

On Thu, May 30, 2019 at 4:02 PM mailto:dave.spicer2...@gmail.com> > wrote:

Hello everyone, I am fairly new to running weewx and so far I love it. I am 
running it on a raspberry pi with a separate MySQL server and HTTP server. Here 
is my problem. This morning I was looking at the weather data thru the http 
server and I noticed that I received a very large amount of rain, but in fact 
there is no rain at the place of my sensor. So I have a couple of questions. 
1st – Is there a way to see what triggered the large amount of rain? It 
measured 5+ inches of rain. 2nd – Is there a way to adjust or remove that entry 
so it doesn’t skew the data? 3rd – I have seen this a couple of times, but is 
there a way to help prevent this?

 

Thanks

Dave

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com 
 .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/19e001d5173b%249ed27680%24dc776380%24%40gmail.com
 

 .
For more options, visit https://groups.google.com/d/optout.




 

-- 

Peter Quinn
(415)794-2264

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com 
 .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAA1SM234TY4DEEGgtUb_3y08VprjFPGUaZ1KON7DSSfsKHx5PQ%40mail.gmail.com
 

 .
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/000d01d5174f%2450275d70%24f0761850%24%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Abnormal Rain amount

[p q]

You can start by tweaking the StdQC section in weewx.conf to limit the
erroneous values.  I don't know what causes it. I get random winds of 40
mph when I've never seen real wind above 20 in my sheltered location.

To fix it, I stop the weewx service (sudo /etc/init.d/weewx stop on my
raspberry PI). Make a backup copy of the database (/var/lib/weewx/weewx.sdb
is the default)  and then edit the database to remove the bogus entries.
You can use any SQLite database editor, but I copy it to my Windows PC and
edit it with DB Browser. You'll want the archive table. DB Browser lets you
filter the results. Look in the rain or maybe rainRate field. I'd just null
out the bad records or put in 0s.
Save and copy the file back and restart Weewx and you should be good to go.

When you're editing the db, one thing I find useful is to check the
dateTime field of the records that I'm editing. This is stored as unix
Epochs. Easiest way to convert to human readable time is to use a online
tool like https://www.epochconverter.com/

Good luck


On Thu, May 30, 2019 at 4:02 PM  wrote:

> Hello everyone, I am fairly new to running weewx and so far I love it. I
> am running it on a raspberry pi with a separate MySQL server and HTTP
> server. Here is my problem. This morning I was looking at the weather data
> thru the http server and I noticed that I received a very large amount of
> rain, but in fact there is no rain at the place of my sensor. So I have a
> couple of questions. 1st – Is there a way to see what triggered the large
> amount of rain? It measured 5+ inches of rain. 2nd – Is there a way to
> adjust or remove that entry so it doesn’t skew the data? 3rd – I have
> seen this a couple of times, but is there a way to help prevent this?
>
>
>
> Thanks
>
> Dave
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/19e001d5173b%249ed27680%24dc776380%24%40gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Peter Quinn
(415)794-2264

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAA1SM234TY4DEEGgtUb_3y08VprjFPGUaZ1KON7DSSfsKHx5PQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Abnormal Rain amount

[dave.spicer2012]

Hello everyone, I am fairly new to running weewx and so far I love it. I am
running it on a raspberry pi with a separate MySQL server and HTTP server.
Here is my problem. This morning I was looking at the weather data thru the
http server and I noticed that I received a very large amount of rain, but
in fact there is no rain at the place of my sensor. So I have a couple of
questions. 1st - Is there a way to see what triggered the large amount of
rain? It measured 5+ inches of rain. 2nd - Is there a way to adjust or
remove that entry so it doesn't skew the data? 3rd - I have seen this a
couple of times, but is there a way to help prevent this?

 

Thanks

Dave

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/19e001d5173b%249ed27680%24dc776380%24%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: Not getting data in WeeWX from alecto WS-5500, tcpdump is getting data

[Roy Rutten]

After looking further into the interceptor.py file I found there are 
specific settings dependent on whether you configure listen or sniff, this 
was not clear for me from the main readme (probably my reading 
comprehension in english). Once I understood this and tested buth listen 
and sniff I found with the correct settings that sniff is working correctly 
now. So I managed to resolve my problem.

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/c98338a8-00e2-43eb-8158-e42025973a82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Davis Vantage Pro2 no data

[John]

Andrew,

I am not having a problem with records in the weewx database with incorrect 
timestamps. I am having a problem with weewx not downloading data from the 
console after an extended power outage.  The underlying problem seems to be 
that if weewx updates the console clock to something earlier than the last 
record in the console's data logger, then weewx will break.  The quick 
solution is to disable weewx from updating the console clock. 



On Wednesday, May 29, 2019 at 9:32:55 PM UTC-5, Andrew Milner wrote:
>
> John
> the issue is not with syncing the clock as such.  The issues are caused by 
> records in the database with weewx generated timestamps which will be 
> incorrect if weewx is started with an incorrect time set on the rpi.  The 
> solution is to install an rtc on the rpi and to be honest I just do not 
> understand your reluctance since they only cost 10-12 dollars.  a computer 
> needs a clock - a teaching aid (as the rpi was designed for originally) 
> doesn't.  Give your RPi a clock!
>
>
>
> On Thursday, 30 May 2019 00:26:54 UTC+3, John wrote:
>>
>> I've disabled weewx from syncing the vantage console's clock. I had an 
>> another power outage yesterday for a bit over an hour and everything seemed 
>> to eventually recover without intervention. The battery backed clock in the 
>> vantage console seems to be adequate. Most routines for syncing battery 
>> backed clocks seem to protect against gross changes, requiring a 
>> manual/forced update if the time deltas are larger than a routine drift. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/ac110c9f-efe4-4af8-8e73-e63b0e2396dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Help with install weewx on Linux to upload to weather underground

[Ken K]

I have a friend who wants to get his Davis Vantage Vue working on a Linux.  
He is brand new to Linux and is looking a how to.
He has been trying for a couple months with no success finding a how to 
that is basic enough with a clear step by step for
someone with zero Linux experience.  I own a raspeberry pi but only use it 
with ready made booting software so I am useless
to him for help.

He has the stock USB interface, not a after market).  The system works 
perfectly on his Windows 7 uploading data to wx underground.
He has a spare computer, linux is free and wants to give it a go for a 
dedicated computer or pick up a raspberry pi.

Any pointers for a "weewx for dummies" would be much appreciated.   

thanks
Ken

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/229b8789-ddfd-4eab-a4db-2f9b900f5fcc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Davis Vantage Pro2 no data

[mwall]

On Tuesday, May 28, 2019 at 11:00:09 AM UTC-4, John wrote:
>
> I propose changing the vantage driver to avert setting the console time, 
> during a routine sync, earlier than the last record in the console. This 
> should prevent weewx from adjusting the console time until the weewx host 
> has had an opportunity to successfully acquire the time from an external 
> source (ntp server).   I suppose setting the console to a future time could 
> cause a problem, preventing weewx from correcting the console time without 
> first clearing the last (errant) record.
>

merge requests are welcome!

it might help to clarify the scenarios before pushing for a specific 
solution.

scenario 1: standalone rpi.  options are to install a clock, depend on ntp, 
or both.  if network is flaky, then the clock might be preferred.  in 
either case, get rid of fakehwclock.  if you depend on setting time over 
the network, then absolutely get rid of the systemd timesync and install a 
real service such as ntp.

scenario 2: rpi on your own network where you can control time.  run an ntp 
server on your network, sync it to a other ntp servers or your own gps or 
other device with known reliable time.  get rid of any systemd rubbish and 
install ntp on the rpi, then configure it to use your time server.

scenario 3: use the weather station's clock to set the rpi clock.  this 
could be done independently of weewx, and probably in a pretty generic way 
that could work for many types of stations.  or it could be done in the 
weewx driver (less desirable).  or it could be done as a generic weewx 
service.  you'll probably never get it to be as accurate as ntp, but it 
might be good enough.

i am sure there are other scenarios...

m

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/510ed650-de25-4d57-b188-95a4ef752d94%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Davis Vantage Pro2 no data

[Oliver Giessler]

Just my 2 Cent as the thread opener:

I solved my problem by removing the batteries from my Vantage Pro2 and 
having just the powercord. Do not ask my why this solved it …




On 28 May 2019, at 17:15, Andrew Milner wrote:

I would recommend you doing the CORRECT solution and installing an RTC 
on

your Pi zero.  Weewx relies HEAVILY on accurate time synchronisation
between weather station and controlling PC - so ensuring your pi 
EITHER has
an RTC onboard OR prevents weewx starting until time has been 
synchronised

is ESSENTIAL for correct operation.

There are many many users of weewx with Davis stations, and many many 
of us

with various models of RPi.  There are also many instances of logger
corruptions and other anomolies.. so fudging the driver for one 
situation
may open a can of worms in another situation - you have been 
warned!




On Tuesday, 28 May 2019 18:00:09 UTC+3, John wrote:


so looking at the vantage driver it seems that if the weewx host
(raspberry pi zero without a RTC) has an incorrect time like after a
restart and syncs it's bad (early) time with the vantage console, 
then
records being added to the vantage console will have an earlier 
timestamp
than existing records. when weewx goes to read the records and finds 
a
"decreasing timestamp" it stops reading more records. manually 
clearing all

the records AND setting the correct time is a solution.

I propose changing the vantage driver to avert setting the console 
time,
during a routine sync, earlier than the last record in the console. 
This
should prevent weewx from adjusting the console time until the weewx 
host
has had an opportunity to successfully acquire the time from an 
external
source (ntp server).   I suppose setting the console to a future time 
could
cause a problem, preventing weewx from correcting the console time 
without

first clearing the last (errant) record.




--
You received this message because you are subscribed to a topic in the 
Google Groups "weewx-user" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/weewx-user/UM-q_RNK_Ps/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/32f79d61-7d81-4bc0-adab-6d1ad66de99c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2D60CD0D-A875-4959-8D80-D83DEA6A2C0C%40giessler.de.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: We have finally put the last nail on the coffin for Wunderfixer?

[Rod Yager]

Have downloaded the wunderdates. 

I am in the UTC+10 timezone.

So far, my experience is that when the current time is between 00:00+10 and 
09:59+10  (14:00UTC to 23:59 UTC) (so the local date is one day in advance 
of the UTC date), the API fetches data for the local-time day immediately 
following the date specified in the URL.  ie a request with date=20190528 
returns the data observations recorded on 20190529 local time.

At all other times (so far) the api returns the data for the local time day 
specified in the request URL (as expected).

>From what I understand, you are in the UTC-4 time zone and your experience 
is that when the current time is between 20:00-4 and 23:59-4 (00:00UTC to 
03:59UTC) (so the local date is one day behind the UTC date), the API 
fetches data for the local-time date immediately before the date specified 
in the URL. ie a request with date=20190529 returns the data for 
observations recorded on 20190527 local time. 

At all other times, I gather the api returns the data for the local time 
day specified in the request URL (as expected).

I'll conduct further tests, and will certainly report anything that doesn't 
fit my hypothesis that the unwanted behaviour reflects the difference 
between the current local time date and the current UTC date. But its 
difficult to see how there could be more to it than this. (Famous last 
words).

It's now 20:14+10 on 20190530  (10:14UTC on 20190503) The last three lines 
of  produced by ./wunderdates  are (as expected)

epoch: 1559210400 date_epoch_local: 2019-05-30 20:00:00 utcepoch: 
1559209400 date_epoch_utc: 2019-05-30 10:00:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T10:00:00Z obsTimeLocal: 2019-05-30 20:00:00

epoch: 1559210700 date_epoch_local: 2019-05-30 20:05:00 utcepoch: 
1559209700 date_epoch_utc: 2019-05-30 10:05:00 tz: Australia/Sydney 
obsTimeUtc: 2019-05-30T10:05:00Z obsTimeLocal: 2019-05-30 20:05:00

Number of WU records:  242


Rod

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/59d22f5e-051c-459d-bc38-b02c087a21c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: [ANNOUNCE] weewx-aqi: A Plugin for Air Quality Index Calculations

[Hartmut Schweidler]

Hallo,

I'm looking for an example in aqi.html.tmpl

like "AQIs have categorical labels associated with the AQI values. The 
index of the current category is available via 
$latest('aqi_binding').aqi_pm2_5_category. From this, the label and color 
category can be found via (hex_color, category_label) = 
service.aqi_standard.interpret_aqi_index(index)"

ich suche nach einem Beispiel für die Verwendung der Farben in einer 
AQI-Seite

Hartmut

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/dc708df1-348b-456f-bd17-f780294c7c9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.