Following a similar sprint two month ago, we had another small KDE Eco meeting in Berlin a week ago. Joseph will probably write a more comprehensive summary like last time, here are just some of the things I looked at and/or worked on.

External energy measurements

Trying to get more useful energy measurement data out of the cheap WiFi power-plugs hit a roadblock unfortunately, as two of those devices ended up no longer responding after triggering a firmware reset.

This seems to happen with newer Tasmota firmware versions when doing the 40sec button press reset. That step can be necessary to make the device forget a previous WiFi configuration, e.g. when wanting it to connect to a different network.

Fortunately there are ways to recover the devices from that state. They have an accessible serial port on the inside which can be used for re-flashing the firmware as well, we just didn’t have the right adapter around.

Photo of an opened Gosund SP111 WiFi power plug showing a circuit board with an accessible serial port.
Opened Gosund SP111 WiFi power plug, serial port in the top right.


Much more successful was the debugging session with Alexander Semke, to resolve the issues we encountered during the last sprint when trying to read the energy measurement data with LabPlot.

This ended quickly with a small four-line fix, and a perfectly fine working LabPlot.

Trying to replicate Alexander’s nice RAPL-based energy measurement demo however then hit the problem that the RAPL interface on my new laptop isn’t compatible with pinpoint yet (the following screenshot is therefore from Alexander).

Screenshot of LabPlot, showing a real-time plot of CPU load as well as CPU/RAM/GPU energy use over time.
LabPlot real-time plot of CPU load and CPU/RAM/GPU energy consumption over time.

The goal of this is to gain a better understanding on how various operations impact energy use, and how that is distributed between the different components of a computer.

Rescheduling software updates

Reducing energy consumption of software is of course the best possible outcome, but there are limits to that. It’s therefore also worth looking at scheduling operations that don’t necessarily have to happen at a specific point in time in a way to optimize for CO₂ emissions.

This needs knowledge about how the energy is produced at your location though, and a forecast for how the production mix is expected to change in the short term future. This information is available from many national or sub-national entities, and there are existing efforts to aggregate that globally, such as The Green Web Foundations’s grid-intensity tool or the data collection scripts of Electricity Maps. Ideally we as KDE can attach to those.

One possible operation that could then be scheduled based on this are software updates. That isn’t an entirely new idea, apparently Microsoft is looking at that as well for Windows updates.


If you are interested in making our software more sustainable and want to collaborate or contribute to this, check out KDE Eco’s get involved page.