wachtmeater

MEATER BBQ probe monitoring with Matrix chat alerts and SIP phone call notifications. Reads MEATER Cloud cooks directly from the cloud WebSocket (with CDP page scraping as fallback), posts status updates to E2E-encrypted Matrix rooms, and calls you when something needs attention (fire out, target reached, stall, cook ended, etc.). Supports automatic per-cook Matrix room creation and TOML-based configuration.

Why this exists

Long cooks — brisket, pulled pork, pork belly — routinely run 10 to 16 hours. You go to sleep, and while you sleep the fire can go out, the meat can stall for hours, or the target temperature gets reached with nobody there to pull it off. By the time you notice, the cook is ruined or at least far from ideal.

wachtmeater watches the MEATER Cloud page continuously and reaches out only when something actually needs your attention. Periodic Matrix messages give you the full picture at a glance — current internal and ambient temps, elapsed time, remaining estimate — so you can check in whenever you want without opening an app.

When things go sideways (or the cook finishes), a SIP phone call is triggered automatically. A phone call is the reliable escape hatch here: push notifications are easy to sleep through, but a ringing phone is not.

Tip: Save the calling number as a contact on your phone and mark it as a VIP / priority / starred contact. That way the call bypasses Do Not Disturb mode and actually wakes you up at 3 a.m. when your brisket hits target.

Screenshots

Real-world Beef Brisket cook, ~14 hours, monitored from start to finish.

Matrix status update mid-cook — 86 °C internal, 9 h 22 min elapsed.

MEATER Cloud dashboard showing "5 minutes before cook ends" — 94 °C with 95 °C target.

Matrix status update near the end — 94 °C internal, 13 h 36 min elapsed.

MEATER Cloud finished cook summary — target 95 °C, peak 94 °C, total time ~14 hours.

Components

CLI Sub-Commands

Matrix Commands

Send these in the Matrix room the bot has joined (case-insensitive):

Operator Commands

Operator commands are recognised only in the room configured as MATRIX_OPERATOR_LISTENING_ROOM, and only when the sender's MXID matches MATRIX_PITMASTER. Any other sender is silently ignored.

Cook-End Detection

When cookend is enabled, the watcher uses four independent mechanisms to detect that a cook has finished:

Mechanisms A, B, and D post a Matrix message and trigger a SIP phone call. Mechanism C sets cook-ended state silently (the watcher loop posts a generic shutdown message). The watcher loop stops automatically once any mechanism fires.

A genuine HTTP 404/410 on the cook URL is treated as authoritative "cook is gone" on both fetch paths. Every other failure — CDP outage, cloud unreachable, timeout — is transient and never ends a cook.

Temperature resolution

The cook page renders temperatures already rounded to whole degrees (.internal-value literally contains 95°), so no amount of DOM parsing can recover decimals. The WebSocket feeding that page carries the underlying fixed-point integers instead, which is why meater_cloud is the preferred path:

The divisor is the share page's own DEFAULT_DENOMINATOR = 32 (TemperatureToCelsius(t) = t / 32), giving 1/32 °C = 0.03125 °C resolution. The connection token sits in the share page HTML (window.MEATER.config), so a plain HTTP GET is enough — no Playwright, no CDP.

Resolution is not accuracy. MEATER specifies roughly ±0.5–1 °C, so the decimals sharpen trends — stall detection in particular, which compares small deltas across checks — rather than making absolute readings more correct. Alert thresholds are unchanged; only the reported values got finer. Status output is formatted to one decimal place.

This is an undocumented internal interface and may change without notice, which is exactly why the scraper is retained as an automatic fallback. When the watcher falls back, its status message says so (Quelle: Browser-Fallback (nur ganze Grad)).

End-phase forecast

After wrapped, the watcher fits the end phase of the cook with Newton's law of heating, T(t) = A - (A - T0)·e^(-c·t), using its own core readings. A is the real smoker temperature (set pit, default 110 °C), the fit starts ENDPHASE_SETTLE_MINUTES after the wrap; c and the start value T0 are fitted with a robust (Huber) loss via scipy, so a single glitchy reading barely moves the curve. The status message shows the ETA to the pull target from the current reading; if that reading is an outlier (clearly off the curve), the ETA starts from the curve value and a second line shows the ETA from the measured value. Background and validation: docs/kerntemperatur-prognose_en.md (German: docs/kerntemperatur-prognose.md).

Configuration

Settings are loaded from a TOML config file (wachtmeater.toml or path in $CONFIG), a flat .env file, or plain environment variables. Existing env vars always take precedence. See wachtmeater.toml.example for a full annotated example.

Local setup

wachtmeater.toml.example is the only config committed to git. For local development, create your own config from it:

cp wachtmeater.toml.example wachtmeater.local.toml
# then edit wachtmeater.local.toml with your MEATER URL, Matrix and SIP credentials

wachtmeater.local.toml is git-ignored (*.local.*) and never committed — keep your real credentials there. It is picked up automatically: read_dot_env_to_environ() searches (package dir, then CWD) for wachtmeater.toml → .env → .local.env → wachtmeater.local.toml. To use a different path explicitly, set CONFIG=/path/to/your.toml (e.g. CONFIG=wachtmeater.local.toml python -m pytest). In the container/K8s the config instead comes from the generated Secret mounted at /config/wachtmeater.toml.

Alert defaults (first run only)

These set the initial values written into a fresh per-cook state file. Once the watcher has saved state, runtime enable … / disable … Matrix commands take precedence — changes to these env vars are ignored on subsequent runs unless the state file is removed. The operator propagates all of these into spawned watcher TOMLs so each new cook starts with the operator's preferred profile.

Installation

pip install wachtmeater

From source

git clone https://github.com/vroomfondel/wachtmeater.git
cd wachtmeater
make install
source .venv/bin/activate

Running locally

# Single status check
./runcli.sh monitor

# Persistent watcher with Matrix listener
./runcli.sh watcher

Override settings in runcli.local.include.sh (sourced automatically, gitignored).

Kubernetes Deployment

There are two ways to run watcher Jobs in a cluster:

A) Direct CLI deploy (one cook at a time)

wachtmeater deploy --meater-url https://cooks.cloud.meater.com/cook/<uuid>

This creates: Namespace meater, Secret with the rendered wachtmeater.toml, and a Job running xomoxcc/wachtmeater:latest. Auth picks load_incluster_config() automatically when KUBERNETES_SERVICE_HOST is set, otherwise reads ~/.kube/config.

To tear down (deletes the per-cook Job and Secret; the shared meater namespace is kept):

wachtmeater deploy --meater-url https://cooks.cloud.meater.com/cook/<uuid> --delete

python -m wachtmeater.create_meater_watcher_job \
  --meater-url https://cooks.cloud.meater.com/cook/<uuid>
python -m wachtmeater.create_meater_watcher_job --delete

B) Operator (Matrix-driven, always-on)

For a more permanent setup, deploy the wachtmeater operator as a long-running Pod in the cluster. It listens in a configured Matrix room for operator new, operator delete, operator list, and operator status chat messages — so spawning a new watcher for the next cook is just a Matrix message away, no kubectl required.

The operator uses the same Matrix MXID as the watchers it spawns and auto-trusts every device of its own MXID at startup, so cross-pod E2E decryption works without manual verification. A separate crypto-store path (OPERATOR_CRYPTO_STORE_PATH) prevents SQLite-store races with watcher pods.

Reference manifests are in k8s/operator/:

Quickstart:

kubectl create namespace meater
kubectl -n meater create configmap wachtmeater-operator-config \
    --from-file=wachtmeater.local.toml=./wachtmeater.local.toml
kubectl apply -f k8s/operator/serviceaccount.yaml
kubectl apply -f k8s/operator/role.yaml
kubectl apply -f k8s/operator/rolebinding.yaml
kubectl apply -f k8s/operator/deployment.yaml
kubectl -n meater logs deploy/wachtmeater-operator -f

The ConfigMap entry is mounted via subPath into the container's WORKDIR (/app/wachtmeater.local.toml), so the file is picked up by the built-in config-file lookup in read_dot_env_to_environ() — no CONFIG env var needed.

Development

License

This project is licensed under the LGPL where applicable/possible — see LICENSE.md. Some files/parts may use other licenses: MIT | GPL | LGPL. Always check per‑file headers/comments.

Authors

• Repo owner (primary author)
• Additional attributions are noted inline in code comments

Acknowledgments

• Inspirations and snippets are referenced in code comments where appropriate.

⚠️ Note

This is a development/experimental project. For production use, review security settings, customize configurations, and test thoroughly in your environment. Provided "as is" without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software. Use at your own risk.