Skip to content
Scott Sargent edited this page Feb 5, 2020 · 3 revisions

The World’s Most Over Engineered BBQ Thermometer

So let me tell you a story. Our story starts on Christmas morning, 2018. I was hosting, my family had spent the night at my house christmas eve. Being foodies we were beyond excited for the succulent 8lb prime grade prime rib that we would be cooking that day, outside on the large big green egg on my deck.

We had an amazing Christmas with presents galore. The grill was at the perfect temperature, the $160 cut of prime grade beef was prepped and it was time to cook. It all went without a hitch as I loaded the grill up and placed the dual temperature probes - one in the meat one on the grill itself. We waited, and waited. After about five hours it seemed like it should be done but the thermometer i was using at the time insisted no that it was not done. So we waited and waited longer. Finally being very curious why it was taking so long I grabbed another instant read thermometer and checked it myself. At 120F we were going to remove it from the grill and let it gradually come up to a perfect rare doneness.

When I plunged the thermometer into the roast I was horrified to see it was already at 142f. It was overcooked by 22 degrees. My thermometer probe had failed and could not be trusted any more. Something had to be done before next christmas.

But what to do? As I stood in shock from the tragedy that had befallen us a plan suddenly became clear.

There is only one thing to do. Only one course of action that would be possible. Build a Mult-Tenant Kubernetes Based BBQ Thermometer in Golang.

Why had I not seen the need for this before? By capturing more than one probe’s worth of data for each data source (two for grill, two for meat) then one could not fail without leaving detectable evidence of the failure. Also, by tracking historical data and combining it with ambient weather conditions if both probes did fail you could compare past cooks with historical ones and against historical weather conditions to tell when the time was getting abnormally long for a cook.

That was just the start though, eventually I would be able to build in AI to detect an event hours before it happened by comparing the temperature curve with historical data. Gradient descent might be a simple way to do it.

It needed to be run in Kubernetes because I would need the scalability of being able to go out to five thousand nodes. We take our bbq very seriously.

In the coming months I would build the thermometer. Its not done yet, the code is all here to be reviewed but there is more work to be done. I have gained a lot of insights by looking at the temperature curve of a cook. Specifically for the rather long cooks - Boston Butt or Brisket. By graphically analyzing the temperature curve I’m able to spot the stall and to see that sometimes it happens sooner than the 160f that its supposed to. Accurately detecting this can cut hours off of a cook.

For a more technical view of what is going on under the covers, take a look at our github repo. https://github.com/ssargent/bbq

Clone this wiki locally