Cooking the perfect holiday ham with IoT, Prometheus, and you

NEW!! Special Event - See Sysdig at AWS re:Invent Nov. 30 - Dec. 18 & Jan. 12-14 9:00 Pacific

With the holidays upon us around the world, some folks here at Sysdig decided to take a technological approach to holiday cooking.

How, you ask? By adding a little PromQL to the mix.

A home kitchen during the holidays can be a very frenetic place. There are often many, many dishes being prepared at the same time and cooked in sequence. Some are short and easy, others can take several hours. It’s inevitable that a dish will get missed, or a step forgotten. We felt technology, specifically PromQL, could help with this problem.

With the addition of a little PromQL, not only can we build alerts that will buzz our watch, we can build predictive alerts. This means we can be more precise on when to perform a step or take action. Now, call us crazy, but at our hearts we are an engineering company at Sysdig, and kitchen gadgets can get expensive quickly. Additionally, we knew we wanted to use PromQL for its ability to do regression and prediction on data points, and this was the perfect excuse to build a kitchen gadget.

Our goal today is to show you how to cook the perfect holiday ham (brown sugar and pineapple glazed ham!) with a custom IoT device, Prometheus, and a little bit of elbow grease.

This amazing project was carried out by Alexander Lawrence (Principal Solutions Engineer at Sysdig), Matthew Andersen (Worldwide Director of Sales Engineering), Patrick Hargett (Staff Customer Reliability Engineer), and Aaron Newcomb (Director of Product Marketing).

What you’ll need

For the Ham For the IoT Device
11 – 12 lbs bone-in smoked ham
2 Pineapples
3 Cups Pineapple Juice
2 Cups brown sugar packed (~400g)
1 Wemos D1 Mini

1 breadboard
2 Dozen male-male jumpers
1 MAX6675 temperature sensor
1 AD8495 analog temperature sensor
2 k-type thermocouple sensor

Directions for the IoT Device

You’ll want to follow this schematic to wire the sensors in with the example config that will be provided:

The Wemos D1 Mini in a default configuration only supports one SPI device (in this case, the MAX6675), so we added a second sensor by using an analog type that just reports raw voltage, and by doing a bit of math.

You’ll want to install ESPHome on your computer so you can load the D1 Mini with the proper config. It can be as simple as doing pip3 install esphome; however, you can find more details on the official documentation.

Once ESPHome is installed on your machine, all you have to do is plug in your D1 Mini via USB and execute esphome [filename].yaml run. It will auto-discover the device and load up the config.

For the pinout and sensors we used above, this is the config you will need:

esphomeyaml:
  name: SysdigHolidayHam
  platform: ESP8266
  board: d1_mini
#replace with your info
#2.4 ghz only
wifi:
  ssid: "SSID"
  password: "PASSWORD"
# Activate Web Server
web_server:
# Activates prometheus /metrics endpoint
prometheus:
# Trying to activate the logger
logger:
spi:
  - id: Food
    miso_pin: D0
    clk_pin: D1
sensor:
  - platform: max6675
    name: "Alex - Meat Temperature"
    cs_pin: D2
    update_interval: 10s
    filters:
    - lambda: return (x * (9.0/5.0)) + 32.0;
    unit_of_measurement: "°F"
  - platform: adc
    pin: A0
    name: "Alex - Pit Temperature"
    update_interval: 10s
    filters:
    - multiply: 3.07
    - lambda: return (((x-1.25)/0.005) * (9.0/5.0)) + 32.0;
    unit_of_measurement: "°F" 

A key thing to point out:

We are using a lambda function to do some math. In the case of the MAX6675, it outputs C and we’re just converting to F. For the AD8495, we are bringing the voltage reported in up to where it needs to be for calculations, then doing a bit of math to get the temperature value in C, and finally converting it to F.

Once you’ve done this, you’ll now have an IoT device reporting the temperature of two sensors via Prometheus!

When you execute the esphome run command, you’ll get the IP of the device and can browse to it to see direct output.

Directions for the ham

  1. Preheat the oven to 325ºF.
  2. Place the ham cut side down in a roasting pan.
  3. Cover the ham with pineapple rings, attached with toothpicks.
  4. Toss the ham in the oven.
  5. While the ham is cooking, make the glaze: Dissolve the brown sugar in the pineapple juice and simmer in a pot until it starts to thicken, stirring occasionally.
  6. About an hour until the ham hits 140ºF, cover the ham in half the glaze.
  7. About half an hour before the ham hits 140ºF, cover the ham with the remaining glaze.
  8. Remove the ham when it hits 140ºF and let it rest for a bit.
  9. Carve and enjoy!

The PromQL

Ok, great! But how do we go from the device to that delicious looking holiday ham?

PromQL!

You’ll note the directions calls for glazing when there is an hour left and half an hour left. Those types of direction based events are very common in cooking as each thing being made might be different sizes, ovens are different, and temperatures vary. Needless to say, it’s frustrating!

But PromQL can help! Let’s look at an alert to find out how.

[BLOG] Holiday Ham will hit 140 in 1 Hour - Add Glaze (PromQL)
Alert Level: Medium
PromQL: 
 predict_linear(esphome_sensor_value{name='Alex - Meat Temperature'}[60m], 3600) >= 140

predict_linear is the key operation here. We are pulling the metric esphome_sensor_value that is named Alex - Meat Temperature and running it through an algorithm built into PromQL, called predict_linear (for you statisticians in the audience, this is doing linear regression analysis and projection). It’s looking at that metric for the last 60 minutes and projecting what it’ll be in 3600 seconds. If that value is greater than or equal to 140, the alert condition would be met and it’ll go off.

What does this mean?

We don’t have to take our best guess at when to glaze, we can let something even better tell us when to: STATISTICS. To cook that perfect ham, we built a number of PromQL alerts to stay on top of things.

[BLOG] Pit is less than 300 (PromQL)
Alert Level: High
PromQL:
 esphome_sensor_value{name='Alex - Pit Temperature'} >= 300
[BLOG] Pit is greater than 350 (PromQL)
Alert Level: High
PromQL:
 esphome_sensor_value{name='Alex - Pit Temperature'} <= 350
[BLOG] Holiday Ham will hit 140 in 5 min (PromQL)
Alert Level: Medium
PromQL: 
 predict_linear(esphome_sensor_value{name='Alex - Meat Temperature'}[10m], 300) >= 140
[BLOG] Holiday Ham will hit 140 in 30 min - Add Glaze (PromQL)
Alert Level: Medium
PromQL:
 predict_linear(esphome_sensor_value{name='Alex - Meat Temperature'}[60m], 1800) >= 140
[BLOG] Holiday Ham will hit 140 in 1 Hour - Add Glaze (PromQL)
Alert Level: Medium
PromQL: 
 predict_linear(esphome_sensor_value{name='Alex - Meat Temperature'}[60m], 3600) >= 140
[BLOG] Holiday Ham is 140! Dinner time! (PromQL)
Alert Level: High
PromQL:
 esphome_sensor_value{name='Alex - Meat Temperature'} >= 140

We also used the same concept in dashboards to track the temperature of the probes during the cook itself.

This was done in Sysdig, though other tools such as Grafana could also be used.

Sysdig is 100% compatible with Prometheus and PromQL. Sysdig’s backend lets it scale to thousands of devices and millions of metrics. While this was just a little device with two metrics, in an enterprise IoT world, the backend scale is absolutely critical.

You can see various panels doing color and prediction based on the probes, as well as charting out the real value overlaying with alerts as they come in (you can see the yellow and red squares above the line denoting when they trigger). Those alerts look like this:

Those same alerts were being funneled to Slack to produce handy reminders.

All I can say is the results speak for themselves.

That was one delicious ham.

PromQL is really versatile

Overall, this little project with a custom IoT device was very fun. The biggest takeaway we had was just how versatile PromQL really is. This application was in home cooking and seems a bit silly, but we quickly realized that there is not a single product on the market you could use to do what we did here. Using a prediction model took the “watch it” variable out of the equation, letting us focus on other things without forgetting about our cooking.

Imagine a world where you just put a sensor in food, and get an alert on your phone telling you what to do next and when it’ll need to be done, predictively. That’s the dream right there!

Watch out for IoT devices

While this is a cooking example, you can imagine that as IoT devices get bigger and bigger in the enterprise, there is a large calling for tools like this. Automobiles that give you greater granularity on the health of components, cell phones that do better analysis of how fast to charge and when, or solar cells that give you modeling on power generation and consumption. Being able to extract, track, and model this data in a standard way will bring a whole new wave of innovation and interoperability to the world of IoT and connected devices, both in the home and enterprise.

Have a nice holiday!

If you’d like to play with what we’ve done in this blog, feel free! If you have an enterprise application for PromQL and IoT, check out Sysdig, we’d love to help. We also invite you to check out PromCat.io, our repository of curated and supported Prometheus integrations and PromQL resources.

From our family to yours, have a wonderful holiday.

Stay up to date

Sign up to receive our newest.

Related Posts

Challenges using Prometheus at scale

Five Prometheus exporters best practices to increase your productivity

Best practices for alerting on Kubernetes