Internet of.... Brisket?

 

Here is an adaptation of the ESP32 BBQ probe, integrated with the more recent experimentation with air quality sensors for an easier to access brisket smoking logger. The main motivations are for more convenient (remote) monitoring and logging. Monitoring is important to make any needed adjustments, especially during initial setup when the temperature is not stable. Logging is important to observe the overall burn times, especially for overnight periods to see how much overall heat actually went into the meat. We're not hardcore enough to care about having a continuous 20 hour cook, and usually end up starting the fire again the next morning after the charcoal "snake" has burnt out.

Overall, the pipeline is relatively straightforward:

Starting with the thermocouple hardware, the sensor data is polled by the ESP32 and served via a HTTP server. A python script running on a computer pulls data from the server, parses the temperature value, and emits it along with a timestamp into a Google Sheet document via the Drive API. From there, the online chart can be set to the appropriate input columns, and will update automatically as more points are added.

The main drawback of this current system is that it still needs a laptop (or computer) to run on the local network to do the bridging between the ESP32 and the cloud server. From a cursory search, it should be possible to implement the Drive API's directly, so that would be a good next step.

What are we cooking with this? One of the two USDA prime briskets we picked up at Costco in Burlington last week, when the border was still open (and return trips did not require PCR testing, as it will within a matter of days):

Pictures of results to come!

Smoke, Round Two

 

We've had the (un)fortunate opportunity to test out the sensors again, during an official heat wave + air quality warning notice. This time, I wanted to compare the indoor and outdoor quality with the presence of an air filter. The tests started with the two sensors moved over from my parents' place and left inside our apartment for a few hours. The first data point was soon after throwing the one sensor onto the balcony, while the other one was placed inside.

Based on the measurements, it looks like the worst of it only spanned Friday during the day and the early parts of Saturday morning:

Beyond the general trend over August 13-14, this data seems to suggest is that:

a.) indoor air quality is better

b.) indoor air quality tracks the outdoor one, to some extent despite the filtration

The obvious questions that I'd like to ask based on this include:

- would swapping the two sensors have yielded similar results?

- assuming the sensors at least track the levels somewhat consistently, how much of the indoor air quality improvement is due to the active filtration?

At some point another neat test would be to sample at higher intervals around the kitchen to see the effect of cooking, coffee roasting, etc. So far, I can also see that cooking has a pretty significant effect:

This was with the balcony doors closed, and you can see the HUGE spike at around 8 in the morning caused by cooking on the stove, even with the vent hood going! At least it came back down quite fast...

Air Quality History - Comparison with external data sources

 So after logging data for a few days, and having experienced a spike two days ago, we see the following:

(note I have not correctly implemented the breakpoint yet for the 50-100 level for the 2.5 AQI number, but the trend is there)

Compared with aqicn.org''s chart at the YVR location over the same period:

What I've noticed however is that there's quite a big difference between stations, at least when the entire city is not completely enveloped in visible smoke. Therefore, any discrepancy, especially when the values are generally low, could be quite localized.

The test google drive spreadsheet is getting a bit long... I'm contemplating either being lazy and just starting a new one (since by default it just tries to write to "Sheet1"), or maybe code up something more interesting...

The other thing of interest is that the aqicn hardware platform uses data tha comes from these Plantower PM5003/7003 sensors, which are in the similar price range of the SDS011 and have very similar performance characteristics. They also have a nice list of similar devices here. Is it time for another AliExpress order?

Air Quality Charts First Take

After some finagling with Google Drive/Sheets API, I managed to update the python script to insert values directly into a Google Sheet. Following the official docs including setting up OAuth was a breeze, and my worst tripup was carelessly naming the .json file containing the secret key "token.json" (which is actually the refresh token to be generated upon initial authentication, and constantly updated to avoid expiry) instead of "credentials.json". Also had to add the user name to the test list in the API console. Once these rookie mistakes were fixed, the API worked pretty flawlessly. The next thing I'd like to do is maybe sandbox the access to a single file through the SCOPE parameter, instead of all the spreadsheets (or entire drive for that matter). Double checks to make sure I didn't publicly check in the private keys...

I placed one sensor inside, while another is sitting on the balcony, like so:

Here's the raw data plots after a few hours, with 20 minute polling intervals:

Nothing exciting to show yet, other than pretty close readings from both sensors both inside and outside. Some things to consider doing in the future include converting the values into Air Quality Index (AQI). The gist of the conversion is that for a given particle/pollutant, there are piecewise linear ranges (or "breakpoints") as the amount of pollutant goes up. For example, for PM2.5:

At "Good" concentrations of between 0 and 12 ug/m^3, it maps to 0-50 on the index. However, at the next "moderate" level (12.1-35.4 ug/m^3), we have a range of 23 ug/m^3 for the 50-100 on the index values. Interestingly enough for the 3rd range (35.5-55.4 ug/m^3), the range goes down to 20 ug/m^3 but then the forth range is 55.5-150.4 which is 100. I guess this must be based on some kind of prior knowledge on the potential health effects at different concentrations... We see a similar pattern for the PM10 values in that the ranges are increasing up to a certain level but then goes down at the "Very Unhealthy" level:

SDS011 Sensor Initial Comparisons

As a followup to the previous post, here is the basic python test code to poll the two sensors at 1 minute intervals, with a 15 second bootup time to stabilize the readings after each sleep period.

Following are two ~1 hour logging sessions, with the two sensors plugged into either side of my laptop, and _R and _L denotes the placement of each sensor. I swapped the two sensors between the two sessions in case there was any variance in the air quality across the surface of the desk itself ;)

Overall, it's difficult to say how well they work but it doesn't look too bad. I think a better test would be to compare across a longer period when more variance in the air quality is observed. One other thing I noticed even from these two rough and dirty tests is that the sensor seems to be sensitive to humidity, as the increase around 18:45 corresponded to when I took a shower... And it also looks like averaging a few consecutive readings for a single sample might make more sense given the amount of noise there is.