The "Black Box" Problem and Sovereign Data Constraints
In the industrial IoT and energy management landscape, the transition from proprietary hardware to custom-built solutions is often born out of necessity rather than choice. Our project initially relied on Fluxbox - a high-end, Linux-based controller designed for energy monitoring. While Fluxbox was capable of bridging Modbus data from Deye inverters and Schneider electric meters, it represented a significant "Black Box" bottleneck.
The primary issue was twofold: cost and compliance. Fluxbox is an expensive, closed-source ecosystem managed by an Estonian provider. For critical infrastructure projects in Ukraine, this created a legal impasse. National regulations demand that sensitive energy data and the servers hosting it must reside within domestic borders. Furthermore, the Fluxbox ecosystem lacked robust support for the IEC 60870-5-104 (IEC-104) protocol - the "lingua franca" of national grid operators. To ensure scalability and legal compliance, we had to move away from this expensive European middleware and build our own domestic stack from the ground up.
Hardware Realities: The Pitfalls of SMT Manufacturing and Human Error
The hardware pivot led us to the "Revention" controller, built on the ESP32 (WROOM-32) module integrated with Wiznet Ethernet chips. However, the hardware phase introduced its own set of "firefighting" challenges. Although designed locally, the PCB Manufacturing and SMT (Surface Mount Technology) assembly remained in Estonia.
This geographical disconnect led to a high defect rate. We encountered numerous instances where components of incorrect values were mounted, such as resistors or capacitors that deviated from the original schematic, or cold joints that compromised signal integrity on the Modbus bus. Our embedded engineer, Mykola, had to spend weeks manually reworking these boards, re-soldering components to ensure the devices could even boot. This experience highlighted a critical lesson: even the best firmware cannot compensate for unstable hardware. The move to ESP32 was a strategic cost-saving measure, but it required an uncompromising focus on SMT quality control to ensure industrial-grade reliability.
The V1 Legacy: Why 5000 Lines of Arduino "Spaghetti" Kills Scalability
The first iteration of our custom firmware (V1) was a textbook case of technical debt. It was written using the Arduino framework - a tool excellent for rapid prototyping but fundamentally flawed for complex, multi-device energy management. The resulting code was a 5,000-line monolith, a single file where polling logic, protocol handling, and network configurations were tightly coupled.
The catastrophic flaw of V1 was its lack of scalability. Network parameters, specifically static IP addresses, were hardcoded into the source. In a real-world deployment where a client might have dozens of Deye inverters spread across multiple facilities, this "brittle" code was unmanageable. Changing a single IP or adding a new Modbus slave ID required a physical visit to the site, a laptop, and a full re-flash of the controller via a wired connection. Furthermore, the monolithic structure used blocking "delay" functions and synchronous loops. If the controller had to poll 10 inverters instead of two, the entire system would hang or experience massive jitter, leading to the second major failure: the IEC-104 implementation.
The "hand-rolled" IEC-104 stack in V1 was non-compliant. It failed to handle standard ASDU (Application Service Data Unit) types and spontaneous connection resets from the grid side. It was a "toy" protocol implementation that couldn't survive the rigorous handshaking required by professional SCADA systems.
Comparative Architecture Table
| Feature | Fluxbox (Legacy Linux) | Revention V1 (Arduino) | Revention V2 (ESP-IDF) |
|---|---|---|---|
| Compute Engine | Linux PC-grade | ESP32 (Monolith) | ESP32 (RTOS-based) |
| Logic Location | Edge (Local Rules) | Edge (Hardcoded) | Cloud (Wezom Engine) |
| Scalability | High (but expensive) | Zero (Hardcoded IPs) | High (Dynamic Config) |
| Manufacturing | Proprietary | SMT (High Defect Rate) | SMT (Validated Rework) |
| Protocol Stack | Modbus / Cloud-only | Broken IEC-104 | Standard IEC-104 + MQTT |
| Update Method | Remote Portal | Physical Wired Connection | Secure OTA (Over-The-Air) |
The V2 Pivot: Event-Driven Design and Protocol Isolation
With Version 2, we moved to the ESP-IDF (the native Espressif IoT Development Framework) to leverage FreeRTOS for true multi-tasking. The core philosophy shifted from a "Smart Edge" to an "Event-Driven Reporter."
In V2, the ESP32 no longer tries to "think" about tariffs or load-balancing logic. Instead, it acts as a lean bridge. We implemented a delta-based polling system: the controller continuously scans Modbus registers for Deye inverters and Schneider meters. If a value, such as battery voltage or grid frequency, remains stable - nothing is sent. However, the moment a significant delta (change) is detected, an "Event" is generated.
This approach allowed us to split the data streams into two isolated paths:
- MQTT for Wezom Cloud: All operational data and telemetry are wrapped in JSON and sent via MQTT to our local Ukrainian servers. This powers the user-facing dashboard, statistics, and the complex "Rule Engine" (e.g., switching to battery power during high-tariff day zones).
- Strict IEC-104 for the Grid: A dedicated, non-blocking task handles the IEC 60870-5-104 connection. This path is reserved strictly for grid operator requirements, ensuring that utility commands (like power curtailment) are handled with sub-millisecond precision without being delayed by cloud telemetry.
Finally, we integrated a robust Bootloader and OTA (Over-The-Air) mechanism. This allows us to push bug fixes and update the Modbus register maps remotely, turning the hardware into a dynamic, evolvable asset.
Hard Lessons in Engineering Rigor
Transitioning from a $500 Linux box to a $5 ESP32 is not just a matter of swapping chips; it's a total reimagining of the software architecture. The failure of V1 proved that technical debt is far more expensive than any hardware. By decoupling the logic into a cloud-based Event-Driven model and standardizing our protocols (MQTT and IEC-104), we transformed a "school-level" prototype into a professional industrial controller capable of managing national-scale energy assets.
