One other question I should have asked. Is the SDR receiver running in another process? Or, is it in the same weewx process? If the latter, make sure you are using an appropriate transaction isolation level. See the MySQL docs on transaction levels <http://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-model.html>. In this case, you would not need a lock at all. You just have to guarantee that the write happens before StdReport needs the data.
The database shim used by Weewx, weedb, uses the READ UNCOMMITTED level. -tk On Wed, Jan 18, 2017 at 12:20 PM, St. B. <[email protected]> wrote: > Yes you got it right :) > > I'll look into the sync of the timings between the reporting task and the > recording tasks. Maybe I could change my trigger to go the other way > around, but it would be more susceptible to wrong reports (ie read the last > pressure and inside temp from wmr table after each insert in the archive > table). This would ensure proper sync of the other tasks. > > On Wednesday, January 18, 2017 at 9:03:00 PM UTC+1, Tom Keffer wrote: >> >> No problem. The reason I ask, is that the upcoming V3.7 treats the >> current record differently. >> >> Let me make sure I understand the setup you have. You have one MySQL >> database, with two archive tables. The default 'archive', and another one >> 'archive_wmr'. The former is the traditional table, and will have a set of >> daily summaries associated with it. It is populated by the SDR. The latter >> is an additional database, that is populated by your WMR base station. >> Whenever an INSERT station is done on this 2nd table, it triggers an insert >> into the first table. >> >> The only problem I can see with this setup is the timing of the trigger. >> If StdReport gets kicked off before the trigger happens, the report might >> be missing some necessary data. >> >> restx uses the standard archive table. What it extracts out of it depends >> on the uploading service you are using, but it will almost surely need >> barometer. So, it cannot proceed either until the trigger is done. >> >> I think you're going to need some sort of lock to insure that the trigger >> is done before the reports get kicked off. This may be as simple as a new >> weewx service, that blocks until 'barometer' shows in the database. It >> should have a timer so it doesn't block indefinitely. >> >> Of course, I may have your setup wrong, or my diagnosis may be completely >> wrong. >> >> -tk >> >> >> On Wed, Jan 18, 2017 at 11:35 AM, St. B. <[email protected]> wrote: >> >>> Oops, forgot to mention : weewx v3.6.2 <http://weewx.com/> >>> >>> On Wednesday, January 18, 2017 at 8:34:09 PM UTC+1, Tom Keffer wrote: >>>> >>>> What version of weewx are you using? >>>> >>>> -tk >>>> >>>> On Wed, Jan 18, 2017 at 11:21 AM, St. B. <[email protected]> wrote: >>>> >>>>> Hello, >>>>> >>>>> I currently have a dual source station : >>>>> - WMR base station for inside temp and pressure >>>>> - SDR for all the recordings. >>>>> >>>>> I have read a bit about the multiple driver conf, and set up 2 >>>>> processes so that one runs the WMR data and the other runs the SDR data. >>>>> The archive, reporting and restx services are all running on the SDR >>>>> process. >>>>> >>>>> Both process store the data in the same mysql database with different >>>>> set of tables (archive and archive_wmr) >>>>> >>>>> In order to still get the inside temp, and pressure, I added a trigger >>>>> to the archive_wmr table so that each recorded data from the wmr process >>>>> goes in the appropriate column of the archive table in the last recorded >>>>> value. >>>>> >>>>> This works fine to store the data, show curves, and historical data, >>>>> but not for current weather, and restx data. I do not understand if I >>>>> missed something or if these processes need some additional conf to get >>>>> the >>>>> data from the database. >>>>> >>>>> >>>>> Thanks >>>>> -- >>>>> >>>>> >>>> >>
