Apocalypse nerding #2: OpenTheWindowCaller

Heatwaves are becoming increasingly difficult to manage, and I realized I needed a more precise way to measure the temperature in my apartment than my usual scale of “how many dehydrated tears I cry at night.”

Time to engineer a thermal management system!

Hardware engineering (aka: shopping)

A friend recommended some Zigbee temperature and humidity sensors from AliExpress. I didn’t want to buy a Zigbee-to-BLE gateway, nor install any random smartphone app. All I really wanted was an alarm that would wake me up when it was time to open the windows during the night.

The sensors are based on TI CC2530, according to this teardown, and complies with Zigbee standard, so it is possible to make a custom Zigbee-to-BLE gateway. The sensor chip is a Sensirion SHT40, the board has a kind of lump to keep the sensor away from electronics-generated heat, as seen in this other teardown.

While unsuccessfully trying to set up the build system for a Nordic Thingy:91, I remembered that I owned a board with nRF52, a buzzer, RGB LEDs and even its own thermal sensor, which was perfect for my application.

The board is called CoffeeCaller, I got mine at OSS2025 after harassing the board designer, and it is an open-hardware nRF52-based dev kit in the shape of a coffee cup (as presented here).

It was a good opportunity to try flashing the nRF52 with my $20 FTDI2232 board and OpenOCD, which turned out to work really well. The trick is to use a 270 Ω resistor to hack two FTDI push-pull-only GPIOs into a tri-state one, because SWD requires a tri-state IO line. The complete hack is detailed here.

I also occasionally use Black Magic Probe on STM32F103 eval kits as cheap probes, but the nice thing with this FTDI is that you do not need to flash any firmware to it.

Software engineering (aka: asking Claude)

Once the hardware part was done, I asked my boyfriend for some Claude tokens to develop the firmware. It wasn’t just laziness; I just could not have pulled off the Zigbee communication with the temperature sensors without it.

Vibe coding is not the only dubious thing about this project. It turns out that the Nordic Zigbee stack, based on a proprietary blob named ZBOSS, is implemented in Nordic NCS v2.8.0 (Zephyr 3.7.99) and was removed from newer NCS releases.

The Zigbee and BLE communication was the hard part. The application itself is quite straighforward, it has:

• An alarm to warn when the outside temperature finally drops lower than inside,
• A button to disable said alarm,
• An LED changing color if the temperature is fresher outside than inside,
• A BLE Environment Sensing profile to read the temperature and humidity values from a smarphone

By chance, I have lots of heatwaves planned this summer to test my prototypes and refine its behaviour.

The project repository is here: https://github.com/everedero/CoffeeCaller/tree/temperature/applications/zigbee_temp

Then, with plenty of sleepless nights still ahead of me, I started wondering about the carbon footprint of the project.

Babbling about Claude’s carbon footprint

I really wanted to know what the carbon footprint of developing this embedded application with an agentic LLM was.

First I found a very nice-looking plugin: https://github.com/gwittebolle/claude-carbon, but I was told that installing Claude plugins was too much of a security risk. So instead I read the README and did a similar computation.

First, we need some numbers, taken from a reseach paper here: https://arxiv.org/abs/2505.09598

Not all models are created equal so we apply a coefficient:

Also, agentic LLMs use caches to not recompute everything every time. It has cache-creation tokens that we count as inputs, and cache-read tokens that only cost a fraction of inputs (here we say 1/10, I have no fancy paper to justify this, but people do 1/8 or 1/10).

The tokens per model and type can be retrieved in .claude in the local folder. I had Claude write a Python script to parse its data.

input_tokens: 153,754
output_tokens: 977,774
cache_creation_input_tokens: 3,781,718
cache_read_input_tokens: 105,842,653
total tokens: 110,755,899
by model:

claude-haiku-4-5-20251001:
input_tokens: 10,995
output_tokens: 35,981
cache_creation_input_tokens: 347,815
cache_read_input_tokens: 7,893,000
total: 8,287,791
claude-opus-4-8:
input_tokens: 15,219
output_tokens: 130,155
cache_creation_input_tokens: 245,769
cache_read_input_tokens: 7,523,608
total: 7,914,751
claude-sonnet-4-6:
input_tokens: 702
output_tokens: 366,911
cache_creation_input_tokens: 755,367
cache_read_input_tokens: 37,203,591
total: 38,326,571
claude-sonnet-5:
input_tokens: 126,838
output_tokens: 444,727
cache_creation_input_tokens: 2,432,767
cache_read_input_tokens: 53,222,454
total: 56,226,786
estimated carbon footprint total: 1,484.3 gCO2e

So I produced 1.5 kg of CO2 equivalent (CO₂e).

In order to make sense of this, let’s find some interesting comparisons in https://www.carbonfootprintof.com/:

• 37 hours of watching video streaming
• 3 km by plane

But wait! What about the hardware?

It would seem that a custom PCB board + vibe-coded firmware (1.4 kg + 1.4 kg) is approximately the same carbon impact as buying the off-the-shelf solution (between 2 and 8 kg). That is, if you conveniently forget that you usually have to order 5 boards, not 1. And, if you already have the hardware, it is more interesting to use it instead of buying new, even if you have to involve Claude.

My takeaways

From a carbon-footprint perspective, is using Claude a disaster?

I still have no idea, but crunching the numbers helped me put things in perspective. My whole weekend project, shopping gizmos in China and vibe-coding included, is less than a steak or 30 km by (gasoline) car.

This is not counting all the other environmental side-effects of the AI race right now, like water, land use, etc. But on an individual level, my Claude usage is probably not the biggest contributor to my carbon footprint.

If in doubt about carbon footprints, you can play the least fun online game ever made: https://nosgestesclimat.fr/en/empreinte-carbone