Hoeveel stroom slurpt mijn werklaptop eigenlijk? Een meetproject met slimme stekkers, Python en MySQL

Mijn werklaptop is een HP EliteBook 860 G10 met een i7, 16 GB RAM en een 16-inch scherm. Thuis hangt hij aan een HP USB-C Dock G5 met drie 4K-monitoren op volle resolutie. Als data-analist werk ik zo erg prettig. Onderweg is het een ander verhaal: na twee uur werken staat de accu nog maar op zo’n 15%. Volgens de servicedesk is dat normaal, en het advies was om vooral aan de lader of het dock te werken.

Ik wilde het accuprobleem niet oplossen. Ik werd wel nieuwsgierig: hoeveel stroom gebruikt deze opstelling nou echt? En als data-analist neem ik geen genoegen met een schatting. Ik wilde metingen, de hele dag door, automatisch opgeslagen in een database. Daarna wilde ik er visualisaties van maken.

Het plan: laptop en dock apart meten

Het doel was om het verbruik van de laptop en het dock los van elkaar te kunnen bekijken. De monitoren waren een leuke extra. Het oorspronkelijke idee bestond uit twee meetpunten:

• Een slimme stekker met energiemeting tussen het stopcontact en de voedingsadapter van het dock.
• Een USB-C-doorvoermeter (de FNIRSI FNB58) tussen het dock en de laptop, om het laptopverbruik direct te meten.

Een Mac mini die toch altijd aanstaat zou de metingen verzamelen en opslaan in MySQL. Daarna zou de data naar mijn website gaan.

Uitdaging 1: die USB-C-meter gaat niet werken

Gelukkig heb ik dit nagevraagd voordat ik iets bestelde. Over de USB-C-kabel tussen dock en laptop gaat niet alleen stroom. Ook de beeldsignalen voor de drie 4K-schermen lopen erdoorheen, via DisplayPort Alt Mode. Een betaalbare USB-C-tester zoals de FNB58 geeft alleen de stroom en de trage USB 2.0-datalijnen door. De snelle lanes voor beeld ontbreken. Met zo’n meter ertussen blijven je schermen dus vrijwel zeker zwart.

Testers die dit wel aankunnen zijn professionele Thunderbolt/USB4-analyzers van honderden tot duizenden euro’s. Voor een hobbyproject is dat veel te veel. De FNB58 viel dus af. Ik moest een slimmere manier vinden om het laptopverbruik te bepalen.

Uitdaging 2: de slimme stekker was niet leverbaar

Mijn eerste keus was de Shelly Plus Plug S. Die heeft een lokale API, dus geen cloud en geen account nodig. Hij was alleen nergens op voorraad. Ik ben daarom tijdelijk overgestapt op de TP-Link Tapo P110 en de scripts zijn daarop aangepast. Uiteindelijk vond ik een 4-pack van de Shelly Plug M Gen3: dezelfde lokale API, een kleinere behuizing en goedkoper. Daarmee kan ik het dock en alle drie de monitoren meten. Toen ben ik weer teruggegaan naar Shelly.

De les: houd je code los van de hardware. Omdat elke meting in de database alleen een source-label krijgt (dock, monitor_1, enzovoort), was wisselen van stekker vooral een kwestie van één collector-script vervangen.

Het laptopverbruik toch bepalen: twee methodes

Zonder fysieke meter tussen dock en laptop gebruik ik twee indirecte methodes. Ze draaien allebei mee, zodat ik ze kan vergelijken.

De subtractiemethode. Eerst meet ik hoeveel het dock verbruikt zonder laptop, met toetsenbord, muis en netwerkkabel gewoon aangesloten. Dat is de nullast. Een script trekt die nullast doorlopend af van het totale dockverbruik. Wat overblijft is een schatting van wat de laptop trekt.

De WMI-batterijsensor. Windows houdt via de accuchip bij hoeveel vermogen er de accu in of uit gaat. Een klein Python-script op de laptop leest dat uit en stuurt het door. Dat werkt ook onderweg. Er is wel een belangrijke kanttekening: zodra de accu vol is en de laptop aan de lader hangt, geeft deze sensor 0 W. De laptop verbruikt dan nog steeds stroom, maar die gaat niet via de accu. Deze methode laat dus vooral zien hoe de accu zich gedraagt. Ze vervangt geen totaalmeting.

Van stekker tot dashboard

De dataflow ziet er zo uit:

1. De Shelly-stekker meet continu het vermogen.
2. Een Python-script op de Mac mini vraagt dat elke 10 seconden op via de lokale API en schrijft het weg in een MySQL-database.
3. Een tweede script berekent de laptopschatting (dockvermogen min nullast).
4. Een derde script stuurt nieuwe metingen elke 5 minuten naar een beveiligd endpoint op mijn WordPress-site.
5. WordPress slaat de data op en toont grafieken op een privépagina die alleen ik als beheerder kan zien.

Het mooie: er is geen inkomend verkeer naar mijn thuisnetwerk nodig. Eerder in een ander project had ik juist veel gedoe met het openzetten van MySQL naar buiten, met poorten, IPv6 en firewalls. Nu praat de Mac mini alleen naar buiten, naar mijn eigen website. Niemand kan van buitenaf bij mijn database.

Kleine valkuilen onderweg

Een paar dingen die ik geleerd heb:

• Kalibreer met het echte apparaat. Mijn eerste test deed ik met een willekeurige lader in de stekker. Die nullast zegt natuurlijk niets over het dock, dus die kalibratie moest opnieuw.
• DELETE in plaats van TRUNCATE. Bij het opruimen van testdata reset TRUNCATE de ID-teller. Mijn scripts onthouden tot welk ID ze al verwerkt hebben, dus dan zouden ze alle nieuwe metingen overslaan.
• Tijdzones. Als MySQL en de Mac een andere tijdzone gebruiken, lijken er geen recente metingen te zijn terwijl ze er wel staan.
• Een onschuldige waarschuwing. De macOS-Python geeft een melding over urllib3 en LibreSSL. Die kun je hier negeren; het script werkt gewoon.

De eerste resultaten

[Vul hier je eerste bevindingen in, bijvoorbeeld: de nullast van het dock, het gemiddelde verbruik van de laptop tijdens werkdagen, pieken bij zware Python- of Power BI-taken, het verbruik van de drie monitoren en wat dit per jaar in kWh en euro’s betekent.]

Wat nu?

De metingen lopen. De volgende stap is analyseren: hoe ziet een typische werkdag eruit, hoeveel van het verbruik komt door de monitoren, en hoe goed sluiten de subtractiemethode en de accusensor op elkaar aan? Daarover volgt een vervolgpost.