SGP30 / SGP40 background sampling

[mikeysklar]

Add SGP30 / SGP40 background sampling. Requires frequently 1s polling or returns 0 values.

Untested and only a proof of concept for feedback. This adds fastTick() polling to keep the SGPxx sensors producing usable data. Thanks @Timeline for the key insight of 1s polling being needed.

Difference observed between 15min polling versus 1s with the SGP40.

Address issue 732

Forum issues:

SGP30 issue with WipperSnapper
SGP40 Air Quality

[mikeysklar]

I can confirm the SGP40 works with this PR. I tested using:

Adafruit Qt Py ESP32-S3 (2MB PSRAM)
build artifact: wippersnapper.qtpy_esp32s3_n4r2.1.0.0-adafruit-67159326.uf2

Trying different settings from 1 second --> 15 minute update intervals for prolonged periods (hours) was working with the keep alive code.

The SGP30 changes are untested as I don't have one on hand.

[ladyada]

brent and tyeth are both out right now but they'll review when return!

[tyeth]

Thanks @mikeysklar, this has been weighing on my mind for a while as there are a few we currently "support" that are out of spec in their current use. I thought there was an existing issue, but can't find one, must be thinking of forum discussions.

The only other previous related thoughts were that it might be worth having an internal poll period defined for each component (with a matching entry in the components repo JSON definition), and then a separate publish period (the current thing in definition file), both potentially displayed to the user (publish >= poll in interface) although we'd then need to specify max and min as well as default internal poll period (fastTick speed).
I think that would help users understand (and play out well in low power mode in the future) poll periods.
Also as you've seen, it wasn't worth reading a lot of sensors too frequently (like more than every second). I'm thinking some other air sensors which are 5seconds minimum poll for example. Longer term it's my desire (and been raised) to have the reference values (temp/RH) be passable to the gas sensors too as currently it (20-25c/50%/101.325) throws all the data off. That would either be input feeds for the sensor/component, or some form of custom sensor properties or RPC thing, probably through Actions initially.

On the averaging front, it might be best to leave it to the current techniques, as I think it's probably expected that the moment it publishes data the value represents the current value and not a time accumulated average. The user can see averaged data instead using the dashboard and feed pages and APIs (charts and API get access to aggregated data at various time intervals), and possibly Actions.
Longer term it makes sense to offer the sample averaging as a configurable option (similarly for Analog averaging and/or hysteresis).
There's also a minor issue with the getEvent situation, as each method resets the data, and usually they are called one after another, before a single publish, so first getEvent(VOC for sake of argument) takes the averaged value from _n samples, but then getEventRAW doesn't match that dataset as the accumulators are reset by getEventVOC and so instead getEventRaw asks for a fresh data sample from the sensor.

These are all minor things, and more an attempt to uncork my stored up thoughts on the issue. I'll bring it up with Brent as to how he'd like to proceed, which will be next week, but I can't see any problem with the current idea at all.

[mikeysklar]

@tyeth

Thank you for the larger explanation. Using a polling frequency value in the JSON config makes a lot of sense.

Another issue @Timeline pointed out is deep sleep mode which I believe is still in the works. I bring it up here only that continuous background polling could cancel out the ability to use sleep mode with these sensors.

A few more options to consider as JSON config values:

• ramp up time (eg. 30sec - 1min)
• number of initial values to throw away
• deep sleep duration (realistic range)

If you are doing hourly air quality samples it doesn't make a lot of sense to keep the controller awake and polling every second.