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 would be null; when I write the TempDay value, TempNight would be null, and vice versa.
On Tuesday, January 24, 2017 at 6:02:15 PM UTC-5, gjr80 wrote: > > 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.
