Glennergy
A connected energy platform combining a Linux-based server system with an ESP32-S3 embedded client for energy data, recommendations, local environmental measurements and touchscreen interaction.
Overview
Glennergy is a connected system developed to explore smarter energy use in properties. A Linux-based server collects electricity spot-price and weather data, processes it through several cooperating services and exposes recommendation, weather and price information through an HTTP interface.
An ESP32-S3 client retrieves this data, combines it with local BME280 environmental measurements and presents the result through a touchscreen interface.
Problem & purpose
The project explores how connected embedded devices and server-side energy data can support more informed decisions about when energy is inexpensive or expensive.
The current recommendation logic derives a normalized score and a buy / hold / sell category from electricity-price statistics, while weather forecasts and local environmental measurements provide additional context in the wider platform.
System architecture
Glennergy consists of two connected subsystems. The Linux server runs several cooperating processes responsible for external data acquisition, caching, recommendation processing and HTTP delivery. Communication between server processes uses mechanisms including Unix sockets, FIFOs, shared memory and synchronization primitives.
The ESP32-S3 firmware runs multiple FreeRTOS tasks for sensor acquisition, connectivity, server communication, diagnostics and UI-related data flow.
Subsystems
Linux / server
A Linux-based multi-process system handles property configuration, electricity-price and weather acquisition, shared input caching, recommendation calculations and HTTP responses.
The current recommendation pipeline calculates a normalized price score together with a buy / hold / sell category and exposes recommendation, weather and price datasets to the embedded client. The current server version is deployed and running on a VPS.
ESP32-S3 client
The ESP32-S3 firmware is written in C and C++ using ESP-IDF and FreeRTOS.
It handles BME280 environmental measurements, Wi-Fi connectivity, HTTP communication with Glennergy, offline data caching, persistent configuration, time synchronization, UART diagnostics and a touchscreen interface with Home, Electricity, Weather, WiFi and Settings views.
My personal contributions
Listed separately from team-wide functionality.
- BME280 sensor HAL and embedded integration
- Shared I2C bus integration and troubleshooting alongside the touchscreen subsystem
- Sensor initialization, acquisition, validation, failure handling and automatic recovery
- UART-based diagnostic and configuration shell
- Event-driven Wi-Fi state and reconnect handling
- Persistent configuration using ESP-IDF NVS
- SNTP-based wall-clock synchronization and timestamp integration
- FreeRTOS task and queue integration, particularly around sensor and diagnostic functionality
- Settings functionality for persistent sensor and server update intervals
- Technical documentation, architecture diagrams and development documentation
- Design and evolution of an AI-assisted Doxygen documentation workflow using GitHub Actions and the OpenAI API
- Documentation workflow auditing, validation and automated draft pull-request generation
- Project planning and workflow documentation
- Project presentation together with the other core developer
Sensor HAL
I developed and iterated on the BME280 integration behind a dedicated sensor HAL. The HAL encapsulates I2C configuration, device initialization and temperature, humidity and pressure acquisition while keeping application-level sensor processing separate from hardware communication.
The final implementation also handles practical failure scenarios: failed reads are tracked, I2C diagnostics can be performed after communication problems, the sensor can be marked unavailable after repeated failures, and the firmware later attempts to reinitialize it. The BME280 shares an I2C bus with the touchscreen hardware, which made bus integration and troubleshooting an important part of the work.
Some photographs in this case study have been lightly edited for readability, including reduced reflections and adjustments to exposure and sharpness. The hardware and interface content remain unchanged.
UART diagnostics
I developed a UART-based diagnostic and configuration interface using ESP-IDF's UART functionality. The shell provides runtime views of system state, sensor readings and timestamps, recommendation data, heap and task diagnostics, and current configuration.
It also supports validated configuration commands for selected runtime settings, with changes persisted through NVS. This provided a practical way to inspect and troubleshoot the device without relying on the touchscreen UI.
Wi-Fi, NVS & time
Wi-Fi handling is event-driven and distinguishes between access-point association and obtaining a usable IP connection. Connection loss schedules bounded reconnect attempts rather than blocking the event callback, while the Wi-Fi worker performs the actual reconnect operations.
Configuration is persisted using ESP-IDF NVS, including Wi-Fi credentials and runtime update intervals. The Settings UI can change sensor and server-fetch intervals and persist them without rebuilding the firmware.
After network connectivity is established, SNTP is used to synchronize wall-clock time. Monotonic time remains useful internally for elapsed-time calculations while synchronized local time can be shown to the user.
Server communication & resilience
The ESP32 client periodically retrieves recommendation, weather and electricity-price datasets from the Glennergy server. A dedicated FreeRTOS worker tracks server health separately from normal data fetching and classifies connectivity as connected, degraded or unavailable depending on the results.
Latest-value FreeRTOS queues distribute datasets to the UI, while SPIFFS caching allows previously received information to remain available during Wi-Fi outages. The current implementation also includes separate health-check and retry scheduling instead of tying server availability directly to a single fetch attempt.
The system running on hardware
Screens from the physical ESP32-S3 device.
Documentation automation
I designed and iterated on an AI-assisted documentation workflow built around Doxygen, GitHub Actions and the OpenAI API. Project-specific rules define how public headers, implementation files, FreeRTOS tasks, callbacks and hardware-related code should be documented while explicitly protecting program logic from automated modification.
The workflow can process changed files automatically, perform deeper semantic audits with additional source context, retry rejected documentation updates, record validation results and create draft pull requests for human review. The system evolved through repeated testing to reduce unnecessary documentation churn while catching inaccurate or incomplete technical descriptions.
Technical challenges
Several parts of Glennergy required debugging problems that only became visible once independently developed subsystems were integrated. Examples included sharing an I2C bus between the touchscreen stack and the BME280 sensor, recovering cleanly from sensor communication failures, coordinating asynchronous Wi-Fi events with FreeRTOS task logic, maintaining useful system state across network outages, and keeping the evolving HTTP producer and consumer implementations compatible.
These problems pushed the project beyond isolated module development and required reasoning about subsystem boundaries, timing, failure states and data ownership across both embedded and Linux environments.
Results & lessons learned
The current system runs end to end: the Linux server stack is deployed on a VPS, while the ESP32-S3 client runs on the physical touchscreen hardware and communicates with the server to display recommendations, electricity prices and weather information alongside local BME280 measurements.
The project has given me practical experience working across hardware abstraction, FreeRTOS task coordination, networking, persistent configuration, Linux services, IPC, diagnostics and deployment. One of the biggest lessons has been that making individual modules work is only part of embedded development—the harder problems often appear at the boundaries between hardware, tasks, communication layers and external systems.
- Linux server deployed on VPS
- ESP32-S3 running on physical hardware
- End-to-end server communication
Glennergy on GitHub
The public Glennergy-ESP repository contains the firmware source, README, an illustrated visual user guide and more detailed technical documentation for anyone who wants to explore the project further.