Rollback
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:
-
Configuration validation - Domain limits, setpoint sanity checks
-
Hysteresis protection - Prevents rapid state changes (300s delay)
-
Comfort deadband - Temperature activation thresholds (±0.5°C)
-
ECO deadband - Wider temperature band for energy savings (±1.0°C)
-
Stage 2 heating - Gradual power increase with delay + deviation logic
-
Stage 2 cooling - Gradual power increase with delay + deviation logic
-
Mutual exclusion - Heating and cooling never run simultaneously
-
Sensor failure safety - Automatic shutdown on sensor faults
-
Temperature units - Celsius and Fahrenheit conversion
-
Fan control - Pre-run (30s), post-run (60s), and manual override
-
Humidity control - Humidification and dehumidification with deadband
-
Hot water demand - On-demand hot water heating
-
Fan timing - Comprehensive pre-run and post-run validation
-
Hysteresis + HVAC - State change delays with fan coordination
-
Comfort deadband + HVAC - Temperature thresholds with fan safety
-
ECO deadband + HVAC - Energy-saving mode with fan coordination
-
Stage 2 heating + HVAC - Multi-stage heating with fan timing
-
Stage 2 cooling + HVAC - Multi-stage cooling with fan timing
-
Mutual exclusion + HVAC - No simultaneous operation through all fan phases
-
Sensor failure + HVAC - Immediate shutdown including fan (safety critical)
-
Open window detection - Detects rapid temperature drops, suspends heating to save energy
-
Open window false positive prevention - Validates gradual changes don’t trigger detection
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).