How much does it cost to develop an ESP32 Temperature Monitoring Device?
Project Context & System Requirements
The client required a low-power ESP32 Temperature Monitoring solution capable of handling inputs from three temperature sensors and one voltage source. The device needed to operate on battery power for approximately one month, alert users via email when thresholds were breached, and allow for easy configuration via USB and a rotary encoder. Below, we present how we helped the client build the device, the technical choices we made, and the overall project cost.
Current Key Pain Points Identified
To address these challenges, WizzDev proposed a custom-designed, battery-efficient ESP32 Temperature Monitoring solution, integrating precise sensor management, threshold-based alerts, and robust connectivity — all tailored for real-world reliability and long-term use.
Hardware Stack
Firmware Stack
Solution Overview
WizzDev proposed a modular ESP32 Temperature Monitoring system, integrating power-efficient components and developing custom firmware drivers for sensors, email notifications, and display. Emphasis was placed on minimizing power usage through thoughtful hardware selection and software optimization. The MVP featured configuration capability, alert handling, and intuitive display navigation using a rotary encoder.
Architecture Overview
The architecture includes modules for sensor interfacing, alert control, WiFi/email stack, display UI, and power management.
Sensors – Measure temperature and voltage using PT1000 sensors. Connected via UART or I2C for real-time monitoring.
Control – Rotary encoder for navigating device menus and adjusting parameters. Enables simple, tool-free configuration.
ESP32 MCU – Runs FreeRTOS to manage sensor data, user input, display updates, and alert logic. Optimized for low power use.
Display – LCD12864 provides visual feedback, including readings, system status, and configuration menus. Connected via UART or I2C.
Email Alerts – ESP32 sends threshold-based alerts via SMTP to notify users instantly when critical values are breached.
User – Receives system alerts via email when sensor thresholds are exceeded.
Project Duration Estimate
| Stage | Description | Min h | Max h |
|---|---|---|---|
|
Component selection |
Component selection involved verifying and choosing the ESP32, an ultra-low-power co-processor, battery, USB port, sensor circuit elements, battery charger, and supporting components to ensure optimal performance and energy efficiency. |
19 |
26 |
|
Drawing of the device schematic |
Prepared the complete schematic for the prototype, including sensor, charger, voltage measurement, and buzzer circuits, ensuring proper integration of all components. |
11 |
14 |
|
Connecting the components |
Assembled the prototype on a universal board based on the schematic, followed by testing, documentation, and a final report. |
12 |
21 |
|
Consultations and meetings |
Time for meetings and consultations with the electronics engineer. |
2 |
4 |
|
Summary time for PCB: |
|
44 |
65 |
| Stage | Description | Min h | Max h |
|---|---|---|---|
|
Initial setup |
Set up the development environment, Git repository, JIRA, Docker build, and Jenkins pipeline. Defined and documented project requirements for client approval, with deliverables including the initialized codebase and acceptance criteria. |
40 |
48 |
|
WiFi Controller |
Developed a WiFi Controller and email interface for connectivity and future alert integration, along with a console tool for variable management and user input. Deliverables included an updated codebase and demo. |
40 |
48 |
|
Display Controller |
Implemented a display driver and user interface class for managing the device menu, including screen layouts and communication with the display controller. Deliverables included an updated codebase and demo. |
64 |
72 |
|
Temperature Sensor Handler |
Developed a temperature sensor driver using either ADC or I2C, depending on the selected component, to enable accurate temperature data acquisition. Deliverables included an updated codebase and demo. |
16 |
24 |
|
Battery monitor handler |
Implemented a battery monitoring class using either ADC or a dedicated IC, depending on the chosen solution, to track battery status in real time. Deliverables included an updated codebase and demo. |
32 |
40 |
|
Rotary encoder handler |
Developed a driver for the rotary encoder to enable intuitive navigation through the device’s user interface. Deliverables included an updated codebase and demo. |
16 |
24 |
|
Business logic implementation |
Implemented core business logic including alarm triggers, low battery alerts, hold/pause mode, watchdog support, and parameter configuration. All settings are stored in non-volatile memory to ensure persistence. |
64 |
80 |
|
Summary time for Firmware: |
|
272 |
336 |
| Summary | Description | Min h | Max h |
|---|---|---|---|
|
Total project time: |
|
316 |
401 |
|
PM |
Project Management
|
32 |
40 |
|
Total project time |
|
348 |
441 |
Risk Assessment
| Risk | Description | Min h | Max h |
|---|---|---|---|
|
No ready-made modules |
Custom circuits may be required due to lack of prebuilt modules. |
0 |
8 |
|
Prototype issues |
Prototype may fail or need rework, causing delays. |
0 |
16 |
|
Risk of requirement misinterpretation |
Requirements may be misunderstood without clarification. |
0 |
16 |
|
WiFi/SMTP integration |
Unexpected issues with connectivity or email features. |
0 |
24 |
|
Display driver issues |
Driver integration depends on available ESP32 support. |
0 |
32 |
|
Sensor readout issues |
ADC or I2C communication might be unstable. |
0 |
16 |
|
Battery IC comms |
Issues with battery monitoring IC may require fallback approach. |
0 |
24 |
|
Encoder readout issues |
Signal handling from encoder may require filtering or tuning. |
0 |
24 |
|
Unclear error behavior |
Edge-case handling and watchdog logic may need refinement. |
0 |
32 |
|
Total risk estimates |
|
0 |
160 |
