E‑paper dashboard med ESP32, PHP og live data

Et fysisk status­das­h­bo­ard, der samler kalen­der, vejr, tempe­ra­tur­må­lin­ger, benzin­pris, dato og klok­keslæt på en 7.5″ tricolor e‑pa­per-skærm.

Projek­tet under­sø­ger, hvor­dan hver­dags­data kan vises på et roligt, fysisk display frem for i endnu en app, brow­ser eller noti­fi­ka­tions­strøm. Løsnin­gen kombi­ne­rer en ESP32 med en PHP-back­end, der henter og forenk­ler data fra blandt andet Google Kalen­der, MET/​Yr og OK’s benzin­pri­ser. ESP32’en modta­ger små JSON-feeds, holder styr på tid og opda­te­rer e‑pa­per-displayet med både full refresh og partial updates.

Hvorfor projektet er interessant

Projek­tet er inter­es­sant, fordi det ikke primært hand­ler om at bygge en vejr­sta­tion eller tilslutte en skærm til en micro­con­trol­ler. Det hand­ler om at gøre digi­tale hver­dags­data tilgæn­ge­lige i et fysisk format, der opfø­rer sig ander­le­des end almin­de­lige skærme.

E‑paper er lang­somt, har begræn­sede farver og kræver omtanke ved opda­te­ring. Til gengæld kan det stå fremme uden baggrunds­lys, uden anima­tio­ner og uden hele tiden at kræve opmærk­som­hed. Det gør tekno­lo­gien veleg­net til infor­ma­tion, der skal være synlig, men ikke påtræn­gende: dagens afta­ler, vejr­ud­sig­ten, tempe­ra­tu­rer og andre små beslutningsdata.

Projek­tet blev derfor en under­sø­gelse af, hvor­dan man desig­ner et embed­ded infor­ma­tions­dis­play, hvor data­kil­der, display­lo­gik, hukom­mel­ses­be­græns­nin­ger og brugero­p­le­velse skal fungere sammen.

Forarbejde og udviklingsproces

Mange af mine projek­ter star­ter som en undren. Kan man egentlig? 
Derfor har jeg som regel en lille ESP32 med en skærm, som jeg hurtigt kan kode. Skær­men har den fordel at jeg hurtigt kan se et eller anden output. Så undrede jeg mig omkring noget data. Kan jeg hente data fra hjem­mesi­der. Kan jeg hente den aktu­elle tempe­ra­tur, et eller andet sted fra. Og så var det året hvor benzin­pri­serne blev meget opad og ned ad. Kan man læse den aktu­elle stan­der­pris, og så den vist på en ardu­ino? Hvorda?. Osv.  Små projek­ter som bliver til som tanker, o bygges hurtigt på en lille bitte esp32 med skærm. 

Så dette projekt bygger videre på tidli­gere ekspe­ri­men­ter med de små ESP32-base­rede displays. Før arbej­det med det store 7.5″ e‑pa­per-dash­bo­ard lavede jeg mindre modu­ler til en lille ESP32-C6-skærm, som jeg ofte havde med mig. Den funge­rede som et mobilt test­miljø, hvor jeg kunne afprøve enkelte dele af idéen i mindre skala: visning af data, opda­te­rings­lo­gik, små infor­ma­tions­fel­ter og samspil­let mellem netværks­data og embed­ded hardware.

Det større dash­bo­ard samler disse erfa­rin­ger i et mere komplekst system. Fokus ligger derfor ikke primært på elek­tro­nik eller grafisk design, men på data­hent­ning, data­be­hand­ling og visning på begræn­set hardware.

Under­vejs blev projek­tet bygget op modul for modul. WiFi, tid, display, sensor­data, vejr, kalen­der og benzin­pris blev testet hver for sig, før de blev samlet i ét dash­bo­ard. Det gjorde det muligt at finde fejl i række­føl­gen mellem display­buf­fer, HTTP-kald, JSON-parsing og e‑pa­per-rende­ring.

Hvad blev konkret udviklet?

Løsnin­gen består af en ESP32, et 7.5″ tricolor e‑pa­per-display og en PHP-back­end på en webserver.

ESP32’en hånd­te­rer WiFi, tids­sty­ring via NTP, data­hent­ning, JSON-parsing og rende­ring på e‑pa­per-displayet. Den viser blandt andet tempe­ra­tur fra to senso­rer, aktuel benzin­pris, dato og klok­keslæt, syv dages vejr­ud­sigt og en syv-dages kalen­der­over­sigt med hellig­dage og fødselsdage.

PHP-back­en­den funge­rer som mellem­led mellem ESP32’en og de eksterne data­kil­der. Den henter og forenk­ler data fra Google Kalen­der, MET/​Yr og OK’s benzin­pri­ser og leve­rer dem som små JSON-feeds. På den måde skal ESP32’en ikke selv hånd­tere store API-svar, OAuth-flow, refresh tokens eller komplekse datamodeller.

Den arbejds­de­ling er central for projek­tet: webser­ve­ren hånd­te­rer de tunge og følsomme inte­gra­tio­ner, mens ESP32’en hånd­te­rer den lokale, fysi­ske visning.

Google Kalender

Kalen­der­de­len krævede mere end bare et API-kald. Jeg satte en Google Cloud-inte­gra­tion op med OAuth, Calen­dar API, redi­rect URI, test­bru­ger og calendar.readonly-adgang. Først godken­des adgan­gen via en brow­ser, hvor­ef­ter serve­ren gemmer et refresh token i en privat mappe uden­for web-roden.

Når dash­bo­ar­det skal bruge kalen­der­data, er det derfor ikke ESP32’en, der taler direkte med Google. PHP-back­en­den bruger refresh token til at hente et access token, læser kalen­de­ren via Google Calen­dar API og omsæt­ter afta­ler, hellig­dage og heldags­af­ta­ler til et lille syvda­ges JSON-feed, som ESP32’en kan parse.

Vejrdata som eget JSON-feed

Vejr­data kommer fra MET/​Yr, men ESP32’en henter ikke det rå vejr-API direkte. Det rå svar er for stort og for komplekst til, at det giver mening på micro­con­trol­le­ren. I stedet henter PHP-back­en­den vejr­data for Grevinge, cacher svaret og omsæt­ter time­se­ries-data til syv enkle dagsposter.

Det JSON-feed, ESP32’en modta­ger, inde­hol­der kun de felter, dash­bo­ar­det skal vise: ugedag, vejr­tekst, dagtem­pe­ra­tur, nattem­pe­ra­tur, regn, vindstyrke og vindret­ning. På den måde bliver det store vejr-API redu­ce­ret til et format, der passer til både skær­mens layout og ESP32’ens hukommelse.

Benzinpris som eget JSON-feed

Benzin­pri­sen hentes også gennem en PHP-back­end. Serve­ren kalder OK’s brænd­stof­data, finder de rele­vante statio­ner og laver et mindre JSON-svar med blandt andet stations­navn, opda­te­rings­tids­punkt og pris for Blyfri 95.

ESP32’en skal derfor ikke kende OK’s fulde data­struk­tur. Den leder kun efter statio­nen Grevinge og feltet for price_​blyfri_​95, hvor­ef­ter prisen kan vises og kun opda­te­res på skær­men, hvis den faktisk har ændret sig.

Data som materiale

En vigtig del af projek­tet har været arbej­det med at hente data ind fra forskel­lige kilder og gøre dem brug­bare i et person­ligt fysisk inter­face. Det har været inter­es­sant at arbejde med forskel­lige API’er, data­for­ma­ter og meto­der til at hente infor­ma­tion udefra — og deref­ter kombi­nere disse data med egne sensor­data og interne aftaler.

Projek­tet viser på den måde en form for prak­tisk data­kon­trol: mulig­he­den for at trække data fra verden ind i egne projek­ter, bear­bejde dem og vise dem præcis i det format, der giver mening i den konkrete hver­dag. Vejr, benzin­pri­ser og kalen­der­af­ta­ler er ikke bare sepa­rate servi­ces; de bliver omsat til et samlet over­blik, hvor eksterne forhold, fami­li­ens planer og egne målin­ger vises side om side.

Kalen­der­de­len er et godt eksem­pel. Fami­lien kan bruge en almin­de­lig delt kalen­der og invi­tere eller oprette afta­ler dér, hvor de alle­rede arbej­der. Dash­bo­ar­det henter deref­ter kalen­der­data og viser dem i et fast, fysisk display sammen med vejr, tempe­ra­tu­rer og andre status­data. På den måde bliver både ydre påvirk­nin­ger og interne afta­ler samlet i ét over­blik, vist på den måde jeg selv har brug for.

Valg af skærm og platform

Valget af en 7.5″ tricolor e‑pa­per-skærm var et kompro­mis mellem læsbar­hed, fysisk stør­relse, strøm­for­brug, pris og teknisk komplek­si­tet. En mindre skærm ville være billi­gere og lettere at arbejde med, men ville hurtigt gøre dash­bo­ar­det for kompakt. En større e‑pa­per-skærm ville give mere plads, men også øge kravene til billed­buf­fers, hukom­melse, opda­te­rings­tid og fysisk indbygning.

7.5″ blev derfor et prak­tisk mellem­for­mat: stort nok til at vise kalen­der, vejr, tempe­ra­tu­rer, benzin­pris og ur samti­dig, men uden at projek­tet blev flyt­tet op i en helt anden pris- og størrelsesklasse.

Skær­men er ikke valgt som fuld­farve-display, fordi projek­tets formål ikke er at vise bille­der, video eller en tradi­tio­nel grafisk bruger­flade. Den begræn­sede farve­pa­lette passer bedre til et status­dis­play, hvor farve bruges selek­tivt til struk­tur og frem­hæ­velse. Sort bruges til hove­d­in­for­ma­tion, hvid til baggrund og rød til marke­rin­ger som dato, over­skrif­ter og særlige kalenderfelter.

ESP32 blev valgt frem for Raspberry Pi, fordi projek­tet skulle være et embed­ded dash­bo­ard og ikke en lille compu­ter med opera­tiv­sy­stem. En Raspberry Pi ville give mere proces­sor­kraft, men også højere strøm­for­brug, længere opstart­s­tid og mere system­ved­li­ge­hol­delse. ESP32’en passer bedre til et device med én tyde­lig opgave: forbinde til WiFi, hente små JSON-feeds, holde styr på tid og opda­tere et e‑pa­per-display.

Grafik på displayet

Grafik­ken på dash­bo­ar­det er ikke lavet som færdige bille­der, der bare vises på skær­men. Layou­tet bliver tegnet direkte i firmwa­ren med tekst, linjer, felter og simple grafi­ske former. Det gælder også vejr-ikonerne, som tegnes som sol, sky, regn, sne, tåge eller torden ud fra vejrteksten.

Kalen­de­ren tegnes på samme måde i faste dagsko­lon­ner. Hellig­dage får rød marke­ring, afta­ler bliver ombrudt eller afkor­tet, og fødsels­dage får et lille Danne­brog, som også tegnes direkte i koden. Det gør grafik­ken tæt koblet til de data, der kommer ind, i stedet for at være stati­ske billeder.

Faktaboks:

• 7.5″ tricolor e‑pa­per-dash­bo­ard med ESP32.
• Viser kalen­der, vejr, tempe­ra­tu­rer, benzin­pris, dato og klokkeslæt.
• PHP-back­end forenk­ler data fra Google Kalen­der, MET/​Yr og OK.
• JSON-feeds er tilpas­set begræn­set embed­ded hardware.
• Projek­tet er bygget op modul­vist med fysisk test på hardware.

Udfordringer og læring

En central udfor­dring var at få flere forskel­lige data­kil­der til at fungere sammen i ét stabilt display. Det hand­lede både om eksterne servi­ces, egne sensor­data, kalen­der­data, tids­sty­ring og e‑pa­per-display­ets særlige opdateringsmønster.

Kalen­der­de­len var særligt kompleks, fordi Google Calen­dar kræver OAuth, refresh tokens og en data­struk­tur, som er for tung til at hånd­tere direkte på ESP32’en. Derfor blev kalen­derin­te­gra­tion place­ret på webser­ve­ren, mens ESP32’en kun modtog et forenk­let syvda­ges JSON-feed.

E‑pa­per-displayet gav også særlige udfor­drin­ger. Full refresh er lang­somt, mens partial upda­tes skal bruges forsig­tigt, så gamle tekst­om­rå­der ryddes korrekt. Samti­dig kræver tricolor-displayet særskilt hånd­te­ring af sort/​hvid og rød visning.

Projek­tet gav især erfa­ring med at placere komplek­si­tet det rigtige sted i syste­met: API-kald, OAuth og data­be­hand­ling på serve­ren; timing, lokal status og visning på ESP32’en.

Arbejde med AI

Projek­tet blev udvik­let i samspil med AI-værk­tø­jer som Chat­GPT og Codex. AI blev brugt som teknisk spar­rings­part­ner til at struk­tu­rere kode, fore­slå modul­op­de­ling, gennemgå fejl, skrive doku­men­ta­tion og fast­holde over­blik undervejs.

Det afgø­rende arbejde fore­gik dog stadig gennem test på fysisk hardware. Hver løsning skulle uplo­a­des, afprø­ves, vurde­res og juste­res. AI funge­rede derfor ikke som erstat­ning for hardwa­re­ar­bej­det, men som et værk­tøj til at holde projek­tet opdelt i mindre, kontrol­ler­bare trin.

Perspektivering

Projek­tet peger på en type digi­talt inter­face med en anden logik end mobi­len og compu­te­ren. Når infor­ma­tion hænger fast på væggen eller står fremme som et fysisk display, bliver den opfat­tet og brugt ander­le­des end data, man først skal finde frem i forskel­lige apps. Det faste display gør infor­ma­tio­nen lettere tilgæn­ge­lig i situ­a­tio­nen: man kan stille sig hen foran det og få et samlet over­blik uden at åbne kalen­der, vejr­ud­sigt, sensor­data og andre tjene­ster hver for sig.

I stedet for at efter­ligne mobi­lens inter­ak­tion med scrol­ling, noti­fi­ka­tio­ner og navi­ga­tion mellem apps bruger projek­tet e‑paper som et roligt fysisk medie til data, der skal være synlige, men ikke påtrængende.

For mig er projek­tet inter­es­sant, fordi det samler flere faglige spor: embed­ded proto­ty­ping, data­in­te­gra­tion, back­end­struk­tur, infor­ma­tions­de­sign og fysisk visning. Det er et projekt, hvor brugero­p­le­vel­sen ikke kun ligger i layou­tet på skær­men, men også i valget af tekno­logi, opda­te­rings­rytme, data­mængde og systemarkitektur.