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. On Tuesday, December 30, 2025 at 11:33:47 AM UTC-8 richard maliszewski wrote: > 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 > -- 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 visit https://groups.google.com/d/msgid/weewx-user/2a962cb6-c44d-4ce3-9ac2-2e91c0c8436fn%40googlegroups.com.
