Glennergy
En uppkopplad energiplattform som kombinerar ett Linux-baserat serversystem med en ESP32-S3-klient för energidata, rekommendationer, lokala miljömätningar och interaktion via touchscreen.
Översikt
Glennergy är ett uppkopplat system utvecklat för att utforska smartare energianvändning i fastigheter. En Linux-baserad server samlar in spotpris- och väderdata, behandlar informationen genom flera samverkande tjänster och exponerar rekommendationer, väder och priser via ett HTTP-gränssnitt.
En ESP32-S3-klient hämtar den här informationen, kombinerar den med lokala miljömätningar från en BME280 och presenterar resultatet via ett touchscreen-gränssnitt.
Problem & syfte
Projektet utforskar hur uppkopplade inbyggda enheter och energidata på serversidan kan hjälpa fastigheter att fatta mer informerade beslut om när energi är billig eller dyr.
Den nuvarande rekommendationslogiken beräknar ett normaliserat värde och en kategori för köp / avvakta / sälj utifrån elprisstatistik, medan väderprognoser och lokala miljömätningar ger ytterligare sammanhang i den större plattformen.
Systemarkitektur
Glennergy består av två sammankopplade delsystem. Linux-servern kör flera samverkande processer med ansvar för extern datainsamling, cache, rekommendationsberäkning och HTTP-leverans. Kommunikationen mellan serverprocesserna använder bland annat Unix-sockets, FIFO, delat minne och synkroniseringsprimitiver.
ESP32-S3-firmwaren använder flera FreeRTOS-tasks för sensormätning, uppkoppling, serverkommunikation, diagnostik och dataflöde till användargränssnittet.
Delsystem
Linux / server
Ett Linux-baserat system med flera processer hanterar fastighetskonfiguration, hämtning av elpris- och väderdata, gemensam cache för indata, rekommendationsberäkningar och HTTP-svar.
Den nuvarande rekommendationskedjan beräknar ett normaliserat prisvärde tillsammans med en kategori för köp / avvakta / sälj och gör rekommendations-, väder- och prisdata tillgängliga för den inbyggda klienten. Den aktuella serverversionen är driftsatt och körs på en VPS.
ESP32-S3-klient
ESP32-S3-firmwaren är skriven i C och C++ med ESP-IDF och FreeRTOS.
Den hanterar miljömätningar med BME280, Wi-Fi-uppkoppling, HTTP-kommunikation med Glennergy, offline-cache av data, persistent konfiguration, tidssynkronisering, UART-diagnostik och ett touchscreen-gränssnitt med vyerna Home, Electricity, Weather, WiFi och Settings.
Mina personliga bidrag
Avgränsat från funktionalitet som utvecklats av teamet som helhet.
- Sensor-HAL och embedded-integration för BME280
- Integration och felsökning av delad I2C-buss tillsammans med touchscreen-delsystemet
- Sensorinitialisering, mätning, validering, felhantering och automatisk återhämtning
- UART-baserat diagnostik- och konfigurationsgränssnitt
- Händelsestyrd Wi-Fi-status och återanslutningslogik
- Persistent konfiguration med ESP-IDF NVS
- SNTP-baserad synkronisering av systemtid och integration av tidsstämplar
- Integration av FreeRTOS-tasks och köer, framför allt kring sensor- och diagnostikfunktionalitet
- Settings-funktionalitet för persistenta sensor- och serveruppdateringsintervall
- Teknisk dokumentation, arkitekturdiagram och utvecklingsdokumentation
- Design och vidareutveckling av ett AI-assisterat Doxygen-flöde med GitHub Actions och OpenAI API
- Granskning, validering och automatisk generering av draft pull requests i dokumentationsflödet
- Projektplanering och arbetsflödesdokumentation
- Projektpresentation tillsammans med den andra kärnutvecklaren
Sensor-HAL
Jag utvecklade och vidareutvecklade BME280-integrationen bakom ett separat sensor-HAL. HAL-lagret kapslar in I2C-konfiguration, enhetsinitialisering samt mätning av temperatur, luftfuktighet och lufttryck samtidigt som applikationsnivåns sensorhantering hålls separerad från hårdvarukommunikationen.
Den slutliga implementationen hanterar även praktiska felscenarier: misslyckade avläsningar registreras, I2C-diagnostik kan utföras efter kommunikationsproblem, sensorn kan markeras som otillgänglig efter upprepade fel och firmwaren försöker senare återinitialisera den. BME280 delar I2C-buss med touchscreen-hårdvaran, vilket gjorde bussintegration och felsökning till en viktig del av arbetet.
Vissa fotografier i denna fallstudie har redigerats lätt för bättre läsbarhet, bland annat genom minskade reflektioner samt justering av exponering och skärpa. Hårdvaran och gränssnittets innehåll är oförändrade.
UART-diagnostik
Jag utvecklade ett UART-baserat diagnostik- och konfigurationsgränssnitt med ESP-IDF:s UART-funktionalitet. Shell-gränssnittet ger runtime-vyer över systemstatus, sensorvärden och timestamps, rekommendationsdata, heap- och task-diagnostik samt aktuell konfiguration.
Det stödjer även validerade konfigurationskommandon för utvalda runtime-inställningar, där ändringar sparas persistent via NVS. Detta gav ett praktiskt sätt att inspektera och felsöka enheten utan att vara beroende av touchscreen-gränssnittet.
Wi-Fi, NVS & tid
Wi-Fi-hanteringen är händelsestyrd och skiljer mellan anslutning till en accesspunkt och att faktiskt ha fått en användbar IP-anslutning. Vid förlorad anslutning schemaläggs begränsade återanslutningsförsök i stället för att blockera event-callbacken, medan Wi-Fi-tasken utför själva återanslutningen.
Konfiguration sparas persistent med ESP-IDF NVS, inklusive Wi-Fi-uppgifter och runtime-intervall. Settings-gränssnittet kan ändra sensor- och serverintervall och spara dem utan att firmwaren behöver byggas om.
När nätverksanslutning har etablerats används SNTP för att synkronisera systemklockan. Monoton tid används fortsatt internt för beräkning av förfluten tid medan synkroniserad lokal tid kan visas för användaren.
Serverkommunikation & återhämtning
ESP32-klienten hämtar periodiskt rekommendations-, väder- och elprisdata från Glennergy-servern. En dedikerad FreeRTOS-task följer serverns hälsostatus separat från den normala datahämtningen och klassificerar anslutningen som connected, degraded eller unavailable beroende på resultatet.
FreeRTOS-köer som behåller det senaste värdet distribuerar dataset till användargränssnittet, medan SPIFFS-cache gör att tidigare mottagen information kan finnas tillgänglig under Wi-Fi-avbrott. Den nuvarande implementationen använder dessutom separata scheman för hälsokontroller och omförsök i stället för att koppla serverstatus direkt till resultatet från en enskild datahämtning.
Systemet i drift på hårdvaran
Vyer från den fysiska ESP32-S3-enheten.
Dokumentationsautomation
Jag designade och vidareutvecklade ett AI-assisterat dokumentationsflöde byggt kring Doxygen, GitHub Actions och OpenAI API. Projektspecifika regler definierar hur publika headers, implementationsfiler, FreeRTOS-tasks, callbacks och hårdvarurelaterad kod ska dokumenteras samtidigt som programlogiken uttryckligen skyddas från automatiska ändringar.
Flödet kan automatiskt behandla ändrade filer, genomföra djupare semantiska granskningar med ytterligare källkodskontext, göra riktade omförsök efter avvisade dokumentationsändringar, registrera valideringsresultat och skapa draft pull requests för mänsklig granskning. Systemet har utvecklats genom upprepad testning för att minska onödiga dokumentationsändringar samtidigt som felaktiga eller ofullständiga tekniska beskrivningar fångas.
Tekniska utmaningar
Flera delar av Glennergy krävde felsökning av problem som först blev synliga när separat utvecklade delsystem integrerades. Exempel var att dela en I2C-buss mellan touchscreen-stacken och BME280-sensorn, återhämta sig kontrollerat från sensorkommunikationsfel, samordna asynkrona Wi-Fi-händelser med FreeRTOS-tasklogik, behålla användbart systemtillstånd under nätverksavbrott och hålla de föränderliga HTTP-producent- och konsumentimplementationerna kompatibla.
Problemen tog projektet bortom isolerad modulutveckling och krävde resonemang kring delsystemsgränser, timing, feltillstånd och dataägarskap i miljöer för både inbyggda system och Linux.
Resultat & lärdomar
Det nuvarande systemet fungerar end-to-end: Linux-serverstacken är driftsatt på en VPS, medan ESP32-S3-klienten kör på den fysiska touchscreen-hårdvaran och kommunicerar med servern för att visa rekommendationer, elpriser och väderinformation tillsammans med lokala BME280-mätningar.
Projektet har gett mig praktisk erfarenhet av hårdvaruabstraktion, koordinering av FreeRTOS-tasks, nätverk, persistent konfiguration, Linux-tjänster, IPC, diagnostik och driftsättning. En av de viktigaste lärdomarna har varit att fungerande individuella moduler bara är en del av utveckling av inbyggda system — de svårare problemen uppstår ofta i gränserna mellan hårdvara, tasks, kommunikationslager och externa system.
- Linux-server driftsatt på VPS
- ESP32-S3 kör på fysisk hårdvara
- End-to-end-serverkommunikation
Glennergy på GitHub
Det publika Glennergy-ESP-repot innehåller firmware-källkoden, README, en illustrerad visuell användarguide och mer detaljerad teknisk dokumentation för den som vill utforska projektet vidare.