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!

ESP32-based wireless BBQ probe

At work I've been using the ESP32 lately, and its proving to be a much more capable platform compared to the cheaper (but more mature) ESP8266. The great thing about the ESP32 is that it has a dual core processor, and a really adaptable I/O matrix that allows you to route hardware ports to many different pins. The flip side is that it costs a bit more (dev boards are around $10, while the chip itself is about $5. This makes the ESP8266 about half the price). Additionally, the software support is nowhere as developed and there are many bugs and undocumented stuff throughout, so for that the ESP8266 may be a more stable platform.

Over the past weekend, I played around with adapting a teensy-based thermocouple 

Part List

- MAX6675 thermocouple driver (and k-type probe)*

- ESP32 dev board (this is the cheapest one with a lot of pins at $7USD currently. You can get a fancier one with built in OLED, or 18650 battery holder and charging circuitry for about $10. There's also one that has a standard Arduino Uno shape if thats what you're into...)

- Mobile phone power bank (I use a 5000mAh one that lasted comfortably overnight. a 10000mAh one like this one would probably power it for 2 days straight ;)

- Computer for programming, and monitoring temperature over http (via a browser)

Hardware Setup

The MAX6675 thermocouple driver uses a simple SPI connection. However, unlike many common setups, the chip doesn't take in any commands from the master so there is no MOSI line and only CS, MISO, and CLK are required. Once the chip select pin is pulled low, the resultant data gets sent out on the MISO line bit by bit for every CLK cycle. 

In this case, I used pins 18, 19, and 21 on the ESP32 for CLK, MOSI, and CS respectively.

The dev board has a micro-USB input for power (and programming), so to power it portably I simply use a power bank.

Software Setup

I'm using the Adafruit driver which can be found and downloaded automatically using the Arduino library manager. Note that like the ESP8266, you may need to add this change to explicitly implement the delay function as util/delay.h does not exist for the Arduino ESP32 library. The library allows you to hook up the MAX6675 to any pin that supports digital I/O, and using additional digital pins for the CS pin supports more than one probe driver if necessary.

To actually serve temperature values, I built upon the SimpleWifiServer example so that the user can access the value through the browser. As a lazy way to make the display update, I added a refresh tag to the served html so the browser will reload the page every 5 seconds. Hacky, but works!

The code is available here.

Test and Use

Here's a short test comparing it with a Thermopro wireless system: off by less than 2F at room temperature. Not bad!

I did a longer test while practicing the "snake" method which is a way to have a long and low temperature cooking technique for smoking on a Weber-style bowl BBQ. Here are some not-so-well-lit shots of the starting of the snake:

With a relatively short snake that spanned less than a third of the grill I managed to keep the temperature around 250~270F for about 3 hours. This bodes well as typical cooking times for pork ribs is around 3-5 hours (depend on a number of factors; here's a good recipe). And the snake could always be lengthened for really long cooks for brisket and larger roasts.

Next Steps

Here are some things I'd like to add to the system:

- a better web user interface!

- multiple probes: at least one for the grill and one for the food. almost essential to do any legitimate smoking.

- explore possibility of powering it directly off a thermoelectric module, making use of temperature difference between the BBQ enclosure and surrounding air.

*note: the MAX6675 is actually discontinued, but it is still widely available on most online retailers. Its replacement, the MAX31855, is also double the cost. What you get as extra are an extended temperature range, as well as some additional sensor info (e.g. probe short circuit detection, etc). Might play around with the newer chip at some point, but for now the 6675 will do... ;)