Distillery monitoring

How much spirit is each cask losing to the angels' share? A gas-sensing node on every cask, plus a classifier trained on your own warehouse, turns raw sensor scans into an ethanol-vapour estimate you can watch over time.

What you can see

  • Per-cask ethanol-vapour trends, refreshed continuously, across a whole warehouse
  • Temperature, humidity, pressure, and the raw gas-scan signals behind the estimate
  • A labelled history of cask events — fills, gaugings, sample draws, cleanings
  • Alerts when ethanol vapour climbs (a possible leak), delivered by email or webhook

The journey

  1. Install the pack — one step seeds the data model, annotation forms, and the correlation job (below).
  2. Provision the gateway — register it with a token; it provisions its own certificate and connects over cellular.
  3. Mount the nodes — one battery gas-sensing node per cask, reporting over Bluetooth to the gateway.
  4. Collect a baseline — the nodes run while you go about your business; data accumulates.
  5. Anchor it with references — take reference measurements (a PID instrument or lab assay) and annotate them against the casks.
  6. Train a classifier — offline, in Bosch BME AI-Studio, against your collected scans and references. This produces a small .config model.
  7. Deploy it — upload the model as a config artefact and bind it to your casks. The estimate now charts live, and you re-train whenever the spirit, cask type, or season changes.

What the pack installs

The mkd.distillery.bme690-pilot pack seeds:

  • Sensor profiles — the BME690 ten-step gas scan, a reference PID ethanol instrument, an outdoor weather station, and a battery fuel gauge
  • Device profiles — the distillery gateway and the scanning and reference node types
  • Annotation classes — cask added/removed, gauging, cleaning cycle, elevated ethanol, suspected leak, and a reference-disagreement label
  • A correlation job — a daily check that compares each gas-scan node against its paired reference instrument and flags when they drift apart, so a model is never trusted on stale agreement
  • Reference pairs — none by default; you declare which node pairs with which reference instrument after commissioning

What's yours, and what's the platform's

The classifier is trained on your warehouse's volatile profile — two distilleries with the same spirit but different cask history or climate can need different models, so the model is part of your operational know-how, not a platform feature. You own the casks, the sampling, the reference instrument, and the trained model (trained on your own laptop, on your data). The platform handles provisioning, ingest, storage, charts, alerts, export, and pushing your model to every gateway — and your data exports out cleanly at any time, with no lock-in.

Hardware

  • Gateway — LilyGo T-SIM7080G-S3 (Bluetooth scanner + cellular). Firmware: embedded/products/gateway-bme690.
  • Node — ESP32-S3 with a Bosch BME690 gas sensor, battery-powered. Firmware: embedded/products/node-bme690.
  • Reference — a photoionization (PID) ethanol instrument for ground-truth sampling.

Customer-side scripts

Training happens in Bosch BME AI-Studio on your own machine, against an export of your annotated data. Reshaping the platform's neutral export bundle for any downstream tooling is a small script you own.

Was this page helpful?