Multi-station system adding ecowitt components - clarification requested

[Cameron D]

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.

[Pascal Hingamp]

Hi Cameron,

I've been in exactly this situation. I started with the GW1000 as a service on top of my original Oregon driver, as it is very neat and straight forward. Because I was unable to get all my Ecowitt variables recorded in the single database (maybe because of overlap since both weather stations report some of the same variables, which I did remap to different names), in the end I went for the weewx_multi strategy with two daemons and two databases which worked out of the box because weewx reports make it in fact quite simple to exploit data from distinct databases. The GW1000 weewx daemon instance does nothing but collect and archive loop data.

I have no doubt GW1000 as a service must clearly be a perfectly viable option, and I think I was very nearly there in getting it configured, just sharing my experience faced with the same dilemna !

Kind regards,
Pascal

[gjr80]

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

[vince]

A somewhat more complicated setup that I use...

Primary station = weewx using Vantage driver on a pi for the VP2 station

Secondary items = weewx using gw1000 driver in docker on a separate system.  That system also runs a docker MQTT broker.

The ecowitt setup publishes to MQTT.  The VP2 (primary) setup subscribes to those MQTT topics.   That gets the ecowitt stuff into the primary (VP2) weewx db very reliably.   Note, however, that I'm mapping all the Ecowitt stuff to extraTemp1 and the like in the primary weewx.  Presumably you could map your ecowitt to unused extraSomethingNNN fields in the primary weewx setup similarly.

The main reason I do it this way is that the primary VP2 weewx 'also' publishes to MQTT, so it makes it easy for me to do an integrated Home Assistant dashboard containing data from all the various sensors. 

[Cameron D]

Thanks everybody,

I am trying the multi approach as it seems cleaner.

 It turns out the systemd changes were trivial - easier than init.d.  I'll add something to the wiki when I have finished.

I noticed that I still need to do remapping in the driver version with the full database otherwise half the data are missing.  Unless I missed a step somewhere.  In any case I tend to prefer to define my own DB structure so I will carry on down that road (for the time being).

[gjr80]

On Sunday, 18 December 2022 at 15:03:16 UTC+10 Cameron D wrote:

I noticed that I still need to do remapping in the driver version with the full database otherwise half the data are missing.  Unless I missed a step somewhere.  In any case I tend to prefer to define my own DB structure so I will carry on down that road (for the time being).

Would be interested to know what data was missing?  I probably should have clarified that sensor battery and signal states would need db schema additions or a mapping change to map them to the existing db fields as the view_extended schema includes a limited number of generic signal/battery status fields for sensors. All the primary sensor values for the sensors you listed (eg humidity, temperature PM2.5 etc) should automatically be saved to database with no changes required. 

Gary

[Cameron D]

Gary,

The main missing data were everything from the WH45 except CO2.  Also battery, signal and everages. I presume there was no intention of storing the 24-hour averages as weewx does its own averaging.

I am using weewx 4.9.1 with  gw1000 v 0.5.0b5.

PM10 in the wview_extended schema is known as 'pm10_0', while the gw1000 driver always shows it as 'pm10'

PM2.5 in  the wview_extended schema is known as 'pm2_5', while the gw1000 driver shows it as 'pm2_55' in test-driver and test-service modes or pm255 in live mode.

Temp and Humidity from the WH45 are also missing (numbered extra-17 in the test-driver output)

for installation, I simply copied over the gw1000.py file (and api_data.py) into the weewx/user directory. then ran wee_config   --install  to create a config file from scratch.  I didn't use wee_extension, so not sure if anything was missed out there.
Cameron.