After completing the hardware architecture of the single-socket IoT energy meter, the next critical stage was implementing reliable energy calculation and data handling on the ESP32.
Unlike simple voltage or current monitoring, a kWh system must continuously compute power and accumulate energy over time. This requires careful handling of sampling intervals, communication reliability, and data persistence.
![]()
Reading Electrical Parameters
The system uses the PZEM-004T module to obtain:
- Voltage (V)
- Current (A)
- Active Power (W)
- Energy (kWh)
- Frequency (Hz)
Communication between ESP32 and PZEM is handled via UART.
![]()
A periodic polling method is implemented to read data every defined interval (typically 1–2 seconds).
To avoid unstable readings:
- Invalid responses are filtered
- Communication timeout is monitored
- Re-read attempts are implemented if data is corrupted
This ensures stable long-term monitoring.
Energy Accumulation Strategy
Although the PZEM module provides accumulated energy internally, I implemented additional logic on the ESP32 for:
- Energy reset functionality
- Session-based energy tracking
- Cost calculation (based on Rp/kWh tariff)
Energy cost is calculated using:
Cost = Energy (kWh) × Tariff (Rp/kWh)
![]()
The tariff value can be configured remotely depending on the electricity pricing scheme.
WiFi Connectivity Handling
Because the device operates in real environments, WiFi stability cannot be assumed.
The firmware includes:
- Auto-reconnect routine
- Offline detection (fallback to local LCD monitoring)
- Timeout-based retry logic
If WiFi is unavailable for a defined period, the system continues measuring locally and resumes cloud synchronization once the connection is restored.
Data Logging Architecture
![]()
All measurement data is transmitted to Firebase Realtime Database using HTTPS-based secure communication.
The structured data tree includes:
- voltage
- current
- power
- energy
- cost
- alert
- timestamp
Each measurement cycle updates the corresponding fields in the database. Separating measurement logic from communication logic ensures modular firmware design.
This architecture allows:
- Real-time remote monitoring
- Historical data visualization
- Cloud-based alert evaluation
- Scalability for multiple devices
By isolating the Firebase client functions from core measurement routines, the firmware remains adaptable for future platform expansion without modifying the energy calculation engine.
Relay Control Logic (Threshold-Based Warning System)
Instead, a threshold-based warning mechanism is implemented.
When:
Energy ≥ Configured Limit
![]()
The system will:
· Set an alert flag in Firebase
· Display warning information on the LCD
· Trigger remote notification via the cloud layer
The load remains active unless manually switched OFF.
This design choice improves safety and avoids unintended service interruption while still providing preventive energy monitoring.
Design Lessons
Accurate kWh monitoring is not only about measuring voltage and current. It requires:
- Stable communication
- Robust error handling
- Persistent data logic
- Proper integration between measurement and cloud layer
This firmware architecture became the backbone for the multi-socket and advanced IoT versions developed afterward.
#Embedded# #ESP32# #iot# #internet of things# #firebase# #kwh meter#
Electronic Community 
