Predictive Motor Temperature.

Project Overview

Watches a motor's temperature and, crucially, its rate of rise — warning before it overheats and trips, so a line is stopped on purpose instead of by a failure.

When an industrial motor overheats, it does not just stop — it takes the production line down with it, unplanned, often at the worst moment, and repeated overheating quietly cooks the winding insulation until the motor fails for good. The motor's own thermal protection trips only when it is already too hot, which means the line stops as a consequence of the problem. This project moves the warning earlier: it watches the motor's temperature continuously and, most importantly, its rate of rise, so it can predict an overheat before it happens and warn while there is still time to intervene — reduce load, improve cooling, or stop the line on your terms rather than the motor's.

A temperature sensor on or near the motor (a contact probe on the frame/bearing, or a non-contact infrared sensor aimed at the winding area) gives the reading. But the key insight is that how fast the temperature is climbing is a better early warning than the absolute value: a motor heading for trouble shows an abnormally fast rise, or a rise that does not level off at its normal steady-state, long before it reaches the trip point. By modelling the motor's normal thermal behaviour — it warms to a steady temperature for a given load and ambient, following a characteristic curve — the monitor can tell a normal warm-up from a developing problem and project when the trip threshold will be reached.

That projection is the value: instead of "the motor is hot" (too late), it says "at this rate the motor will hit its limit in N minutes — act now". It stages alerts (watch/warning/critical), can trigger protective actions, and logs the thermal history so recurring overheating (a sign of overload, poor cooling, or a developing bearing/electrical fault) is visible and fixable. It is honest that it complements, not replaces, the motor's built-in thermal protection and proper thermal design, and that sensor placement and the motor's real thermal path matter. But as a predictive layer that turns temperature and its rate of change into advance warning, it converts unplanned overheating shutdowns into planned, controlled interventions — which is exactly what keeps a line running.

What this project does

• Monitors motor temperature continuously (contact or non-contact)
• Tracks the rate of rise, the key early-warning signal
• Models normal thermal behaviour to tell warm-up from a problem
• Projects time-to-trip and warns before overheating
• Stages alerts (watch/warning/critical) and can trigger protection
• Logs thermal history to reveal recurring overheating causes
• Complements the motor's own thermal protection

Real-World Applications

Deployment contexts where a build of this kind earns its keep.

Features & Capabilities

• Rate-of-rise prediction, not just a hot-threshold alarm
• Normal-thermal-behaviour model (steady-state vs abnormal)
• Time-to-trip projection for advance warning
• Staged alerts and protective triggers
• Thermal-history logging for root-cause (overload/cooling/fault)
• Contact or non-contact temperature sensing
• Complements built-in protection and thermal design

Difficulty, Time & Required Skills

Skills you should have (or will pick up)

• Contact/non-contact motor temperature sensing and placement
• Rate-of-rise computation and simple thermal modelling
• Time-to-threshold projection and staged alerting
• Thermal-history logging and root-cause interpretation
• Protective action and safe integration

Bill of Materials

Every part below is commonly available from Indian and international hobby-electronics suppliers. Prices are indicative 2026 retail figures in Indian rupees and will drift — treat them as a budgeting guide, not a quotation.

Estimated total: ₹3,895, excluding tools, shipping and consumables.

Tools and consumables

• Soldering iron (temperature controlled, 350 °C) with 0.8 mm 60/40 or lead-free solder
• Digital multimeter — continuity, DC volts and current ranges
• Wire strippers, flush cutters and a small set of precision screwdrivers
• Heat-shrink tubing and a heat gun (or a lighter, carefully)
• A laptop with a USB port and the toolchain listed above

Hardware Specifications

Consolidated electrical and interface specifications for every active part in the build.

Power Budget & Supply Sizing

Add up the typical active current of every part, then size the supply with at least 50 % headroom so transmit bursts and motor inrush never brown out the controller.

Summed typical draw is 3283 mA. With a 1.5× design margin the supply should deliver at least 5000 mA continuously at the stated rail voltage.

Software Requirements & Development Environment

Reference toolchain: Arduino IDE 2.3.x with the ESP32 board package 3.x (or PlatformIO on VS Code). Anything newer normally works; anything older may lack the board definitions used here.

• Install the Arduino IDE 2.3.x (or PlatformIO if you prefer a real editor and dependency locking).
• Add https://espressif.github.io/arduino-esp32/package_esp32_index.json under File → Preferences → Additional Board Manager URLs, then install esp32 from the Boards Manager.
• Set the correct port under Tools → Port. On Linux add yourself to the dialout group: sudo usermod -aG dialout $USER and log out and back in.
• Open the Serial Monitor at 115200 baud — every sketch here logs its state there.
• Keep File → Preferences → Show verbose output during: compilation switched on while you are debugging build errors.

Required libraries

Block Diagram

The block diagram shows the functional decomposition of the system — what senses, what decides, what acts, and where the data ends up.

Circuit Diagram & Wiring

Every signal line in the build is shown below, followed by a pin-by-pin connection table you can work through with a multimeter in hand.

Wire one row at a time and tick it off — most "it does not work" reports trace back to a single swapped pair.

Wiring explanation

• Place the temperature sensor where it best represents the motor's hot path — a probe on the frame near the winding/bearing, or an IR sensor aimed at the winding area — and record the offset to the true internal temperature.
• Ensure good thermal coupling for contact probes (thermal paste/clamp) and correct emissivity/aim for IR.
• Measure ambient too, so the thermal model can distinguish a hot day from a motor problem.
• Interface any protective action (load reduction/stop) to the drive/starter safely and in coordination with its own protection.
• Keep electronics tolerant of the motor's heat and vibration.

System Architecture

Read the stack from the bottom up: physical hardware, the firmware that drives it, the transport that moves data off the device, and the software a human actually looks at.

Working Principle

A motor's temperature carries a warning long before its own protection trips, but only if you read it the right way. The naive approach — alarm when the temperature exceeds a threshold — fires when the motor is already too hot, so the line stops as a consequence of the fault, which is exactly the unplanned event you wanted to avoid. The predictive approach reads the temperature's rate of rise and its trajectory, because a motor heading for an overheat betrays itself early: it heats faster than normal, or it fails to level off at its usual steady-state, well before it reaches the trip point. Catching the abnormal trend is what buys the time to act.

This works because a healthy motor has a characteristic thermal behaviour. Switched on at a given load and ambient temperature, it warms along an exponential curve toward a stable steady-state temperature (heat generated equals heat dissipated), reaching it in a predictable time with a predictable final value. That normal curve is the reference. A motor that is overloaded generates more heat and climbs toward a higher, possibly unsafe, steady-state; one whose cooling is impaired (blocked vents, failed fan, high ambient) dissipates less and also runs hotter; a developing bearing or electrical fault adds heat abnormally. Each shows up as a deviation from the normal thermal curve — a steeper rise, a higher plateau, a rise that does not settle — which the monitor can detect by comparing the live behaviour to the learned normal, accounting for ambient so a hot day is not mistaken for a fault.

From the rate and the model comes the actionable output: a time-to-trip projection. If the temperature is rising at a certain rate and the trip/limit is a certain distance away, the monitor projects when the limit will be reached — turning "the motor is warming" into "at this rate it will trip in N minutes, act now". That projection drives staged alerts: a gentle watch when behaviour is mildly abnormal, a warning when a trip is projected within a comfortable margin, and a critical alarm (with optional automatic protective action — reduce load, stop the drive in coordination with its own controls) when a trip is imminent. Staging gives operators graduated, timely information rather than a single last-second alarm.

Finally, the thermal history is where longer-term value lives. A single overheat is an event; a pattern of overheating is a diagnosis. Logging temperature, rate and ambient over time reveals whether a motor routinely runs too hot (chronic overload — resize or offload), overheats when cooling degrades (maintenance — clean vents, fix the fan), or shows a slow upward creep in running temperature over weeks (a developing bearing or electrical fault). This turns the monitor from an alarm into a root-cause tool. The design is explicit that it complements the motor's built-in thermal protection and proper thermal/electrical design rather than replacing them — the embedded protection remains the last line of defence, and sensor placement and the motor's real thermal path bound the accuracy — but as a predictive layer, reading rate-of-rise and trajectory against a normal thermal model, it delivers the thing that keeps a line running: warning of an overheat before it stops the motor, so the intervention is planned and controlled, not forced by failure.

The maths behind it

Rate of rise (early warning)

From successive temperatures T at times t:
  dT/dt = (T_now − T_prev) / (t_now − t_prev)   [°C/min]

Abnormally high dT/dt, or dT/dt not decaying toward 0 as
the motor should approach steady-state, is the early sign
of a developing overheat — before T is high.

Time-to-trip projection

With current T, trip limit T_trip and rate dT/dt > 0:

  t_to_trip ≈ (T_trip − T) / (dT/dt)

  warning if t_to_trip < T_warn_margin
  critical if t_to_trip < T_crit_margin (or T near T_trip)
Projects WHEN the limit is reached → act in advance.

Normal thermal model (deviation)

Healthy warm-up: T(t) → T_ss with time constant τ:
  T(t) = T_amb + ΔT_ss·(1 − e^(−t/τ))

T_ss and τ characterise the motor at a load/ambient.
Deviation (higher T_ss, steeper rise, no settling) vs the
learned normal = overload / poor cooling / developing fault.

Program Flowchart

The firmware is a single cooperative loop. Nothing blocks for long, so networking, sensing and the user interface all stay responsive.

Assembly Instructions

Build on a breadboard first and only commit to solder once the whole system has run for an hour without a fault.

1. Place the temperature sensor well

   Fit a contact probe on the motor frame near the winding/bearing (well coupled), or aim an IR sensor at the winding area with correct emissivity. Record the offset from this reading to the true internal temperature.

   Add an ambient sensor so the model can separate a hot environment from a motor problem.

2. Wire alerting and protection

   Connect a display, a buzzer, and a protective relay/interface to reduce load or stop the drive — coordinated with the drive's own protection, not fighting it.

3. Set up modelling and reporting

   Configure the normal thermal model/baselines, staged alert thresholds and time-to-trip margins, and Wi-Fi reporting with history logging.

Step-by-Step Implementation Guide

Work through these in order. Each step ends in something you can observe, so a failure is always localised to the step you just finished.

1. Compute rate and project time-to-trip

   Read motor and ambient temperature, compute the smoothed rate of rise, project the time-to-trip, and stage alerts against the projection and the normal model.

   cppthermal-predict.ino Copy Download

   #define T_TRIP 120.0f        // motor limit (deg C) — set to the motor
   #define WARN_MIN 15.0f       // warn if trip projected within 15 min
   #define CRIT_MIN 5.0f
   float prevT=NAN; uint32_t prevMs=0; float rateS=0;
   
   float rateOfRise(float t, uint32_t now){
     if (isnan(prevT)){ prevT=t; prevMs=now; return 0; }
     float dtMin=(now-prevMs)/60000.0f;
     float r = dtMin>0 ? (t-prevT)/dtMin : 0;
     prevT=t; prevMs=now;
     rateS = 0.7f*rateS + 0.3f*r;               // smooth
     return rateS;
   }
   
   const char* stage(float t, float rate){
     if (t >= T_TRIP) return "CRITICAL (at limit)";
     if (rate > 0.1f){                           // only project while rising
       float tToTrip = (T_TRIP - t) / rate;      // minutes
       if (tToTrip < CRIT_MIN) return "CRITICAL (trip imminent)";
       if (tToTrip < WARN_MIN) return "WARNING (trip approaching)";
     }
     if (rate > NORMAL_RATE_MAX) return "WATCH (rising fast)";
     return nullptr;
   }

   rateS = 0.7f*rateS + 0.3f*rThe rate of rise is lightly smoothed so a noisy reading does not produce a wild projection while still tracking a real climb.

   float tToTrip = (T_TRIP - t) / rateProjects how many minutes until the motor reaches its limit at the current rate — the advance-warning number an operator can act on.

   if (tToTrip < WARN_MIN) return "WARNING (trip approaching)"Staged alerts fire on the projection, not just the current temperature, so the warning comes before the motor is dangerously hot.

   if (rate > NORMAL_RATE_MAX) return "WATCH (rising fast)"An abnormally fast rise is flagged even before a trip is projected, catching a developing problem at the earliest sign.

2. Act, log and diagnose

   Sound alerts, take protective action on critical (coordinated with the drive), and log temperature/rate/ambient over time so recurring overheating and its cause become visible.

Complete Source Code

The listing below is complete and compiles as written — there are no elided sections. Read the annotations under each block before you upload it.

/* ═══════════════════════════════════════════════════════════════
   Predictive Motor Temperature — ESP32

   Monitors motor temperature and its RATE OF RISE against a normal
   thermal model, projects time-to-trip, and stages alerts/protection
   BEFORE an overheat trips the line. Logs history for root-cause.
   Complements the motor's own thermal protection.
   ══════════════════════════════════════════════════════════════════ */

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

#define OW_MOTOR 4
#define OW_AMB   5
#define PIN_RELAY 26
#define PIN_BUZZER 13
#define T_TRIP   120.0f
#define WARN_MIN 15.0f
#define CRIT_MIN 5.0f
#define NORMAL_RATE_MAX 3.0f    // deg C/min considered normal warm-up

OneWire owM(OW_MOTOR), owA(OW_AMB);
DallasTemperature motorT(&owM), ambT(&owA);
Preferences prefs;
WiFiClient net; PubSubClient mqtt(net);
float prevT=NAN, rateS=0; uint32_t prevMs=0;

float rateOfRise(float t, uint32_t now){
  if (isnan(prevT)){ prevT=t; prevMs=now; return 0; }
  float dtMin=(now-prevMs)/60000.0f;
  float r = dtMin>0 ? (t-prevT)/dtMin : 0;
  prevT=t; prevMs=now;
  rateS = 0.7f*rateS + 0.3f*r; return rateS;
}

const char* stage(float t, float rate, float &tToTrip){
  tToTrip = -1;
  if (t >= T_TRIP) return "CRITICAL_LIMIT";
  if (rate > 0.1f){
    tToTrip = (T_TRIP - t) / rate;
    if (tToTrip < CRIT_MIN) return "CRITICAL_IMMINENT";
    if (tToTrip < WARN_MIN) return "WARNING";
  }
  if (rate > NORMAL_RATE_MAX) return "WATCH";
  return "OK";
}

void setup(){
  Serial.begin(115200);
  pinMode(PIN_RELAY, OUTPUT); pinMode(PIN_BUZZER, OUTPUT);
  motorT.begin(); ambT.begin();
  WiFi.begin(WIFI_SSID, WIFI_PASS); mqtt.setServer(MQTT_HOST,1883);
}

void loop(){
  if(!mqtt.connected()&&WiFi.status()==WL_CONNECTED) mqtt.connect("mtemp-1");
  mqtt.loop();
  uint32_t now = millis();

  motorT.requestTemperatures(); ambT.requestTemperatures();
  float t   = motorT.getTempCByIndex(0);
  float amb = ambT.getTempCByIndex(0);
  float rate = rateOfRise(t, now);

  float tToTrip; const char *st = stage(t, rate, tToTrip);

  bool critical = (strncmp(st,"CRITICAL",8)==0);
  digitalWrite(PIN_BUZZER, (critical || strcmp(st,"WARNING")==0) ? HIGH:LOW);
  if (critical) {
    digitalWrite(PIN_RELAY, HIGH);            // protective action (coordinated)
    mqtt.publish("motor/1/protect", "reduce/stop");
  } else digitalWrite(PIN_RELAY, LOW);

  char m[200];
  snprintf(m,sizeof m,
    "{\"t\":%.1f,\"amb\":%.1f,\"rate\":%.2f,\"t2trip_min\":%.1f,"
    "\"stage\":\"%s\"}", t, amb, rate, tToTrip, st);
  mqtt.publish("motor/1/thermal", m);          // live + history

  delay(2000);
}

Configuration & Calibration

Configuration steps

• Set T_TRIP to the motor's limit and the warn/critical time margins.
• Set NORMAL_RATE_MAX and the normal thermal model/baseline for the motor at its duty.
• Configure the sensor placement offset and the ambient sensor.
• Configure protective action (coordinated with the drive) and reporting/history logging.

Calibration procedure

An uncalibrated sensor produces confident, precise, wrong numbers. Do this once per physical unit and record the constants.

1. Sensor offset

   Determine the offset from the measured point to the true internal/winding temperature (from the motor's thermal data or a reference), and apply it.

2. Normal thermal curve

   Record the motor's normal warm-up and steady-state at typical loads/ambient to establish the reference the model compares against.

3. Thresholds

   Set the rate and time-to-trip thresholds so warnings arrive with useful lead time without nuisance alarms during normal warm-up.

Network Architecture & Connectivity

Communication protocol

Thermal readings, rate and projected time-to-trip publish continuously; staged alerts and protective actions publish immediately, and history is logged for root-cause.

Message contract between the device and the broker.

Cloud platform configuration

A maintenance/SCADA dashboard trends motor temperature, rate and time-to-trip, raises staged alerts, and keeps thermal history so recurring overheating and its causes are diagnosable.

Dashboard setup

Per-motor temperature and rate-of-rise trends, projected time-to-trip, alert stage, and overheating-episode history with load/ambient context.

Mobile app integration

Staged alerts (watch/warning/critical) with projected time-to-trip.

Security considerations

• Authenticate nodes; coordinate any protective action with the drive's own safety systems.
• Keep the motor's built-in protection as the last line of defence, independent of this monitor.
• Alert on sensor/link silence.

Testing Procedure & Expected Output

Test from the bottom up. Confirm power, then each sensor in isolation, then the integrated loop — the first failing step tells you exactly where to look.

Bench-test checklist. If a row fails, stop and fix it before moving on.

Expected output

The display/dashboard shows motor temperature, rate of rise, projected time-to-trip and the alert stage; history reveals recurring overheating.

{
  "t": 98.4,
  "amb": 34.0,
  "rate": 4.8,
  "t2trip_min": 4.5,
  "stage": "CRITICAL_IMMINENT"
}

At 98 °C rising 4.8 °C/min, the monitor projects the 120 °C limit in ~4.5 minutes and raises a critical alert (and protective action) — warning issued before the motor's own protection would have tripped the line.

Troubleshooting: Common Errors & Fixes

Performance Optimisation

• Sample every second or two — thermal changes are not fast — and smooth the rate for stable projections.
• Model normal behaviour and use ambient context to avoid nuisance alarms.
• Log history for root-cause without flooding the network.
• Keep protective action coordinated with, and secondary to, the drive's own protection.
• Replace every delay() with a millis() comparison — blocking delays are the single most common cause of dropped readings.
• Sample sensors on a fixed cadence and publish on a slower one; you almost never need to transmit at the sampling rate.
• Move networking into its own FreeRTOS task so a slow DNS lookup cannot stall the control loop.
• Use uint8_t / uint16_t where the range allows; on an 8-bit AVR a 32-bit add costs four times as much.
• Batch several samples into one MQTT publish. Radio time, not CPU time, dominates the energy budget.
• Set the MQTT keep-alive to a value that matches your reporting interval so the broker does not churn reconnections.
• For battery builds use deep sleep between samples: an ESP32 drops from ~160 mA awake to about 10 µA asleep, which is the difference between days and months of runtime.

Safety Precautions

• This complements, and does not replace, the motor's built-in thermal protection and proper thermal/electrical design.
• Coordinate any protective action with the drive/starter's own controls; do not create conflicting or unsafe behaviour.
• Sensor placement and coupling bound accuracy — measure the real hot path and apply the correct offset.
• Work on motors safely (lockout/tagout) and keep electronics rated for the heat/vibration environment.
• Mains voltage kills. Anything on the load side of the relay is at 230 V. Do not work on a powered circuit, and never leave exposed mains wiring on a bench where someone could touch it.
• Keep at least 6 mm of creepage between the mains and low-voltage sides of any board you make, and never route mains tracks under the microcontroller.
• Have a qualified electrician do the final installation into a consumer unit or wall fitting. In most jurisdictions this is a legal requirement, not a suggestion.
• Fit an RCD/RCBO upstream and fuse the load appropriately for its rating.
• Wear eye protection when soldering or cutting, and solder in a ventilated space — rosin flux fumes are a respiratory irritant.
• Power the circuit through a bench supply with a current limit while you are testing. A 300 mA limit turns a wiring mistake into a beep instead of a dead board.
• Disconnect power before changing any wiring. Hot-plugging a sensor onto a live bus is the fastest way to lose a controller.

Maintenance

• Re-verify sensor placement/coupling and offset after any remounting.
• Update the normal thermal model after motor/load/cooling changes.
• Act on recurring overheating (clean cooling, resize load, investigate faults).
• Test the alert stages and protective action periodically.
• Re-check every screw terminal and header after the first week — thermal cycling loosens connections that felt tight on day one.
• Keep the broker and dashboard containers patched, and rotate device credentials at least once a year.
• Recalibrate at the interval given in the calibration section, and keep the constants in a text file next to the firmware — not only in flash.
• Keep a short logbook of firmware versions and what changed. Six months later you will not remember why that constant is 1.083.

Future Improvements & Upgrades

A working v1 is a platform, not a finish line. These are the upgrades that add the most capability for the least rework.

• Add motor current alongside temperature for a fuller thermal/electrical picture.
• Fit a proper thermal model (winding time-constant) for more accurate projection.
• Correlate with vibration for combined predictive maintenance.
• Integrate protective action with the VFD for graceful load reduction.
• Design a proper PCB. Once the breadboard version has run for a month, moving to a two-layer board removes the intermittent-contact failures that dominate prototype faults.
• Add over-the-air firmware updates so you never have to physically reach a deployed node again.
• Add persistent local storage (microSD or the on-chip flash) so a network outage does not create a hole in your data.
• Move configuration out of the source: a captive-portal setup page or a JSON config file makes the build reusable without a recompile.
• Add a battery and solar option so the unit survives a power cut and can be sited away from a socket.
• Write a small test harness that feeds synthetic sensor values through the decision logic, so you can validate thresholds without physically triggering the event.

Frequently Asked Questions

References & Learning Resources

These are the primary sources worth reading in full. Manufacturer datasheets always outrank forum posts when the two disagree.

1. Electric motor thermal protectionReference
2. Thermal time constant and heating curvesReference
3. Insulation classes and motor temperature limitsReference
4. MLX90614 non-contact IR thermometer (datasheet)Melexis
5. Predictive maintenance / condition monitoringReference