Nulls are not a problem, have a look in your database and I am sure you will
find heaps, for example sites that have no uv sensor will have null in their uv
field. In fact you could say weewx relies on them, a null in a field indicates
there is no observation as opposed to it being 0.
Gary
--
Thanks so much, Gary, I really appreciate the detailed response. :)
The only reason I was thinking two tables might be appropriate was because
I was going to use the standard Unix Epoch timestamp as the primary key
each time data is written. So each time a row is created, one of the
values
Hi,
People are seldom on the wrong track, just on a longer or more difficult
one! A few things to think about
1. Leverage off the weewx code wherever possible, weewx already does
everything you will want to do except calculate the 'day' and 'night'
temperatures. The service StdArchive
Okay, I got some basic thoughts down and I think I'm ready to actually
create a service. Or something. This is a simple task and there's a bunch
of ways to do it, so I'm coming across a lot of "where do I do it"
questions. Do I write more code and have my python file do it manually, or
do I
At this point I'm starting to feel like this would be a neat little project
for me to get familiar with a number of things (weewx, python, sqlite,
etc.), so I'm feeling a bit ambitious and think I'll give this a try myself.
I definitely think storing the info in a database is the way to go.
weewx-WD provides warmest night/coldest day stats by maintaining two fields,
outTempDay and outTempNight, in the weewx-WD database. Data is stored using the
0600-1800 day. Aggregates over month, year all time etc now become very simple,
just part of the standard weewx machinery and you avoid
On Monday, January 16, 2017 at 9:06:24 AM UTC-8, mwall wrote:
>
> you could write a separate, standalone tool to backfill - it would crawl
> through your existing data and bring the separate database up to date.
>
>
>
It kind of sounds like a NOAA monthly report, just with the start of a
"day"
Yes, I was thinking along those lines as well. This might be the best
approach since you're not continually calculating something against a
steadily increasing set of data. Putting it in the database would also
allow you to see these stats whenever you want, however you want (i.e.,
coldest
My initial reaction is that this would become an incredibly time consuming
calculation without having a additional daily night and day tables holding
max and min like the existing daily tables, and have an associated
service updating them. Thinking aloud perhaps the same can be achieved by
