All good points, and I'll keep those in mind as I flesh out my architecture.
But I sort of veered off topic. What are the thoughts on me adding an aviation unit system? I see the benefits of a skin definition for reports but, unless Unit Systems are generally being deprecated in favor of skin definitions, then I also see the sense in a new Unit System. It might not be the most interesting FR + submission for aviation purposes, but it wouldn't be a bad start. Also, is this the best place for future 'intent to implement' discussions? I'm used to starting them as a github issue (which then allows the PR to be linked to it, etc.) On Tuesday, September 12, 2017 at 3:51:31 AM UTC-7, mwall wrote: > > there are a few ways to collect data from multiple instruments and/or > types of instruments: > > 1. > > driver plus service(s). the driver collects data from the 'primary' > instrument, with one or more services running to collect data from > additional instruments. for example, use the vantage driver to collect > data > from a davis weather station, with the owfs service to collect data from > one-wire sensors. pro: single instance of weewx, single report generation. > con: becomes unwieldy if there are many different types of instruments. > 2. > > one weewx instance per instrument. run a weewx instance for each > instrument. run wee_reports as a cron job with a configuration that > produces a report with data combined from all the instruments. pro: > possibly more robust if a single instrument fails. con: gotta manage > multiple processes. > > imho, when you get into the realm of real-time data, then you really > should use MQTT. configure each weewx instance to send data to an MQTT > broker. then configure an influxdb server as a consumer to the MQTT feeds. > that way you get weewx saving data locally, so you can recover gaps in data > from network outages, for example. and you get a single, real-time (or > near-real-time, depending on your sensors) source to get the current data > (MQTT broker) and fast database for central access to all historical sensor > data (influx database). > > if you don't need local reports, then don't run the weewx reports. > > if you don't need centralized historical data, then don't run influx. > > > >
