🔥 OpenEmber

Open-source, programmable firmware for wood-pellet grills — with the Make Now style recipe engine the stock Traeger app keeps behind its cloud.

OpenEmber is an ESP32 firmware for a replacement controller that reuses your grill's existing auger, hot-rod igniter, induction fan, temperature sensor and meat probe, and adds:

• 🌡️ PID temperature hold with a windowed auger duty cycle (no more ±30 °F swings)
• 📋 Programmable multi-step recipes — the Make Now analogue, but the recipes live on your device, not a vendor cloud, and you write your own
• 💨 Super Smoke, Keep Warm (165 °F), controlled ignition & shutdown
• 🔬 Meat-probe target alarms, step timers, and progress tracking
• 🏠 Home Assistant integration over MQTT (auto-discovery) — dashboards, notifications, Alexa/Google, and automations, no phone-app build required
• 🕸️ A self-hosted web UI and a clean REST API
• 🛟 A safety-first controller: over-temp cutoff, flameout & ignition-failure detection, sensor-loss lockout, fail-safe outputs

⚠️ This drives a mains-powered appliance that lights a fire. Read docs/SAFETY.md before you build or flash anything. No warranty. Not affiliated with or endorsed by Traeger.

Designed and documented against the Traeger Pro 575 (D2 WiFIRE controller, part KIT0402), and portable to any pellet grill with an auger + igniter + fan.

---

Why

The Pro 575's hardware is excellent, but its best software features — WiFIRE app control and the ~1,600 guided Make Now recipes — are gated behind Traeger's cloud and mobile app. If the cloud changes, your grill's smarts change with it. OpenEmber puts a comparable (and programmable) experience entirely on hardware you own, and hands off the "app" to Home Assistant so there's nothing proprietary in the loop.

See docs/FEATURE_PARITY.md for a feature-by-feature comparison with the stock Pro 575.

How it works

Recipe (JSON, "Make Now")  →  RecipeEngine  →  GrillController  →  auger/igniter/fan
                                    ↑                 ↑
                              TempSensor (RTD + meat probe)
   Web UI / REST / MQTT  ──────────┘

All fire safety lives in GrillController; recipes and the network can only ask it to do safe things. Full design in docs/ARCHITECTURE.md.

Data model / ERD

OpenEmber does not use SQL. The ERD below maps the persisted LittleFS JSON files and the live REST/MQTT status payloads to their firmware structs.

erDiagram
    DEVICE_CONFIG {
        string hostname
        string wifiSsid
        string wifiPass
        float kp
        float ki
        float kd
        float grillOffsetF
        string mqttHost
        int mqttPort
        string mqttUser
        string mqttPass
        bool haDiscovery
    }

    RECIPE {
        string id PK
        string name
        string author
        bool keepWarm
        int stepCount
    }

    RECIPE_STEP {
        string recipeId FK
        int stepIndex PK
        string name
        float setpointF
        bool superSmoke
    }

    ADVANCE_RULE {
        string recipeId FK
        int stepIndex FK
        string type
        int seconds
        int probeIndex
        float targetF
    }

    RESUME_STATE {
        bool active
        string recipeId FK
        int stepIndex FK
        bool paused
    }

    STATUS_SNAPSHOT {
        string fw
        int uptimeS
    }

    GRILL_STATUS {
        string state
        float tempF
        float setpointF
        bool augerOn
        float augerDuty
        bool igniterOn
        bool fanOn
        bool superSmoke
        bool lit
        int secondsInState
        string error
    }

    COOK_STATUS {
        string state
        string recipe
        int stepIndex
        int stepCount
        string stepName
        float stepSetpointF
        bool stepSuperSmoke
        string advanceType
        float stepProgress
        int stepElapsedS
        int stepRemainingS
        int percentComplete
        int probeIndex
        float probeTargetF
    }

    PROBE_READING {
        int index PK
        bool connected
        float tempF
    }

    NET_STATUS {
        string mode
        bool connected
        string ip
    }

    OUTPUT_COMMAND {
        float augerSpeed
        bool augerReverse
        bool igniter
        float fanSpeed
        bool aux
    }

    DEVICE_CONFIG ||--o{ RECIPE : stores
    DEVICE_CONFIG ||--|| NET_STATUS : configures
    RECIPE ||--|{ RECIPE_STEP : contains
    RECIPE_STEP ||--|| ADVANCE_RULE : advances_by
    RECIPE ||--o| RESUME_STATE : persisted_as
    RECIPE_STEP ||--o| RESUME_STATE : resumes_at
    RECIPE ||--o| COOK_STATUS : drives
    RECIPE_STEP ||--o| COOK_STATUS : current_step
    STATUS_SNAPSHOT ||--|| GRILL_STATUS : includes
    STATUS_SNAPSHOT ||--o| COOK_STATUS : includes
    STATUS_SNAPSHOT ||--|{ PROBE_READING : includes
    STATUS_SNAPSHOT ||--|| NET_STATUS : includes
    GRILL_STATUS ||--|| OUTPUT_COMMAND : commands
    PROBE_READING ||--o| ADVANCE_RULE : can_satisfy

Loading

Persistence is intentionally small: /config.json stores DeviceConfig, /recipes/<id>.json stores each Recipe with its ordered steps and advance rules, and /resume.json stores the current recipe/step pointer for reboot recovery. GET /api/status and <hostname>/state publish StatusJson, which embeds grill, cook, probe, and network status in one snapshot.

Hardware

You need a small controller board: an ESP32, an RTD amplifier (MAX31865) for the grill probe, NTC dividers for the meat probes, and an isolated relay/SSR board for the three mains loads. It plugs into the grill's existing wiring harness, so every original sensor and actuator is reused.

Full teardown of the Pro 575 (boards, ICs, connectors, pinouts, screen, buttons) and the reference build: docs/HARDWARE.md. Default pin map: include/pins.h.

Build & flash

# 1. Install PlatformIO (pip install platformio) and clone the repo
git clone https://github.com/superbeetle1973/openember.git && cd openember

# 2. Build + flash the firmware
pio run -t upload

# 3. Upload the web UI to the device filesystem
pio run -t uploadfs

# 4. First boot: join Wi-Fi "OpenEmber-Setup", open http://192.168.4.1/,
#    enter your Wi-Fi + (optional) MQTT under the config, reboot.

Step-by-step flashing, wiring, first-light dry-run, and PID tuning: docs/FLASHING.md.

Writing recipes

Recipes are small JSON files — a list of steps, each with a temperature and a condition that advances the cook (a timer, a probe target, a grill target, or a manual tap). Ends in Keep Warm or shutdown. Format and examples: docs/RECIPE_FORMAT.md · seeds in recipes/.

python3 tools/validate_recipe.py recipes/*.json   # validate before uploading

API

REST + MQTT, same payload on both. See docs/API.md.

Project layout

Path	What
src/hardware/	Outputs (relays), TempSensor (RTD + NTC probes)
src/control/	Pid, GrillController (state machine + all safety)
src/recipe/	Recipe, RecipeEngine (Make Now)
src/storage/	Storage (LittleFS: config, recipes, resume)
src/net/	Wi-Fi, web server, MQTT/HA, shared status JSON
data/www/	web UI (uploaded to LittleFS)
recipes/	example recipes + JSON schema
docs/	hardware, flashing, safety, architecture, API, parity
tools/	recipe validator

Contributing & license

MIT — see LICENSE. PRs welcome, especially teardown data and pin maps for other grills. Please keep all fire-safety logic in GrillController and never let a new feature bypass the hard limits in config.h.

Independent project. Not affiliated with, endorsed by, or supported by Traeger. "Traeger", "WiFIRE", and "Make Now" are trademarks of their respective owners, used here only to describe interoperability.