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 (class StdArchive in engine.py) takes care of saving obs to database, service StdWxCalculate (class StdWXCalculate in wxservices.py) adds derived obs to the loop packets and archive records. 2. You could put everything in one service but I would do it in two to keep in line with the weewx architecture. I would have one service, derived from StdWxCalculate, that calculates 'day' and 'night' temperature and adds them to loop packets and archive records. I would have another service, derived from StdArchive, that takes care of getting your data into the database. No need to be copying from database to database or creating databases yourself, just define a schema for your archive table, put it in a file in bin/weewx/user (can use extensions.py or create your own) and when properly defined in weewx.conf (bindings etc) your derived StdArchive service will take care of almost everything for you. I would suggest you famialiarise yourself with StdArchive and StdWXCalculate. 3. Why have two tables, why not one? It keeps it simpler and you only need to remember one binding when using tags in a template. Think carefully about the names for you new obs, they will be used in tags in your templates to display the data. For example, $day($binding=new_binding).day.max will display the max daytime temp for today so far (assumes your new database is bound to the binding new_binding). Weewx obs fields are typically a little more informative as to what it is they are measuring, what does 'day' measure? Maybe something like $day($binding=new_binding).outTempDay.max might be better, now the obs name hints at what it holds. But to do this would require you yo use the column outTempDay in your database. So a little bit of thought and planning up front will help in the end. 4. I would expect you would see a new binding added to [DataBindings] and a new datbase added to [Databases] in weewx.conf. You will probably need a stanza for your new StdArchive derived service, if for nothing else to specify what binding it will use. 5. Developing and testing is the fun stuff. Attack the job piecemeal, that's the best way to eat an elephant. Develop the code to get day and night temps into the loop packets and archive records, you can monitor this by simply running weewx directly. If you run into issues a few syslog lines in your code will give you some output to the log that you can monitor when running your code. You really want 3 screens open; one with your code for editing, one to monitor the log with tail and one to start/stop weewx etc. Once you are getting the right data in the loop packets and archive records then put together the code for saviing it to database. This can be harder to monitor, you probably need to do a little bit of command line SQL from sqlite or mysql to see what is in your database. It will be a steep learning curve but once learnt will give you a far better understanding of what goes on within weewx and set you up well for your next project. Gary On Monday, 23 January 2017 02:51:18 UTC+10, Jared wrote: > > 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 take advantage of what's already built into weewx? If so, how? > > I decided that I want to go with a separate database called day_night.sdb > with two tables, 'day' and 'night'. I made the tables with the following > schemas. Just a timestamp, the units, and the average day/night > temperature respectively for that day. > > CREATE TABLE day (`dateTime` INTEGER NOT NULL UNIQUE PRIMARY KEY, > `usUnits` INTEGER NOT NULL, `temp` REAL); > CREATE TABLE night (`dateTime` INTEGER NOT NULL UNIQUE PRIMARY KEY, > `usUnits` INTEGER NOT NULL, `temp` REAL); > > So I need to hit the real weewx database, query it, then write to my > database. As a test I made a python file, imported the sqlite3 module, and > performed some database writes. This worked fine. I suppose I could query > the weewx database this way as well, do the calculations, and then write, > but this feels like it's not the right way to think about things. I feel > like I should be using more of the internal weewx stuff. > > For example I see [DatabaseTypes] in weewx.conf. Would I add my database > file here or that unnecessary since I don't think I'll be using any wee > database functions (I'm not writing to the standard database after all). > As far as the service itself, it seems like this would piggyback off > StdArchive as an archive_service? What's the best way for me to test stuff > as I'm figuring it out? > > Am I on the right track or no? :) > > > > On Monday, January 16, 2017 at 5:41:05 PM UTC-5, Jared wrote: >> >> Oh and I suppose I need Units as well. >> >> On Monday, January 16, 2017 at 5:34:41 PM UTC-5, Jared wrote: >>> >>> 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. >>> mwall mentioned creating a separate database and then running a service >>> twice a day. I like this approach because it will allow me to mess around >>> as a noob without potentially screwing up the real database. >>> >>> I also like the sunrise/sunset as the day/night boundary idea. With >>> that said, what do you guys think makes the most sense from the standpoint >>> of database construction and then calling upon it usefully later? This is >>> what I was thinking (and please let me know if this is silly, especially if >>> my primary key makes no sense). The DB will have one table with the >>> primary key, day, and night values. I can use something like YYYY-MM-DD as >>> the primary key. Night would be the average temperature between sunset the >>> previous day and sunrise of the present day. Day would be populated at >>> sunset with the average temperature between sunrise and sunset. >>> Alternatively, the primary key could be the unix epoch for 00:00 GMT of >>> that day to keep conversions more fluid (since the service would only >>> populate it at sunrise and sunset and the value is not really >>> time-dependent but rather date-dependent). Or it could just be the unix >>> epoch for the time that the service runs. Whatever makes it easier for >>> later recall. >>> >>> On Monday, January 16, 2017 at 4:33:26 PM UTC-5, gjr80 wrote: >>>> >>>> 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 some pretty messy and slow queries that would have to operate on the >>>> archive. The downside is you are essentially double recording outTemp but >>>> what's another few Mbytes. >>>> >>>> I agree it's a very useful statistic and one that is quite relevant >>>> here at this time of year. >>>> >>>> Gary >>>> >>>> -- 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.
