How to clear and recaculate records in Belchertown

124 views
Skip to first unread message

RonV42

unread,
Jun 7, 2025, 10:07:22 AM6/7/25
to weewx-user
I had to replace my Tempest station and the new one they sent didn't have the radiation and lux sensor properly calibrated.  This effected the records in the Belchertown skin where I now have the radiation exposure of the planet Mercury as a record on May 27th.  I set all the data values to null and rebuilt daily and fixed the graphs but the record for that measurement doesn't seem to want to clear and be re-canulated.  Any idea's on how to fix this? 

Thanks

vince

unread,
Jun 7, 2025, 11:29:19 AM6/7/25
to weewx-user
Quick glance seems to say it is displaying $alltime.radiation.max and $alltime.radiation.maxtime.raw like any other skin would, so it doesn't seem like Belchertown does anything special in how it displays records.

Check your db again.  Guessing you missed something.

https://github.com/weewx/weewx/wiki/Cleaning-up-old-bad-data has the wiki answer, but I do it a 'little' differently.  Capturing it here for future-me.....

Here's how to query your tables to look for records you missed cleaning up, using my db as an example.  In my case I had a failing anemometer that used to record absurdly high readings.  Looks like I neglected to clean up windGust back years ago when I cleaned up the sustained wind values, so I have some crazy readings still in there for windGust that I'll use as an example.

# find daily maximums that were over a reasonable high for this location
pi@pi4:~/weewx-data/archive$ echo "select datetime(dateTime,'unixepoch','localtime'),datetime,max from archive_day_windGust where max > 50;" | sqlite3 vp2.sdb
2018-03-27 00:00:00|1522134000|57.0
2018-04-15 00:00:00|1523775600|67.0
2018-04-17 00:00:00|1523948400|59.0
2018-09-11 00:00:00|1536649200|64.0
2018-09-22 00:00:00|1537599600|52.0

# verify those maximums came from archive table readings for those days
pi@pi4:~/weewx-data/archive$ echo "select datetime(dateTime,'unixepoch','localtime'),datetime,windGust from archive where windGust > 50;" | sqlite3 vp2.sdb
2018-03-27 11:15:00|1522174500|55.0
2018-03-27 11:20:00|1522174800|55.0
2018-03-27 12:15:00|1522178100|57.0
2018-03-27 12:20:00|1522178400|57.0
2018-04-15 06:45:00|1523799900|67.0
2018-04-15 06:50:00|1523800200|67.0
2018-04-17 02:30:00|1523957400|59.0
2018-04-17 02:35:00|1523957700|59.0
2018-04-17 03:05:00|1523959500|52.0
2018-04-17 03:10:00|1523959800|52.0
2018-09-11 10:00:00|1536685200|53.0
2018-09-11 10:30:00|1536687000|54.0
2018-09-11 10:35:00|1536687300|64.0
2018-09-22 17:15:00|1537661700|52.0

# clean up the archive table - perhaps should set windGust=0 here in this example
echo "update archive set windGust=NULL where windGust > 42;" | sqlite3 vp2.sdb

# rebuild-daily for just the 5 days in the output above.....
weectl database rebuild-daily --date=2018-03-27
(and so on)

Note - you should really work off a 'copy' of your db anytime you want to modify it.  It's a little interesting to me that weectl database doesn't have an easy to use "--from filename.sdb" kind of option to pick the filename of the 'copy' of the db that you want to mess with.  I suppose it can be faked with a bogus weewx config file to run against via the --config option.  Maybe others have better ease of use ideas.

RonV42

unread,
Jun 9, 2025, 7:00:51 AM6/9/25
to weewx-user
Thanks I will dig deeper into the archive as you suggested I have done cleanup many times with false rain and wind and use "zeros' for the value.  I am going to try setting zeros around the time where the station was reporting excessive radiation.

vince

unread,
Jun 9, 2025, 11:00:47 AM6/9/25
to weewx-user
I cleaned mine up yesterday as I suggested and Belchertown records caught up just fine.

RonV42

unread,
Jun 15, 2025, 9:24:53 AM6/15/25
to weewx-user
Though I posted this yesterday but I wasn't able to see it.  Anyway cleaned up the records I updated with NUL and put in the value 0.0 for the radiation fields and after a few runs of Belchertown the record high of Solar is now gone.   The NUL value was the root of the issue.
Reply all
Reply to author
Forward
0 new messages