Our Approach
We evaluated several wireless protocols before settling on ESP32 as the core MCU. Why? Because the ESP32 gives us dual-core processing, built-in WiFi and BLE, and enough GPIOs to handle multiple sensor inputs without external multiplexing. For a project like this, it hits the sweet spot between capability and cost.
Our team designed a custom PCB around the ESP32-WROOM-32 module. The board includes:
- ADS1115 16-bit ADC for analog sensor inputs
- MPU6050 accelerometer for vibration monitoring
- DS18B20 temperature sensors (one per machine zone)
- ACS712 current sensors on the power lines
- A simple voltage divider for 0-10V industrial sensor compatibility
The PCB layout was done in KiCad, with careful attention to isolation between the high-current sensing traces and the digital logic. We learned the hard way on earlier projects that industrial environments are noisy — a poorly laid out ground plane can kill your ADC accuracy.
Firmware Development
We built the firmware on the Arduino framework running on FreeRTOS. The ESP32's dual cores let us dedicate one core to sensor polling and the other to network communication.
Here's the rough architecture:
Core 0: Polls all sensors every 100ms. Temperature readings go through a moving average filter. Vibration data gets FFT analysis for bearing wear detection. Current readings trigger immediate alerts if they exceed configurable thresholds.
Core 1: Manages MQTT connection to the cloud broker. Publishes aggregated data every 5 seconds during normal operation, switches to real-time streaming when anomalies are detected.
The MQTT payload is JSON, around 2KB per message. With 40 devices publishing every 5 seconds, that's about 64 Kbps of uplink — well within WiFi capacity even in a noisy factory environment.
We also added a local fallback mode. If the WiFi drops, the ESP32 stores data in its RTC memory and SPIFFS partition, then syncs when connectivity returns. This was non-negotiable for the client — they couldn't afford data gaps.
Hardware Challenges
The first prototype had issues. The ACS712 current sensors drifted with temperature changes on the factory floor. We switched to the ACS723, which has better thermal stability, and added a software calibration routine that runs during machine idle periods.
Another problem: the DS18B20 sensors use OneWire protocol, which is notoriously timing-sensitive. Long cable runs in the factory caused signal reflections. We added a 4.7kΩ pull-up resistor and twisted-pair cabling, which solved it.
The PCB went through three revisions before we were satisfied. Each revision cost about $150 for a small batch from JLCPCB. Cheap compared to the cost of a field failure.
Cloud Infrastructure
On the backend, we set up an AWS IoT Core instance with MQTT broker. Data flows into a DynamoDB table for time-series storage. A Lambda function processes alerts and sends notifications via SMS and email.
The client's maintenance team gets a Grafana dashboard showing real-time metrics for each machine. They can set custom alert thresholds per device — for example, trigger an alert if a motor's temperature rises more than 10°C in 30 seconds, which indicates a cooling fan failure.
We also built a simple mobile view using React Native. It's not fancy, but it shows the three most critical metrics per machine and lets technicians acknowledge alerts from the floor.
Results
After a 3-week deployment and testing phase, the system went live across 42 machines. Here's what the client reported after 6 months:
- Unplanned downtime reduced by 37% — they caught bearing failures before they seized up
- Maintenance costs down 22% — no more blanket replacement schedules
- Energy consumption dropped 8% — they identified two compressors running inefficiently and replaced them
The total bill of materials per monitoring node was about $35 in quantity. The client's ROI calculation showed payback in under 4 months.
What We Learned
Industrial IoT product development company is different from consumer IoT. The environment is harsh, the stakes are higher, and the maintenance team doesn't want another app to manage. Keep it simple.
We also learned to over-spec the power supply. Our first design used a 5V wall adapter. In a factory with welding equipment and large motors starting up, the line voltage sagged enough to brown out the ESP32. We switched to a Mean Well industrial PSU with a wide input range. Problem solved.
Why Work With an IoT Product Development Company
This project might look straightforward on paper — ESP32, some sensors, MQTT to the cloud. But the devil is in the details. The PCB layout, the firmware architecture, the edge-case handling — these are things you learn from doing it wrong a few times.
If you're considering building something similar, you can
hire embedded developer talent in-house. But expect a learning curve. Our team has shipped over a dozen industrial IoT projects in the last three years. We know the common failure modes and how to avoid them.
The client in this case study came to us because they tried building it themselves first. Six months and two dead prototypes later, they called us. We had a working system in their hands in 10 weeks — including PCB design, firmware, cloud infrastructure, and a full prototype shipment for testing.
Next Steps
We're now working on a second phase for this client: adding over-the-air firmware updates using ESP32's OTA capability, and integrating with their existing SCADA system via Modbus TCP.
If you're facing similar challenges — equipment monitoring, predictive maintenance, or any industrial IoT application — we'd be happy to talk through your requirements. We build things that work in the real world, not just on a lab bench.
Need Something Similar?
If you’re looking to build a real industrial monitoring system — not a prototype, not a proof of concept, but something that runs 24/7 in a dusty factory —
hire IoT developers who have done it before. We handle the full stack: firmware, PCB, enclosure design, cloud integration, and deployment.
Discussion (0 comments)