Compressed air leak monitoring turns an invisible, always-on loss into a number you can trend, report and act on. In this guide you will design a monitoring setup with flow and pressure sensors that publish over MQTT, calculate leakage from off-shift consumption and pressure decay, and raise alerts when the leak rate creeps back up after a repair campaign.
Why Compressed Air Leaks Deserve Continuous Monitoring
Compressed air is one of the most expensive utilities in a factory per unit of useful energy delivered: the compressor converts electricity into heat for the most part, and only a fraction ends up as work at the tool. Leaks make that worse because they draw air every hour of every day, including nights and weekends when nothing is producing.
Most plants already know leaks exist. Maintenance teams run ultrasonic surveys, tag leaks and fix them. The problem is what happens next: without measurement, nobody can say how much the campaign saved, and within months new leaks appear at quick couplings, worn hoses, drain valves and cylinder seals. Continuous monitoring closes that loop. It tells you the leak rate today, compares it with the rate after the last repair, and flags when it is time for the next survey.
What to Measure
You do not need a sensor on every machine to get started. A small set of measurement points answers the important questions.
| Measurement point | Sensor | What it answers |
|---|---|---|
| Main header after the dryer | Thermal mass flow meter | Total air consumed by the plant |
| Compressor discharge | Pressure transmitter (4 to 20 mA or Modbus) | Generation pressure and control band |
| Far end of the network | Pressure transmitter | Pressure drop across pipes, filters and dryers |
| Each compressor | Current transformer or the controller's Modbus registers | Load, unload and off states, electrical power |
| Large consumers or zones (optional) | Branch flow meters | Which area is responsible for the leak load |
| Production schedule | MES, PLC or a simple shift calendar | When the plant is supposed to be idle |
Thermal mass flow meters are the usual choice for the header because they measure standard flow directly and have low pressure loss. Many current models expose readings over Modbus RTU or Modbus TCP, some over 4 to 20 mA, and a few speak MQTT natively.
Architecture: From Sensor to Leak Number
The data path is the same pattern used for any utility monitoring:
- Sensors and meters sit on the air network and on the compressors.
- An edge gateway (an industrial PC, a Raspberry Pi with an RS-485 interface, a PLC with an MQTT library, or Node-RED) polls Modbus registers or analog inputs every few seconds.
- The gateway publishes JSON over MQTT to a broker, using a topic structure based on the plant hierarchy.
- Consumers subscribe: a historian writes the values to a time-series database, a small service computes leak metrics, and dashboards and alerts read the results.
The broker decouples all of them. If you are not sure what an MQTT broker does in this picture, think of it as the switchboard every producer and consumer connects to, so adding a new dashboard never touches the gateway.
A topic layout that follows ISA-95 keeps things readable and lets ConnectMQ show the devices by level in its devices view:
connectmq/plant1/utilities/compressed-air/header/flow {"ts":1760600000,"nm3_min":18.4}
connectmq/plant1/utilities/compressed-air/header/pressure {"ts":1760600000,"bar":6.9}
connectmq/plant1/utilities/compressed-air/end-of-line/pressure {"ts":1760600000,"bar":6.4}
connectmq/plant1/utilities/compressed-air/comp1/state {"ts":1760600000,"state":"load","kw":72.5}
connectmq/plant1/utilities/compressed-air/leak/offshift {"ts":1760600000,"nm3_min":4.1,"share_pct":22.3}
The last topic is a derived value, published retained so a dashboard opening at any time sees the latest leak figure immediately.
Method 1: Off-Shift Baseline Flow
The simplest and most robust way to quantify leakage continuously is to look at flow when production is stopped. During a planned idle window (night shift off, Sunday, lunch break on a line that fully stops) almost everything flowing through the header is leakage plus a few legitimate always-on users such as purge air or air knives that were not switched off.
The service below subscribes to header flow, checks whether the current time falls within a configured idle window, averages the flow over that window, and publishes the result. It uses the public test broker for the demo; swap in your credentials for production.
#!/usr/bin/env python3
"""Off-shift compressed air leak estimator."""
import json
import statistics
import time
from datetime import datetime
import paho.mqtt.client as mqtt
BROKER = "broker.connectmq.com"
PREFIX = "connectmq/demo/air-7f3k/plant1/utilities/compressed-air"
FLOW_TOPIC = f"{PREFIX}/header/flow"
LEAK_TOPIC = f"{PREFIX}/leak/offshift"
IDLE_HOURS = range(1, 5) # 01:00-04:59 is a planned idle window
PRODUCTION_AVG_NM3_MIN = 18.0 # reference average flow during production
samples = []
window_open = False
def in_idle_window(now: datetime) -> bool:
return now.hour in IDLE_HOURS
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe(FLOW_TOPIC, qos=1)
def on_message(client, userdata, msg):
global window_open
data = json.loads(msg.payload)
now = datetime.now()
if in_idle_window(now):
window_open = True
samples.append(float(data["nm3_min"]))
elif window_open and samples:
leak = statistics.median(samples)
result = {
"ts": int(time.time()),
"nm3_min": round(leak, 2),
"share_pct": round(100 * leak / PRODUCTION_AVG_NM3_MIN, 1),
"samples": len(samples),
}
client.publish(LEAK_TOPIC, json.dumps(result), qos=1, retain=True)
print("Published leak estimate:", result)
samples.clear()
window_open = False
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="leak-estimator-7f3k")
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.loop_forever()
Using the median instead of the mean makes the estimate resistant to someone briefly blowing off a part during the night. In a real plant you would take the idle window from the production schedule or from machine states instead of a fixed hour range, and you would subtract known always-on users.
Method 2: Pressure Decay Test
When there is no flow meter yet, or you want to validate it, a pressure decay test gives a direct leak estimate. With all consumers stopped, the compressors are switched off and the system pressure is logged as it falls. Because the pressure transmitters already publish over MQTT, you only need to note the start and end of the test.
The leak flow in free air is approximately:
Q_leak [l/min free air] = V [l] x (p1 - p2) [bar] / (t [min] x 1.013 [bar])
V = total system volume (receivers + piping)
p1 = start pressure, p2 = end pressure (gauge)
t = time to fall from p1 to p2
For example, with a 3,000 litre system falling from 7.0 to 6.0 bar in 2 minutes, the leakage is about 3,000 x 1.0 / (2 x 1.013), or roughly 1,480 l/min of free air. Some practitioners apply a correction factor because leaks flow faster at full pressure than at the lower end of the test; whichever convention you choose, apply it consistently so results stay comparable over time.
Run the test at the same times each month and publish the result to a leak/decay-test topic, and you get a second trend line that does not depend on the flow meter.
Compressed Air Leak Monitoring Alerts and KPIs
Numbers only change behaviour when someone sees them. A practical alert and KPI set:
- Off-shift leak flow per night, trended weekly. This is the headline number.
- Leak share as a percentage of average production flow, useful for comparing plants of different sizes.
- Specific power (kW per m³/min) of the compressor station, which reveals inefficient load/unload cycling.
- Pressure drop between the compressor discharge and the end of the network, which often explains why setpoints were raised.
- Alert when the leak share exceeds the post-repair level by a margin you choose, signalling that a new ultrasonic survey is due.
In the ConnectMQ portal you can create a threshold alert rule on the nm3_min or share_pct field of the leak topic; each breach lands in the alerts log. For notifications by email, chat or SMS, a small Node-RED flow or Python subscriber connected to the broker forwards the event, since ConnectMQ itself does not send webhooks. The threshold alerts guide shows that pattern step by step.
Common Pitfalls
- Wrong flow meter position. Installing the meter before the dryer measures purge and condensate drain losses too. Put it after the air treatment unless you specifically want those.
- Ignoring always-on users. Air knives, blow-off nozzles and cabinet coolers left running at night are not leaks, but they are waste. Identify them separately so the leak number stays honest.
- Confusing normal and standard flow. Make sure every meter reports in the same reference conditions before comparing or summing.
- No link to production state. Without knowing when the plant is idle, the baseline is guesswork. Pull state from your machine status monitoring topics if you already have them.
- One-off projects. A dashboard nobody owns decays quickly. Assign the leak KPI to a person and review it in the same meeting as other energy figures.
Fitting into the Wider Energy Picture
Compressed air is usually one line item in a broader programme. The same broker and topic structure carry electrical meters, gas and water, so the leak estimator above sits next to the data described in factory energy monitoring and the machine-level breakdown from electrical sub-metering. If you are preparing for ISO 50001, compressed air is frequently identified as a significant energy use, and continuous leak data becomes evidence of improvement. For the strategic view of where energy fits among other initiatives, see the smart manufacturing guide.
Running the broker yourself is possible, but utilities data is only valuable if it is always there. A cloud MQTT broker removes the patching, certificates and uptime worries from the maintenance team's list so they can focus on fixing leaks.
Monitor Compressed Air on ConnectMQ
ConnectMQ is a fully managed MQTT broker with TLS, an ISA-95 aware devices view, a live topic explorer and threshold alerts. Prototype your leak monitoring on broker.connectmq.com, then create a free Serverless broker with no credit card and point your gateways at it.
Frequently Asked Questions
Do I need a flow meter to start compressed air leak monitoring?
No. Pressure transmitters alone let you run periodic pressure decay tests and log the results over MQTT. A thermal mass flow meter on the main header makes the measurement continuous and is the recommended next step.
How often should the leak estimate be calculated?
Once per planned idle window is usually enough, typically every night or weekend. Trend the values weekly so short-term noise does not trigger unnecessary surveys.
Can existing compressor controllers provide the data?
Often yes. Many compressor controllers expose load state, pressure and running hours over Modbus, which a gateway can read and publish over MQTT next to your own sensors.
Does the MQTT broker calculate the leak rate itself?
No. ConnectMQ transports the sensor data and can raise threshold alerts on published values. The leak calculation runs in a small service, Node-RED flow or edge script that connects to the broker as an MQTT client.
