ESP32-S3 Modbus Cloud Data Logger with Weeks of Local Buffer
An ESP32-S3-based Modbus data logger that uploads to the cloud and can buffer several weeks of data locally during outages.
Intermediate Project
— This is more than a simple sensor project because it combines RS-485 Modbus timing, WiFi/cloud retries, local file buffering, and power-loss-safe logging, all of which need careful firmware structure and validation.
Assumptions:
- Modbus is over RS-485 (most common for industrial devices).
- The prototype will use a microSD card for local buffering rather than onboard flash, because weeks of logs can exceed internal storage quickly.
- Cloud streaming means periodic upload over WiFi, not cellular.
- The ESP32-S3 will be used as a dev board/prototype platform, not a custom RF design.
- Data rate is modest enough that microSD write speed and wear are manageable with batching.
Bill of Materials
Compatibility Notes
- ESP32-S3 GPIOs are 3.3 V, so the ESP32-S3-DevKitC-1-N32R16V transceiver and microSD breakout must be 3.3 V logic compatible or level shifted.
- The SN65HVD1782 and microSD breakout both fit well with the ESP32-S3's 3.3 V I/O, but the ESP32-S3-DevKitC-1-N32R16V side still needs proper bus termination and biasing on the cable.
- Weeks of buffering means microSD is the right storage choice; internal flash on the ESP32-S3 is not a good fit for sustained log retention.
- If the dev board is powered from USB, make sure the 5 V source can handle WiFi current spikes; 2 A gives comfortable margin.
- For cloud streaming, WiFi and SD writes can overlap in firmware, so use batching and a queue to avoid blocking Modbus polling.
You'll Also Need
- RS-485 connector or terminal block for the Modbus bus.
- 120 ohm termination resistor and bias resistors if the bus does not already provide them.
- microSD card itself, preferably industrial or high-endurance if logs are frequent.
- USB cable and a stable 5 V power adapter.
- Prototype wiring, headers, and possibly a small perfboard or carrier PCB.
- ESD/TVS protection for the RS-485 lines if the cable leaves the bench.
- Enclosure and strain relief if this will be used near real field wiring.
Estimated BOM Cost: $40-45 (based on live distributor pricing)
Design Considerations
Buffering Strategy
For a few weeks of outage tolerance, write logs to microSD in time-stamped records rather than trying to keep everything in RAM. Even a modest 1 kB record every 10 seconds is about 8.6 MB/day, so a 4 GB card gives huge margin, but wear and file fragmentation still matter. Batch writes in 4 kB or larger chunks and flush periodically to reduce card wear and improve throughput.
Modbus Robustness
Modbus RTU over ESP32-S3-DevKitC-1-N32R16V is sensitive to wiring quality, termination, and bus timing. Use a single master polling loop with explicit timeouts and retry counters, and treat CRC errors or missing replies as normal field conditions rather than fatal faults. If the bus is long or noisy, add termination only at the ends and verify biasing so the line does not float during idle periods.
Cloud Retry Architecture
Do not couple cloud upload directly to the Modbus polling task. Use a producer-consumer model: one task samples and stores records, another task uploads queued records when WiFi is available. This prevents cloud outages from causing missed Modbus polls and makes it easy to resume uploads from the oldest buffered record.
Power and Brownout Handling
ESP32 WiFi current spikes can cause brownouts if the 5 V source or USB cable is weak. Budget for short peaks well above the average current and enable brownout detection plus watchdog recovery so the logger reboots cleanly instead of corrupting the queue. If you later move off USB, choose a supply with enough transient headroom for WiFi bursts and SD card writes.
Storage Reliability
microSD cards are convenient but not all cards are equal for continuous logging. For a field logger, prefer a high-endurance card and keep the filesystem simple, with periodic file rotation and integrity markers so a power loss does not destroy the whole log. Test power-cut recovery by yanking power during writes and verifying the logger can resume without manual repair.
Firmware Architecture
Use a state machine with separate states for polling, buffering, WiFi connect, upload, and recovery. Add a watchdog and a monotonic sequence number in each record so you can detect gaps after resets. If cloud connectivity is intermittent, make uploads idempotent so retransmitting buffered records does not create duplicates in the backend.
Want to customize this project or build something different?
Try the Project Advisor
