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]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/efb35466-08a3-473f-ab35-63e43c7ec970n%40googlegroups.com.
