gjr80 writes:
Thank you for taking the time to explain things to me. I misunderstood
a few things, which may just be me, or may be useful for enhancing the
docs (which are very impressive).
> WeeWX is doing exactly what it should/has been told to do. Inside
> dewpoint is not provided by Davis VP2 hardware (have a look at the
> loop, loop2 and rev A/rev B archive records in the Davis Serial
> Communications Reference (about page 30 in
> https://www.davisnet.com/support/weather/download/VantageSerialProtocolDocs_v261.pdf).
> StdWXCalculate
> has been told to 'prefer' gettting inside dewpoint from
> hardware. Since the hardware doesn't provide inside dewpoint weeWX
> calculates it instead (if it was set to hardware_only the weeWX would
> not calculate it) and adds it to loop packets and archive
> records. That explains why you are seeing inDewpoint.
I assumed it was from the hardware because the LOOP line output on
stdout (I am saving to a file, not using --daemon, for now) had it. I
realize now (I think) that the LOOP line is a virtual LOOP packet which
has the hardware-supplied values and the calculated values.
> As Vince said weeWX defaults to using the wview schema and the wview
> schema does not include inDewpoint, so weeWX does not save inDewpoint
> to the database (by default weeWX will save to the database any fields
> in an archive record that are also defined in the db schema you are
> using).
So fields that are calculated by StdReport will just be dropped, if they
aren't in the schema. That makes sense now that I understand the grand
plan, but I didn't expect that. (I did read most of the docs all the
way through quickly before starting to use weewx, and I have never used
any other weather logging software.)
> In terms of reports, something like $current.inDewpoint will
> work because reports can use any field in the current archive record
> without having saved it to the database. However, any aggregates eg
Ah. That explains my confusion when indeed that worked. I knew
something was wrong when adding inDewpoint to the inTemp graph threw an
exception.
> $day.inDewpoint.max used in a report or plotting inDewpoint will not
> work as these require inDewpoint to be saved to the database. There
> are a number of ways to add inDewpiunt to the database, you can extend
> the current schema (as Vince points out) or you could add a new
> database. The former will be easier. This link might help
> http://weewx.com/docs/customizing.htm#archive_database
Thanks. I found that from Vince's hint and it explained exactly how to
do things. I just adjusted my sources, did a backup and ran
wee_database --config, and now things are fine.
The other thing that might be good to make clear -- but maybe this is
getting into nits that are confusing rather than helpful for new poeple
-- is that all the calculations are either at LOOP or just before
archive time, and do not work to synthesize values from the existing
data for use in graphs.
I don't mean to sound cranky. My out-of-box experience with weewx has
been far smoother than I could possibly expect given the inherent
complexity of the problem, and the effort to do something odd has been
very small.
(I realize I'm quite odd for wanting indoor dewpoint. Basically I'm
concerned about indoor humidity and want to keep an eye on my
humidifier, and am curious to see how dewpoint tracks because the
temperature varies with day/night setpoints. Outdoors, I find humidity
to be a confounded combination of dewpoint and temp, and don't pay much
attention to it. It may be that indoors, it's really humidity that
matters, since for values one wants, it tends to zero absent the forced
humidifier -- my outdoor dewpoint is -2.3F right now.)
Greg Troxel
--
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.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
