all good questions. in response, the AQI can be ignored - for our purposes it exaggerates/amplifies peaks in PM2.5. i was not aware that the quality/interpretation of the 24hav values is unknown to us at present - i will take them out of the problem statement the driver/weewx is showing me much the same PM2.5 as the phone app so i’m sure the values themselves are not a driver/weewx artifice but it doesn’t eliminate interaction between driver and gw1000 as causing issues - i haven’t tried them independently of weewx i have uninformed opinion that PM2.5 data will be spikey - a cloud of dust blowing past, for example. no doubt this is why the AQI is taken from average over an interval (though my equally uninformed opinion is that 24 hours is much too long, despite the experts using this as the definition). of course, the driver should report the spikes faithfully, smoothing/interpreting them is not its responsibility it is winter here now and i live in the bush so woodfire is going strongly (coonara not open fireplace). this wafts some smoke around internally - which is why i am interested in PM2.5 inside - and externally it collects in the river valley from other folks’ fires at night - so i am interested in outsde PM2.5. when a bit of wet redgum goes on the fire, PM2.5 values can climb dramatically… i have been looking for my single smoke source being picked up by both sensors (inside and outside) and at first thought this was the cause of them rising and falling together. but i moved the outside one to other side of the wind and had similar results, so it “felt” like cross-talk between the sensors so i isolated one of the sensors in air-tight box. some hours later, the boxed sensor reset itself for no apparent reason, and the other sensor plummetted in value! this was the basis of my problem statement (quantum pairing :-) i found the boxed sensor settled on 5 ug/m3, so added offset -5 via gw1000 (and applied it to the other sensor too, after it had been boxed in its turn). rebooted everything, even purged the PM2.5 and AQI data from database (and dropped daily tables and rebuilt them!) and started monitoring afresh the sensors are now behaving properly. i am getting values consistent with what i think is real (whereas before they were highly inflated), i get occasional spikes as expected. internal value rises a bit after the outside one does, which i expect as outside air pemeates inside, but inside value rising no longer drives an external surge. graph of last 24 hours attached (guess what time folk light their fires during the pandemic restrictions on movement? :-)
i am no longer experiencing the problem i reported. however, please note the behaviour (inflated and lock-step) for future reference cheers > On 27 Aug 2020, at 12:36 pm, gjr80 <[email protected]> wrote: > > I've read through this a few times and I am still not 100% sure what I am > looking at (eg you mention a self-derived AQI, is that what is plotted on the > second plot or is that an Ecowitt derived AQI). I guess my first thoughts are > focus on the core PM2.5 data and put averages/indexes aside, we really have > no idea how Ecowitt calculates either the 24 hour average or their index. > Also, is it repeatable. > > You mention you have had high readings since using the b11 driver, have you > taken the driver out of the equation and looked at the PM2.5 data on the WS > View app or via the Ecowitt dashboard. Whilst the app only gives current data > the dashboard gives you plots. I only have a single WH43 that happens to be > located near the kitchen. I do notice PM2.5 spikes that appear around meal > times but also notice the occasional unexplained spike. So far casual > checking has found it to be evident both in the app and via the driver. > > Gary > On Tuesday, 25 August 2020 at 16:14:43 UTC+10 [email protected] wrote: > problem: in trying to find out why the ecowitt PM2.5 sensor inside my house > has unexpectedly high readings (one problem), i discovered that its values > interfere with an identical sensor outside my house (another problem) > > since deploying my two new ecowitt pm2.5 sensors (one inside, one outside) > using the new beta gw1000 driver i have been getting much higher readings > than expected, both pm2.5 values and pm2.5_24hav (from which i derive AQI - > the algorithm is not relevant except that it is monotonic increasing with > pm2.5 value) > > so, just before 2am last night, i sealed my inside pm2.5 sensor in an > air-proof plastic container and continued readings. the graphs below show the > results (i hope forum software posts them….) > > *inside* pm2.5: the “zero” reading shows as about 5 ug/m3. the specification > says +/- 15 in this range so that’s acceptable (memo to self: calibrate > anyway) > [mind you, ‘good’ air quality changes to ‘moderate’ at 12, so +/-15 is a lot > at the low end of the scale!] > > *inside* aqipm2.5: the “zero” reading reflects the pm2.5 value it is supplied > → not a problem > > but notice that the pm2.5 and pm2.5_24hav readings for the independent > *outside* sensor also apparently drop at same time as *inside* sensor! that > can’t be correct > > and about 2.5 hours later there is another abrupt event(s): the *outside* AQI > (thus pm2_52_24hav) dives off a cliff, and the *inside* sensor apparently > resets. the graph shows a gap for inside sensor, the logs (extracts below) > show that both PM values for *inside* sensor are absent from packet: > > shows all the values are present in packet, but *outside* sensor value has > already plummetted: > 06:20 'pm2_5': 6.0, 'pm2_52': 5.0, 'soilMoist1': 36.0, 'soilMoist2': 46.0, > 'pm2_51_24hav': 6.0, 'pm2_52_24hav': 6.8, > > shows *inside* sensor values absent from packet, but absence of other errors > indicates *outside* sensor values present: > 06:25 Aug 25 06:25:18 dizzy weewx[28238] DEBUG user.alarm: Alarm [AQI PM2.5 > Inside (Good/Mod)] name 'aqiPm2_52' is not defined > Aug 25 06:25:18 dizzy weewx[28238] DEBUG user.alarm: Alarm [AQI PM2.5 Inside > (Sens/Unh)] name 'aqiPm2_52' is not defined > Aug 25 06:25:18 dizzy weewx[28238] WARNING user.alarm: Alarm [WH41 PM2.5 > Inside Battery ↑OK] '>=' not supported between instances of 'NoneType' and > 'float' > Aug 25 06:25:18 dizzy weewx[28238] WARNING user.alarm: Alarm [WH41 PM2.5 > Inside Battery ↓Low] '>=' not supported between instances of 'NoneType' and > 'float' > > somehow, the *inside* and *outside* sensor values are linked in some way > (interfering with each other) > > ideas, anyone? > > > > > > > -- > 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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/weewx-user/efb35466-08a3-473f-ab35-63e43c7ec970n%40googlegroups.com > > <https://groups.google.com/d/msgid/weewx-user/efb35466-08a3-473f-ab35-63e43c7ec970n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/F4847014-0911-4277-BF5D-D6CDBD0E5E97%40gmail.com.
