Struggling a bit with WeeWx, Purple Air, and GW1000

[richard maliszewski]

The box that was running WeeWx for us had its disk go full and after a lot of thrashing, I just scraped what I needed from it and started over. It was running an older version of WeeWx. Inbound data from a GW1000, MQTT, and a Purple Air using the now-MIA purpleair driver (which was putting its data into a separate DB) and the AQI service that worked with it.

Brave new world. Have GW1000, MQTT, and Purple Air all providing data, that last through the “weewx-purple” driver, which appears to do its own AQI calc.

Here’s the problem I believe I am up against. We have an indoor air quality sensor for the Ambient WS5000 reporting through the GW1000. It sure looks to me like the data field names and DB rows used by the GW1000 driver for that and those used by the weewx-purple driver collide. This wasn’t a problem in our old setup, where the PA data was bound to a different DB. But now, if I graph the hopefully indoor current PM2.5 value (pm2_5) and the current PM2.5 AQI value (pm2_5_aqi), it’s clear that what’s getting graphed is exactly the same value, just on a different scale. Maybe that’s expected, but not by me. And the current PM2.5 AQI doesn’t seem to track what’s given by the PA map for the same sensor…although I am not as certain this is a real problem yet.

Anyway, I am reasonably certain that at least the pm2_5 value (which is all I believe the WS5000 sensor reports) is getting stomped on by the weewx-purple driver. I have looked at the GW1000 driver and the weewx-purple driver code a bit, and am probably creeping towards understanding what they’re doing. Not so much that I’d be happy modifying them.

So here’s my question: assuming i am right about the name collision, how can I fix this?

1) Can I do a name-remapping for the WS5000 sensor either in the driver or one of the configuration files? I’m pretty certain I’d have to use an existing field name, as I suspect the weewx-binding DB has a fixed schema.
2) I guess I could abandon the weewx-purple setup. I could have an external daemon query the PA for JSON, parse it and publish it to WeeWX via MQTT, and just store the values in existing unused fields. Not crazy about this, but I would then own my own destiny.

Thoughts?

—Richard

[vince]

I don't know which driver you are referring to when you say 'the now-MIA purpleair driver (which was putting its data into a separate DB)'.  There are a lot of purpleair drivers.

I take a little different approach - I use https://github.com/bakerkj/weewx-purpleair for my PA as an extension, FWIW

(1) it writes to a separate db:

    [[purpleair_binding]]
        database = purpleair_sqlite
        table_name = archive
        manager = weewx.manager.DaySummaryManager
        schema = user.purpleair.schema

(2) And in skin.conf - I create a graph with the outside AQI specifying that db binding

    [[[daypurpleair]]]
           [[[[aqi2_5]]]]
              data_binding = purpleair_binding

(3) And I also need to specify that binding in my skins....

              <tr>
                <td class="stats_label">AQI (current)</td>
                <td class="stats_data">$latest('purpleair_binding').aqi2_5.raw</td>
              </tr>

I have an inside Davis Airlink that isn't hooked up into weewx here, but if I wanted to do so I'd run a second (different?) extension to do that and let that one write to the default weewx.sdb database.  That way I'd have two sensors would be in different db and they couldn't step on each other.

I don't know if the one you're using can handle multiple sensors, but your extension's author is pretty active here and will likely chime in.