Industrial monitoring with ESP32: where to use it and where not to

Knowing whether a machine is running, the temperature of a store or how many seconds a cycle takes does not always require a major automation investment. When designed within the right boundaries, an ESP32-based data acquisition unit can make a small monitoring project cost-effective. The real engineering question is not getting the board onto the internet; it is the reliability of the measurement, the behaviour when the connection drops and how it is separated from the production system.

01First, separate monitoring from control

A monitoring system records the current state, whereas a control system manages the machine's motion and process. A delay of a few seconds in a temperature measurement may affect a report. By contrast, a delay in stopping an axis can create a physical hazard. The two tasks therefore cannot be substituted for one another simply because the hardware costs the same.

An ESP32 can be considered for tasks such as environmental measurement, reading data from an energy analyser, independent part counting and condition logging for maintenance purposes. Safety functions, deterministic motion control and functions that keep the process within safe limits should remain within an appropriate industrial control architecture. Equally, a standard PLC is not a safety PLC on its own; the safety function is designed separately.

02Do not connect field signals directly to a GPIO

The inputs of a development board do not have the same electrical robustness as an industrial input module. A 24 V status signal from a machine requires appropriate level shifting, input protection and, if necessary, galvanic isolation. In analogue measurement, looking only at ADC resolution is not enough: reference stability, sensor accuracy, cable effects and calibration also determine the total error.

If a 4–20 mA or 0–10 V signal is to be acquired, a suitable analogue front end is selected. Cable length, common-mode voltage and the earthing relationship between devices are assessed. Reading the RS-485 output of an off-the-shelf industrial sensor may be more manageable than building a precision analogue measurement circuit from scratch. The choice should be based on the quantity to be measured and the capabilities of the maintenance team.

03Data contract: a number on its own is not enough

For every record, the device ID, measurement time, engineering unit and data quality should be stored. A “Temperature 28.4” message is misleading if it is not known that the measurement was taken five minutes ago. A sensor disconnection, unreliable time information and an out-of-range value can each be flagged with a separate quality status.

{
  "device": "izleme-01",
  "sequence": 1842,
  "temperature_c": 28.4,
  "quality": "good",
  "timestamp": "2026-10-27T09:30:00Z"
}

This schema is for illustrative purposes. In a real project, the time source, the sequence-number behaviour after a restart and how missing data will be displayed are defined together. The time at which the server receives a message must not be assumed to be the same as the sensor's measurement time.

04Design for connection loss as a normal condition

A Wi-Fi connection can drop because of congested channels, a metal enclosure, antenna placement or an access point change. Software waiting indefinitely for a connection must not halt the measurement task as well. Measurement and communication tasks should be separated, and reconnection attempts should be made at controlled intervals.

Using MQTT does not solve data loss on its own. QoS selection, the client's persistent session, broker behaviour and the buffer on the device are addressed together. Duplicate messages can be filtered out using the device ID and sequence number. Rather than writing every sample to flash memory, a buffering and batch-logging strategy that takes write endurance into account is chosen.

05How do we size a pilot implementation?

As an example, suppose we take one temperature record per minute from five cold stores. That produces 5 × 1,440 = 7,200 records per day. Assuming 100 bytes of raw data per record gives approximately 720 kB/day; protocol, index and database overheads are not included. This calculation turns the idea of “very little data” into a concrete storage and outage budget.

06Do not test only normal operation during acceptance testing

Disconnecting the sensor, switching off the access point, making the server unreachable and cutting and restoring power in a controlled way are all part of the test scenarios. It is checked that, when the device recovers, it does not produce incorrect counter values, empties the buffer in the correct order and does not present old data as if it were new.

For power supply and antenna placement, the manufacturer's design guidelines for the ESP32 variant in use should be followed. The industrial enclosure, connectors and ambient conditions are assessed separately from the development board. Ultimately, a successful pilot is not just a graph appearing on screen; it is the same measurement being obtained repeatedly in a way that is maintainable and whose errors can be understood.

07Example verification scenario

Suppose a one-hour network outage scenario is defined for pilot acceptance. The device must keep measuring throughout the outage, send the records with their original measurement times once it reconnects, and must not count the same record twice in the total. A power cut is then tested to verify which part of the buffer is persistent. The final report states the number of lost records, the recovery time and the clock drift separately. A graph being drawn without gaps is not sufficient evidence on its own; server-side interpolation can hide data loss.

AuthorInfinitium TeknolojiEngineering content team