Bearing Temperature Monitoring with Wireless Sensors and MQTT Alerts

Bearing temperature monitoring is one of the simplest ways to protect motors, pumps, fans and conveyors from unplanned stops. This use case shows how to put wireless temperature sensors on bearing housings, publish readings over MQTT, compensate for ambient temperature and raise threshold and rate-of-rise alerts well before a bearing overheats.

Why Monitor Bearing Temperature

Bearings fail for familiar reasons: lubrication breakdown, over-greasing, contamination, misalignment, excessive belt tension and simple fatigue. Most of these show up as extra friction, and extra friction shows up as heat. A bearing that normally runs a steady amount above room temperature and starts creeping upward is telling you something.

Temperature is usually a later indicator than vibration. A vibration sensor may catch an early surface defect weeks ahead, while temperature tends to rise once damage or lubrication problems are well under way. That does not make it less valuable. Temperature sensors are cheap, easy to install and easy to interpret, and they are excellent at catching the failure modes that develop quickly, such as a lubrication failure after a missed greasing round or a seized seal. In practice the best programs use both: vibration monitoring sensors for early mechanical warning and temperature as a robust second opinion.

The Monitoring Setup

The use case below covers a typical utility area: six pumps and four fans, each with a drive-end and non-drive-end bearing. Running cables to twenty measurement points across a plant room is expensive, so the sensors are wireless and battery powered.

Mounting the probe

Mount the probe on the bearing housing, as close to the outer ring as possible, ideally in the load zone. A small tapped hole with a threaded probe gives the best thermal contact; thermal epoxy or a magnetic mount with thermal paste works where drilling is not allowed. Avoid mounting on guards, covers or the motor frame far from the bearing, because they lag behind and read low. Label each probe with its asset and position, for example pump3/de for the drive end.

Wireless Node Firmware

The sketch below wakes an ESP32 every minute, reads a bearing probe and an ambient probe on the same OneWire bus, publishes one JSON message and goes back to deep sleep. Install PubSubClient, OneWire and DallasTemperature from the Arduino Library Manager. For a deeper look at the sensor itself, see the ESP32 DS18B20 MQTT tutorial.

#include <WiFi.h>
#include <PubSubClient.h>
#include <OneWire.h>
#include <DallasTemperature.h>

const char* WIFI_SSID = "YOUR_WIFI";
const char* WIFI_PASS = "YOUR_WIFI_PASSWORD";
const char* CLIENT_ID = "brg-pump3-de-51ad7e";
const char* TOPIC = "connectmq/demo/51ad7e/utilities/pump3/bearing_de";
const uint64_t SLEEP_US = 60ULL * 1000000ULL;

// Replace with the addresses printed by a OneWire scanner sketch
DeviceAddress BEARING = {0x28, 0xFF, 0x64, 0x1E, 0x15, 0x21, 0x03, 0x9A};
DeviceAddress AMBIENT = {0x28, 0xFF, 0x3C, 0x0B, 0x15, 0x21, 0x03, 0x41};

OneWire oneWire(4);
DallasTemperature sensors(&oneWire);
WiFiClient net;
PubSubClient mqtt(net);

void sleepNow() {
  esp_sleep_enable_timer_wakeup(SLEEP_US);
  esp_deep_sleep_start();
}

void setup() {
  sensors.begin();
  sensors.requestTemperatures();
  float bearing = sensors.getTempC(BEARING);
  float ambient = sensors.getTempC(AMBIENT);

  WiFi.mode(WIFI_STA);
  WiFi.begin(WIFI_SSID, WIFI_PASS);
  uint32_t start = millis();
  while (WiFi.status() != WL_CONNECTED) {
    if (millis() - start > 15000) sleepNow();  // give up, try next cycle
    delay(100);
  }

  mqtt.setServer("broker.connectmq.com", 1883);
  if (!mqtt.connect(CLIENT_ID)) sleepNow();

  char payload[160];
  snprintf(payload, sizeof(payload),
           "{\"bearing_c\":%.2f,\"ambient_c\":%.2f,\"delta_c\":%.2f,\"rssi\":%d}",
           bearing, ambient, bearing - ambient, WiFi.RSSI());
  mqtt.publish(TOPIC, payload, true);  // retained: dashboards see the latest value at once
  mqtt.loop();
  delay(100);
  mqtt.disconnect();
  sleepNow();
}

void loop() {}

The message is retained, so a dashboard that opens between wake-ups still shows the latest reading immediately. Publishing delta_c, the difference between bearing and ambient temperature, is the single most important design decision in this setup.

Why Ambient Compensation Matters

A fixed alarm on absolute bearing temperature behaves badly across seasons. A pump room in summer can be much warmer than in winter, so a limit that is safe in July may never trigger in January, and a limit tuned for January will cause nuisance alarms all summer.

The temperature rise above ambient, by contrast, depends mainly on load, speed and the condition of the bearing. Alarming on the delta removes the seasonal effect, while a separate absolute limit still protects against operating outside the lubricant's and bearing's rated range. Manufacturers publish maximum operating temperatures for bearings and greases; use those documents as the upper bound rather than a generic number from the internet.

Alert Strategy: Three Layers

A good bearing temperature monitoring scheme combines three kinds of rules:

1. Absolute limit. Bearing temperature above the maximum allowed by the bearing and grease specification. Always an alarm.
2. Delta limit. Rise above ambient significantly higher than the learned normal for that bearing. Usually a warning first, then an alarm.
3. Rate of rise. Temperature climbing faster than normal over a short window, for example several degrees within half an hour at stable load. This catches fast-developing failures early, often before either limit is reached.

The first two are simple thresholds. In the ConnectMQ portal you can create threshold alert rules on the bearing_c and delta_c fields of each topic and review every excursion in the alerts log, with no code. Rate of rise needs history, so it runs in a small subscriber service.

Rate-of-rise detector in Python

import json
import time
from collections import defaultdict, deque
import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/51ad7e"
WINDOW_S = 30 * 60          # look back 30 minutes
MAX_RISE_C = 5.0            # alert if delta rises more than this within the window
STALE_S = 5 * 60            # node missed several wake-ups

history = defaultdict(deque)   # topic -> deque of (time, delta_c)
last_seen = {}

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/+/+/+", qos=1)

def on_message(client, userdata, msg):
    if msg.topic.endswith("/alert"):
        return
    now = time.time()
    data = json.loads(msg.payload)
    h = history[msg.topic]
    h.append((now, data["delta_c"]))
    last_seen[msg.topic] = now
    while h and now - h[0][0] > WINDOW_S:
        h.popleft()
    rise = h[-1][1] - min(v for _, v in h)
    if rise > MAX_RISE_C:
        alert = {"ts": int(now), "kind": "rate_of_rise", "topic": msg.topic,
                 "rise_c": round(rise, 1), "window_min": WINDOW_S // 60,
                 "bearing_c": data["bearing_c"]}
        client.publish(f"{msg.topic}/alert", json.dumps(alert), qos=1, retain=True)
        print("ALERT", alert)
        h.clear()

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="brg-ror-51ad7e")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()

while True:
    time.sleep(60)
    for topic, seen in list(last_seen.items()):
        if time.time() - seen > STALE_S:
            print(f"STALE {topic}: no reading for {int(time.time() - seen)} s")
            last_seen.pop(topic)

The detector ignores retained alert topics, compares the latest delta with the lowest value in the window and clears its history after alerting so it does not fire every minute. The stale check matters for battery nodes: a sensor that silently stops reporting is as dangerous as a hot bearing nobody sees.

Rolling Out Across a Plant

1. Pilot on a few critical assets. Pick machines whose failure stops production, not the easiest ones to reach.
2. Collect two to four weeks of data before tuning. Learn normal delta per bearing at typical load.
3. Set delta and rate-of-rise limits per bearing. Drive-end and non-drive-end bearings often run at different temperatures.
4. Agree on a response. Who receives a warning, who receives an alarm, and what they check first (lubrication, alignment, belt tension, load).
5. Record findings. Each alert should end with a short note of what was found, so thresholds improve over time and your MTBF and MTTR calculation reflects reality.
6. Move to a private broker. Replace the public demo with credentials from the portal, TLS on port 8883 and ISA-95 topics such as acme/plant1/utilities/pumproom/pump3/bearing_de.

The demo above runs on the free public MQTT broker, where everything is visible to anyone. For real assets, a managed MQTT broker keeps the data private, the certificates renewed and the service running without anyone on your team maintaining servers.

Battery Life and Reliability Tips

• Wake, publish and sleep as fast as possible. Most battery drain comes from the Wi-Fi connection, so a one-minute interval is a trade-off; five minutes is plenty for slow trends if you keep rate-of-rise windows long.
• Use a static IP or a fast-reconnect strategy to cut connection time.
• Report rssi and battery voltage so weak nodes are fixed before they drop out.
• For large sites or metal-heavy plant rooms, consider sensors that use a dedicated wireless protocol and a gateway that republishes to MQTT.

Where Bearing Temperature Fits

Temperature is one signal among several. Combined with motor current monitoring it separates load-driven heating from friction-driven heating, and combined with vibration it confirms mechanical faults from two independent sources. The smart manufacturing guide shows how these signals share one MQTT backbone and topic structure across the plant.

Protect Your Bearings with ConnectMQ

ConnectMQ provides a private, TLS-secured MQTT broker with retained messages, a live topic explorer, a devices view by ISA-95 level and threshold alert rules in the portal. Start on the free Serverless plan at app.connectmq.com, no credit card required, and connect your first bearing sensor today.

Frequently Asked Questions

What is a normal bearing temperature?

It depends on the bearing, load, speed, lubricant and environment. Learn the normal rise above ambient for each bearing and use the bearing and grease manufacturer's maximum ratings as the absolute upper limit.

Is bearing temperature monitoring enough on its own?

It catches lubrication failures and fast-developing faults well, but temperature often rises later than vibration. Combine both for the earliest warning.

How often should a wireless bearing sensor report?

Every one to five minutes is typical. Bearing temperature changes slowly, and longer intervals greatly extend battery life.

Why alarm on temperature rise above ambient?

Ambient temperature varies with season and time of day. The rise above ambient reflects bearing condition more directly, so alarms stay meaningful all year.