Arguably I have a biased viewpoint, but I would suggest using the Ecowitt Gateway driver(nee GW1000 driver). As you point out the Ecowitt Gateway device driver can be run as a driver or service plus you do not need to 'use' your gateway device custom server to upload to WeeWX. You will also find the Ecowitt Gateway driver supports a richer set of sensors than the interceptor driver, but that is largely due to Matthew not having had the time to update the interceptor driver when Ecowitt releases new sensors.
In terms of WeeWX architecture either 1 or 2 or two will do what you want. weewx_multi is likely more robust; if one instance fails for some reason the other instance is unaffected (some folks experience the occasional hiccup with the Ecowitt devices going non-responsive to the API calls used by the Ecowitt Gateway driver). I have been running such a setup for a couple of years without issue, the main problem I encounter is at times I forget I have weewx_multi running and I issue incorrect start/stop commands. Running the Ecowitt Gateway driver as a service has the advantage of putting all of your data in one database. Whilst WeeWX easily handles reporting from multiple databases, at time you can get timing issues when using multiple databases. For example, if instance A records data and generates reports and instance B records data only, if instance B has not saved the current archive record to database when instance A starts it report cycle the instance b archive record will be omitted from the reports. Minor issue but some can live with it others cannot. You are right that if running the Ecowitt Gateway driver as a service you would need to map some Ecowitt obs away from those provided by your primary station. From the sensors you list you would need to re-map around five sensor fields, basically anything that is emitted by your current driver and the Ecowitt Gateway driver with the th sensors you have. This is a one off addition that would only need a handful of entries under [GW1000] [[field_map_extensions]] in weewx.conf and would only (potentially) need changing when you add more Ecowitt sensors or change your primary station. Sorry, can't help with a system unit file. Gary On Friday, 16 December 2022 at 22:33:32 UTC+10 Cameron D wrote: > My Oregon WMR300 is still happily chugging away generating weather data > and I thought I'd augment it with some air-quality sensors. > The easiest in my situation seemed to be an Ecowitt WH45 CO2/particle > sensor with a GW1100 gateway, and a WH31 temp/RH sensor thrown in for > almost nothing. > So my new system reports: > 1 x barometer > 3 x temperature > 3 x humidity > 1 each CO2, PM2.5, PM10. > sundry battery and signal strengths > > One of my requirements is to have some plots containing data from both > systems on the one chart. > > There seem to be two choices for driver - the Ecowitt (GW1000) and the > interceptor. Are there any strong reasons to choose one over the other? > > There also seem to be two choices for implementation: > 1. using weewx_multi and keep everything separate. Then use the multiple > binding technique in one skin to incorporate all data in a single report. > 2. use the GW1000 code *as a service* in a single instance of weewx, with > a single database. > > The second method seems in some ways simpler, but am I right in thinking I > would need to remap many of the names to avoid clashes with data from the > WMR300? > > If I choose weewx_multi - is there a suitable systemd unit file I can use > as a template? > > Thanks. > Cameron. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/2561fb3f-7036-499c-b7b8-c38666cf73d1n%40googlegroups.com.
