[Babase] WeatherHawk design review

Karl O. Pinc kop at meme.com
Fri Jul 3 00:07:54 EDT 2009


On 07/02/2009 04:31:12 PM, Niki Learn wrote:

> On the rain decimal thing:

<snip>

>  Also, as I
> understand
> it the rain gauge only reads rain in whole mm and does not in fact
> take a
> reading if there is less than 1 mm of rain, a situation which has led
> us to
> wonder how much the weatherhawk is underestimating the amount of rain
> due to
> evaporation of small amounts of rain between rain events.  Therefore
> there
> should not be decimals for rain measurements in any case.

I was bumping around the weatherhawk.com site and noticed that it
claims accuracy to 1mm.  That does not mean that it does not report
with higher precision.  Maybe it needs the higher precision to
avoid roundoff errors that would make it less accurate?  I don't
work with instrumentation regularly and haven't spent a lot of
thought on this so maybe I'm wrong here.  It would be nice to
get rid of the decimal points.

> 
> There was no data provided for 2300 on 2005-07-02 - that row should be
> deleted.  I was not aware of duplicate date/times occurring.  A quick
> look
> at t29/05/2009 shows me identical data for the two dates.  I will
> verify
> that the others are like the same and then we can delete the extra
> rows.
> Problem solved.

Yay!   700+ rows are a lot to delete manually.  It might be
easier to delete with a sql delete statement and re-upload.

Maybe things got uploaded twice?


> Questions/comments on the whawks documentation page:
> 
> At the top: "This table is not yet implimented."  This should be
> implemented.
> 
> I don't know what you mean by this: "The WeatherHawk data dump encodes
> this
> value in two separate places."  Where's the other place besides in the
> time
> column?

The date is in one place and the time another.
The date is recorded in the upper left hand cell of the spreadsheet.
There seems to be one spreadsheet per date.

To upload the data into babase you'll need to mess with the
raw weatherhawk dump to get the date and time into one column.
I'm guessing that the spreadsheet column would be textual;
I'm not sure what Tabby did to do the same thing with the
manual weather data -- put a date and time into one
column.  I assume there's a macro involved to make it
painless.

> 
> On YearRain: "The amount of rain since 12AM January 1st[133] in
> millimeters."  Crazy question - wouldn't rain measured at 12am on
> January
> 1st actually be the last hour of rain for the previous year since the
> rain
> would have been collected between 11pm and 12am?  Not sure if that's
> worth
> bothering with, especially since the weatherhawk counts it as a
> January 1st
> measurement (though really, at least for rain, it should belong with
> the day
> before).  Feel free to tell me to stop overanalyzing...

We're overanalyzing now so that we get it out of the way
and don't have to do it repeatedly in the future.  ;-)

My intention was that "The amount of rain since" is
"the rain that has fallen since that time", not
"the sum of the rain measurements starting at that
time".  In other words, "since" is not supposed to
be inclusive.

I can't come up with better wording this hot minute,
and I'm not the one who the docs are written for
anyway.  So this is where I stand back and take
suggestions for a better wording.

> 
> Are we sure EV and ET are the same thing?

No.  I'm not very sure of all that much when it comes
to some of these columns.  I'm guessing that an older
version of the weatherhawk software reported evaporation
and the newer stuff now reports evapotranspiration.
My guess is that the computation did not change
and they were sloppy in their original column names.
I do know that either one or the other value is present,
never both, so it's not as if any data is actually lost
if we record the switchover date somewhere.

I'm making
these guesses because I don't see any reason to stop
reporting a value (evaporation) and replace it with
something different.  If they're computing a new
value rather than just changing the name of the column
I can't think of a reason why they would not just
output another column.  (Well, I couldn't at the
time.  Now that you mention it I can.)
IIRC the weatherhawk.com marketing materials play
up the "manage your garden" aspect, which makes
me think that it was always evapotranspiration.

The way to find out is to either dig up the manuals,
on-line or physically, or contact the company.
If that does not work then it could be that we don't
know how the value is computed anyway and we may
as well not record the data in Babase.  If it's
computed and not the output of an instrument
then there's no real point in storing it
because we could re-compute it anyhow.
(Maybe from temperature, windspeed, and relative humidity?)

> 
> On Heat_lx_in: "The WeatherHawk data dump names this column "Heat Lx
> In"."
> It's actually Ix - I and l look practically the same in Excel but the
> I is
> shorter - I checked and it is definitely an I.  Ix is probably short
> for
> index but I don't know what these "in" measurements are supposed to
> mean...

Ok.  If we keep this column I'll fix it.   I think I looked at
the data and found it to be either 0 or 17 or NULL, but
maybe I'm confusing it with something else.

> 
> On DayRain: "The amount of rain since midnight[136] in millimeters
> with 2
> decimal points of precision."  The weatherhawk does reset this value
> at
> midnight (see for example Oct 18-19, 2004) but that means it is really
> rain
> since 2300 the day before - this goes back to that problem of the
> weatherhawk counting midnight with the am hours for rain even though
> it is
> really measuring rain in the last pm hour.

I suspect that the weatherhawk is reporting only 23 hours of rain.
(It stupidly clears the totals before it's midnight report instead
of after.)  I ran the following query (in babase_copy,
you'll need to tweak if you want to use the babase_pending.whawk
table):

select whdaytime, hourrain, dayrain
   from whawks
   where extract('hour' from whdaytime) = '23'
         and hourrain != 0
   order by whdaytime;

and got no results.  Is it possible that it never rained
in the 23:00 hour?

This is also interesting (although not accurate because
of the duplicate rows):

select extract('hour' from whdaytime) as hour, count(*), avg(hourrain)
   from whawks
   where hourrain != 0
   group by hour
   order by hour;

(Note that 23:00 does not show up.)

If I'm right you could test by setting the clock
on a weatherhawk to 23:00 (or 22:00?), using a watering can,
and waiting an hour.

I tried retrieving the 23:00 hour rainfall from the
lst24hrrain column but had no luck:

select wh2.whdaytime, wh2.lst24hrrain - wh1.lst24hrrain
   from whawks as wh1, whawks as wh2
   where wh2.whdaytime = wh1.whdaytime + '1 hour'::interval
         and extract('hour' from wh2.whdaytime) = 23
         and wh1.lst24hrrain = wh2.lst24hrrain
   order by wh2.whdaytime;

> It might be too much to
> go
> against the weatherhawk to fix but we should be clear in documentation
> that
> the 11pm - 12am hour is included with the day that begins at 12am, no?
>  Of
> course explaining it clearly might be a challenge too...  Same basic
> comment
> for MonthRain.

I suspect also for YearRain.



Karl <kop at meme.com>
Free Software:  "You don't pay back, you pay forward."
                  -- Robert A. Heinlein



More information about the Babase mailing list