Happy New Year! We’ve made significant progress on the Hestia32 - New model? project, our next-generation ESP32-based thermostat controller. Here’s where we stand:
Hardware Components:
ESP32-C5 microcontroller
IPS 3.5" touchscreen display (SPI with ILI9488)
Key Features:
MQTT over WiFi (both 2.4 and 5GHz)
Zigbee
Matter over WiFi
Matter over Thread
LVGL-based touch UI for smooth, responsive interface
Firmware updates with rollback protection
We’re currently focusing on display optimization and sensor integration. The platform maintains the simplicity HestiaPi users expect while offering flexibility for different use cases.
As this will be a client-based approach, an existing (agnostic) smart home server will be expected, while keeping full offline functionality as a standalone thermostat alone.
Looking forward to hearing your thoughts on feature priorities and what you’d like to see supported!
The key features outlined in the original post seem like more than enough as far as I’m concerned. I don’t really want or need most of that, but as long as I can disable them (or at a minimum the Zigbee radio), it’s cool.
Rollback protection
I’d like to request that there be some way to roll back to old versions of the firmware. I’ve been bitten too many times where an update causes some feature to break, or it gets removed, or something like that and I can’t go back to the version I liked because of anti-downgrade "protection”. I understand the motivation for such restrictions, but in my experience it’s caused far more problems than it’s prevented.
I think an acceptable compromise would be to allow wiping+flashing an old version onto the device. This allows people to run the firmware version they want, while giving people are concerned that an attacker will downgrade the firmware on their thermostat and steal/abuse their MQTT credentials.
Initial setup
I want the initial setup to be as easy as it is with the HestiaPi ONE.
I mention this because it’s been on my mind lately in that I’m not sure how I’m going to make the UI for the ONE connect to another server. Maybe a customized version of the turnkey project (which seems like it’s abandoned at this point anyway)? I dunno, but I wanted to mention it because ease of use is a strong point of this project and I want to make sure that remains to be the case with future versions that add features.
Random thought
It might be cool to have an option to couple this with a Raspberry Pi 4 that can run the home automation software of the user’s choice (all in one case). That could help the people who want to just plug and play and get all the smart thermostat features.
I like the idea of having an “All in One” option though, off the cuff I would also recommend the option of selling a companion central server with the client(s). That could be helpful when having many thermostats.
There will be no rollback protection. In fact the ESP holds 2 partitions for firmware. One is the active one that currently runs. Any new firmware will be stored in the second one and if it succeeds in booting into, it will be marked as the new active and will be used in following reboots. This allows peace of mind for possible bricking as it will “automatically“ go back to last good-known-working version. Remember this will be fully open source and open hardware, encouraging users to fork and tweak the code to their liking so we made sure it will be “brick-safe“.
Also a factory settings feature (keep a special button pressed for some seconds on boot) will erase all settings and boot into a clean firmware if a user tweaked it too much
Features
As there will probably be no immediate app for now, all configuration and features will be available on the screen to enable/disable at will. If firmware grows too large to fit all WiFi, Zigbee and Matter in the same file, we may distribute separate firmware to flash whichever is needed.
We have already started developing the main thermostat logic in a private repo till there is a prototype or BoM for others to play with. Here are some of the features that are 100% developed and tested:
As we have wasted too much time testing on the touchscreen the various scenarios, the above logic is split from the main firmware (that is hardware-related) and can be compiled and run on any PC with gcc compiler. The reason behind that is that we developed tests for each feature and we can run all of them in a seconds simulating input parameters (settings stored, setpoints set, sensor values, elapsed time) and confirmed expected with actual output. If something fails, code is fixed on the same PC. The fixed code is then imported into the firmware. This saves so much time!!!
Initial setup
Almost identical UI from “turnkey” is already developed. If WiFi credentials are correct it reboots into main UI. If not, it reboots again into provisioning Access Point to repeat. As this is an ESP, either of these scenarios are instant (boots in 2 seconds)
Instant support
What you mention is called discovery and is already in our specifications so that OpenHAB and HomeAssistant pickup what this new device (Hestia32) supports and prepare the UI with ALL needed elements in ONE step. This is important and will be in the MVP!
Not sure if it will make sense (commercially) to bundle it with a Pi 4 with an SD pre-flashed to one of the home automation… I mean it could simply be an SD image to download. Where is the added value to pre-flash an SD card and resell a Pi with a case and a power supply? Anyone can do that on their own to avoid paying us do it for them. Unless you are talking about putting a full Pi 4 inside the case of the Hestia32 which is going to be a huge case on your wall that generates too much heat to get accurate readings and requires a much bigger power supply. I think we’ve reached a point where “everyone“ has a smart home server. Either in their house local or the cloud (Google, Apple, Alexa).
