Laundromat IoT Dashboard

A laundromat looks like a retail business from the front, but from the back it is an uptime business. If gas or water runs out, the software layer does not matter: machines stop, staff improvise, customers wait, and the owner learns about the problem too late.

The useful public lesson from this project is simple: small physical operators do not need a “smart building” platform. They need a narrow observability loop around the few resources that can shut the business down.

For a laundromat, the first two resources are LP gas and water.

Operating Goal

The dashboard should answer four questions without exposing private branch details:

1. What is the current usable level of each critical supply?
2. Is the reading trustworthy, stale, or physically suspicious?
3. How many operating days are left at the recent consumption rate?
4. Who needs to act now, and what is the next action?

That last question matters most. A gauge is useful only if it changes behavior before the outage.

System Shape

flowchart LR
  A["Gas tank / water cistern"] --> B["Sensor adapter"]
  B --> C["Edge device"]
  C --> D["Ingestion API"]
  D --> E["Readings store"]
  E --> F["Policy engine"]
  F --> G["Dashboard"]
  F --> H["WhatsApp / Telegram / email alert"]
  H --> I["Acknowledgement and restock workflow"]

The system has four layers:

• Measurement: turn a physical level into a normalized reading.
• Transport: move readings from the branch to the backend with timestamps and device health.
• Interpretation: convert raw readings into level, confidence, trend, and days-to-empty.
• Action: route alerts to the person who can restock, inspect, or escalate.

Sensor Tradeoffs

The safest default is to avoid invasive measurement. A laundromat is a harsh environment for hobby electronics: heat, humidity, vibration, staff cleaning, customers, and metal enclosures all matter.

LP Gas

Option	Good fit	Tradeoff
Magnetic or Hall-effect reader on a compatible dial	Non-invasive readings from an existing analog gauge	Requires gauge compatibility, careful alignment, and calibration against the dial range
Camera pointed at the gauge	Cheap retrofit when the gauge is visible and difficult to instrument directly	Needs lighting control, enclosure design, image parsing, and local privacy rules so images do not become a data leak
Supplier or industrial telemetry	Best when the gas provider already supports remote tank monitoring	Higher recurring cost, vendor dependency, and less control over API quality
Load cells	Useful for portable cylinders	Usually awkward for stationary tanks and heavy installations

For gas, the decision rule is safety first, integration second, price third. The first production version should treat the gas sensor as advisory until manual readings prove the calibration.

Water

Option	Good fit	Tradeoff
Ultrasonic sensor above the cistern	Low-cost level measurement with easy maintenance access	Condensation, foam, tank shape, and sensor dead zones can create bad readings
Hydrostatic pressure sensor	Better signal quality for deep tanks and irregular geometry	Requires submerged hardware, analog conversion, cable sealing, and occasional inspection
Float switch	Cheap high/low safety backup	Binary signal only; it cannot estimate trend or days remaining
Flow meter	Consumption and leak detection	Measures usage, not stored level, so it complements rather than replaces a level sensor

The practical water setup is often a level sensor plus a float switch. The level sensor powers the dashboard; the float switch catches obvious failure modes.

Data Model

The backend should not store only “percentage full.” It should keep enough context to debug the physical system:

• site_id: logical location without public address details.
• asset_id: gas tank, cistern, pump, or future monitored resource.
• device_id: edge device sending the reading.
• raw_value: distance, pressure, dial angle, image-derived value, or vendor payload.
• normalized_percent: estimated usable level from 0 to 100.
• quality: ok, stale, noisy, out-of-range, impossible-change, or manual-override.
• observed_at: sensor timestamp, not only server receipt time.
• battery_or_power: health signal for wireless devices.
• rssi_or_connectivity: useful when WiFi quality explains missing data.

This keeps the dashboard honest. Operators should see “42%, low confidence” instead of a polished number that hides bad telemetry.

Alerting Flow

Alerts should be stateful. A threshold alone creates noise.

1. Readings arrive on a fixed interval or after a meaningful level change.
2. The backend rejects impossible values, such as a sudden increase without a delivery event.
3. The policy engine calculates trend, days-to-empty, and severity.
4. A warning opens when the level crosses a configurable band, for example below 30%.
5. A critical alert opens when the level crosses a lower band, for example below 15%, or when days-to-empty falls below the operating buffer.
6. The alert is routed to the right role: staff for inspection, manager for approval, supplier contact for restock.
7. Someone acknowledges the alert with an expected action and due time.
8. The alert closes only when the reading recovers, a delivery is logged, or a manager marks the sensor as faulty.

Two small details prevent alert fatigue:

• Hysteresis: do not clear a 15% alert at 16%; require a higher recovery band.
• Staleness alerts: “no reading in six hours” is a different problem from “water is low” and should have its own runbook.

Implementation Path

Phase 0: Manual Baseline

Before installing sensors, collect manual readings for a few weeks: current level, time, operating day, and restock events. This produces the first calibration curve and exposes how often humans can realistically check supplies.

Phase 1: One Branch, Two Resources

Install one gas reading path and one water reading path. Keep manual readings in parallel. The first milestone is not prediction; it is agreement between the dashboard and the physical gauge.

Phase 2: Dashboard and Alerts

Add current level, trend, device health, last reading, and open alerts. The dashboard should live near existing staff or manager workflows, not in a separate tool people forget to open.

Phase 3: Operator Workflow

Connect alerts to action:

• acknowledgement,
• assigned owner,
• restock requested,
• delivery logged,
• sensor inspection logged,
• alert closed.

At this point the system becomes an operations tool, not a charting experiment.

Phase 4: Reusable Deployment Template

Turn each installation into configuration:

• assets per location,
• sensor type per asset,
• calibration values,
• alert thresholds,
• notification recipients by role,
• maintenance reminders,
• runbook links.

The reusable part is not the hardware bill of materials. It is the workflow contract between sensors, alerts, and operators.

Reuse Outside One Laundromat

The same architecture works for other small physical operators when the monitored resource has three properties:

• running out causes immediate operational pain,
• the level changes slowly enough to forecast,
• someone can act before the outage.

That includes gas, water, chemicals, detergent, filters, consumables, cold-room temperature, and some machine-health signals. The domain changes; the loop stays the same:

resource -> reading -> confidence -> policy -> alert -> acknowledged action

To make it reusable, the system should avoid hardcoding laundromat assumptions. “LP gas tank below 15%” and “restaurant CO2 cylinder below 15%” are different policies over the same primitive: a monitored resource with a level, confidence score, owner, and runbook.

What Stays Private

This public note intentionally omits branch addresses, supplier routes, staff contacts, exact tank sizing, construction specs, vendor quotes, financial ledgers, credentials, and branch-specific escalation rules.

Those details are necessary to operate the business. They are not necessary to teach the architecture.

Related

• Laundromats
• Laundromats Overview
• Building for LatAm