I reverse-engineered my Masterbuilt Gravity smoker and built a full read + write Home Assistant integration (with a custom card)

My Gravity Series 800 has WiFi and a phone app, but no local API and nothing in HA that could actually control it. So I went down a rabbit hole. Here's where it landed and how I got there.

What it does now

• Live: grill temp, up to 4 meat probes + their targets, heat/fan %, signal, errors
• Control from HA — set the grill and probe targets (step or type it in); the write goes to the smoker and it obeys
• Full cook history pulled from Masterbuilt's cloud at ~10s resolution, including cooks from before I installed the integration
• Stale-data detection (more on why below)
• A companion Lovelace card: live cook, a chart that fits the cook, a state timeline, a history browser, and the setpoint controls

How I got here

1. Bluetooth was a dead end. An HCI snoop of the official app proved BLE on this firmware is setup-only — it provisions WiFi and nothing else. All cook data goes controller → Masterbuilt cloud over WiFi.
2. The cloud is two planes. Static analysis of the Android app (dumping the DEX string pool + androguard) revealed a REST API (cas.masterbuilt.com) for auth + history, and a separate AWS IoT device shadow for live state and control.
3. Reads were the easy half — and there's a hidden sessions API storing every cook at 10s resolution server-side. Fun aside: it independently confirmed a night my smoker's WiFi wedged — its last data point matched exactly when UniFi last saw the device.
4. Writes were the hard half. No write route exists on the REST API. Setpoints are MQTT publishes to the AWS IoT shadow, authenticated with a per-install X.509 cert the app provisions for itself — and that provisioning chain wasn't fully in the APK.
5. So I ran the app in an Android emulator behind mitmproxy (no cert pinning, thankfully), captured the whole cert-mint + policy-attach flow, replicated it in Python, and tested it live on the grill — nudged the setpoint, watched the controller obey, set it back.
6. Then built all of it into the integration as proper number entities + a control engine, plus the card.

The staleness thing is worth calling out: the controller keeps cooking even if its WiFi module wedges, and the cloud then cheerfully reports power: off with no temperature while your brisket is still going. A naive integration shows "off." So there's a dedicated stale data sensor driven by the shadow's own per-field timestamps — alert on that, never on the power sensor.

Honest caveats

• Unofficial, not affiliated with Masterbuilt; they could change the API any time.
• Cloud-dependent — no local control (BLE genuinely can't do it on this firmware).
• Power on/off is deliberately not implemented. I confirmed setpoints; I'm not shipping a guessed on/off command for a live fire.
• It's a fork of u/hruskin's existing read-only integration (MIT) — full credit for the original CAS reverse-engineering.

Install: HACS → custom repositories (one integration, one dashboard card). Both are submitted to the default HACS store and waiting in the review queue.

• Integration: github.com/lucvan/masterbuilt-gravity-ha
• Card: github.com/lucvan/masterbuilt-cook-card

Tested on a Gravity 800; should work across the Gravity Series but that's the one I have. Happy to answer anything.