Hestia32 - Open Source Smart Thermostat

One of the goals of Hestia32 is to keep the hardware as open as the software. That means more than publishing the source files: it also means giving people meaningful choices when building the device.

The first Hestia32 designs use the Seeed XIAO ESP32-C5. I've now completed the HVAC and EU board designs using a generic 30-pin ESP32-C5 DevKit as well.

https://github.com/MakeOpenStuff/hestia32/tree/develop/pcb

Why support another board?

The XIAO is a good fit for a compact design, but it shouldn't be the only way to build Hestia32.

Some builders may prefer a generic development board, already have one available, or simply want to avoid depending on a particular module. Supporting both approaches makes the project more flexible and gives people another route to building their own thermostat.

Same functionality, different hardware

The generic DevKit variants are intended to offer the same functionality and feature set as their XIAO-based counterparts. The controller board changes, but the goal for the thermostat itself remains the same.

The attached render shows the EU version with the generic 30-pin ESP32-C5 DevKit installed. The HVAC version follows the same approach.

Keeping the project open

For me, open hardware should give people the freedom to inspect, modify, build and maintain a design without unnecessary vendor dependence. Supporting an alternative controller takes additional design work, but it's consistent with that goal.

These DevKit variants won't be included in the upcoming Crowd Supply campaign. I'm still exploring how best to make them available afterwards, potentially as bare boards.

The main crowdfunding campaign remains planned for the primary Hestia32 variants.

You can follow the project and subscribe for launch updates here:

https://www.crowdsupply.com/makeopenstuff/hestia32

More development updates as the hardware and user interface continue to evolve.

One of the interesting transitions in an open hardware project is moving from a working prototype to something that can actually be manufactured consistently.

I've reached that stage with Hestia32.

I'm happy to share that Hestia32 is now working with Seeed Studio on bringing the hardware toward production.

There isn't a finalized production agreement yet, but we've been working through the practical manufacturing side of the project.

Optimizing the BOM

The prototype BOM isn't necessarily the right BOM for production.

We've been reviewing the component selection and optimizing the BOM with production costs, availability and manufacturing in mind.

This is one of those parts of hardware development that isn't particularly exciting to look at, but it has a major effect on whether a design is viable beyond a handful of prototypes.

Production quantities

We're currently discussing an initial inventory level in the 100-200 unit range.

That gives us a realistic starting point without immediately committing to a large production run.

We're also discussing larger enclosure production runs, including the possibility of around 500 units.

Enclosure production

The enclosure is another part of the design we're working through with production in mind.

In addition to the current 3D-printed enclosure approach, we're looking at production options including two-colour enclosures.

I'll share more about the enclosure once there is something tangible to show.

What's next?

The longer-term plan is to work with Seeed through its Co-Create/Bazaar ecosystem, making Hestia32 available beyond the initial crowdfunding campaign.

For now, though, the planned first step is Crowd Supply.

If you'd like to follow Hestia32 and get notified when the campaign moves forward:

Hestia32 on Crowd Supply

There's still plenty to do before production, but this is an important milestone: the project is moving from designing and validating hardware toward figuring out how to make it available to other people.

During testing of the previous Hestia32 XIAO HVAC PCB, I found an unexpected problem: the SHT45 temperature sensor was consistently reading around 6-7°F higher than the actual ambient temperature after the board had been running for a while.

The cause turned out to be heat traveling through the PCB copper planes from other components towards the sensor.

For the next revision, I removed the copper fill around the sensor and added two L-shaped slots to create an air gap around that section of the PCB. I kept two narrow bridges: one carries the sensor connections while also providing mechanical support, while the other is purely structural.

I then tested the two revisions side by side on a 10 cm thick styrofoam "wall", powered from the same 24V AC source and connected to Wi-Fi. The displays were deliberately left on continuously to maximise power consumption and therefore heat generation.

After two hours:

• Old v1.5: 87.2°F
• New v1.6: 83.9°F
• Reference thermometer: 83.8°F

That reduced the measured temperature error from +3.4°F to +0.1°F, or roughly a 97% reduction.

A thermal camera made the difference particularly obvious. On v1.5, the copper fill creates a visible thermal path towards the sensor. On v1.6, the copper-free area and PCB slots substantially isolate the sensor from the rest of the board.

There is still more validation to do, but the new design is behaving much closer to what I want: the sensor measures the environment rather than the PCB.

Next up: continued hardware validation and the touchscreen UI.