How does WeeWx use the database file?

148 views
Skip to first unread message

DR

unread,
Sep 11, 2023, 11:10:51 AM9/11/23
to weewx...@googlegroups.com
I'm just thinking about another project, and wonder how WeeWx uses the
default database.


When it is running does it open and leave open the database all the time?

If so, is the database able to have another program add records to the
database while WeeWx has it open?

The reason I ask, is that I would like to have another program running
which reads snow depth from a Campbell Scientific table, then add that
value to the standard database at say 15 minute intervals with a field
defined and added to the schema.

In some days past, I know some databases would prevent more than one
attempt to access it, even if not in the traditional deadly embrace
situation.

If WeeWx is busy stuffing new values in every 2 seconds during loop
functions, can I also access it simultaneously as long as I don't try to
touch the fields that WeeWx is writing to?


Or is it necessary to shut down, briefly, access, then have the snow
depth program open it, write the value, close it and then let WeeWx go
merrily on it's way?

I hope this question is within the scope of this user discussion.  Dale


weather list

unread,
Sep 11, 2023, 11:34:43 AM9/11/23
to weewx...@googlegroups.com
Can you not simply add that snow depth DB as another data binding in weewx.conf and read the data from it as needed?

From the docs:

Binding names

While most users will only need the one weather database that comes with WeeWX, the reporting engine allows you to use multiple databases in the same report. For example, if you have installed the cmon computer monitoring package, which uses its own database, you may want to include some statistics or graphs about your server in your reports, using that database.


--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/918b02a3-72d7-f7f7-2e77-a3a374489a85%40gmail.com.

weather list

unread,
Sep 11, 2023, 11:40:19 AM9/11/23
to weewx...@googlegroups.com
Can you not simply add that snow depth DB as another data binding in weewx.conf and read the data from it as needed?

From the docs:

Binding names

While most users will only need the one weather database that comes with WeeWX, the reporting engine allows you to use multiple databases in the same report. For example, if you have installed the cmon computer monitoring package, which uses its own database, you may want to include some statistics or graphs about your server in your reports, using that database.

On 11 Sep, 2023, at 11:10, DR <wxe...@gmail.com> wrote:

Tom Keffer

unread,
Sep 11, 2023, 12:00:09 PM9/11/23
to weewx...@googlegroups.com
I'm not sure your approach is the best one, but to answer your questions:

1. Yes, WeeWX opens the database and leaves it open.
2. Contention is managed by the SQLite database. See this documentation.
3. Unless an extension is acting otherwise, WeeWX does not write with every LOOP packet. Only when archive records arrive.

DR

unread,
Sep 11, 2023, 1:57:47 PM9/11/23
to weewx...@googlegroups.com

Thank you for not only the information, but the link to learn more.  I appreciate that.

Since this group lives and breathes solutions, I'm curious as to the comment that my approach (as you can tell, a very inexperienced programmer) was the best way.

The only other thought I would have would be to create my own little SQLite data base (one filed other than the date and time) and have WeeWx use that new database as a second source of information, rather than try to just stuff one more new field in the schema.  Does someone have a more reasonable and sensible approach than what I suggested?  Just a key word or two for me to go looking would be helpful.  Dale

p q

unread,
Sep 11, 2023, 2:02:37 PM9/11/23
to weewx...@googlegroups.com
I was going to add just one field to the database, I would repurpose an existing field that is unused but has a similar unit. If you're going do more than 5 fields, then doing your own db may be the better way. If you're writing a single value every 15 min, I wouldn't worry about performance/locking issues.



--
Peter Quinn
(415)794-2264

DR

unread,
Sep 11, 2023, 2:06:53 PM9/11/23
to weewx...@googlegroups.com
Thank you.  That is helpful.

I didn't think it was permissible to fiddle with fields which are
defined, even if unused, but since I'm the only one using it, I guess it
wouldn't hurt.


I scanned the link to the SQLite discussion of how fields are written
and I'm amazed how how the 'lite' program works.  Some major smarts go
into these things.  Thank you.  I'm sure I'll be even more amazed when I
read it again a few times.


Thank you for the guidance. Dale


Tom Keffer

unread,
Sep 11, 2023, 2:55:18 PM9/11/23
to weewx...@googlegroups.com
The WeeWX database includes a "daily summary," which is a synopsis of data for a day. Things like the minimum value for the day, what time it occurred, etc. It's an optimization strategy. See the documentation Daily summaries.

So, if you did it your way, you would have to either maintain the daily summary for your new type yourself, or forgo the optimizations that it gets you. 

It's much easier to leverage the machinery that WeeWX already gives you. See this wiki article, Strategies for getting data into weeWX

As for the database, with V4.5 or later, it's super easy to add and subtract columns from the database. See the documentation for wee_database, options --add-column and --drop-columns.

-tk



On Mon, Sep 11, 2023 at 10:57 AM DR <wxe...@gmail.com> wrote:

DR

unread,
Sep 11, 2023, 3:52:27 PM9/11/23
to weewx...@googlegroups.com
Thanks for this clarification.


I've been reading the documentation, again, especially pertaining to the
database.

The discussion talks about removing columns which one never will use
(such as extra temps or soil temps) or renaming.

I was under the initial assumption that the default schema (the extended
one) was sacrosanct and should not be touched, but this makes it clear
it is OK to modify the database on my installation as I needed it
without too much fear of breaking something.

This is reassuring and I'll keep planning.  Thank you for all the
answers and discussions.  Dale

Reply all
Reply to author
Forward
0 new messages